Luigi Auriemma

you can't do that that simple.
theoretically you should rename the original ws2_32.dll for example as ws_old.dll and then placing the proxocket's one at its place modifying the name of the real dll searched by it (hex editing/recompiling) from ws2_32.dll to ws_old.dll... but I'm almost sure that at boot this should cause some chaos.

then that doesn't mean that it's not identifieable, because exist some ways to identify a proxy dll.
anyway if you need to test your server I suggest the sudppipe method, it's simpler and doesn't have the doubt if can give problems with VAC.

for the moment I think that the discussions about VAC can be closed here because it's totally off-topic so are accepted only technical updates.

Ok, now, I have totally missed sudppipe. I'm starting to understand things better and clear now, but as I told you before, I wasn't using sudppipe's method, and I was able to join then this is a %100 vac ban now I have to buy Counter-strike source again, and last thing, the sudppipe why does sudppipe proxy has to connect to the server?, so every time I use those dll's the ws2_32_dll I have to run sudppipe and point to the server I will be testing on. Thanks, that's all I need to know

the ws2_32.dll of proxocket has nothing to do with sudppipe.
client -> sudppipe -> server

quick usage for sudppipe:
- download sudppipe: http://aluigi.org/mytoolz.htm#sudppipe
- copy myproxocket.dll in the same folder of sudppipe and start it:
sudppipe -l myproxocket.dll SERVER PORT 1234
- start the client and join the server on 127.0.0.1:1234

for throughness I have updated the "entity null pointer" proof-of-concept because the protocol was not handled correctly (although worked), removing the unneeded parts (like the cl_vars) and making it compatible with the latest build of the Source engine (TF2 fixed this bug but was necesasry to add support for it):

http://aluigi.org/poc/sourcenullentity.zip

so this is mainly for who wants to learn better the Source protocol and if someone is interested to it just open a new thread in which to discuss about the meaning of the various bits of the protocol since I have collected various details during my short research which are partially visible in the stuff I released.

Are you sure TF2 fixed this bug? I think npc_speakall still works.

BTW, the only commands you listed before which exist on TF2 are:

npc_speakall
physics_debug_entity
physics_select


And the two physics_ have been fixed a few months ago because someone already discovered them and was crashing servers.

Do you think there is any more commands which lead to the NULL pointer vulnerability on TF2 (a lot of new commands were added since CSS, so there might be a few other ones).

EDIT: I just tested on TF2, and using npc_speakall while connecting to the server still crash my server, but your myproxocket.dll doesn't crash my server.

I tell you what I did for findings all the bugged commands in less than 2 minutes.
I simply searched all or almost all the available commands supported by the engine and then inserted them in a text file which was parsed by my local minimalistic client and so it tested all of them one by one quickly.

and the result were the 7 commands I posted but maybe there could be other (I doubt) which I didn't collected in my list file and so were not scanned.

Not sure if you've seen my edit since I edited at the same time as you posted.

"I just tested on TF2, and using npc_speakall while connecting to the server still crash my server, but your myproxocket.dll doesn't crash my server."

uhmmm very strange, maybe I will verify it later

ok found, the problem was simply that I placed those commands at the end of the list and so they weren't tried or you needed to join your server multiple times to reach them.
I have updated the PoC, now they are at the beginning and I have commented out the others.

Ok, this now works, it crashes my server.

I saw you kept this:
"physics_select", // TF2 3939 too
"physics_debug_entity", // TF2 3939 too

As I said above, those commands no longer crash the servers on TF2, they were fixed with an update a while ago, see here:
http://store.steampowered.com/news/2214/
"Added UTIL_IsCommandIssuedByServerAdmin() checks to several "physics_" CON_COMMAND scripts to prevent clients issuing the commands"

(and you could crash it with physics_constraints too IIRC, which probably doesn't exist on CSS)

Historically VAC has been unable to detect such "proxy" dll's as you used.. Many hacks were implemented as wrappers around the opengl/d3d libraries, making them undetectable. I haven't confirmed this is the case in a long time though, so it's possible they added detections for it.

Only one real way to find out, and that's waiting to see if anyone gets banned for it.

the fact is that while a proxy dll for the graphic functions is a classical and well known way to cheat in games, the same is not valid for the proxy dlls of the sockets functions.
this secondary type of proxies/hooking is used in some rpg/mmorpg games where for some unknown reasons the server doesn't track the objects and so the users can modify the packets for gaining gold, weapons and other stuff.

but in a FPS checking for this type of proxy is totally senseless or at least in this moment I can't think to a way of cheating through it, so excluding the fact that VAC considers it a risk or not remains the fact that it doesn't have sense for the purpose of VAC (catching cheaters).

I can't even exclude that some softwares (security&AV like) use similar proxy methods (avast does a particular job with the sockets but I don't know if it's for any application or only browsers).

Well then I guess you guys have used me as bait? I joined a server without using proxy sudppupi and I was managed to join a server even though in the main time I able to crash my server. I joined for about 1 minute or so then disconnected I did this for about 2 times to see if it will happen again which it did. So all your eyes on me if I will be getting Vacced or not. strange though because it was for a short time, and without using the proxy so yeah I just have to wait? how long again? its been 3-4 days. how long to go? thanks. willing that I wont get vac ban

personally I'm completely uniterested to this thing of VAC, but since was called in the discussion I said my personal opinion.

while for the "time" discussion, seems that a VAC ban could be raised even after 6 weeks from the catching of the cheat:

http://en.wikipedia.org/wiki/Valve_Anti-Cheat

I would think VALVe is more strict against server exploits/crashes if they have a way to catch you... for example they could disable the Steam account entirely since it is a breach of the Steam User Agreement under section 2e.

But if you play on a VAC disabled server, isn't the checking of proxy dlls/cheats/etc. turned off? So you could still exploit a VAC disabled server unless Steam has another way of tracking this stuff. I doubt they do though.

But it was nice to see they released a fix for Orange box the other day for some of these exploits.. too bad it wasn't for all Source games :(

in section 2E they refer to ways ("exploit" is one of those terms used for everything and nothing) which allow to bypass/circunvent the limitations imposed by Steam, so everything which is "piracy/cracking" related and maybe also things related to the protocol used by the Steam application or emulating the functions of steam.dll for playing the games in "particular conditions".

sorry for refreshing old topic...

My question is - is there ANY protection against this?!

Yes.

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

You see I even posted the code that fixes this exploit on the first page of this thread.