How difficult is to decompile C++ file?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
3
down vote

favorite












I am writing an Android app with AES encryption and I am going to save AES key as a string to a C++ file with extension .cpp.



I am also going to create an iOS app which will use the same AES key. Is it possible to save the key in C++ file in iOS?
How difficult would it be to decompile the C++ file and read the key?



Here is the C++ file from Android:



#include <jni.h>
#include <string>

extern "C"
JNIEXPORT jstring JNICALL
Java_com_android_app_aesKeyFromJNI(JNIEnv *env, jobject /* this */)
std::string secret = "somesecretkey";
return env->NewStringUTF(secret.c_str());










share|improve this question









New contributor




Daniel Foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 2




    A plain ascii string is anything but secret.
    – joxeankoret
    2 hours ago














up vote
3
down vote

favorite












I am writing an Android app with AES encryption and I am going to save AES key as a string to a C++ file with extension .cpp.



I am also going to create an iOS app which will use the same AES key. Is it possible to save the key in C++ file in iOS?
How difficult would it be to decompile the C++ file and read the key?



Here is the C++ file from Android:



#include <jni.h>
#include <string>

extern "C"
JNIEXPORT jstring JNICALL
Java_com_android_app_aesKeyFromJNI(JNIEnv *env, jobject /* this */)
std::string secret = "somesecretkey";
return env->NewStringUTF(secret.c_str());










share|improve this question









New contributor




Daniel Foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 2




    A plain ascii string is anything but secret.
    – joxeankoret
    2 hours ago












up vote
3
down vote

favorite









up vote
3
down vote

favorite











I am writing an Android app with AES encryption and I am going to save AES key as a string to a C++ file with extension .cpp.



I am also going to create an iOS app which will use the same AES key. Is it possible to save the key in C++ file in iOS?
How difficult would it be to decompile the C++ file and read the key?



Here is the C++ file from Android:



#include <jni.h>
#include <string>

extern "C"
JNIEXPORT jstring JNICALL
Java_com_android_app_aesKeyFromJNI(JNIEnv *env, jobject /* this */)
std::string secret = "somesecretkey";
return env->NewStringUTF(secret.c_str());










share|improve this question









New contributor




Daniel Foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I am writing an Android app with AES encryption and I am going to save AES key as a string to a C++ file with extension .cpp.



I am also going to create an iOS app which will use the same AES key. Is it possible to save the key in C++ file in iOS?
How difficult would it be to decompile the C++ file and read the key?



Here is the C++ file from Android:



#include <jni.h>
#include <string>

extern "C"
JNIEXPORT jstring JNICALL
Java_com_android_app_aesKeyFromJNI(JNIEnv *env, jobject /* this */)
std::string secret = "somesecretkey";
return env->NewStringUTF(secret.c_str());







c++ android ios






share|improve this question









New contributor




Daniel Foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Daniel Foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 14 mins ago









0xC0000022L♦

7,54142861




7,54142861






New contributor




Daniel Foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 3 hours ago









Daniel Foo

161




161




New contributor




Daniel Foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Daniel Foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Daniel Foo is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.







  • 2




    A plain ascii string is anything but secret.
    – joxeankoret
    2 hours ago












  • 2




    A plain ascii string is anything but secret.
    – joxeankoret
    2 hours ago







2




2




A plain ascii string is anything but secret.
– joxeankoret
2 hours ago




A plain ascii string is anything but secret.
– joxeankoret
2 hours ago










2 Answers
2






active

oldest

votes

















up vote
3
down vote













Not hard enough!



First of all, if you save the key as a non-encrypted string, a simple strings command will find it and IDA x-ref will even show the reverser where it's used.

If you save the key encrypted, a simple breakpoint will let them see the decrypted password. (or understanding the decryption algorithm).






share|improve this answer






















  • edited your answer ... I think you meant strings, not string. If I'm wrong, kindly roll back my change (and if that doesn't work because I'm mod, let me know in a comment here, thanks).
    – 0xC0000022L♦
    15 mins ago

















up vote
2
down vote













A plain text string like this will be visible by looking at the file in a hex editor (like hte or a viewer like xxd or od) or with the Sysinternals strings command or with strings(1) on a Linux/FreeBSD etc, for example. Most reverse engineering tools have a separate view for strings, because those are usually exceptionally useful to reverse engineers. Amirag already pointed that out for IDA.



In terms of Android that C++ file is likely going to end up as a shared object in ELF file format. These are binary files with a known structure. Simply by looking at the exported functions/symbols, it will be trivial to find the "secret". Even if you were to obfuscate this further, it would still not help. Obfuscation is security through obscurity. It's not actual security. So even writing that string as some xor-ed array of bytes or using the Caesar cipher will add no tangible protection if that's the goal.



