I was tasked with analyzing android apps that utilize segmentation/detection and try to find out how they're doing it. I've decompiled the code into java and can infer that a) the detection is done via ndk. b) the so libraries are loaded dynamically at runtime from somewhere.
How do I proceed further? I've hit a wall.
Ask HN: How do I go about reverse engineering an apk
1–5 of 5 posts
Re: Ask HN: How do I go about reverse engineering an apk
#2If you have decompiled the DEX classes, what do you miss? You must be able to find from which place the libraries are loaded?
Re: Ask HN: How do I go about reverse engineering an apk
#3https://github.com/OWASP/owasp-mstg/blob/master/Document/0x0... has all the relevant information, including reversing apps using native libraries to hide functionality.
Re: Ask HN: How do I go about reverse engineering an apk
#4Those libraries are usually included in the APK. More specifically in the /include folder? Depending on the APK, it might have a x86, or arm version. Then its just a matter of reversing the library.
Re: Ask HN: How do I go about reverse engineering an apk
#5Some other things to look at if you haven’t:
- Sniff network traffic with something like mitmproxy / burp. I would do this first. Probably 99% of the information of interest to you will go over the wire. Note you may need to disable certificate pinning, which could either be done system wide or by modifying the SSL handshake function in the binary.
- Recompile the APK with hooked functions that log their arguments to syslog. That’s a crude, quick way of getting a trace of code paths. Not sure exactly how it’s done on Android, but on iOS there’s a big ecosystem for this so I imagine it’s similar with android.
- Attach the running application to a debugger, eg gdb or lldb and walk through the program. This is 100x easier if you have the symbol table.
If you need any more help with this, I’m a software consultant and this is exactly the kind of thing I do sometimes. Email is in my profile.