Removing Debugging Information from Visual C++/C# Projects

It’s often surprising how many malware programmers forget to do the simplest things. Mostly because many are so concerned with functionality, stealthiness and other production concerns, that details slip easily of their minds – a clear advantage to forensics. One of these details is the Program DataBase (PDB) information added by Visual Studio, which most malware authors used for Windows development. While it may seem innocuous, this string reveals a lot about the operating system used by the author, its user name and most notably, symbols that can be used by IDA and ease understanding of the disassembly.

Share

Introduction

It’s often surprising how many malware programmers forget to do the simplest things. Mostly because many are so concerned with functionality, stealthiness and other production concerns, that details slip easily of their minds – a clear advantage to forensics. One of these details is the Program DataBase (PDB) information added by Visual Studio, which most malware authors used for Windows development. While it may seem innocuous, this string reveals a lot about the operating system used by the author, its user name and most notably, symbols that can be used by IDA and ease understanding of the disassembly. This information allows to link multiple pieces of malware together, by using the username for example. Of course, this also allows for the creation of signatures. Thus, removing this information will add a hurdle to the analysts.

Contents

The Program Database File

The Program Database (PDB) is a binary file used to store debugging information about DLL and EXE files. The PDB file is created when you build your project and stores a list of symbols  their addresses along with the name of the file and the line number on which the symbol was declared. PDB files is also used for services collecting crash data to send it to developers for resolution.

Debugging Information

In Visual Studio, you can select to build your project in Debug or Release mode. In Debug mode, VS will include debugging information with your executable. In Release mode, no debug information is included by default, but in some cases is enabled so that if the program crashes, information can be retrieved and sent to the author for fixing. However for some reasons, some developers don’t really bother to use the Release mode, and simply use the executable generated by the Debug mode. Generally, you don’t want that if you are making malware (or any program really!). If left within the executable, a path to the PDB file will be included and can be extracted:

Path to the PDB file
Path to the Program Database (PDB) file used by Visual Studio for debugging purposes, extracted using the “strings” program.

Within the strings, you can determine that:

  1. The program was developed on Windows 7+ (because of C:\Users folder),
  2. The username of the developer is SUPPORT_23e45RT
  3. The source, or part of it, can be found on Github
  4. The original name of the program is CaitSithTest

These indicators can be useful to link this specific program with others and provide a common link between multiple malware. Additionally, the username could potentially be used to conduct open source research and find linked accounts or forum posts. But wait, there’s more…

If you leave the debugging information, you may be able to restore all the original names of variables and functions of the source code using IDA. IDA will first detect debugging information and ask the analyst if he wants to retrieve it, either via Microsoft – http://msdl.microsoft.com/download/symbols (not browseable)- or by looking locally.

IDA detected that debugging information is available and ask if the user wishes to retrieve it.
IDA detected that debugging information is available and ask if the user wishes to retrieve it.

If for some reason, the user is able to retrieve the information, he will have access to the names of the original symbols, which will make reverse engineering much more easier.

Since symbol information is available, the original names of the variables are displayed.
Since symbol information is available, the original names of the variables are displayed.

Compare the information from the figure above to the figure below, in which debugging information has been stripped at build time:

IDA could not find any debugging information and thus used its own labelling system to identify variables.
IDA could not find any debugging information and thus used its own labelling system to identify variables.

You can see that the variables defined in the first figure, such as ClipboardData, isProcessElevated and isDebugged have been preserved. By keeping information about the symbols, reverse engineering is much more easier compared to figure 2, in which information about the code is lost.

Disabling Debugging Information

To prevent VC from including this information in your executable, right click on your project, go to Project Properties > Linker > Debugging configuration menu. Select No in the Generate Debug Info option.

Removing debugging information in Visual Studio.
Removing debugging information in Visual Studio.

After doing this, rebuild your project and rerun the string extraction program against your binary, the path to the PDB file should not be present in the executable anymore.

no_debug_info
The path to the PDB file is not included in the executable once debugging information has been omitted.

Doing so makes it a bit more difficult to fingerprint the malware and hides information about the author’s system.

Conclusion

This is a simple tactic that is often omitted not only by malware author, but penetration testers, which are often Google programmers, i.e. copy-pasting code snippets from Stack Overflow or googling functions ūüėČ If you attempt to hide your malware into the System32 folder, looking for this information in the EXE or DLL files will quickly tell you which files are bad, since legitimate files will rarely have this info, or have legitimate looking one. As such, if you want to make sure, create a legitimate-Microsoft-looking user (Bill.Gates) on your machine and put your code into a Microsoft-looking project and path (C:\users\Bill Gates\Documents\HTA\Release\).

Starting in Exploit Development – Day 03

Share