Furthermore you should never ever include the private key in code that ends up with the user. The reason why it's called a secret is because it should be kept secret. Just "mangling" the representation of this secret with a compiler isn't going to help at all.



If it's a secret the user shouldn't see it, this belongs on the server-side or into a HSM (hardware security module), but not on the user's machine in any form. There is no other way to reconcile mistrusting the user and at the same time placing "secrets" into the user's hands. It's the fundamental conundrum of software protection mechanisms also.






share|improve this answer




















    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "489"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    noCode: true, onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );






    Daniel Foo is a new contributor. Be nice, and check out our Code of Conduct.









     

    draft saved


    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2freverseengineering.stackexchange.com%2fquestions%2f19840%2fhow-difficult-is-to-decompile-c-file%23new-answer', 'question_page');

    );

    Post as a guest






























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    3
    down vote













    Not hard enough!



    First of all, if you save the key as a non-encrypted string, a simple strings command will find it and IDA x-ref will even show the reverser where it's used.

    If you save the key encrypted, a simple breakpoint will let them see the decrypted password. (or understanding the decryption algorithm).






    share|improve this answer






















    • edited your answer ... I think you meant strings, not string. If I'm wrong, kindly roll back my change (and if that doesn't work because I'm mod, let me know in a comment here, thanks).
      – 0xC0000022L♦
      15 mins ago














    up vote
    3
    down vote













    Not hard enough!



    First of all, if you save the key as a non-encrypted string, a simple strings command will find it and IDA x-ref will even show the reverser where it's used.

    If you save the key encrypted, a simple breakpoint will let them see the decrypted password. (or understanding the decryption algorithm).






    share|improve this answer






















    • edited your answer ... I think you meant strings, not string. If I'm wrong, kindly roll back my change (and if that doesn't work because I'm mod, let me know in a comment here, thanks).
      – 0xC0000022L♦
      15 mins ago












    up vote
    3
    down vote










    up vote
    3
    down vote









    Not hard enough!



    First of all, if you save the key as a non-encrypted string, a simple strings command will find it and IDA x-ref will even show the reverser where it's used.

    If you save the key encrypted, a simple breakpoint will let them see the decrypted password. (or understanding the decryption algorithm).






    share|improve this answer














    Not hard enough!



    First of all, if you save the key as a non-encrypted string, a simple strings command will find it and IDA x-ref will even show the reverser where it's used.

    If you save the key encrypted, a simple breakpoint will let them see the decrypted password. (or understanding the decryption algorithm).







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 16 mins ago









    0xC0000022L♦

    7,54142861




    7,54142861










    answered 2 hours ago









    Amirag

    4266




    4266











    • edited your answer ... I think you meant strings, not string. If I'm wrong, kindly roll back my change (and if that doesn't work because I'm mod, let me know in a comment here, thanks).
      – 0xC0000022L♦
      15 mins ago
















    • edited your answer ... I think you meant strings, not string. If I'm wrong, kindly roll back my change (and if that doesn't work because I'm mod, let me know in a comment here, thanks).
      – 0xC0000022L♦
      15 mins ago















    edited your answer ... I think you meant strings, not string. If I'm wrong, kindly roll back my change (and if that doesn't work because I'm mod, let me know in a comment here, thanks).
    – 0xC0000022L♦
    15 mins ago




    edited your answer ... I think you meant strings, not string. If I'm wrong, kindly roll back my change (and if that doesn't work because I'm mod, let me know in a comment here, thanks).
    – 0xC0000022L♦
    15 mins ago










    up vote
    2
    down vote













    A plain text string like this will be visible by looking at the file in a hex editor (like hte or a viewer like xxd or od) or with the Sysinternals strings command or with strings(1) on a Linux/FreeBSD etc, for example. Most reverse engineering tools have a separate view for strings, because those are usually exceptionally useful to reverse engineers. Amirag already pointed that out for IDA.



    In terms of Android that C++ file is likely going to end up as a shared object in ELF file format. These are binary files with a known structure. Simply by looking at the exported functions/symbols, it will be trivial to find the "secret". Even if you were to obfuscate this further, it would still not help. Obfuscation is security through obscurity. It's not actual security. So even writing that string as some xor-ed array of bytes or using the Caesar cipher will add no tangible protection if that's the goal.



    Furthermore you should never ever include the private key in code that ends up with the user. The reason why it's called a secret is because it should be kept secret. Just "mangling" the representation of this secret with a compiler isn't going to help at all.



    If it's a secret the user shouldn't see it, this belongs on the server-side or into a HSM (hardware security module), but not on the user's machine in any form. There is no other way to reconcile mistrusting the user and at the same time placing "secrets" into the user's hands. It's the fundamental conundrum of software protection mechanisms also.






    share|improve this answer
























      up vote
      2
      down vote













      A plain text string like this will be visible by looking at the file in a hex editor (like hte or a viewer like xxd or od) or with the Sysinternals strings command or with strings(1) on a Linux/FreeBSD etc, for example. Most reverse engineering tools have a separate view for strings, because those are usually exceptionally useful to reverse engineers. Amirag already pointed that out for IDA.



      In terms of Android that C++ file is likely going to end up as a shared object in ELF file format. These are binary files with a known structure. Simply by looking at the exported functions/symbols, it will be trivial to find the "secret". Even if you were to obfuscate this further, it would still not help. Obfuscation is security through obscurity. It's not actual security. So even writing that string as some xor-ed array of bytes or using the Caesar cipher will add no tangible protection if that's the goal.



      Furthermore you should never ever include the private key in code that ends up with the user. The reason why it's called a secret is because it should be kept secret. Just "mangling" the representation of this secret with a compiler isn't going to help at all.



      If it's a secret the user shouldn't see it, this belongs on the server-side or into a HSM (hardware security module), but not on the user's machine in any form. There is no other way to reconcile mistrusting the user and at the same time placing "secrets" into the user's hands. It's the fundamental conundrum of software protection mechanisms also.






      share|improve this answer






















        up vote
        2
        down vote










        up vote
        2
        down vote









        A plain text string like this will be visible by looking at the file in a hex editor (like hte or a viewer like xxd or od) or with the Sysinternals strings command or with strings(1) on a Linux/FreeBSD etc, for example. Most reverse engineering tools have a separate view for strings, because those are usually exceptionally useful to reverse engineers. Amirag already pointed that out for IDA.



        In terms of Android that C++ file is likely going to end up as a shared object in ELF file format. These are binary files with a known structure. Simply by looking at the exported functions/symbols, it will be trivial to find the "secret". Even if you were to obfuscate this further, it would still not help. Obfuscation is security through obscurity. It's not actual security. So even writing that string as some xor-ed array of bytes or using the Caesar cipher will add no tangible protection if that's the goal.



        Furthermore you should never ever include the private key in code that ends up with the user. The reason why it's called a secret is because it should be kept secret. Just "mangling" the representation of this secret with a compiler isn't going to help at all.



        If it's a secret the user shouldn't see it, this belongs on the server-side or into a HSM (hardware security module), but not on the user's machine in any form. There is no other way to reconcile mistrusting the user and at the same time placing "secrets" into the user's hands. It's the fundamental conundrum of software protection mechanisms also.






        share|improve this answer












        A plain text string like this will be visible by looking at the file in a hex editor (like hte or a viewer like xxd or od) or with the Sysinternals strings command or with strings(1) on a Linux/FreeBSD etc, for example. Most reverse engineering tools have a separate view for strings, because those are usually exceptionally useful to reverse engineers. Amirag already pointed that out for IDA.



        In terms of Android that C++ file is likely going to end up as a shared object in ELF file format. These are binary files with a known structure. Simply by looking at the exported functions/symbols, it will be trivial to find the "secret". Even if you were to obfuscate this further, it would still not help. Obfuscation is security through obscurity. It's not actual security. So even writing that string as some xor-ed array of bytes or using the Caesar cipher will add no tangible protection if that's the goal.



        Furthermore you should never ever include the private key in code that ends up with the user. The reason why it's called a secret is because it should be kept secret. Just "mangling" the representation of this secret with a compiler isn't going to help at all.



        If it's a secret the user shouldn't see it, this belongs on the server-side or into a HSM (hardware security module), but not on the user's machine in any form. There is no other way to reconcile mistrusting the user and at the same time placing "secrets" into the user's hands. It's the fundamental conundrum of software protection mechanisms also.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 17 mins ago









        0xC0000022L♦

        7,54142861




        7,54142861




















            Daniel Foo is a new contributor. Be nice, and check out our Code of Conduct.









             

            draft saved


            draft discarded


















            Daniel Foo is a new contributor. Be nice, and check out our Code of Conduct.












            Daniel Foo is a new contributor. Be nice, and check out our Code of Conduct.











            Daniel Foo is a new contributor. Be nice, and check out our Code of Conduct.













             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2freverseengineering.stackexchange.com%2fquestions%2f19840%2fhow-difficult-is-to-decompile-c-file%23new-answer', 'question_page');

            );

            Post as a guest













































































            Comments

            Popular posts from this blog

            What does second last employer means? [closed]

            Installing NextGIS Connect into QGIS 3?

            One-line joke