Datamining Android apps and games

ROllerozxa	ROllerozxa Site Admin	Posted on 2022-06-23 13:51 Link \| ID: 42
Site Admin Posts: 229 Joined: 2022-06-04	So you have a cool old Android game you have a lot of nostalgia for and now want to ruin it by cracking it open? Cool! In case you don't already know, Android apps are APK files, which is essentially just a zip file following a certain file structure. If you extract any APK file you're bound to find all the assets and resources, either in `assets/`, `res/drawable/` or `res/raw/` depending on the game. If you're lucky the game assets are stored in sane formats like PNG and OGG Vorbis, but you also have the chance of stumbling over some obscure or even in-house formats. Some Googling might help since these obscure formats tend to be shared across many apps. (e.g. the PKM format which is an uncompressed image format that's intended to give the absolute lowest possible overhead with OpenGLES) But you might want to dive even deeper than that. More often than not Android apps are written in large part in Java, which is compiled to Dalvik bytecode and stored in the classes.dex file inside of the APK. This bytecode can rather easily be reversed into more human readable Java source code using JADX, but this code more than often is hard to recompile into a working app again. I'm sure you could find a lot of interesting stuff, not only unused content but also an overview of how the internals are laid out. If you're lucky the developer was too lazy to obfuscate the code or accidentally pushed an unobfuscated update, otherwise you might see garbled class and method names like `a.a.b.cc`. In that case you could try looking for older versions of the app and seeing if they are obfuscated too (sometimes they are not), or you can work from logging strings to figure out what is happening. There is also apktool which disassembles (baksmali's) the bytecode into a kind of Dalvik assembler language called Smali. It is more verbose and harder to read, but is easier to make simple mods to the code and then rebuild the app. I recommend finding the same code in JADX as the code you're working in Smali as it's a good way to get a better overview of the code. However if the classes.dex is small or consists only of Android platform code or spyware libraries there's a likely chance the app is written in large part native code, in which it is stored in the `lib/` folder, one folder for each unique architecture. If this is the case, usually you're pretty fucked since it is harder to decompile native code into something that's relatively readable (Java bytecode contains much more superfluous information that can be taken advantage of by a decompiler). But if you're comfortable with reverse engineering binaries you might find some use out of feeding the native library into Cutter or Ghidra and figuring out the context from source strings and potentially unstripped symbols. (Might write more in the future if I can think of anything more to add)