Installing MinGW (gcc, g++) on Kali Linux to Compile Windows Code

Wednesday, March 5, 2014

It is possible to compile windows code natively in Backtrack and Kali using MinGW compiler and Wine. While MinGW comes already installed and configured for users in Backtrack, it does not in Kali.

Let's go over how to install and configure MinGW for Kali and how to use it to compile windows code, but first some quick definitions.

What is Wine?

Wine allows windows applications to be run on several platforms such as Linux, Mac OS X and more.

What is MinGW?

MinGW is a collection of windows development tools including compilers such as GCC and G++. Using both MiniGW and Wine it is possible to compile windows code thus creating a portable executable (pe) which can be later run with wine.

Installing MinGW on Kali Linux

As previously mentioned, MinGW does not come installed on Kali by default. Thus one does not have access to important tools and compilers such as gcc. Let's install and configure it.

  1. Download the MinGW installer from their sourceforge.
  2. Run the installer (mingw-get-setup.exe) with wine.

  3. Select the Install with GUI option.
  4. The MinGW installation manager should now be open. Select mingw32-base.

  5. Select Installation > Update Catalogue on the top left hand corner.

  6. Some missing DLLs will need to be downloaded, download them here
  7. Unzip them and move them to the wine drive_c/windows folder.

Excellent, we now have Mingw installed! You can confirm this by visiting the /root/.wine/drive_c/MinGW directory. You should also have gcc installed under /root/.wine/drive_c/MinGW/bin/gcc.exe.

Compiling Windows Code in Kali and Backtrack

With MinGW installed all we have to do now is use gcc to compile our c code. Below is an example of usage. The example below assumes the user is inside the /root/.wine/drive_c/MinGW/bin directory.

There we have it! Go Compile!

Buffer Overflow: Smashing the Stack Tutorial

Tuesday, October 22, 2013

Buffer Overflows or stack smashing are common attack vectors. There are numerous tutorials online on how to perform buffer overflows and the theories behind them, but in this example we'll dive in a little deeper.

What you'll need:

Please remember, this is solely for educational purposes. 
The techniques mentioned below are not to be used for malicious purposes outside of a controlled research environment.


A stack overflow is accomplished when one overwrites the space allocated for the stack. Let's take a look at simple example. Below we have a program which takes a five digit zip code from a user and places it into an array of five elements. Can  you see a problem with this program?

If you were thinking that there was no bound checking you are correct! This program does not validate user input thus allowing a malicious user to input a zip code containing a thousand characters if s/he wishes. Let's check to see how the stack looks like during the execution of this program. The image below depicts the Stack Example.

For simplicity purposes I have divided the stack into three blocks. The first block will contain the zip code array, the second block will contain the saved frame pointer (ESP), and lastly the return address (EIP). Once the user inputs his/her zip code the character array will be populated as shown below.

Excellent. The program seems to be working thus far. The zip code, 89101, was stored within the zip code array just fine. However, what happens when a user decides to send a thousand characters? Let's take a look.


 Oops! The program has crashed. This happens because the program had no bound checking. If the program were to have implemented input validation and used the strlcpy instead of strcpy function then this could have been avoided.

Now you may be asking yourself, how exactly can someone exploit this? Well, if the user wants to inflict some damage then s/he must find enough space for their payload and make the application point to the payload at the time of the crash. Let's go through this in detail.


Before we get started, be sure to go through the bullet points below to make sure you're ready to go:

  • Ensure that both of your virtual machine's (windows and kali/backtrack) network settings are set to internal/host only.
  • Install Free Float FTP and Immunity Debugger onto your Windows OS.
Great you're locked and loaded. In order to see and investigate the crash we need to attach the FTP server to a debugger, Immunity Debugger.

Open Free Float FTP and Immunity Debugger. Once inside Immunity Debugger go ahead and attach the FTP executable.

Next, click on the play button (F9) in the toolbar. We are now running the FTP server successfully under Immunity.  Check out the application's register values on the top right column within Immunity. They should look like the ones depicted below.

Now, let's move on to the fun stuff. In your Kali/Backtrack machine let's make a simple proof of concept code to see the crash happen. In this application, the buffer overflow vulnerability is trigged when a user submits 1000 characters to the application. Every application is different and requires fuzzing in order to determine the point of the crash.

Our proof of concept script below submits a thousand letter A's to the application using the FTP MKD command.

