- IDA Pro
- Lab16-03.exe SHA256: f36de55cf09c24045f241d50519a2ff1e5578336d0e8426eeabe5b39162d9006
- Detection Rate: 0/56
- Analyzed on 2016-03-19
Compilation Date: 2011-10-22 19:36:11
- View report here
Analyze the malware in Lab16-03.exe using a debugger. This malware is similar
to Lab09-02.exe, with certain modifications, including the introduction of
anti-debugging techniques. If you get stuck, see Lab 9-2.
1. Which strings do you see when using static analysis on the binary?
these are the only strings of interest to us that we can observe statically.
2. What happens when you run this binary?
Nothing happen. It just terminates.
3. How must you rename the sample in order for it to run properly?
In ollydbg, we set breakpoint @0x401518 (strncmp) to see what the malware is comparing against. The executable name needs to be “qgr.exe“. However nothing happen when we attempt to run the malware via command line…
Firing up IDA Pro we trace back the variable that was used to match against the current running executable filename.
Seems like the variable is initially set to ocl.exe. It is then passed to a function where QueryPerformanceCounter was called twice… In between the 2 QueryPerformanceCounter is a Division by zero opcodes that is purposely set there to slow down the debugged process.
The time difference between the 2 QueryPerformanceCounter will determine if var_118 is 2 or 1 which will affect the return result of this subroutine. If we are using debugger the QueryPerformanceCounter difference might be above 1200 due to the triggering of the division by 0 error… if the time difference is above 1200, var_118 will be set to 2 and the filename should be qgr.exe else var_118 will be set to 1 and the filename should be peo.exe.
By manually making sure that var_118 is set to 1 and not 2, we get the following filename; peo.exe.
Renaming the executable as peo.exe will do the trick in running the app properly.
4. Which anti-debugging techniques does this malware employ?
The techniques used are all time based approach
- rdtsc (subroutine: @0x401300)
5. For each technique, what does the malware do if it determines it is
running in a debugger?
- QueryPerformanceCounter – determines what name should the executable be, in order to execute properly
- GetTickCount – crashes the program by referencing a null pointer
- rdtsc – call subroutine @0x004010E0; self delete
6. Why are the anti-debugging techniques successful in this malware?
The malware purposely triggers division by 0 error that will cause any attached debugger to break and for the analyst to rectify. This action itself is time consuming as compared to a program without debugger attached throwing exception and letting SEH handler to do the job. Therefore the malware codes are able to determine whether a debugger is being attached just via the time difference.
7. What domain name does this malware use?