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
rasm2 -d 90909090819000c300038b00531b53ff00780000
adc dword [eax + 0x300c300], 0x1b53008b
inc dword [eax]
.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
add dword [eax - 0x34a79770], edx
sar dword [eax + 1], cl
add dword [eax - 0x7e6f6f70], edx
add bl, al
add byte [ebx], al
mov eax, dword [eax]
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.