Luigi Auriemma

i have been able to sucessfuly use aluigis method to delete my own server.cfg, however when i tried on linux and other windows systems, it was un effective, any advice on how to use this poc would be helpfull.

the last time I checked this bug (17 Sep 2009) the bug was still unfixed because valve failed in doing that job (pfff).
so try writing "cfg\server.cfg\hello.txt" (with the null byte at the end) over the XXXXXXXXXXXX (25 'X's) and redoing the test.
for testing the bug on linux try also substituiting \ with /

Sorry for the lack of corispondance, i forgot all about this post lol.

so, this is a copy of my current .c file,

http://www.xtcr.net/myproxocket.c


i tested this on my home box, windows, and it worked like a charm.

i tried it on my linux remote box, didnt work at all, so i tried it on my remote windows box, with no sucess.

firstly, i dont understand why i had to change

static u8 myinput[] = CLIENTS_FILE;


and then define clients file, otherwise, nomatter what i enter in as the variable, it says to hex edit it:


that line of code basicly says that if the imput is the same as the imput, give an error. am i wrong? what am i missing here? reguardless, changing the imput to a new defined variable worked, but im just so confused as to how this thing actualy works, i get that im supposed to pop in the path to the file and with a null pointer,

EG: server.cfg/1.txt.xxxxx etc,

why is it not working on remote systems but it is working on my local system? user policies?

i would like to note that i tried both compiling it and hex editing the one that you provided. neither work, however i am still able to use it against my home box, with the current source version, so i belive its not patched.

any advice at all? ive been trying to get this to work for weeks but im stumped and its pretty frustrating lol,

ive tried a douzen different combinations of files, such as

/cstrike/cfg/server.cfg.1.txt.XXXX....XXX

or

\cfg\autoexec.cfg\1.txt.XXXX....XXXX

and even what you told me to retry.

i just dont get why it works localy but not remotely.

you can remove both DEAFULT_FILE and any reference to it like that strcmp

and a small possible problem is the fact that CLIENTS_FILE contains all those X after it, while it should terminate after 1.txt.

the Xs I used where placed there so that who wanted to test/proove the bug but had no time/desire to recompile the code would simply overwrite them in the dll with the needed filename.

then note that the proof-of-concept CANNOT work with the newer versions of the Source engine (those released months ago to fix all the bugs I found) because I used a work-around for building the packet (read the comment near build_standard_file_upload_pck) which was part of another bug fixed in those new versions.

I verified that the file deletion bug wasn't fixed reallowing my custom packets on the server modifying a check inside it, but by default you can no longer use that code.
you must reverse the protocol better to reach that upload zone

i see, thanks for the quick response, do you have any advice on how to reverse the protocall?

reversing the protocol of an application is something natural if you have the needed knowledge, that's why is impossible to answer to your question: if you were able/had the knowledge to do it, you didn't need to ask it.

anyway if you need some advices: ollydbg, x86 assembler, some experience in analogue reversings and tons or patience