Dummy code - trick for begginers

For quite some time I have been testing the capabilities of OllyDbg 2.01. I have never used this debugger at work, but the project has been developing for many years now and it could be an essential tool for analysts - not only the beginning ones. I wanted to check how it would cope with one of the oldest tricks of crackers - dummy codes. It is a method of hiding the CPU instruction opcodes in the parameters of the assembler instructions. The implementation of such codes in MASM32 is not particularly difficult, but it requires a number of tests before the release of the program - their use can lead to serious runtime errors. The method makes it difficult to analyze the executable code, which is why it is used by the blackHats to hide bugs or - used by software manufacturers to protect intellectual property rights. This way or another, the analyst must be able to recognize such a code. It is not difficult because debuggers start to behave strangely - with the code sliding - literally. The worst part is that only instruction tracking reveals the truth about the program. Below I present an example of using dummy codes in the assembler.

.486
.model flat, stdcall

option casemap :none
 
include         \masm32\include\windows.inc
include         \masm32\include\kernel32.inc
include         \masm32\include\user32.inc
includelib      \masm32\lib\user32.lib
includelib      \masm32\lib\kernel32.lib

.data
   MsgCaption    db "www.FiveWithFour.blogspot.com",0
   MsgBoxText    db "Dummy Codes Example",0

.code
   start:
      invoke MessageBox, NULL, addr MsgBoxText, addr MsgCaption, MB_OK
   @Code:
      add eax, 009Eb336Ah  
      mov esi, 012345678h
      jmp @Code+1
      invoke MessageBox, NULL, addr MsgBoxText, addr MsgCaption, MB_OK  
      invoke ExitProcess, NULL
   end start 

While reading the source we can conclude that the program will throw - one after another - two identical windows of the MB_OK type, containing information. But the result is as follows:

The first window is MB_OK (called within code), but the second one with the same call is a combination of MB_ICONWARNING and MB_YESNOCANCEL - despite the lack of appropriate parameters in the source. The code has been executed in a different way and in order to see how, one should use a disassembler, like OllyDbg which did not cope very well with decompiling, and the debugger leaves much to be desired - at least in terms of the "factory" settings. IDA 6.3 Demo correctly translated the binary code into the assembly code, and the debugger detected the modification of the code during execution. I used a standard build.bat of MASM32 - for those who would like to check out how it actually works. The conclusion is that the free IDA (truncated functions) coped better with an atypical code than OllyDbg. You can find the screenshots of IDA below - the first one relates to a disassembled file - correct according to source, and the second one refers to instructions actually executed by the processor - mov esi, 012345678h in the source it is an additional code - all to deceive the enemy ;-)

Before the code execution:

After the code execution:

The second screenshot is clearly illegible even in IDA. Such a method of code protection against analysis can be a hindrance but also provokes the analysts. The code looks destructive and meaningless, but will not be executed - this is why the dummy codes may be deceitful, but they are not hard to master - their appearance may be the evidence of hidden capabilities of the procedures. It is much harder to analyze even a simple code written in an appropriate high-level language and compiled by one of the all-in-one compilers. Thought experiment with Schrödinger's cat is the simplest way to illustrate this trick ;-)