Hi folks,

It’s quite a long time since last post, I am sorry about that. I am in the middle of a quite long traveling period, so forgive me to slowing down a little bit my security posts. Today I d like to share an interesting Post written by “Spider Labs Anterior ” regarding the string deobfuscator using IDAPython.

Yes, it is on Flame too.. I wouldn’t write about Flame since everybody out here is talking about it, plus I had no time to personal analyze it, so unfortunately I have nothing to add to the enormous flock of posts on it 🙂 (BTW this paper is high recommended ).

The author, Josh Grunzweig, shows his path to find out the obfuscating technique used in Flame. I think it is worth to keep in mind because perfect to didactic purposes. From IDA graph he reproduced the following code. Every analyst should do this step!! I often miss it and try to solve by patching the code or by pencil and paper, but doing in this way will save a lot of time in long term analysis. I collect his main analysis following.

The function above is taking the obfuscated String as a parameter, and checking the sixteenth byte to determine if it is null. This byte is acting as a Boolean value to tell the function if the String has already been decoded. In the event that this byte is not set to null, or 0x00, another function is called, and the sixteenth byte is set to 0x00. Finally, the result of String that was initially supplied as a variable, with an offset of +20, is returned. If I were a betting man, I’d suspect that the second function (named ‘deobfuscate() in the above Ruby code) is manipulating the data somehow. In order to find out, let’s investigate what is going on. If we look above, we can see that this new function is supplied two arguments—The ‘obfuscated_string’ variable with an offset of +20, as well as the eighteenth byte in ‘obfuscated_string’. So this function appears to call a third function (last one I promise), and proceeds to subtract the resulting number from the specific character in the string before replacing it. So if we were looking at the first byte (0xA7), and the third function returned 0x82, we would get the following:0xA7 – 0x82 = 0x25 (“%”)

Great job Josh and thank you for sharing it !