Imposter BlazEy

by 123abc on 02/20/2008 03:27, 29 messages, last message: 02/29/2008 15:56, 6036 views, last view: 05/18/2024 09:23

I rly dont want to complain about this but it has been getting pretty ridiculous lately. A man or child goes around pretending to be wouters, metlslime, even Aardappel, and destroys maps for no reason. He has even acted like my friend and just destroyed my map. Then after his rampage of blocking and deleting the map he renames himself BlazEy. Now the main reason im telling everyone this is because its not just me getting pissed off, Ive seen more than a dozen people get there maps ruined. Im sure he ruined a lot more than what ive just seen but its pretty sad because i believe this kid may be hurting sauers community. Just today i saw 6 people get there map ruined by him disguised as Aardappel. Hes only messed with one of my maps but just think of all the other people just trying to have fun and a name u think u know connects to the server then destroys your work. When he destroyed my map he was disguised as a friend of mine. I actually thought it was my friend destroying my stuff until i talked to him a few days later. I think this has got to stop or the community may be hurt by this one stupid kid. I rly dont expect anyone to respond to this but i just want u all to know about this dumbass on the loose.

   Board Index   

#1: ..

by rtyhyteruwrte on 02/20/2008 20:52

just go offline..

or if you really want to do it online, just use mastermode 2 and only unspec people that you trust. >.>

reply to this message

#2: ..

by tman_elite on 02/20/2008 21:09

Save often when you're working on a map online so you don't lose all of your work.

Or, just don't make maps online.

reply to this message

#3: ..

by SanHolo on 02/21/2008 10:27

That's why there is mastermode 2. :P

reply to this message

#4: ..

by scasd on 02/23/2008 23:11

Its a bit old, but have you red it ?

http://www.nixcoders.org/forum/index.php?showtopic=459

found by a google search for "sauerbraten wallhack"

reply to this message

#5: Re: ..

by ezombie on 02/24/2008 03:36, refers to #4

The ammo hack is no longer possible in current versions, since it is server side now IIRC.

reply to this message

#6: Re: ..

by Drakas on 02/24/2008 13:26, refers to #4

wow, those guys are serious trolls :-)

reply to this message

#7: ..

by scasd on 02/24/2008 18:48

As far as I can remember it should be possible to move (in less than a second) to an ammopack and back... but I dont know how complicated that would be. Serversided physics are a must have to prevent further hacks I think.

I have also heard guys complain about edited maps where you can move through walls and have secret clip cubes and jumppads. *boing*

Did you red the thread until the end ? There are such things discussed. Not only ammo hacks.

It is not only 'one' cheater. It is a whole community - argh. They called Sauerbraten 'an easy target'.

reply to this message

#8: ..

by scasd on 02/24/2008 19:03

@ezombie: Admin hacks (sending trojans etc to clients) could be avoided by having a 'trusted only'-flag which allows a client to md5 check the received code from the server. That would be really secure I think. In both ways server-client and client-server.

Player models and shader scripts should also be md5 checked for my opinion but that is another story. A cheater could still binary hack the whole construct but it is no longer an easy 'compile and run' thread.

reply to this message

#9: ..

by ezombie on 02/25/2008 03:05

OMG! - don't feed the trolls.

As for admin hacks... what are you talking about? From the phrase "received code from the server", I assume you are referring to the VM in ET:CE. It's going to be sandboxed, so don't worry - the bytecode cannot access your HD or network interface.

And how does MD5 checking help secure anything on the client? One simply 'fakes' it before the 'compile and run' step. If you can program a physics hack, that step would be cake.

This has been explained in depth before. Data hashing for security purposes in the context of Cube's MP setup is fundamentally meaningless. It is the same on all other open source MP engines.

Yes ET:CE shall use it, but merely for user convenience (the autodownload feature). It is just to let your client check to see if it has the same version of a PAK file as everyone else - then download the updated one if needed.

reply to this message

#10: ..

by scasd on 02/25/2008 18:22

If you run your game logic only in a LUA VM someone could avoid this by modifying the main source/binary. In this case a md5 check would be indeed needless - except the VM has holes but that depends on the clients.

reply to this message

#11: ..

by ezombie on 02/25/2008 20:08

It's pointless in any case. They would just change the network code to report whatever MD5 signatures they wanted to.

If someone REALLY wanted to use glowing enemy skins to gain an (sorta) advantage, there is no way you can stop them - short of taking control of their machine.

