Luigi Auriemma

If you replace one of the gcf files with a 0 byte file, and write protect it you should be able to do this. I believe it's something like sourceinit.gcf.

VAC runs client side, so it knows your steamid before you connect to a server. It's entirely possible that it could ban for this, but Valve isn't exactly a fast moving company here.

The real question is if this has been reported to valve yet or not?

Good thinking, I'll try and write a stand alone plugin for people who don't want to run SourceMod just for this.

Go make a fake players bug and add this to it lol.

If you disable VAC locally (via sourceinit.gcf), you won't get banned, but you also won't be able to connect to secure servers. (or this was the case when I did it a year or so ago).

I've forwarded a link to this thread to Valve, with any luck they patch this relatively soon (in valve time that is)

You mean they'll just bite their nails and hope that only a few people read this thread. That sounds more like VALVe.

this is exactly the first thing I did for my local test, but obviously an Internet server needs the correct key and cookie (I guess they are retrieved by the player when he logs on the steam network) which are not implemented.

If anyone else is attempting to block this in SourceMod, OnClientCommand is not fired for these commands for some reason. You need to manually hook every available command. I've updated my plugin to prevent this: here

OnClientCommand() is very weird. I've stayed away from it for quite some time.

I was able to successfully reproduce it using the second tutorial.

Will I be VAC banned?

no because with the second method (sudppipe) it's impossible for the client and the server to recognize that there is something in the middle of the connection, indeed you can even use sudppipe remotely (like on a virtual machine)

If you're right, I'm a very happy camper. Now I know how these bastards are doing it. I'm no expert at networking at all, but if it was simple enough for me to accomplish, it's simple enough for anyone.

Thanks for the proof of concept, I'll be checking back regularly for updates.

*EDIT*

I had some free time and decided to make a quick test for completing the discussion about this bug and talking about other (known) problem.

the full list of commands which lead to the NULL pointer vulnerability are the following:


I have also noticed that using the "say" command the message is displayed from the "Console"... nothing important (although irritating for the admin) but I guess it's another bug that Valve should solve.

instead in attachment there is a quick proof-of-concept for testing a known problem with commands like dump_globals, sv_soundemitter_flush, sv_soundemitter_filecheck, sv_findsoundname, sv_soundscape_printdebuginfo and rr_reloadresponsesystems (does almost nothing).

these commands cause a big consuming of CPU in the process of the server (srcds.exe) so if they are used too much frequently the server freezes completely.... yeah another task for Valve but as already said this problem is public from long time (this is the first time I touch the Source server, but on Google there are various references to it) so I don't know why it's still unfixed.

*edit* removed the proof-of-concept because not necessary although enough interesting from a techncal point-of-view

New update:

http://forums.alliedmods.net/showthread.php?t=93934