If you do not understand what this program is doing then I highly recommend you visit the python documentation.

After running the proof of concept script we can see that the FTP server registers (specifically ESP, EDI and EIP) within Immunity debugger have changed and are now populated with letter A's (EIP is populated with 41414141 which is the hex value for letter A). This means we have successfully trigged the buffer overflow vulnerability!

Now that we have overwritten EIP we must find where exactly EIP was overwritten. To do this we will use metasploit's pattern create and pattern offset scripts. The pattern create script will create a unique string for a given length. We will create a string consisting of 1000 characters and place that into our program's buffer variable.

Be sure to restart the debugger and FTP application before running the proof of concept script again. Once executed the registers will now be overwritten with the unique pattern. EIP, ESP and EDI should be overwritten. Copy the EIP value (should be 69413269) and use metasploit's pattern offset to figure out exactly where the location of EIP is at the time of the crash.

Great, we can see that the offset or location for EIP occurs at the 247th byte. Repeat this process for the other registers to obtain their respective offsets.

We now have the locations of EIP, ESP and EDI. In this example we will be placing our shellcode at the beginning of the ESP register, but first we must find an instruction to jump to our shellcode. What does this mean? Let's break that concept down.

An application is constantly performing actions and going through instructions. Our goal is to control the execution of the application. Once we control the execution then we would be allowed to insert our own instructions.

The EIP register keeps track of the address for the next instruction. In other words, it controls program execution. What we must now do is find an instruction within that says go to ESP or jmp esp which would make the application go to our shellcode.

Within Immunity click on View > Executable Modules and select user32.dll. We should now have User32.dll loaded within Immunity. Right click within the module and search for a command containing JMP ESP.

Great, we now have the JMP ESP instruction located at 768C4E5B. Now within our proof of concept we will place this value in little endian after the EIP offset followed by our shellcode after the ESP offset. I used metasploit to create shellcode to execute a windows calculator. 

Be sure to also include some NOPs (\x90) for shellcode padding and then restart the FTP application without Immunity debugger and launch the proof of concept code. There we have it! 

We have successfully exploited the buffer overflow vulnerability for Free Float FTP and hopefully obtained a better understanding of buffer overflows. Check out the full proof of concept code here.

Go Further! 

I highly encourage anyone to dive deeper into this subject matter. This example was very simple but there is much more to be learned. Go check out some of the sites mentioned below for a better understanding.

Special Thanks to b33f @ Fuzzy Security. Be sure to check out his in depth exploit development tutorial at fuzzy security.

MySQL Injection: Manual Enumeration

Friday, August 30, 2013

Let's build on last week's post and go over some manual My SQL injection techniques. After reading and trying out some combinations of manual SQLi I believe these are a good bunch to use.

If you want practice with manual SQLi I recommend loading some vulnerable web applications such as bricks, webgoat, or dvwa. You can also check out our friends at for pre-built VMs.

Although tools like SQLmap make our life easier, it is still good to know how to manually test a database.

Please remember, this is solely for educational purposes. 
The techniques mentioned below are not to be used for malicious purposes outside of a controlled research environment.

Our goal in this scenario is to use a UNION SELECT query but in order use it one must first know the number of columns in the database. Let's dive into it!

Number of Columns

Detecting the number of columns can be done in two ways. The first method is using ORDER BY clauses and increment the number of columns till an error is depicted. 

The second method is using a UNION SELECT query and incrementing NULL values.

Vulnerable Columns

Great so we determined how many columns are contained in the database, but now let's see which columns are the ones depicted by the web application on our screen. To do this we provide a false query and the UNION SELECT query.

Go Enumeration

Now that we know the number of the columns being depicted on the screen we can use those to enumerate the database. In this scenario column 1,2 and 3 are being depicted so we can use any of those to query the database and see the results.

Working Directory

Database Name

Table Name

Column Name

The first number in LIMIT is the column number (i.e. LIMIT ,1) . Increase that number to see the different columns within the database.

Pulling Column Data

We now have the database name, table name, and column names. Let's pull some data from columns named 'username' and 'password'.

Hidden Bonus: Congrats! You found a hidden bonus. Use 'file_priv from mysql.user' and 'load_file('x')' to check for LFI vulnerabilities. Remember to use this in a controlled research environment and not for malicious intentions!
 That's it! There might be some modifications one might do depending on the web app (e.g. adding quotes, comments). The mitigations to this are the same as our previous post on MS SQL injection.