2

I'm trying to analyze a decryption algorithm I'm reverse engineering and am wondering if anyone would from looking at the logic be able to identify one of the standard/common ciphers people use.

The decryption code I'm extracting this from calls out to these functions which are all in essence very similar (they are about 50 functions in total that call to one another), they all are composed of a series of while loops, if statements and VERY LONG switch/case statements which seem to analyze each position or byte value for a position and decide a course of action to generate the output from it.

Some of these functions are 11-30k lines in length, which makes me wonder if this is how the original code was built or if this might be a compiler optimization deal that expands the original logic to so many lines like that.

Here's an extract for 2 of these functions: https://gist.github.com/robertoandrade/ac3a810b82ba48d3b136

I renamed them both just for ease of identification and both have a similar signature: int ____________________switch_magic (followed by a number just to help count how many of them exist).

PS: I found the same logic in a series of applications I've tried to reverse engineering, hence my assumption this is some kind of common algorithm I'm unable to identify by looking at the obfuscated decompiled code.

Improve this question
1
  • maybe a VM implementation to hide the algorithm?
    – Henno Brandsma
    Oct 29, 2014 at 16:09

1 Answer 1

Reset to default
3

This is control flow flattening obfuscation, probably coupled with constant obfuscation, opaque predicates and all the other bells and whistles.

My guess is that it's a whiteboxed crypto implementation, i.e. the key and other constants have been embedded in the obfuscated code itself and are not present as separate data chunks. It's unlikely that you'll be able to recover the keys or even the algorithm without deobfuscating the code, although who knows....

Improve this answer
6
  • Funny you mentioned the Apple's FairPlay on the original post you referenced, because that's precisely what I'm trying to reverse engineer here :) Any tips on how to put the functions back into their original non-obfuscated form?
    – Roberto Andrade
    Oct 29, 2014 at 17:36
  • But aside from the obfuscation, even if it would be possible to follow the flow of logic in the separate blocks in each switch statement, is that flow something recognizable from a standard encryption algorithm function they're embedding? I know at one point in time they used RSA on top of AES to exchange the key, now they replaced the RSA portion with this custom FP stuff but I'm thinking behind scenes they are still delegating to a standard cipher algorithm... they wouldn't have gone thru the trouble of creating their own cipher for this I don't think.
    – Roberto Andrade
    Oct 29, 2014 at 17:38
  • the problem is that each of those basic blocks probably implements one simple operation (like mov, add, multiply etc.), so you'll have to stitch them back together into something more high level.
    – Igor Skochinsky ♦
    Oct 29, 2014 at 18:33
  • what you can try instead is what was described (I think) in the Phrack article: treat each function as a black box but observe its input and outputs; then try to map that back to the steps of the AES (or another crypto algorithm).
    – Igor Skochinsky ♦
    Oct 29, 2014 at 18:35
  • What I've noticed while studying this algorithm in the dozen or so apps I've seen it replicated is that all of the binaries contain pretty much the same obfuscated logic consistently, so I'm thinking no one got to understand what it does but were still able to pull the logic from Apple's original binaries and embed into theirs. Any idea how?
    – Roberto Andrade
    Nov 24, 2014 at 1:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.