How would one go about understanding the content of this write-up? Even after the first paragraph it begins to go completely over my head.
Reverse Engineering Snapchat: Obfuscation Techniques
111–120 of 180 posts
Re: Reverse Engineering Snapchat: Obfuscation Techniques
#112Some I see are surprised to see the level of obfuscation used in the application. Many pointed, many ingredients for the obfuscation used in the app are off-the-shelf and few of them can be said to be well known in the industry, but still there is a cost in integrating them into a product. Obfuscation is notorious in breaking things which should work normally (normal compilation process) and as a own goal making it h…
I think that it is due to the copy cats that keep stealing apps and repacking them. Most Android developers lack native coding experience, so after failing attempts to protect their applications with the DEX bytecodes obfuscator, they think that recoding parts of the application with the NDK will save them. However as this article shows, and most here know, they shortly learn that against good attackers, the only ben…
> they think that recoding parts of the application with the NDK will save them.
Yeah like that one app I reversed a while ago that generated the API key in a native library. I was able to get the key by building my own app around their library and calling the function that returns the key. Didn't even have to disassemble the thing.
Re: Reverse Engineering Snapchat: Obfuscation Techniques
#113Earlier quoted context omitted.
Funny thing about things like that is that you can likely write tools to automatically deobfuscate, if you know the mechanisms. Of course, this takes time and effort, and is beyond most spammers' capabilities.
Very unlikely you can actually. It is kinda similar to why we cannot have the source of binary even if we know how the compiler works.
We cannot have _the_ source, but we can have a good enough approximation of it, especially if a human is in the loop (see: commercial decompilation software like the Hex-Rays decompiler, Binary Ninja, and even Ghidra).
Re: Reverse Engineering Snapchat: Obfuscation Techniques
#114Earlier quoted context omitted.
Very unlikely you can actually. It is kinda similar to why we cannot have the source of binary even if we know how the compiler works.
We cannot have _the_ source, but we can have a good enough approximation of it, especially if a human is in the loop (see: commercial decompilation software like the Hex-Rays decompiler, Binary Ninja, and even Ghidra).
The point is that we cannot automate reversing these obfuscation mechanisms the same way we cannot automate reversing a binary file to a higher level than assembly.
Re: Reverse Engineering Snapchat: Obfuscation Techniques
#115Earlier quoted context omitted.
We cannot have _the_ source, but we can have a good enough approximation of it, especially if a human is in the loop (see: commercial decompilation software like the Hex-Rays decompiler, Binary Ninja, and even Ghidra).
The point is that we cannot automate reversing these obfuscation mechanisms the same way we cannot automate reversing a binary file to a higher level than assembly.
This not quite true, especially with current state-of-the-art tools like Ghidra, IDA pro (with Hex-rays), etc.
In fact, Rolf Rolles wrote a wonderful guest post[1] for the Hex-Rays blog about automating the reversal of this exact obfusactor, though he wasnt aware of it's origins at the time.
[1]: https://www.hex-rays.com/blog/hex-rays-microcode-api-vs-obfu...
Re: Reverse Engineering Snapchat: Obfuscation Techniques
#116Earlier quoted context omitted.
The point is that we cannot automate reversing these obfuscation mechanisms the same way we cannot automate reversing a binary file to a higher level than assembly.
This not quite true, especially with current state-of-the-art tools like Ghidra, IDA pro (with Hex-rays), etc. In fact, Rolf Rolles wrote a wonderful guest post[1] for the Hex-Rays blog about automating the reversal of this exact obfusactor, though he wasnt aware of it's origins at the time. [1]: https://www.hex-rays.com/blog/hex-rays-microcode-api-vs-obfu...
Exactly. Such tools are definitely possible, even if they rely on Ghidra or IDA's plugin systems.
What I like is the economics of the idea that one company can build an obfuscator, and then another company can build an anti-obfuscator which completely nullifies the value proposition of the first company.
Re: Reverse Engineering Snapchat: Obfuscation Techniques
#117I’m surprised that no one has mentioned how this is actually accomplished. The answer is: largely automatically, at the compiler level. Snapchat acquired Obfuscator-LLVM and the people behind it in 2017, which was actually partially open source for a period of time. It is a compiler backend for LLVM that obfuscates your code for you. You can read a bit about some of the techniques used on their old wiki: https://gith…
Funny thing about things like that is that you can likely write tools to automatically deobfuscate, if you know the mechanisms. Of course, this takes time and effort, and is beyond most spammers' capabilities.
I'm gonna write about this in pt. 2. Basically you can use symbolic execution to recover the CFG[1] (using something like miasm), you can eliminate dead code, restore dynamic lib calls with an emulation, and whatever else. But the point is that it would take an incredible amount of work and co-operation between tools, and then you wouldn't have even begun understanding anything about the binary, which is a whole another story. Now there's a kind of a little shortcut to all of this, which when combined with a couple of tools, you'd be able to make sense of things in this binary, which I'm gonna reveal in my next post.
[1]: https://blog.quarkslab.com/deobfuscation-recovering-an-ollvm...
Re: Reverse Engineering Snapchat: Obfuscation Techniques
#118Earlier quoted context omitted.
The point is that we cannot automate reversing these obfuscation mechanisms the same way we cannot automate reversing a binary file to a higher level than assembly.
This not quite true, especially with current state-of-the-art tools like Ghidra, IDA pro (with Hex-rays), etc. In fact, Rolf Rolles wrote a wonderful guest post[1] for the Hex-Rays blog about automating the reversal of this exact obfusactor, though he wasnt aware of it's origins at the time. [1]: https://www.hex-rays.com/blog/hex-rays-microcode-api-vs-obfu...
All these are great programs, but none of them can understand that level of obfuscation so far. As stated in the post, both Ghidra and IDA interpret the very first block in any of the obfuscated functions, which ends with an indirect branch, as a complete function in and of its own. Because this is the usual case, indirect branches AKA tail calls terminate a function to start another, all with the same stack frame.
EDIT: also keep in mind the CFG isn't flattened here.
Re: Reverse Engineering Snapchat: Obfuscation Techniques
#119Best value of this kind of obfuscation is they usually rely on a random seed, and every time you obfuscate you have different results. So once you update the app (and change hash function), for new version, spammer need to the all reversing once again.
Not all of it, really ;)
Re: Reverse Engineering Snapchat: Obfuscation Techniques
#120I would love to be able to make a bot for the snapchat group my friends and I have. We already have a blast using it now. A bot that could randomly do things that we could all interact with would be hilarious. Sadly I don't think this functionality will be introduced. So it will be cool to maybe slap something together before all of this gets fixed.