And exactly what holes are you referring to?

reply to this message

#12: ..

by scasd on 02/25/2008 23:03

I mean the security hole when servers send code to clients. This was possible in quake2 where parts of the engine are send as code when you have a special flag turned on. There are known quake2 server hacks which infect clients. With an official md5 checksum from a modmakers team this would not be possible (just mentioned).

Checksums are used under Linux and Unix (Windows not by default) to verify code and data. It would be heavy to modify the code AND find the matching md5 and modify it too. I dont trust my provider by the way ;)

hmm fullbrightmodels doesnt work for me...

reply to this message

#13: ..

by ezombie on 02/26/2008 02:46

I see your point.

But each server is free to customize the gameplay through editing the files. In essence, each server can be it's own *official modmaker*.

So the only place to get the checksum is... the server that sent you the data. The quake2 engine is a bad example, since it was not using a VM that was designed from the ground up for being sandboxed, and used in industrial machinery control applications, and refined over eight years by one of the larger oil companies.

(jeez that last sentence was a bit punny)

For those who are crazy paranoid, and cannot read the code for themselves to see that it is properly sandboxed - I suggest you play only on stock ET:CE servers. We will provide a marker on the server list (easily verified by the master server performing a checksum on the code sent by the server) just for this reason.

LOL@eihrul -> go for it, means one less reason for people to try and cheat. It's not a cheat if EVERYONE has access to an advantage...

reply to this message

#14: Re: ..

by Hirato Kirata on 02/26/2008 15:29, refers to #12

it adds brightness, so you need to try values like /fullbrightmodels 200 to actually see it to it's full effect, not just 1.

~Hirato Kirata

reply to this message

#15: Re: ..

by SheeEttin on 02/26/2008 16:09, refers to #13

Rather than checksums, perhaps cryptographically signing the content?
That way, it'd be much harder to forge content.

reply to this message

#16: Re: crypto

by ezombie on 02/26/2008 18:01

So you are proposing that we setup a keysigner on the master server that signs the servers key?

I'm not getting it. Wouldn't a malicious admin just sign his code, like the legitimate ones?

BTW, he is talking about server admins making a *mod* that messes up your machine somehow.

The single answer is a proper sandbox. People have made it a doctoral thesis studying the ways to completely sandbox Lua. There are many good whitepapers, that took many years and involved many good engineers. I would suggest people trust the pro's, and if they don't - just have a crafty coder friend run through the VM code.

A fancy code signing thingy with public/private key pairs and other such stuff is just eyecandy for the soul. It will not increase security, it will just make the program twice as big, and take twice as long to build/test. A false sense of security is actually a *security breach*.

That is why it can be harmful to add such features. We would rely on a secure code concept, instead of spending the time making sure we have a secure running environment.

The biggest strength of open source is review by peers. Remember that ;)

reply to this message

#17: Re: crypto

by graham on 02/27/2008 01:48, refers to #16

A crypto system could work...distributed code could be signed by a trusted authority that could verify that the code is safe. It wouldn't be an automated process, it would need someone to manually inspect people's code. Once a piece of content has been deemed safe, the content's checksum is encrypted with the authority's private key. The encrypted checksum would then be delivered alongside the content. The idea is server admins cannot generate their own checksums, players only trust checksums coming from a "checksum authority".

How effective would a trusted authority be at detecting all malicious code? A secure sandbox is a much better idea. :)

reply to this message

#18: Re: crypto

by yetanotherdemosthenescomputer on 02/27/2008 01:52, refers to #17

Extremely ineffective. All you have to do is grab *one* good checksum via a packet grabber and rip into the code and have it send that in place of generating and sending one.

reply to this message

#19: Re: crypto

by graham on 02/27/2008 02:06, refers to #18

lol but the modified content would not match the trusted checksum. Players would use the authority's public key to decrypt the checksum.

reply to this message

#20: Re: crypto

by yetanotherdemosthenescomputer on 02/27/2008 02:16, refers to #19

Oh, read it wrong. Why would distributed code matter at all? There's no reason for anything of that nature, aside from proper sandboxing. It's modified copies of it that would need to be worried about. Your whole suggestion is based on the backward assumption that people would continue downloading content from a provider that the community didn't trust. Any malicious stuff is going to get informally blacklisted even without sandboxing, and therefore made harmless.

reply to this message

   Board Index