Intel PIN is an awesome dynamic binary instrumentation framework. I've been using version 2.14 (build 71313) for a long time and decided to switch to the latest version today. Well, if you're using Visual Studio, you will have troubles building the sample projects shipped with the framework, not to talk about setting up projects from scratch.
Opaque predicates are often used for code obfuscation as they are complicating code analysis, especially when it's done statically. An example of an opaque predicate in x86 assembly is a conditional jump which is always continuing execution either at taken or not taken branch - regardless of user input, OS version, etc. The other, never taken branch, usually contains complete junk code or code belonging to some other routine. If we can prove that a conditional jump can be eliminated (either replaced with unconditional jump or completely removed/replaced with NOPs), then we can significantly improve and simplify code analysis.
I've decided to start playing with Z3, a powerful SMT solver developed by Microsoft which, amongst many other things, can also be used for proving the existance of opaque predicates in code.
Welcome to my new site!
Crrently I'm just importing old posts from my blog and various websites and forums I contributed to during the past 10 years, but I will also start posting new reverse engineering related articles and projects in the near future!
I have seen many examples and available solutions for string encryption, but they mostly force you to bloat your code with a lot of garbage. Usually it's something in form of randomly generated lines of code that will fill a buffer with the desired string or something in form of: XorString("\xf0\xdb\x5c\xc3\x6e\xd3\x0d\xd6\x90\xde", 0x6b1c485a, 10)
While these truly are string encryptions and they do their job, it's very hard to quickly modify such strings in your code. In either of those two examples you would have to go back to the application/site that generates the code for you, plus it also makes the code very hard to read.
Writing a string encryption tool takes literally not more than 15-20 minutes and you get to decide how it behaves, which type of encryption you want, etc.
Many people rely only on virtualization software when protecting their binaries which is often very bad. There's plenty of information on existing VM protections on popular reversing sites, some even offer what is pretty much a 1-click devirtualization tool.
However, whether there's existing tools for fighting your choice of VM or it's still undocumented, there's absolutely no reason why you shouldn't put in extra effort to make reverse engineering harder. I will demonstrate one very simple method to do so: emulation of binary operations on the source code level.
After releasing the x86obf tool for free I received quite a few requests for the source code. It was planned for the future, but I've decided to release it sooner.
The source code has been slightly stripped. Junk code generators are removed (they emit NOP only), data encryption is removed and so is bytecode encryption/obfuscation.
x86obf is now a free and public project. There are no limitations on number of blocks and number of instructions you can protect.
What is x86obf? x86obf is a tool for executable binary protection. It works by locating marked code blocks of code and converting them to a series of instructions understood only by a randomly generated virtual machine in order to make reverse engineering harder.
After having seen a discussion on /r/ReverseEngineering/ regarding the amount of executed instructions in applications protected by popular code virtualization tools, I've decided to benchmark the execution time. Benchmarked application has been protected with CodeVirtualizer, VMProtect and Themida. All three of them have been tested with the lightest and most complex VM settings. I will benchmark x86obf when it's finished and Enigma Protect if I ever decide to get a license for it.