13 Feb 2010
Having a working Windows c compiler on your Linux system can be very handy for penetration testing and incident response activities, as it allows you to create executables from Windows shellcode to aid in analysis or to compile Windows c based exploits so you can run them on your Linux box using wine.
In this post I will briefly cover the steps required to install the MinGW C compiler on a Linux system.
In order to achieve this, you will need a working version of wine, and you will need to be running your Linux system in GUI mode. Many Linux distributions will have wine available in their repositories, otherwise you can install it from here. I am performing the following steps on BackTrack 4 where wine comes installed by default.
Edit: ColForbin over at the BackTrack forums just kindly pointed out to me that MinGW comes installed by default on BackTrack 4 Final. I apparently missed this because I run BackTrack as a non root user (against the recommendations of the BackTrack Developers by the way), and MinGW is only installed under the root users home directory. So if you use BackTrack 4 Final, you only need to do the install of MinGW if you run as a non root user.
Start by download the latest version of the installer from here.
Now run the installer using wine.
user@bt4:~/Downloads$ wine MinGW-5.1.6.exe
The installer window will appear, as shown below.
Hit Next and follow the bouncing ball through the first few steps, accepting the defaults.
When asked where to install MinGW, install it to the path in the C:\ drive, which wine creates under your home folder in ~/.wine/drive_c/.
Progress through the installer, then wait while the components of MinGW are downloaded and installed.
Once the install is done hit Finish.
To actually use the compiler, run it as follows:
user@bt4:~$ wine ~/.wine/drive_c/MinGW/bin/gcc.exe
gcc.exe: no input files
To compile a Windows c source file into an executable:
user@bt4:~$ wine ~/.wine/drive_c/MinGW/bin/gcc.exe code.c -o code.exe
For programs that require the use of particular libraries, you can also use one of the following command line switches to gcc to compile a given program using the given library:
- -l[library name]
- -Xlinker [Full path to library file]
Examples:
Use the wsock32 library:
-lwsock32
Use the GDI32 library:
-Xlinker C:/mingw/lib/libgdi32.a
09 Feb 2010
To tide everyone over while I finish up writing part 5 of my exploit tutorials (which will hopefully be done by the end of this week), I have a number of interesting links that I have collected recently.
Didier Stevens has been up to some very interesting things recently with getting dlls loaded from memory (so a copy of the DLL does NOT have to be stored on the hard disk). This has very interesting implications for those who are looking for a way to avoid leaving a trail that can be picked up by forensic investigation of the hard drive. He has implementing this dll loading in shellcode and has also managed to create dll based versions of cmd.exe and regedit.exe. I'll leave it up to you to ponder the possibilities/implications of this from a pen testing and/or incident response perspective. Links are here.
The dll loading method used by Didier is also an interesting reference, not least because of the detail it provides on the Windows PE format.
I have already written about how to analyse a malicious pdf document (and if you read that post you may want to know that the PDF tools from Didier Stevens have been updated since), but if you want more information on the topic I have since discovered a number of other references that you might find interesting.
And if you want to analyse other document types such as Word documents, Excel documents, etc? Well, you can try the strings method I mentioned im my PDF post, or you could refer to this or this.
Everyones favorite network scanning tool Nmap (well, maybe its not everyones favorite tool, but its certainly mine) now has the ability to send UDP application level probes when UDP port scanning, giving a much greater chance of getting accurate results from a UDP scan. Given that on the protocol level the correct response for an open port is... no response most UDP port scans can be unreliable. Is that port really open, or is a firewall blocking our probes or the port unreachable responses? Now NMap can send application level data for certain well known UDP services, which should trigger a UDP response at the application level if the associated services is running on the appropriate port. Getting one of these responses gives you positibe proof that a port is actually open. More information here.
An interesting post on bypassing DEP that I ran across.
Last but not least, Richard Bejtlich (he who runs the Taosecurity blog) has recently written an article on how to test Snort using Metasploit. Those who use the Snort IDS might be interested in using this method to find out just how well they have configured their Snort installation, but penetration testers might also be interested in turning this article on its head to see how they can launch attacks that will bypass an IDS. I have done some testing on this myself using Snort as my guinea pig IDS, and I may write something up on this for a future blog entry.
OK, thats it for the moment, look for the next exploit tutorial here very shortly.
