many users recommend downloading 2.8.3, which you can find in the crybaby fest linked above. personally, i'm not content rolling with an ancient version like some bucolic hillbilly. nah. i must break the latest version and get all those sweet sweet features.

compare old and new

i reckoned the best way to find where the cache was controlled would be to compare 2.8.3 and 2.8.4, where it changed. maybe there was just a setting somewhere they changed, or a number was reduced from "big" to "tiny". here's how i did it:

acquire 2.8.3 and 2.8.4. former was in link above, latter was from play store. i used this extension to download from play

use latest jd-gui to get java for whole app (file -> save all sources)

use diff -rq <dir1> <dir2> to get a sense of what changed

give up on diff inspection because delta was huge

randomly search for "cache" in 2.8.3

thank you soundcloud, for not obfuscating your app at all. it was much easier to find what i was looking for with class and variable names. it takes about an hour to setup proguard such that you still get debugging symbols, but hey, whatever, right?

found some likely places for cache control in 2.8.3, but it looked like there was an api rewrite between 2.8.3 and 2.8.4, so even if i found it, it wouldn't help me, because none of that code was used in later versions.

enjarify is supposed to be this snazzy new dex -> java class conversion tool. the results were "meh". i'm sure it's going to be very good eventually, and i have more faith in the professionalism of the devs of enjarify than, say, otherdevs.

educated guess searching

started searching around for the word "cache". there's quite a lot of caching going on. i poked around a few files that looked like they were just setting up LRU caches for something, and those looked promising, but then i found: Lcom/soundcloud/android/playback/CacheConfig;.

unfortunately, this creates new problems. as soon as you modify the code, you have to update the dex. if you update the dex, you break the signature and have to resign. if you resign, it breaks facebook logins, and probably some other stuff, because they uses signatures to generate a token that identifies which app is trying to do the login. luckily, antilvl knows how to handle spoofing signatures.

It decrypts most types of string encryption and can remove some types of obfuscation, especially code that doesn't actually do anything.

This may be all you want to know. But this has got me thinking about optimization and deobfuscation, so continue on if you're into that sort of thing.

App obfuscation and string encryption are getting more popular, and they can be annoying as fuck. But, fundamentally, obfuscators just apply a set of rules to code, and the rules aren't that complex, because complex is really hard. It's just a thin layer of changes added on top. Intuitively, this means a general solution for undoing the changes probably takes a little more effort to undo than it did to conceive the original rules. So no matter how bad things get for crackers, it should always be possible to make a tool to fix things up.

In the PC scene, obfuscators are more evolved, but so are the deobfuscators. Just look at the feature list on this: https://github.com/0xd4d/de4dot. It's a deobfuscator and an unpacker, plus it supports a huge list of stuff.

There are a few tools like this for Android, but they are not nearly as complex (yet). Time for bullet points!

Dare - Made by people who certainly seem to know what they're doing, but it often fails or gets put into infinite loops, and it focuses on optimization more than deobfuscation.

If you retarget DEX to JAR via JEB, dex2jar, or similar, you can use Java deobfuscators

Simplify deobfuscates by virtually executing an app and analyzing the execution afterwards. So if there is an encrypted string that gets decrypted at run time, Simplify will see the encrypted, see it passed to the decryption method, and see it get get decrypted. And after it knows the value, it can remove the encrypted value and the decryption method call as redundant and replace it with a 'const-string' instruction with the decrypted literal.

It's not all the way cooked yet, but the idea is solid, and there are some interesting issues github page I'd quite like to see implemented. One of them is deobfuscating reflection.

Also, anyone who takes the time to create issues on github and follow through with closing them when they're resolved, is probably more than a little obsessive. Should be fun to watch.

Saturday, September 20, 2014

After a bunch of people told me how much the black background + white text was murderizing their eyes, I decided a bunch of people didn't appreciate my enlightened aesthetic sensibilities. Today's blog layout change to a white background + black text is in no way me admitting I was wrong.

Android packers getting more common, and if you're doing any significant amount of reversing, you're bound to come across one. While any serious reverser should 1.) familiarize themselves with how they work, 2.) unpack a few by hand, and 3.) write their own tool, it's always nice to kick back and pull something off the shelf. Or, at least, learn how someone else is doing it.

Thursday, March 20, 2014

there's a new decompiler on the block. it targets dex directly,
rather than java class bytecode, so it doesn't rely on dex2jar. i'm
pleased by it's performance so far, and it's worth checking out:
https://github.com/skylot/jadx

output
is configurable -- you can chose to have "simple" branching, where it
wont try to be smart about how it decompiles conditionals and loops.
this can actually be much easier to read than jd-gui's pervasive
"while(true) //a bunch of stuff" constructs.

Wednesday, February 12, 2014

if you use dex2jar + jd-gui and you find the results less than satisfying, that's normal. jd-gui hasn't been updated in at least 100 years. methods often fail to compile and blocks of code are sometimes omitted.