I have seen that you maintain also a list (http://code.devicenull.org/index.php?ti ... 2_Exploits) of the known public problems affecting the Source engine which seems very useful to known if a problem is already known.

if I'm not in error it doesn't seem to include the commands which cause CPU and resources consumption like dump_globals, sv_soundemitter_flush, sv_soundemitter_filecheck, sv_findsoundname, sv_soundscape_printdebuginfo and rr_reloadresponsesystems or are they indexed with a different name/description?

then about the A2C_PRINT thing, it can be defined as a bug only in two occasions which probably Valve didn't consider:
- flooding with spoofed IP address (because the engine blocks those from the same after a certain number)
- the usage of the bell char (0x07) if the server runs in console mode (the most used mode) and with the beep service active (default)

anyway the bell bug or the generic "spamming" on the console can be exploited also in tons of other ways, so for the bell problem the only way is to disable the useless beep service: sc config beep start= disabled

Funny you would mention the BELL character, I found it awhile ago. Adding large numbers of BELL to your name can be really annoying to all the players, as the server lags really hard.
It causes massive havoc on Windows servers. Does the box actually beep?

the problem is not just the beep (ok I want to exclude the human factor of being lightheaded by the endless beep) but in how the Windows system reacts.
this OS seems to have very heavy problems with the handling of the beep causing even the freeze of the entire computer (so not only the process) which becomes completely unusable.

anyway just recently I had the occasion to test the effect of the bell bug in the console dedicated server of another game (Trackmania) which doesn't filter the bad chars and although both the beep and freeze effects were present as usual the server's process didn't seem to have problems or big problems in its work like accepting the players from my other test computer.
That was enough unusual because with other games I remember to have ever noticed the freeze of the process activities too.

using isprint() is a requirement when is planned to write a console server.

Interesting. I've never heard of this BELL bug until now. How would one go about adding to their name as a means of testing?

Is this what it looks like? I add this to my name in CS and it shows up as a box.

???

the char is created keeping ALT pressed and typing 007 on the numeric pad at right but usually it's not supported in-game or by the most text editors.

so the simplest test is editing the configuration file which contains the nickname with notepad++ and adding a couple of these bell char with the ALT+007 sequence at the end of the nickname (they are easily visible because displayed with a black backgrounded "DEL" signature).

I've attached a program that copies a character to your clipboard by it's ASCII code.
Just insert the number 7 and press "To Clipboard". Now you can paste it into a textbox.
Please take note that on source you CANNOT SEE the character, although it is there.

Wow, I am very surprised. First of all, I'm new to this forum, about 1-2 months I'm looking for Counter-Strike: Source exploits, bugs but more like server crashing. As far I see other concepts and methods on other websites,Videos I actually found the source of this. I cannot believe the things I find online are actually the people in here. Which I am quiet happy about. I have managed to find other css crashing script I know I should have made a Topic but since its related here ill just post it here:
The command to crash cs:s servers doesn't require sv_cheats 1

dump _ entity _ sizes (delete the spaces in between) by simply spamming this to the server can crash it, make a bind like:
bind mwheeldown "dump _ entity _ sizes;dump _ entity _ sizes;dump _ entity _ sizes;dump _ entity _ sizes"
and just scroll down more than once will crash the server now. I allways thought that if it is possible to crash a server Without actually joining it, or even on the loading screen, now i have found some programs, UDP flooders, a DOS working one and a GUI one they both work good, they are both private, I dont like using them since their are like very illegal and just not confort with that so far i found this topic was looking for it for 5 hours, can you actually send command to the server side? while your on loading screen I'm just new to this forum if possible can someone explain how to do it in details thanks.

I have found Videos on YouTube I don't exactly know if they snatched it here, don't even know if this is a normal cfg script but watch this
http://www.youtube.com/watch?v=8ScKSfsd3TU <---------------- This one just shows the concept that his friend is just retrying, disconnecting, and joining again and at the last it crashes
http://www.youtube.com/watch?v=970VQZ6Ng6Y <---------------- This one is actually like this one stops at loading screen and crashes. ( a guy named haloshadow ? familiar with this guy?)
http://www.youtube.com/watch?v=FF446hjTUVM <----------------- This is actually the one who actually rejoines but never even gets in to css and types exec crash or what ever just join and keeps retrying then server crashes

so, my point is that is it really possible by SCRIPT (CFG) or do we need like a program running on the background? and i still didnt get this topic is it a CFG or a tool will anyone explain thank you.

OMG, OH MY GOD, OKe guys, i just did it xD oke um Will i get a VAC ban for this I dont get it >.< does this overlay steam?

It really doesnt matter if it doesn't join the server but it connects to the server ! please Looking forward to your reply!

oke, i dont get this aluigi, what do you mean by "no because with the second method (sudppipe)" whats the second method, i just put the dll's the 2 dll's only in to css directory when even i join it crahses um will i get banned?

practically the second method for testing these bugs acts like if there is a "packets modifier" in the middle of the connection and not inside the process space of the game, that's why with the sudppipe/proxy method the client (where resides VAC) has no possibilities to know if there is a function hooker running in the process because it's all at another level (indeed the proxy can be used even on another machine instead of the local computer).

for the question about the "scripts" (I guess you refer to the in-game sequences of commands usually called scripts) well all depends by the type of bug and its level.
for example all the recent vulnerabilities found by me (or almost all of them) require a direct modification of the packets which is impossible to do simply in-game because it's just a modification of the low level protocol used by the game engine and not a simple sequence of repeated commands that anyone can do.

anyway I have never had or played these games in my life so I don't know what are the real limitations of the scripts supported by the Source engine or the other related technical informations.

additionally the youtube videos you linked are totally useless and even ridiculous for various reasons, just a good way to laugh at something :)
first of all the software security is a specific field where each problem has a cause, one or more effects and tons of other related details.
uhmmm how to say... a phrase like "css server crasher" without details near it is a perfect idiocy because it's referred only to a possible effect of a problem usually used if the person who said it has no idea of the cause of the problem and doesn't know how to describe it (access violation for example) but it's often referred to the incompetence and ignorance of the person who has absolutely no idea of what is security and has its mind obfuscated only by the malicious purposes he wants to reach.

