A new blog entry is available at my webpage:
zubcic.re/blog/experimenting-with-z3-proving-opaque-predicates
Tomislav Zubčić's blog
Reverse engineering, software development, free software protection tools and resources
Thursday, August 18, 2016
Monday, August 15, 2016
New website
This blog has been moved to zubcic.re - new posts and projects will be posted there from now on.
Monday, March 23, 2015
Simple source code level tricks that will make reverse engineering harder
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.
Here's a simple implementation of binary addition for 32 bit numbers:
... and here's a header file with some other operations implemented: obf_tricks.h
After emulating the simple operations, you can implement some more complex operations based on the simple ones. For example, three simple ways to compare two integers using XOR, XNOR and bit counting:
#define X_ISEQUAL1(x,y) (X_XnorIntegers(x,y) == -1)
#define X_ISEQUAL2(x,y) (X_CountHighBits(X_XnorIntegers(x,y)) == 32)
#define X_ISEQUAL3(x,y) (X_XorIntegers(x,y) == 0)
For a quick demonstration here's an extremely simple C code that will print all command line arguments:
... which translates into a very straightforward code: main_disassembly_normal.txt
Now we can rewrite the main application using these macros:
... which now translates into something not that straightforward: main_disassembly_obf.txt
This is a very primitive obfuscation attempt and every somewhat experienced reverser will have no real issues understanding the code. However, if you combine this with virtualization software you will complicate things further and the reverser will have to invest more time into the process of understanding how your algorithms work.
Please note that this is just a simple PoC for demonstration. In real world you should come up with your own ideas.. and it's really not hard to come up with something that does not look like the usual code modern compilers output. Start with obfuscation of some very simple operations and then you can base more complex ones on them.
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.
Here's a simple implementation of binary addition for 32 bit numbers:
... and here's a header file with some other operations implemented: obf_tricks.h
After emulating the simple operations, you can implement some more complex operations based on the simple ones. For example, three simple ways to compare two integers using XOR, XNOR and bit counting:
#define X_ISEQUAL1(x,y) (X_XnorIntegers(x,y) == -1)
#define X_ISEQUAL2(x,y) (X_CountHighBits(X_XnorIntegers(x,y)) == 32)
#define X_ISEQUAL3(x,y) (X_XorIntegers(x,y) == 0)
For a quick demonstration here's an extremely simple C code that will print all command line arguments:
... which translates into a very straightforward code: main_disassembly_normal.txt
Now we can rewrite the main application using these macros:
... which now translates into something not that straightforward: main_disassembly_obf.txt
This is a very primitive obfuscation attempt and every somewhat experienced reverser will have no real issues understanding the code. However, if you combine this with virtualization software you will complicate things further and the reverser will have to invest more time into the process of understanding how your algorithms work.
Please note that this is just a simple PoC for demonstration. In real world you should come up with your own ideas.. and it's really not hard to come up with something that does not look like the usual code modern compilers output. Start with obfuscation of some very simple operations and then you can base more complex ones on them.
Tuesday, March 17, 2015
A ready to use Intel PIN Visual Studio project
Intel PIN is a great tool, but configuring a Visual Studio project is not very straightforward from its documentation. I know a couple of people who have heard of it, but have given up after not being able to set up a working project easily.
I've uploaded a ready to use PIN Tool based on a sample code that comes with it. PIN itself is not included, you need to download it and then copy the Pin directory to the folder where PinTool.sln is located.
Download: PinTool.zip
I've uploaded a ready to use PIN Tool based on a sample code that comes with it. PIN itself is not included, you need to download it and then copy the Pin directory to the folder where PinTool.sln is located.
Download: PinTool.zip
Friday, February 27, 2015
How to encrypt strings in your applications
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.
I've written some code quickly to make an easy to understand example. I wanted it to be easy to read and change strings in the code, like this:
After compiling this code, you need to pass it to the string encryption tool:
I won't be explaining the code in details, it's really nothing special and should be easy to understand. Please note that this is just a PoC and that normally you would add a better encryption than simple xor, you would make sure it doesn't leak memory (se_decrypt returns malloc'd memory which is not freed - or you'd make it not allocate new memory, but replace the encrypted string with decrypted, but it involves usage of VirtualProtect), etc.
Download: string_encrypt.zip
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.
I've written some code quickly to make an easy to understand example. I wanted it to be easy to read and change strings in the code, like this:
After compiling this code, you need to pass it to the string encryption tool:
I won't be explaining the code in details, it's really nothing special and should be easy to understand. Please note that this is just a PoC and that normally you would add a better encryption than simple xor, you would make sure it doesn't leak memory (se_decrypt returns malloc'd memory which is not freed - or you'd make it not allocate new memory, but replace the encrypted string with decrypted, but it involves usage of VirtualProtect), etc.
Download: string_encrypt.zip
Wednesday, February 25, 2015
x86obf source code
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.
Virtualization handlers have been removed for some important and some
not so important instructions. One of the important handlers were Jxx
instructions which cannot be executed by the VM in its native form. In
fact, every instruction that somehow changes execution flow (e.g. CALL,
RET, JMP, Jxx, etc) must be handled manually.
I am releasing this as a learning material, not a ready to use
compile-my-own-protector source. It will successfully virtualize and
produce working binaries for short blocks of code which don't have
conditional jumps. If you want to build a real protector on top of this,
you will have to develop some code yourself.
x86obf was initially meant to be a commercial application, but it didn't
work out. It had two versions, local and remote, which is why it's split
into two projects and still has context data transferring code which is
not needed in its current state.
If you have any questions, feel free to send me an email!
The public version of x86obf will continue to be developed, in fact it's
being rewritten slightly to provide better functionality and also to
compensate for this source code release - I am changing its internal VM
design.
You're free to use this source code in free and commercial projects, but
please do credit me.
Writing virtualization handlers is straightforward:
Download: x86obf_source.zip
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.
Virtualization handlers have been removed for some important and some
not so important instructions. One of the important handlers were Jxx
instructions which cannot be executed by the VM in its native form. In
fact, every instruction that somehow changes execution flow (e.g. CALL,
RET, JMP, Jxx, etc) must be handled manually.
I am releasing this as a learning material, not a ready to use
compile-my-own-protector source. It will successfully virtualize and
produce working binaries for short blocks of code which don't have
conditional jumps. If you want to build a real protector on top of this,
you will have to develop some code yourself.
x86obf was initially meant to be a commercial application, but it didn't
work out. It had two versions, local and remote, which is why it's split
into two projects and still has context data transferring code which is
not needed in its current state.
If you have any questions, feel free to send me an email!
The public version of x86obf will continue to be developed, in fact it's
being rewritten slightly to provide better functionality and also to
compensate for this source code release - I am changing its internal VM
design.
You're free to use this source code in free and commercial projects, but
please do credit me.
Writing virtualization handlers is straightforward:
Download: x86obf_source.zip
Saturday, February 21, 2015
x86obf code virtualizer released for free
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.
x86obf currently supports only 32bit PE files (EXE and DLLs, kernel drivers are not yet supported).
Please note that not all x86 instructions are virtualized yet and there may be bugs - please report if you find any.
The instructions on how to use and a sample project are inside the archive.
Download: x86obf.zip
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.
x86obf currently supports only 32bit PE files (EXE and DLLs, kernel drivers are not yet supported).
Please note that not all x86 instructions are virtualized yet and there may be bugs - please report if you find any.
The instructions on how to use and a sample project are inside the archive.
Download: x86obf.zip
Friday, December 6, 2013
VM Code protection benchmark
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.
I wanted to benchmark virtualization of arithmetic/logical operations, but floating point operations as well. The benchmark tool is nothing fancy and could have probably been better, but I think it's enough for some general view on the speeds. The arithmetic/logical test is an MD5 computation and floating point is a loop of some floating point math which makes no real sense.
This is the test application's source code: http://pastie.org/8534270
All three protection tools have been tested with lightest VM settings available and also with the most complex configuration. Anti-debugging, packing, anti-dumping and other protection options have been disabled. Below is an image showing results of the benchmark (click to enlarge). The slowdown column tells how many times slower the virtualized code was compared to native code with no protection. The commas are there for easier reading, they are not decimal separators (1,329 means 1329 times slower).
I wanted to benchmark virtualization of arithmetic/logical operations, but floating point operations as well. The benchmark tool is nothing fancy and could have probably been better, but I think it's enough for some general view on the speeds. The arithmetic/logical test is an MD5 computation and floating point is a loop of some floating point math which makes no real sense.
This is the test application's source code: http://pastie.org/8534270
All three protection tools have been tested with lightest VM settings available and also with the most complex configuration. Anti-debugging, packing, anti-dumping and other protection options have been disabled. Below is an image showing results of the benchmark (click to enlarge). The slowdown column tells how many times slower the virtualized code was compared to native code with no protection. The commas are there for easier reading, they are not decimal separators (1,329 means 1329 times slower).
Monday, May 20, 2013
Wednesday, June 1, 2011
ChapljaVM Code Obfuscator 0.0.1 alpha
This is a release of a very early alpha version of the program, make sure to read the README!
Download: chaplja.net/ChapljaVM.zip
README file contents:
Download: chaplja.net/ChapljaVM.zip
README file contents:
# ChapljaVM Code Obfuscator readme
ChapljaVM Code Obfuscator is a tool used for protection of PE executable
files. It is currently in alpha stage and is thus far from finished.
Many instructions are not supported yet or may be improperly mutated
which can result in the protection application not functioning correctly
(e.g. crashing).
Notes: The input executable must be compiled with image randomization
disabled and no relocation sections or it will crash when loaded at non
default base address. This means you must disable the above mentioned
features in your compiler for your EXE files as well. Only 32bit files
are supported at this stage and instructions in the marked code blocks
must not have any prefixes (e.g. lock, repne, etc). Also, certain
instructions are currently supported only in certain forms, for example:
"xor register, register" may be supported, but "xor [mem], imm" not.
More instructions will be supported soon, but you may report an
instruction used by your program if it's not supported and it will take
priority over other instructions. Contact details are on the bottom of
this file.
The code produced at this stage is a bit too large (100 bytes of code
becomes around 1600 bytes of code, but that will be optimized soon) and
not all instructions are mutated, some are simply copied in its original
form. Remember, this is an alpha version! Many things are temporary and
the obfuscation complexity will be much more complex in future versions.
The protection options are not customizable at this stage, the options
block will be enabled at a later point.
How to use: Include the "ChapljaVM_SDK.h" in your C/C++ project and use
CVM_BEGIN and CVM_END macros to mark the start and the end of a code
block you wish to protect.
Please report all bugs to chaplja@gmail.com - this includes unsupported
instructions as well as any other kind of bug (e.g. the generated exe
file is crashing or producing wrong results).
# Credits for used libraries
* PeLib - www.pelib.com
Copyright 2004 by Sebastian Porst
Original license in PELIB_LICENSE.txt
* libudis86 - http://udis86.sourceforge.net
Copyright (c) 2002, 2003, 2004, 2005, 2006, 2007, 2008
Original license in UDIS86_LICENSE.txt
* AsmJit - http://code.google.com/p/asmjit/
Copyright (c) 2008-2010, Petr Kobalicek
Original license in ASMJIT_COPYING.txt
# www.chaplja.net | www.valsimot.com | chaplja.blogspot.com
# chaplja@gmail.com
Labels:
chaplja,
chapljavm,
code obfuscation,
cvm,
download,
obfuscator,
packer,
protection,
virtual machine,
virtualization
Monday, May 30, 2011
ChapljaVM progress update
Here's a binary obfuscated with the current CVM version. It's still in a very early development phase and the mutation complexity is very simple compared to the plans I have for later, but it should already stop quite a few newbies from easily reversing a mutated block of code.
The obfuscated application is a SHA-1 implementation with a self-test program which computes a checksum of predefined values and compares them to the expected result. The original program's source can be found here: http://www.packetizer.com/security/sha1/
Download the obfuscated binary here: http://chaplja.net/SHA1_2011_05_30.exe
Hopefully I'll be able to release a test version for testing to public soon.
The obfuscated application is a SHA-1 implementation with a self-test program which computes a checksum of predefined values and compares them to the expected result. The original program's source can be found here: http://www.packetizer.com/security/sha1/
Download the obfuscated binary here: http://chaplja.net/SHA1_2011_05_30.exe
Hopefully I'll be able to release a test version for testing to public soon.
Labels:
chaplja,
chapljavm,
cvm,
obfuscation,
packer,
pe,
protection,
virtual machine
Thursday, May 19, 2011
ChapljaVM v2 - Code mutation/virtualization engine (work in progress, pre-alpha)
Previous release: chapljaVM assembler/scripting
Ok, this is not really related to it because this is now a completely different and way more complex project, but the tool I'm working on now will also support a language similar to what I linked above to be inserted into the executable binary or to be executed from memory using an SDK function.
Click here for a small pre-alpha screenshot
I have done quite a lot of research and have done a lot of testing, which I believe is the hardest part of the work. Now I need to implement everything I've done so far in simpler tests. It's not very hard, but it's a lot of work because really many instructions and cases need to be covered.
The goal is to make a codevirtualizer/vmprotect-like application which allows you to select areas of code you'd like to protect within your C/C++ sources - but with the actual obfuscation being priority, the anti-debugging and similar things being less of a priority and will be implemented after everything else is.
It doesn't do much yet, of course not everything is implemented what is seen in the application window, but almost everything has been tested in various console apps and now needs to be implemented into actual obfuscation engine and this gui version.
I've tested relocation of selected code blocks into a new section which the tool generates and it's working fine (though not finished yet - need to take care of relocations so DLLs are supported in case they're loaded at a different address, but it won't be hard to implement).
These are the first important features I'd like to cover:
- Code mutation (one instruction is transformed into multiple instructions which end up having the same result)
- Code virtualization (will come after mutation is fully implemented)
- Junk code insertion between original instructions
- Other 'standard' features such as IAT obfuscation, debug information removal, etc, not really giving much attention to it now, it's not very hard to implement these)
Hopefully I'll have an alpha version for testing or at least a produced binary of some more complex code within some reasonable amount of time.. will post more updates as the development progresses further.
Ok, this is not really related to it because this is now a completely different and way more complex project, but the tool I'm working on now will also support a language similar to what I linked above to be inserted into the executable binary or to be executed from memory using an SDK function.
Click here for a small pre-alpha screenshot
I have done quite a lot of research and have done a lot of testing, which I believe is the hardest part of the work. Now I need to implement everything I've done so far in simpler tests. It's not very hard, but it's a lot of work because really many instructions and cases need to be covered.
The goal is to make a codevirtualizer/vmprotect-like application which allows you to select areas of code you'd like to protect within your C/C++ sources - but with the actual obfuscation being priority, the anti-debugging and similar things being less of a priority and will be implemented after everything else is.
It doesn't do much yet, of course not everything is implemented what is seen in the application window, but almost everything has been tested in various console apps and now needs to be implemented into actual obfuscation engine and this gui version.
I've tested relocation of selected code blocks into a new section which the tool generates and it's working fine (though not finished yet - need to take care of relocations so DLLs are supported in case they're loaded at a different address, but it won't be hard to implement).
These are the first important features I'd like to cover:
- Code mutation (one instruction is transformed into multiple instructions which end up having the same result)
- Code virtualization (will come after mutation is fully implemented)
- Junk code insertion between original instructions
- Other 'standard' features such as IAT obfuscation, debug information removal, etc, not really giving much attention to it now, it's not very hard to implement these)
Hopefully I'll have an alpha version for testing or at least a produced binary of some more complex code within some reasonable amount of time.. will post more updates as the development progresses further.
Friday, August 7, 2009
chapljaVM - my own x86-like assembler/virtual machine
I have no idea if these are the right terms to name something like this, but I call it my own virtual machine/assembler.
I work on a lot of stuff that relies on security-through-obscurity and also own legal licenses for some commercial protection tools, but I always wanted to make something on my own. I believe that home made protection is usually better than anything else, even if it's technically weaker.
Basically this is an assembler that gets "compiled" into an executable image that can be loaded using appropriate runtime library.
This archive contains an example assembler source code and a "compiler" plus code required to execute binaries.
More information available in the readme.
Download: chapljaVM.rar
I work on a lot of stuff that relies on security-through-obscurity and also own legal licenses for some commercial protection tools, but I always wanted to make something on my own. I believe that home made protection is usually better than anything else, even if it's technically weaker.
Basically this is an assembler that gets "compiled" into an executable image that can be loaded using appropriate runtime library.
This archive contains an example assembler source code and a "compiler" plus code required to execute binaries.
More information available in the readme.
Download: chapljaVM.rar
Browsing vBulletin mysql database dumps
If you have a mysql dump of a vBulletin forum, you don't have to install the entire forum package to read it, you can instead use this simple script I made.
Download: vb_reader.rar
Download: vb_reader.rar
Subscribe to:
Posts (Atom)