|
On October 04 2010 22:57 GoDannY wrote: All we can do is raise the barrier for those without in-depth knowledge about exploiting and programming to prevent them from using an actual hack. Those who are desperate to hack will do so and will find a way, sadly, but true.
But I think a hack in a shooter (aka wallhack and aimbot) are more of a threat than a maphack in Starcraft. Still it is annoying as hell, though, unless the hacker found some time to learn how to play, it wont help him as much as a hack in a shooter would do.
I hope we still have some progress regarding anti-cheat from both sides, the community and Blizzard. Thanks Ashur for the read!
this isn't necessarily true, in warcraft 3 towards the ends of it life (close to when sc2 came out) there was a hack that pretty much did it all. Complete map vision (thats a given) but it also could result in buildings that were invincible (so you could literally never lose, you would lose all your units but your buildings coudlnt be targeted so it woudl come down to which person would be willing to stay in game longer for a win), and a "micro" portion of it, which meant all you had to do was attack move into a base, and when your units reached 100ish health (this was low in wc3 for those that didnt play it) they would automatically be sent back to your base, without you having to touch them
this hack raged on for months without any type of intervention from Blizzard, but we all just assumed it was due to them putting so much work into sc2.... i hope that if anyhting serious occurs at sc2 they will be able to fix it much faster
|
On October 04 2010 23:36 Chill wrote: Wait, why are you allowed to post here still?
I've always thought it was a sad story that you went from coding tools the entire SC community used to coding SC hacks. If what he says is true then releasing his own source wont make a difference.The hacks will be released eventually and blizzard will have to make a move. I'm confident they won't sit still, hopefully this thread and info will get them moving a little faster.
|
On October 04 2010 23:13 Ashur wrote:Show nested quote +On October 04 2010 23:08 Klumaster wrote: Wouldn't address space layout randomisation at least make this kind of thing a bit harder? I'm not really an expert on it, and I can see how maybe with massive knowledge of the game you could follow a chain of pointers to always find the appropriate data, but I don't know, is it even feasible to know that much? I'm guessing the current generation just works by knowing where to look in advance? Randomization? Like to find pointer(s) to randomized data? The game needs to know where it is. And if game knows, hacker knows.
Don't worry, I'm not completely stupid. What I mean is that a hacker currently might not need to know the entire structure of the program - if unit info always gets stored in the same place, or pointers to it always get stored in the same place, that's all the hack needs to read. With more randomisation, surely you'd need a much more in-depth knowledge of the game, because you'd have to work out where the game's core had been allocated, then work your way down the whole hierarchy. Or I suppose some sort of pattern-matching could find it? I don't know, it's not exactly my area.
|
On October 04 2010 23:36 Chill wrote: Wait, why are you allowed to post here still?
I've always thought it was a sad story that you went from coding tools the entire SC community used to coding SC hacks. Can you post more on this? From the sounds of it he accidentally make a program for BW that could be interpreted as a hack so he didn't release it, and for SC2 he tried making an undetectable hack (possibly to prove a point to blizzard?)
|
Wait a second! So making a maphack to SC2 and bragging about it here is perfectly fine. Biggest community site of the game.
I wasn't around in SC1 so this was kind of a surprise.
|
On October 04 2010 22:53 228zip wrote:
IIRC, the problem is the number of units involved. For all I know, HoN doesn't allow you to reveal a few hundreds units by simply clicking a button the way a scanner sweep does it. If the data was sent to the client only then, you'd probably have lag. Lots of it. However I'm not sure all clients need to have the observer info, like income and production. But without it, generating the replays would probably be a nightmare.
Not such a simple problem, sadly.
I have seen this thrown around a few times and I just don't believe it. Some things to note:
-It's not much data. It's just unit type, position and maybe upgrades (although this can be optimized). It is literally maybe a couple of bytes per unit. How many units are going to be revealed at once? Not a whole lot... -If there is lag for scanner sweep they can make it part of the gameplay mechanic (sweep has a .5 sec delay or something) -Currently the client is getting data have hundreds of units on the entire map moving around, so it's pretty much the same amount of data (or less) than if someone did a scanner sweep and had to get all the data at once. -Additionally, there will be less data coming down overall because the client is no longer getting data about the WHOLE map just sections of the map.
It is more complicated to do things this way, but I think it is definitely solvable. I don't think network latency should be an issue here. It's just laziness on Blizzard's part.
|
The solution lies in social engineering. We can count on legit players to report hackers if they are being too obvious about it.
|
On October 05 2010 00:52 MuadDib wrote:
-Currently the client is getting data have hundreds of units on the entire map moving around, so it's pretty much the same amount of data (or less) than if someone did a scanner sweep and had to get all the data at once. -Additionally, there will be less data coming down overall because the client is no longer getting data about the WHOLE map just sections of the map.
I think the idea currently is that it uses deterministic/lockstep simulation - the units are 100% predictable so they don't need to transmit any state. Instead you just transmit orders given by the players. One problem you'd have with "hidden units not transmitted" system is that if a hacked client did manage to bypass Warden, you could (for instance) not actually build anything for the first five minutes, scout their base, and instantly spawn a believable counter anywhere in their fog of war. You could even spawn impossible armies so long as they they weren't so ridiculous that the opponent would realize. Not to mention no one would be able to watch replays.
|
On October 05 2010 01:11 Klumaster wrote: I think the idea currently is that it uses deterministic/lockstep simulation - the units are 100% predictable so they don't need to transmit any state. Instead you just transmit orders given by the players. One problem you'd have with "hidden units not transmitted" system is that if a hacked client did manage to bypass Warden, you could (for instance) not actually build anything for the first five minutes, scout their base, and instantly spawn a believable counter anywhere in their fog of war. You could even spawn impossible armies so long as they they weren't so ridiculous that the opponent would realize. Not to mention no one would be able to watch replays.
Hmm, yeah I guess that makes things more complicated. I guess if the clients transmitted orders to the server it might be easier, but that is a lot more server load and perhaps lag issues.
|
On October 05 2010 00:37 Siwa wrote: Wait a second! So making a maphack to SC2 and bragging about it here is perfectly fine. Biggest community site of the game.
I wasn't around in SC1 so this was kind of a surprise.
Only if you're Ashur.
|
On October 05 2010 01:09 Tdelamay wrote: The solution lies in social engineering. We can count on legit players to report hackers if they are being too obvious about it. Not if the hacks are technically undetectable. Smart maphackers can't be detected by watching a replay. Also many people get lucky once in a while and it sucks when someone call you hacker when you just got a lucky bo win.
You are probably not a broodwar player but if some people remember the MistrZZZ vs Hullah controversy they understand why we need a real technical solution to detect the hackers ...
|
On October 05 2010 00:52 MuadDib wrote: -It's not much data. It's just unit type, position and maybe upgrades (although this can be optimized). It is literally maybe a couple of bytes per unit. How many units are going to be revealed at once? Not a whole lot...
It actually is much data.
- Unit id - Unit type - Unit position (x/y) - Movement vector (delta x/y) - Movement command (attack, move, patrol) - Upgrades - Buffs - Debuffs - Spellcasts - Flying Projectiles - Kills - Unit status (which animation to draw)
And now imagine an 8 player game with 50-100 Mutas each, flying around and just slighty stepping in and out of fog of war...
The whole unit state right now can be persistent until there is a change, so you only send updated movement vectors, referring to the unit id. If you wanted a true fog of war system, you would need to send a lot of individual updates. Something that is 1 packet right now (for example one long movement), can become dozens of packets if you want to only give the client what he has to know (fog of war in between the sightings). Well yes, you could do some sort of caching here, but then you would need to compare the version of the cached state which would mean even more unnecessary control information and if you want it granular for individual attributes, the control data transmission would exceed the data, unless you store state about client updates on the server as well, to insanely increase server hardware requirements..
Plus you need some sort of border at which you start showing stuff, so it does not suddenly "pop in". Again it would be possible to visualize that and give the maphacker more information.
Furthermore, the whole replay would have to be constructed and stored on the server instead of the client.
Overall, it would make the whole thing insanely complex, especially if you want to achieve a consistent and smooth gaming experience even for people with low bandwidth and slow connections and it would stress the servers a lot more, since fog of war calculations are pretty intense.
The warden way is probably a lot easier to implement and allows for a better gaming experience for the legit players instead of making them suffer for the cheats.. They only got to ban really frequent. And if they would enforce the requirement of a real identity and ban you forever, people would probably stop using that shit quite quickly. ;P
|
On October 05 2010 01:14 MuadDib wrote:Show nested quote +On October 05 2010 01:11 Klumaster wrote: I think the idea currently is that it uses deterministic/lockstep simulation - the units are 100% predictable so they don't need to transmit any state. Instead you just transmit orders given by the players. One problem you'd have with "hidden units not transmitted" system is that if a hacked client did manage to bypass Warden, you could (for instance) not actually build anything for the first five minutes, scout their base, and instantly spawn a believable counter anywhere in their fog of war. You could even spawn impossible armies so long as they they weren't so ridiculous that the opponent would realize. Not to mention no one would be able to watch replays. Hmm, yeah I guess that makes things more complicated. I guess if the clients transmitted orders to the server it might be easier, but that is a lot more server load and perhaps lag issues.
Yeah, then you're moving into the realm of Blizzard hosting dedicated servers for every game. Without a hefty subscription fee, I don't see that happening. I suppose they could do a system that lets the clients handle game state, but also logs all their commands on the server and gives you them at the end. No idea if that's feasible for the current volume of players, but that would make it easy to see a cheat, since the replay would desync the minute they did something impossible.
|
On October 05 2010 00:13 Klumaster wrote:Show nested quote +On October 04 2010 23:13 Ashur wrote:On October 04 2010 23:08 Klumaster wrote: Wouldn't address space layout randomisation at least make this kind of thing a bit harder? I'm not really an expert on it, and I can see how maybe with massive knowledge of the game you could follow a chain of pointers to always find the appropriate data, but I don't know, is it even feasible to know that much? I'm guessing the current generation just works by knowing where to look in advance? Randomization? Like to find pointer(s) to randomized data? The game needs to know where it is. And if game knows, hacker knows. Don't worry, I'm not completely stupid. What I mean is that a hacker currently might not need to know the entire structure of the program - if unit info always gets stored in the same place, or pointers to it always get stored in the same place, that's all the hack needs to read. With more randomisation, surely you'd need a much more in-depth knowledge of the game, because you'd have to work out where the game's core had been allocated, then work your way down the whole hierarchy. Or I suppose some sort of pattern-matching could find it? I don't know, it's not exactly my area.
I never worked anti-hack or security but just starting to think about it makes me want to take up this (futile, according to Ashur) mantle.
I think you're on to something here, but randomly spreading the data around, by maybe randomizing the order of allocating structs or something, would only be half the battle. Ashur is saying they want to knwo the number of workers, so there is still a word somewhere in RAM that says "0x00000010" and hackers will find it by knowing what the data should be and hunting for it. They'll train one probe at a time and monitoring memory to see what word increments, or something like this. So you can't just hide the data by moving it around.
How about spreading the data around and obfuscating it in RAM? Ashur, I'd like to know whether this sounds hard to crack to you. So you've got some obs data like mineral income, let's say the true word is 0xaabbccdd. How many of these critical words are there? Maybe a few hundred (units/buildings/positions/upgrades all secret player state)? Let's store them inefficiently to hide them, and only reconstruct them in registers. No outside process can peek at register values or even if they could, know what they're looking at, could they? I never looked at a hack in my life but I believe this has to be true. That's just how computers work, you context switch everything out when a new program, like a hack, gets the CPU.
So we take 0xaabbccdd and split it up somehow, say into 4 four words with bit shift--I know we can come up with something sneakier, but its a example:
0x000aa0 0x000bb0 0x000cc0 0x000dd0
Now do what Klumaster said and put those 4 words somewhere different in memory every time game loads, just so they are hard to correlate as one value. Then, NEVER store the true value 0xaabbccdd in RAM, never in a packet, nothing.
Load the split values into registers, bit shift, then OR together, BAM hackers never see the mineral income.
Another problem: hackers will load game and probe it like black box to undo what you did: fine, generate pseudo random "effects" from every game action that make dummy values tick and tack all over. Make it so painful to find that they won't. I mean, would you mind wasting a megabyte of memory if it made good noise for hiding important values?
What do you think, Ashur, or have you already busted through something 10x beefier?
|
On October 05 2010 00:24 RebirthOfLeGenD wrote:Show nested quote +On October 04 2010 23:36 Chill wrote: Wait, why are you allowed to post here still?
I've always thought it was a sad story that you went from coding tools the entire SC community used to coding SC hacks. Can you post more on this? From the sounds of it he accidentally make a program for BW that could be interpreted as a hack so he didn't release it, and for SC2 he tried making an undetectable hack (possibly to prove a point to blizzard?)
I believe it's in reference to this thread http://www.teamliquid.net/forum/viewmessage.php?topic_id=85836
|
It'd be neat if people of talent actually applied it for... iuno, good, and not fag.
|
On October 05 2010 01:21 dimfish wrote:
So we take 0xaabbccdd and split it up somehow, say into 4 four words with bit shift--I know we can come up with something sneakier, but its a example:
0x000aa0 0x000bb0 0x000cc0 0x000dd0
Now do what Klumaster said and put those 4 words somewhere different in memory every time game loads, just so they are hard to correlate as one value. Then, NEVER store the true value 0xaabbccdd in RAM, never in a packet, nothing.
Could be easier just to XOR it with a random value that's also hidden at a random location, obviously if the hacker has total knowledge they already know where that value is, and also where your four bitshifted parts are, and how to recombine them.
What I'm interested in knowing is does the hacker spend time and effort looking for that counter that goes up? Do they have to play practice games where they do specific things to find which counters change, or is this something they can automate so it just searches out the data while they play?
|
On October 04 2010 21:21 Ashur wrote: You might think, that it actually advertise cheats, but truth is that it just describes how the current problematics works and how it worked in SC1...
...So, when SC2 beta came out, I was evil enough to fight for the shadowwalker's glory and research code like mad to finish the maphack as first in the world.
The sources (not just mine) are already published...
Yes, there might be technical argues that you can find the handle in other processes, but... if you think twice.. Blizzard cannot do that because of thousand reasons.
Just in case you are interested in the source codes, feel free to PM me I will guide you.
I'm baffled by the positive response this is getting on TL. This thread is absolutely "I've made an undetectable hack look at my e-peen." He openly invites anyone to PM him for a look at his awesome code, and provides no real reason as to why this won't turn out to be the same tug-of-war it has always been (updated hack, updated warden, updated hack and so on). His entire argument is 'trust me guys, this one can't be beat.' I would understand if this were a report on new hacking methods (made by someone other than the OP) and what could potentially by done about them. As it stands, what does this add to the community other than inflating the OP's ego?
I think its particularly appalling that he can openly state that he has published his maphack code.
This is attention whoring at its worst.
|
To all those obfuscate / hide / encrypt comments: This will never work. Period. It's the same as with copy protection: everything that is in software can be broken. The only viable protection is in hardware and even that can be broken with a mod chip after all. As long as we have normal computers without trusted computing in hardware, there will be ways to hack.
And: you can never win that fight by trying to hide stuff. Hackers will figure, they are more and they got more time and resources than you. You only give them a challenge and motivate them even more if you try to hide it.
The only solution imho is warden with frequently updated modules and more frequent banwaves. I am not that much into software though to know the details of sandbox solutions and how it behaves if run inside a virtual environment, while the hack resides on the host system... There will probably be ways to figure it out for a long while at least which will lead to enough banwaves to make the average kiddie be too frightened to use it. ;o)
|
It's a valid area of research. I am genuinely surprised Blizzard uses such a simplistic methods...
Edit:
And make no mistake, it's possible there is no Perfect Solution (unless all calculations are done server side, which still isn't feasible), it should be a hell of a lot harder than this.
|
|
|
|