even Valve has made the same mistake (probably voluntary) describing the format string and memory corruption vulnerabilities I reported as a simple "crash" while that's false because the termination of the server (vulgarly called "crash") is only the minimal effect of such bugs which instead lead to code execution.
and in the security field there is a huge difference between a Denial of Service (access violation, null pointer, socket related errors, endless loop, etc) and a bug which allows an attacker to take the complete control of the remote system (the entire remote machine)

so, for concluding, don't trust to all the idiocies you see on youtube (come on... youtube) or other places where the people have no idea of what they talk (*cut*) and they just talk about nothing (no proofs, no descriptions, no details, no causes, no possible effects, nothing).
don't mix security with "something else".

Hmm, I do get what you mean. Well I'm sorry for the silly post before, well then you are true. For security purpose only, and I also have one question I was able to join a server while those file were on the folder is this normal? I tried other servers it didn't join but there's a server where it would join, I did accidently joined to the server fully, now will I get a vac ban?

Thanks for the help by the way, you are totally right.

uhmmm sincerely I don't know, as far as I have read seems that VAC takes one week or more to confirm a ban but it's possible that the proxifying of ws2_32.dll doesn't match the rules of a VAC ban.

oh damn :/ so i might get a ban or not. *EDIT no IP addresses* it was this server i dont get it it joins the server with unnamed.

Fist of all is this ws2_32.dll overlaying CSS? if it is, I guess I would get a Vac ban. doesn't matter if it isn't a cheat or what ever as long its running on background.

a bit of theory useful to anyone:

ws2_32.dll is the system dll used on Microsoft Windows for performing the socket operations like send, sendto, recv, recvfrom and thousand other functions.

the ws2_32.dll of my proxocket project acts as a "proxy dll".
I guess that the proxy theory is clear to anyone, if not it's very simple:
application -> proxy_dll -> real_dll
so "something" in the middle between a starting point and an ending one.

that's possible because the ws2_32.dll file loaded by the main application (any software) is first looked inside the current folder where resides the executable, then in the Windows folder (where is located the REAL one) and then other locations.
that's the default rule applied by Windows for the loading of the shared objects (dll).

so when you put the proxocket's ws2_32.dll file inside the application/game's folder it will be loaded by the game at the place of the real one and at the same time my ws2_32.dll will load the REAL ws2_32.dll of Windows so that it can intercept the call to the sendto/recvfrom functions and modifying them as specified in the myproxocket.dll plugin.

that's all the theory about the proxy dlls.
now I have already said to have never touched CSS, HL2 or VAC in my life but "as far as I know" VAC claims to monitor only the changes to the dlls (maybe a hash based check based on trusted hashes) and a proxy_dll can't be properly defined as a "change" although (in my opinion) it should be monitored too.
who knows more specific to VAC please correct me if I'm wrong.

my proof-of-concepts were focused only on the Source engine and absolutely not on VAC to which I have no interest and wasn't involved directly or indirectly with the vulnerability research session I performed in these days.
but as showed before the proxy_dll was only one of 2 methods for performing the test because the suppipe one (udp proxy) wasn't more secure from the point of view of VAC, because it's not good if an admin gets banned for having verified if his server was or wasn't vulnerable.

I hope this has answered to any doubt.

now I want to add an useless personal consideration, so feel free to ignore it and to not take it as an offense.
in case wasn't clear the proof-of-concept I released for the problem reported by nowayz and the people on garry's mod (2006 right?) was released for verifying and demostrating the vulnerability ("proof" of "concept", not "exploit") so if you go to abuse of it versus servers not owned by you and/or without the permission of the admin and moreover without having the minimal idea of what they do and how they do (maybe I overvalue the knowledge of the other people or I think that some things are clear to anyone why they aren't)... expecting a ban is not something that you don't deserve (double negation).
traduced in poor words: the proof-of-concepts I release are made for testing the own servers and not those of others.
I see perfectly that it's a good thing to make other admins aware of a problem if they don't know if (the only good side of the malicious exploiting) but my philosophy about the proof-of-concepts is perfectly clear as stated before.