11 ms·

Android App Reverse Engineering 101

380 points by conductor 7y ago

nneonneo 7y ago
Ghidra has a pretty good structure editor and structure definition system. You can import a C header (like a modified jni.h) and then you can declare parameters as being of type “JNIEnv *” - after that, Ghidra will automatically resolve function pointer calls for you. No need to keep consulting an offset table. (IDA’s decompiler has all of this too, but it costs a lot more!)
- souprock 7y ago
  What about graph view? IDA will let you use struct offsets in the assembly language, making the assembly much more readable. I'm hearing that Ghidra doesn't, and that you are forced to use the decompiler to make use of the structs.
  - saagarjha 7y ago
    I'm not completely sure what you're talking about, but if you annotate variables with types Ghidra will show member accesses instead of offsets in the assembly listing.
    - pjmlp 7y ago
      This graph view I guess. https://www.hex-rays.com/products/ida/pix/idalarge.gif https://www.hex-rays.com/products/ida/pix/idalarge.gif
      - saagarjha 7y ago
        Ghidra has a function graph view that shows the control flow for a function.
      - souprock 7y ago
        No, like this: https://www.hex-rays.com/products/ida/tech/graphing.shtml https://www.hex-rays.com/products/ida/tech/graphing.shtml It is sort of like a flow chart, with the assembly shown for each chunk. I've loaded up functions with over 5000 blocks of code, including one function that was a third of a megabyte in size. Navigation becomes important. Ghidra is supposedly slow at this scale. I'm also told that Ghidra seems to not do struct offsets in that view, forcing the use of the decompiler. With IDA the struct offsets can be chosen and viewed, all without involving the decompiler.
