In this section, we will look at how to use IDA to debug a malware binary. Consider the disassembly listing from a 32-bit malware sample. The malware calls the CreateFileW API to create a file, but, just by looking at the disassembly listing, it is not clear what file the malware creates. From the MSDN documentation for CreateFile, you can tell that the first parameter to CreateFile will contain the name of the file; also, the suffix W in the CreateFile specifies that the name of the file is a UNICODE string (details regarding the API were covered in the previous chapter). To determine the name of the file, we can set a breakpoint at the address where the call to the CreateFileW ➊ is made, and then run the program (F9) till it reaches the breakpoint. When it reaches the breakpoint (before calling CreateFileW), all of the parameters to the function will be pushed onto the stack, so we can examine the first parameter on the stack to determine the name of the file. After the call to CreateFileW, the handle to the file will be returned in the eax register, which is copied into the esi register at ➋:

.text:00401047     push  0          ; hTemplateFile
.text:00401049     push  80h        ; dwFlagsAndAttributes
.text:0040104E     push  2          ; dwCreationDisposition
.text:00401050     push  0          ; lpSecurityAttributes
.text:00401052     push  0          ; dwShareMode
.text:00401054     push  40000000h  ; dwDesiredAccess
.text:00401059     lea  edx, [esp+800h+Buffer]
.text:00401060     push  edx        ; lpFileName
.text:00401061  ➊ call  ds:CreateFileW 
.text:00401067     mov  esi, eax ➋

In the following screenshot, the execution is paused at the call to the CreateFileW (as a result of setting the breakpoint and running the program). The first parameter to the function is the address (0x003F538) of the UNICODE string (filename). You can use the Hex-View window in IDA to inspect the contents of any valid memory location. Dumping the contents of the first argument, by right-clicking on the address 0x003F538 and choosing the Follow in hex dump option, displays the filename in the Hex-View window, shown as follows. In this case, the malware is creating a file, SHAMple.dat, in the C:Users estAppDataLocalTemp directory:

The malware, after creating the file, passes the file handle as the first argument to the WriteFile function. This indicates that the malware writes some content to the file SHAmple.dat. To determine what content it writes to the file, you can inspect the second argument to the WriteFile function. In this case, it is writing the string FunFunFun to the file, as shown in the following screenshot. If the malware is writing executable content to the file, you will also be able to see it using this method: