What is being passed as parameter to the subroutine sub_402D70 in the CALL that is found in address 0x004035E6?
In 16-02. It would seem that the password is easy to guess, but... 1. It sets up a TLS which terminates the program if being run under debugger.
- Before the string comparison, it runs a thread that performs some sort of decoding of the compared string. If you run the debugger it doesn't run the thread?
Some anti-debugger snippets are included throughout the exec which prevent the password from being properly decoded (when looked through the debugger). Just use a concealment plug-in, correclty conceals the debugger from the techniques and shows the password!!.
Anti-debugging techniques.
In this lab we will be analyzing a Windows executable that uses some of the anti-debugger techniques we discussed to make life misserable for the reverse engineer. It is classified as malware by virustotal.com so proceed with caution. We will be conducting a mixture of static analysis using IDA and dynamic analysis using Immunity Debugger.
https://tuts4you.com/e107_plugins/download/download.php?view.2168
This lab is an adaptation of Lab 16-2 from the awesome "Practical Malware Analysis" book.
-
Download the executable available at http://rarceresearch.fun/misc/Lab16-02.exe.
-
Run the executable from the command line (
wine Lab16-02.exe
). What happens? -
Try guessing the password. Did you get it? Describe the response of the program?
-
Open Lab16-02.exe in IDA and lookk briefly through the
main
subroutine. Can you explain the delay that you observed after you ran the program from the command line? -
There is a
call _strncmp
at0x0040123A
that seems to compare the string you provided in the command line to some other string in memory. How would you convince someone that the comparison is actually against the command line argument? -
What is the address of the string that is being compared to the string received from the command line?
-
Can you guess what is the password from the parameters passed to the
call _strncmp
? Explain how you came up with the guess and try it in the command line (if possible). -
Guessing the password from the static analysis is very hard because this program is performing some modifications to the data before the actual
strncmp
. Thus a logical next step would be to load Lab16-02.exe into a debugger and let it run up to just before thestrncmp
and look at the parameters in the stack. RunImmunity Debugger
, loadLab16-02.exe
and set a breakpoint at0x0040123A
. Then run. What happened? The program seems to have dissapeared from memory!!! This must the work of an anti-debugging technique. But which? According to the IDA disassembly nothing much happened between the start of themain
subroutine and thestrncmp
. -
The reason you are not even able to get to the breakpoint is that this program implements a TLS that disrupts the program execution when it detects that its being run in a debugger. Let's see.
-
Run
PE Explorer
, openLab16-02.exe
and explore its section headers. The section called.tls
. is the telltale sign that this program contains TLS code. Write down the virtual address of the TLS code since you will need it for the next steps. -
In IDA inspect the code that starts at the virtual address that corresponds to the TLS code. Notice that IDA had identified as
TlsCallback_0
. This is the TLS subroutine that is being called before the actualmain
subroutine of the program. Which of the techniques discussed in class is this subroutine using to disrupt the flow when it detects that "OLYYDBG" debugger is present? What action is taken by the subroutine whe it detects that the "OLLYDBG" debugger is present? -
Patch the instruction at
0x40107c
with NOPs so that the program is not exited when this subroutine detects a debugger. -
If you haven't already, create a breakpoint in the
call _strncmp
instruction at0x40123a
. Thiscall
is part of themain
subroutine, which will exit the program unless it receives two command line parameters. To pass a string toLab16-02.exe
from ImmunityDebugger chooseDebug
-Arguments
and enterLab16-02.exe
followed by your guess of password. Make sure that the patch of NOPs at0x40107c
is still active. -
Run the program until the debugger stops at the break point
0x40123a
(thecall _strncmp
). Notice how ImmunityDebugger has annotated the arguments the_strncmp
. What is the value of the string that is being passed as second parameter to_strncmp
? -
Try that string in the command line to test if you've got the correct password. Hint: The password is still wrong becuase the program is performing several other debugger detection tricks that mess up the comparison string. In other words, unless you patch all the debugger detection maladies you will see a wrong string being passed to
strncmp
. This is getting tedious.... however... -
Luckily there are plugins that you can download for Immunity Debugger that will help it avoid the detections of anti-debugging malware. In other words, the plugin will allow Immunity to debug a malware and the malware will think that it is NOT being run by a debugger. Once such plugin is called Imm_PhantOm Plugin 1.54 available at https://tuts4you.com/e107_plugins/download/download.php?view.2168.
RUN IN WINDOWS!!!!! CHECK ALL PAHTNOM OPTIONS IN OLLYDBG USE THE VERSION THAT COMES WITH ALL THE NEEDED PLUGINS!!!
- If detection of "OLLYDBG" fails, the program could call
sub_401020
. What doessub_401020
do?
as part of the TLS section. Study the subroutine that starts at 0x401020
. Which of the techniques discussed in class is this subroutine using to disrupt the flow when it detects that a debugger is present?
- In Immunity Debugger inspect the subroutine that begins at the virtual address that corresponds to the TLS code. Don't get confused by a few
0x00
and0xCC
Try guessing the password from the disassembly provided by IDA. What is the address of the string that is being compared to the password entered in the command line?
Perform static analysis using IDA Pro Demo to follow the steps bellow and answer the questions.