ignoramous 7y ago
The author is yet to complete the tutorial but its an interesting resource, nonetheless. The tutorial does leave out https://frida.re https://frida.re which offers a runtime no-root reverse engineering mechanism, which I'm currently using it to MiTM apps with cert-pinned TLS. There's also the excellent FlowDroid and Androguard, the latter of which I've used for static analysis [0]. I recall NateLawson founded a YC startup, SourceDNA [1], that offered intelligence on reverse engineered iOS and Android apps (based on static analysis). I wonder what tools they used. [0] https://github.com/ashishb/android-security-awesome https://github.com/ashishb/android-security-awesome [1] https://news.ycombinator.com/item?id=10049925 https://news.ycombinator.com/item?id=10049925
- ollyfg 7y ago
  Wow! How have I not heard of frida? This should make my normal process much simpler! 1) Decompile App -> smali 2) Decompile App -> Java (non-reversible, but easier to read) 3) Search the app for certificate pinning code (check for network_security.xml or grep for OKHttp pinning functions) 4) Find the code I just found in java, in the smali version 5) Remove the pinning code 6) Recompile smali -> apk 7) Fix whatever was causing the smail not to recompile 8) Recompile again 9) Pray 10) Install on device 11) Run app (that hopefully doesn't crash) 12) Pipe connection through Charles proxy 13) Read api calls! I'll definitely give it a go. In general I think there are nowhere near enough resources on decompilation, particularly on a purportedly "open" platform like Android. Really looking forward on the rest of the tutorial coming online.
  - sonnyblarney 7y ago
    "there are nowhere near enough resources on decompilation, particularly on a purportedly "open" platform like Android." Most apps are definitely not 'open' and unfortunately most of 'reverse engineering' has nefarious intentions. Once one has had key code stolen from them, it changes one's perspective a little.
    - saagarjha 7y ago
      Are you suggesting that reverse engineering resources not be made available because you feel it will lead to people stealing code?
wolfi1 7y ago
that begs one question: where to get the apk from?
- saagarjha 7y ago
  From your device using adb pull?
  - scrollaway 7y ago
    Is there a more reliable way to get the APK programmatically, without having to use an android device as a middleman? I know of gplaycli (https://github.com/matlink/gplaycli/ https://github.com/matlink/gplaycli/) but its reliability leaves a lot to be desired afaik.
    - lucb1e 7y ago
      There is also the Yalp store (open source Google Play service front-end), as well as a bunch of third party websites that will happily give you an untrusted APK (they all claim to be secure and original, but somehow the sha2 hashes of identical versions are n=3 always different for me).
      - notafrog 7y ago
        Could it be that it's a case of multiple APK? Perhaps different CPU architecture? In any case I would check the value of versionCode first (https://developer.android.com/guide/topics/manifest/manifest-element.html#vcode https://developer.android.com/guide/topics/manifest/manifest...).
- tatoalo 7y ago
  You can either install it from your real hw device and, once connected via usb, do a $ adb pull test.apk or you can download it from these sites: (I've tried them both for different RE purposes and they also have the latest updates for a lot of apps) APKCombo [1] & APKPure [2]. [1] : https://apkcombo.com/ https://apkcombo.com/ [2] : https://apkpure.com https://apkpure.com
saagarjha 7y ago
Somewhat related: has anyone found a difference in the quality of decompiled Dalvik bytecode and JVM bytecode, with the former being register-based?
Abishek_Muthian 7y ago
I used to reverse engineer android apps between 2010-2012. I used couple of methods. 1.Dare + JD Decompiler +Cavaj (or) DJ Decompiler 2.dex2jar + JD Decompiler + Cavaj (or) DJ Decompiler 3.AndroChef Java Decompiler And for selective decompilation, Smali (or) Backsmali with deodexing for system applications. They all were plagued by different decompilation & retargeting issues of those time. I would love to see how things have changed now.
krtkush 7y ago
MobSF[1] is a good tool for anyone in need of reverse engineering an apk for security audit purposes. [1] https://github.com/MobSF/Mobile-Security-Framework-MobSF https://github.com/MobSF/Mobile-Security-Framework-MobSF
revskill 7y ago
I know some of my friends, who "steal" famous apps on Google Store, then re-compile and re-publish into their own namespaces. Even worse, he then reported back the original author for stealing his apps. What he did, is to steal resources and put his Ads into the stolen app. I'm not sure if Google could track those things. That's why i always consider most of Vietnamese apps on Android store are "stolen" in some cases. In Vietnam, "stealing apps" is a real dark business.
- tinus_hn 7y ago
  Google could stop distributing pirated apps after complaints. It should be pretty clear who published the app first.
  - ignoramous 7y ago
    They seem to be doing just that: https://security.googleblog.com/2019/01/pha-family-highlights-zen-and-its.html https://security.googleblog.com/2019/01/pha-family-highlight...
  - revskill 7y ago
    The problem, is the author doesn't always know his apps are stolen.
  - pjc50 7y ago
    Sounds like they could do with an automated plagiarism detector, although that has its own gameability problems.
    - UncleMeat 7y ago
      Doing this in a fully automated way that works well is tough. Blindly applying DroidMOSS falls over against simple techniques. Add to it that lots of repackaged apps are distributed outside channels that Google controls and you've got a hard problem.

380 points by conductor 7y ago

Ghidra has a pretty good structure editor and structure definition system. You can import a C header (like a modified jni.h) and then you can declare parameters as being of type “JNIEnv *” - after that, Ghidra will automatically resolve function pointer calls for you. No need to keep consulting an offset table. (IDA’s decompiler has all of this too, but it costs a lot more!)

souprock 7y ago
What about graph view? IDA will let you use struct offsets in the assembly language, making the assembly much more readable. I'm hearing that Ghidra doesn't, and that you are forced to use the decompiler to make use of the structs.
- saagarjha 7y ago
  I'm not completely sure what you're talking about, but if you annotate variables with types Ghidra will show member accesses instead of offsets in the assembly listing.
  - pjmlp 7y ago
    This graph view I guess. https://www.hex-rays.com/products/ida/pix/idalarge.gif https://www.hex-rays.com/products/ida/pix/idalarge.gif
    - saagarjha 7y ago
      Ghidra has a function graph view that shows the control flow for a function.
    - souprock 7y ago
      No, like this: https://www.hex-rays.com/products/ida/tech/graphing.shtml https://www.hex-rays.com/products/ida/tech/graphing.shtml It is sort of like a flow chart, with the assembly shown for each chunk. I've loaded up functions with over 5000 blocks of code, including one function that was a third of a megabyte in size. Navigation becomes important. Ghidra is supposedly slow at this scale. I'm also told that Ghidra seems to not do struct offsets in that view, forcing the use of the decompiler. With IDA the struct offsets can be chosen and viewed, all without involving the decompiler.

ignoramous 7y ago

The author is yet to complete the tutorial but its an interesting resource, nonetheless. The tutorial does leave out https://frida.re https://frida.re which offers a runtime no-root reverse engineering mechanism, which I'm currently using it to MiTM apps with cert-pinned TLS. There's also the excellent FlowDroid and Androguard, the latter of which I've used for static analysis [0]. I recall NateLawson founded a YC startup, SourceDNA [1], that offered intelligence on reverse engineered iOS and Android apps (based on static analysis). I wonder what tools they used. [0] https://github.com/ashishb/android-security-awesome https://github.com/ashishb/android-security-awesome [1] https://news.ycombinator.com/item?id=10049925 https://news.ycombinator.com/item?id=10049925

ollyfg 7y ago
Wow! How have I not heard of frida? This should make my normal process much simpler! 1) Decompile App -> smali 2) Decompile App -> Java (non-reversible, but easier to read) 3) Search the app for certificate pinning code (check for network_security.xml or grep for OKHttp pinning functions) 4) Find the code I just found in java, in the smali version 5) Remove the pinning code 6) Recompile smali -> apk 7) Fix whatever was causing the smail not to recompile 8) Recompile again 9) Pray 10) Install on device 11) Run app (that hopefully doesn't crash) 12) Pipe connection through Charles proxy 13) Read api calls! I'll definitely give it a go. In general I think there are nowhere near enough resources on decompilation, particularly on a purportedly "open" platform like Android. Really looking forward on the rest of the tutorial coming online.
- sonnyblarney 7y ago
  "there are nowhere near enough resources on decompilation, particularly on a purportedly "open" platform like Android." Most apps are definitely not 'open' and unfortunately most of 'reverse engineering' has nefarious intentions. Once one has had key code stolen from them, it changes one's perspective a little.
  - saagarjha 7y ago
    Are you suggesting that reverse engineering resources not be made available because you feel it will lead to people stealing code?

wolfi1 7y ago

that begs one question: where to get the apk from?

saagarjha 7y ago
From your device using adb pull?
- scrollaway 7y ago
  Is there a more reliable way to get the APK programmatically, without having to use an android device as a middleman? I know of gplaycli (https://github.com/matlink/gplaycli/ https://github.com/matlink/gplaycli/) but its reliability leaves a lot to be desired afaik.
  - lucb1e 7y ago
    There is also the Yalp store (open source Google Play service front-end), as well as a bunch of third party websites that will happily give you an untrusted APK (they all claim to be secure and original, but somehow the sha2 hashes of identical versions are n=3 always different for me).
    - notafrog 7y ago
      Could it be that it's a case of multiple APK? Perhaps different CPU architecture? In any case I would check the value of versionCode first (https://developer.android.com/guide/topics/manifest/manifest-element.html#vcode https://developer.android.com/guide/topics/manifest/manifest...).
tatoalo 7y ago
You can either install it from your real hw device and, once connected via usb, do a $ adb pull test.apk or you can download it from these sites: (I've tried them both for different RE purposes and they also have the latest updates for a lot of apps) APKCombo [1] & APKPure [2]. [1] : https://apkcombo.com/ https://apkcombo.com/ [2] : https://apkpure.com https://apkpure.com

saagarjha 7y ago

Somewhat related: has anyone found a difference in the quality of decompiled Dalvik bytecode and JVM bytecode, with the former being register-based?

Abishek_Muthian 7y ago

I used to reverse engineer android apps between 2010-2012. I used couple of methods. 1.Dare + JD Decompiler +Cavaj (or) DJ Decompiler 2.dex2jar + JD Decompiler + Cavaj (or) DJ Decompiler 3.AndroChef Java Decompiler And for selective decompilation, Smali (or) Backsmali with deodexing for system applications. They all were plagued by different decompilation & retargeting issues of those time. I would love to see how things have changed now.

krtkush 7y ago

MobSF[1] is a good tool for anyone in need of reverse engineering an apk for security audit purposes. [1] https://github.com/MobSF/Mobile-Security-Framework-MobSF https://github.com/MobSF/Mobile-Security-Framework-MobSF

revskill 7y ago

I know some of my friends, who "steal" famous apps on Google Store, then re-compile and re-publish into their own namespaces. Even worse, he then reported back the original author for stealing his apps. What he did, is to steal resources and put his Ads into the stolen app. I'm not sure if Google could track those things. That's why i always consider most of Vietnamese apps on Android store are "stolen" in some cases. In Vietnam, "stealing apps" is a real dark business.

tinus_hn 7y ago
Google could stop distributing pirated apps after complaints. It should be pretty clear who published the app first.
- ignoramous 7y ago
  They seem to be doing just that: https://security.googleblog.com/2019/01/pha-family-highlights-zen-and-its.html https://security.googleblog.com/2019/01/pha-family-highlight...
- revskill 7y ago
  The problem, is the author doesn't always know his apps are stolen.
- pjc50 7y ago
  Sounds like they could do with an automated plagiarism detector, although that has its own gameability problems.
  - UncleMeat 7y ago
    Doing this in a fully automated way that works well is tough. Blindly applying DroidMOSS falls over against simple techniques. Add to it that lots of repackaged apps are distributed outside channels that Google controls and you've got a hard problem.