Today I’ve followed part 3 of the FuzzySecurity tutorial, which went pretty smoothly now that all the VMs and software have been setup and fixed. In the end, I was successful in binding a shell to a port. Yet, I had the feeling that I often have when learning by tutorial: it works now, but would I actually be able to replicate this while exploiting another application? And what really happened? I mean I have loaded my shell code, but yet, I don’t have a clear understanding of what SEH really is. So after completing the tutorial, I actually took time to try to figure out what exactly happened.

The Structure Exception Handler (SEH)

The SEH is a Windows native mechanism to handle both hardware and software exceptions in Windows at both kernel and user spaces. So when the normal flow of an application is interrupted, the SEH comes in to handle the management of the interruption. Basically, this is the native component of Windows which triggers the¬†try…catch…¬†statement you use in your programs. So how does SEH works?

SEH3 Stack Layout
The overall layout of the SEH in the stack (by Igor Skochinsky – 2006)

As depicted above, the SEH is a linked list in memory, in which each nodes contains 2 pointers; one pointer to the next node in the list and one pointer to the function who handles this specific exception. There is a node for each exception handled by the current function. These nodes are basically all your “catch (FileNotFoundException)…catch(NullPointerException)” etc…. Each node of the linked list stores the pointer to the Structure Exception Handler and a pointer to the next Structure Exception Handle. The root node, the default exception handler is actually stored in the stack. So in this tutorial, when we smash the stack, we gain control of those 2 pointers, which we will use to jump to our shell code.

So in this case, what is happening is that we smash the stack with “A”s, overwriting EIP with an invalid pointer (0x41414141). Since this is not a valid value, an “Illegal Instruction”/”Access Violation” exception is thrown and thus triggers the SEH handler code. This means the code pointed by the “SEH Handler” [SEH] part of the stack will be called, which is actually a call to the next node in the SEH linked list.

By writing an address pointing to “POP POP RET” instructions at [SEH] and having it executed them, we will load the stack address of [nSEH] into EIP and as such, execute the op code at [nSEH]. So if we insert a short JMP to the address of our shell code (0xEB06 [shellcode]) at the address pointed by [nSEH], we’re done.

This technique won’t work with SafeSEH and SEHOP.

Moving on with Exploiting DVDX Player

You should have no issue generating the Playlist file to overflow the EIP register and trigger a exception.

Crashing EIP of DVDX Player
Crashing DVDX Player by overflowing EIP with a specially crafted playlist

Then by replacing the long string of “A” by a Metasploit pattern and !mona findmsp, we can find the offsets, as in past tutorials;

Offsets calculated by Mona when exploiting DVDX Player
Mona located the Metasploit pattern overwritting the SEH record at 608 bytes and 1384 bytes for our payload

Since we’re interested in exploiting SEH in this tutorial, we’re interested at which offset ¬†the SEH is being overwritten by the Metasploit pattern. In this case, it’s overwritten at 608 bytes and we have 1384 bytes of buffer for our shell code. That means that the nSEH is at 608 bytes and SEH at 612: “A”*608 + [nSEH] + [SEH] + [Shellcode].

To link with what we’ve read in the first section, here is what happens: Our string of 608 “A” will crash the EIP and cause an exception, jumping directly to the contents of [SEH]. [SEH] must contain an address. [SEH] is located at [ESP]+8 at execution. Remember that the ESP is an indirect pointer to the top of the stack, and the stack grows downwards. By POPping two times and returning, we will load the stack address of [nSEH] into the EIP and execute whatever instruction at this address. To be perfectly honest, I’ll need to further understand this part….

Accordingly, we will look in memory for a “POP POP RET” combination using “!mona seh“. Mona will return quite a few results. We will prefer results located in DLLs owned by DVDX Player, since they are OS-independent.

Using Mona to locate POP-POP-RET to defeat SEH
Mona returns multiple POP-POP-RET combination to defeat SEH.

We’ve picked up 0x640345e7 (“\xe7\x45\x03\x64”) since it’s located within DVDX Player and contains no invalid bytes. We now got the [SEH] part of our payload:

Now for [nSEH], we’ll need to put a “jmp [offset]” instruction in it. ¬†Our shell code begins right after the [SEH] (4 bytes) and our jmp instruction is 2 bytes. The short jump op code is 0xEB, followed by the number of bytes to jump from EIP, i.e. 6 bytes. So the instruction to insert at [nSEH] is “\xeb6\x90\x90”:

All that is left is the shellcode, which is a quick NOP slide and a shell bind. Done! Excited, I plug the payload into DVDX Player and fail miserably to have have the shell code executed. I used the same shell code as the previous tutorial in an attempt to minimize the number of things that can go wrong. By doing so, everything went wrong. Well not exactly everything, but the previous shell code had byte “0x1A” in it, which created additional READ exception in the code once the shell code loaded. So I regenerated the code without bytes 0x00, 0x0A, 0x0D and 0x1A and everything went perfect. Or almost. When running the shell code, Windows asked me to unblock port 4444 to listen to inbound connection. I guess using a reverse shell or a “download and execute” is quieter…

Windows Asking to Unblock DVDX Player
Using a shell_bind_tcp payload will result in Windows asking you to unblock the application you are exploiting.

I wonder if anything I wrote made any sense since I’ve been so focus into this exploit today. The ascii diagram from FuzzySecurity summarize the principle well enough:

Summary of the SEH Exploitation Technique
Summary of the SEH Exploitation Technique from FuzzySecurity (c) b33f
Well enough for today, my frontal lobe is overheating. More tomorrow…

[1]¬†“Structured Exception Handling.” Windows Dev Center. http://msdn.microsoft.com/en-us/library/windows/desktop/ms680657(v=vs.85).aspx (accessed March 15, 2014).

[2]¬†Skochinsky, Igor. “Reversing Microsoft Visual C++ Part I: Exception Handling.” OpenRCE. http://www.openrce.org/articles/full_view/21 (accessed March 15, 2014).

[3]¬†Mariani, Brian. “Structured Exception Handler Exploitation.” Exploit-db. http://www.exploit-db.com/wp-content/themes/exploit/docs/17505.pdf (accessed March 15, 2014).

Starting in Exploit Development – Day 01

Share

I’ve always seen exploit research and development has the pinnacle of computer security, the ultimate black art of hacking, probably because writing exploit requires full understanding of low-level memory and CPU operations. And given the complexity required nowadays to not only find a vulnerability, but actually exploit it, given protection such as DEP, ASLR and EMET, keeps amazing me. Just tonight, a Chinese team successfully pwned Safari and Flash at the annual Pwn2Own[1]. They could have make serious money on the black market with these two exploits. So I asked myself recently: why don’t I start learning exploit development? There’s certainly a future in it.

As such, I’ll be starting at the bottom and follow the Fuzzy Security tutorials, which seems quite detailed. Today, I’ll be following part 1¬†and part 2, using a virtualized Windows XP 32-bit box. I’ve downloaded Immunity Debugger and Mona.py and Metasploit, filling out those pesky registration form. Of course if you are not aware yet, use FakeNameGenerator and 10 Minute Mail, which work for all these sites. I’ve skipped¬†pvefindaddr.py since it wasn’t available for download anymore. You’ll also need Python 2.7+ for Immunity Debugger.

Basically, I have a quick setup of 2 virtual machines; one runs Windows 7 64-bit with Metasploit 4.8.2-1 and Python 2.7.6, the one is a Windows XP SP3 32-bit machine with Immunity Debugger, the Mona.py script and the vulnerable FreeFloat FTP. With VirtualBox, I’ve set a Host-Only Adapter on both machines on the same virtual network.¬†Copy the mona.py into the¬†C:\Program Files\Immunity Inc\Immunity Debugger\PyCommands folder. If you’re using something else than Backtrack or Kali, you’ll need to download and install a Ruby interpreter and the Development Kit¬†to use the pattern_create.rb of Metasploit. When installing Ruby, make sure you select “Add Ruby executables to the environment path”. Finally, once you have, you need the “bundler” package for Metasploit. Within the Development Toolkit, run the “devkitvars.bat” file. This will add the DevKit to your PATH. Simply type “gem install bundler” and you should be on your way.¬†Or so I thought…

Metasploit then complains it cannot find the rake-10.1.0 sources….What a pain. ¬†That’s because the version or Ruby I’ve install contains Rack version 10.1.1 instead of version 10.1.0. To install the correct version use the following;

This will install the correct version. Unfortunately, the same problems happens with additional packages. After trying to install each of them manually, I got tired of it, so I try the “bundle install” command, which needs to be execute from “C:\metasploit\ruby\bin” folder;

WTF? I’m pretty sure I’ve just install this…whatever, let’s try again…

Dammit…After some Googling I find a forum post that recommends to try a few commands to clean the packages:

After a few seconds, seems that new packages are installed. I’m hopeful that I can finally start exploiting stuff…

At this point, I just give up and install every damn packages I need manually. After 10 minutes of this I just rage quit when the network_interface-1.0.0 package kept failing to install. I’ve downloaded an ISO of Kali. The only success I had tonight was overflowing the EIP register…guess I have a long way to go…

Overflow of EIP

[1] Mimoso, Michael. “Keen Team of China Takes Down Safari and Flash at Pwn2Own.” Threatpost English Global. https://threatpost.com/keen-team-of-china-takes-down-safari-and-flash-at-pwn2own/104790 (accessed March 13, 2014).