Hacking Fortress Theory.

DaVinci243 · 2014-04-15 12:05:54

DISCLAIMER

THIS IS ONLY A DEMONSTRATION OF HACKING IN FORTRESS THEORY.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

After some tries, I made it so I would be able to hack in it.

Oh and, this means any closed source build is hackable by injection.

iceman · 2014-04-15 12:14:55

A. What exactly is DogeWolf?
B. What does the hack do? It looks like you just printed the house map from edit mode. Does that work even when robbing others? If so, why in the world are you posting how to cheat in a game publicly?!?!?!?

DaVinci243 · 2014-04-15 12:17:18

iceman wrote:

A. What exactly is DogeWolf?
B. What does the hack do? It looks like you just printed the house map from edit mode. Does that work even when robbing others? If so, why in the world are you posting how to cheat in a game publicly?!?!?!?

A. DogeWolf is not related with this.

B. It works on any house in any mode.

C. I don't show HOW I show possibility.

Oh btw, do you have any kind of skype etc. I can contact you with?

Blip · 2014-04-15 12:41:03

I'm honestly not that shocked that TCD is hackable by a DLL injection. I think that having protected processes only works on Windows 7 or higher anyways (and TCD isn't a Windows 7+ exclusive), and messing with ld or dyld should work for Linux or Mac, respectively.

The point is that, regardless of how you're doing it, you shouldn't be hacking. I do think it's good that you're bringing this up, but it might be smarter to just email Jason (and maybe iceman, as it's his mod), rather than posing it on the forums.

poor · 2014-04-15 13:45:19

regardless of how you're doing it, you shouldn't be hacking.

Even if it's just to show it's possible? Even if it's never actually used to someone's advantage?

it might be smarter to just email Jason (and maybe iceman, as it's his mod), rather than posing it on the forums.

Eh. He's not publicly revealing how to do it.

Also, I have a tangential but important point to make here:

"Harder to hack" is not a good reason to avoid distributing the source code. Keeping it secret just because someone could hack it also means keeping it secret from people who might notice and point out how it can be hacked, and might even submit changes to fix it. It really has no effect.

Also, public source code means I don't have to wait for a Linux build.

Blip · 2014-04-15 13:53:08

poor wrote:

regardless of how you're doing it, you shouldn't be hacking.
Even if it's just to show it's possible? Even if it's never actually used to someone's advantage?
it might be smarter to just email Jason (and maybe iceman, as it's his mod), rather than posing it on the forums.
Eh. He's not publicly revealing how to do it.

Well, saying that it's hackable by injection, and showing a program that performs injections for you, is enough for some wannabe hacker perusing the forums to get pretty far in making his own hack.

MMaster · 2014-04-15 14:25:10

Of course you can do it with DLL injection. It's even easier when you have the code it was based on. I think it would be possible even without DLL injection just by memory scanning. As I said to you before - the fact that iceman did not release source code doesn't make it any more protected against hacks. It's just the fact that modifying open-source game is not hacking - it is just simple programming. You proved that you can do better than that. But still it's not cool to do hacks - try to find a way how to prevent them. I guess you have code for hacking anything from showing you house maps to death prevention. You have everything - now find out how to prevent it. Then you will be hero. Posting your hacking success publicly on game forums is not going to get you any fame.

Last edited by MMaster (2014-04-15 14:25:57)

cullman · 2014-04-15 14:32:50

As someone in the computer security industry this is the right thing to do. If you can publicly talk about it, that's the best way to resolve it. Otherwise, hacking goes on anyway, no one works to fix it, everyone jumps to the idea, well of course someone just got 1 out of 512 combo guess the third time through your house, it was bound to happen! While I hate cheating, I welcome pointing out the weaknesses of the game so that we can fix them.

Last edited by cullman (2014-04-15 14:33:18)

Blip · 2014-04-15 14:42:30

MMaster wrote:

Of course you can do it with DLL injection.

Can't you have protected processes in some of the newer versions of Windows to prevent vulnerability by DLL injection? I think I read that somewhere, but I'm not sure, and I don't use Windows so I can't test it.

You have everything - now find out how to prevent it.

I think there's really nothing the game itself can really do to prevent DLL injection, or memory scanning, or whatever other hacks are possible, without pinging the server to get visible tiles every time a step is made, which wouldn't work given the current server capacity. I could be wrong, as I don't do security stuff myself (I'm an EE guy - feel free to correct anything dumb I say, cullman or MMaster), but from what I know, there's not much we can do.

Last edited by Blip (2014-04-15 14:43:06)

MMaster · 2014-04-15 14:59:47

Everything that DaVinci243 mentioned in his previous posts is already known and also stated in forums as well as in the source code and you HAVE to read it if you want to compile it for main server. Is it not public enough? Showing that he has done it is just stupid as he HAD to read the part from Jason that he knows it's possible and he trusts him to NOT do it.
I'm really really curious how will you resolve this one .. or the one where I just do map shot of your house. And no - you can't send just part of the house to client, because of animals and electronics (mainly electronics). You would have to simulate it on server which is the only way to completely get rid of cheats like this, then you can implement things like occlusion culling and so on. But I guess running all clients on single server and doing HTTP request per turn is not really good use of server resources.

If you want ideas I have an idea how to prevent move list modifications in my mind for quite some time:
There is already PING implemented in game that gets sent every 5 (4) minutes. What can be done is to do something very similar to PING that sends current move list to the server every X(30-60) seconds. Server can check if something was just added to the move list or if it was reset/modified in comparison to previous move list. It would not be hard limit so even if the client does not send it for 5 minutes it should be fine (he can have some internet connection problems), but if that repeats over several robberies or if it just does not send the move list changes at all he would be detected. That way the cheater can only modify move list within the 30 seconds and then send it to server and not modify it anymore which would prevent him from cheating death. It would need some tweaking but I think that would work without putting too much stress on the server.

MMaster · 2014-04-15 15:00:59

Blip wrote:

MMaster wrote:
Of course you can do it with DLL injection.
Can't you have protected processes in some of the newer versions of Windows to prevent vulnerability by DLL injection? I think I read that somewhere, but I'm not sure, and I don't use Windows so I can't test it.

You can, but you have no control over it as developer of the game. The user can override it as he is the owner of his computer and he can do anything he wants as administrator (even disable the protection).

iceman · 2014-04-15 15:05:26

You guys are going way beyond what I know about hacking and cheat prevention (which is practically nothing), so I'm just going to step out quietly...

DaVinci243 wrote:

Oh btw, do you have any kind of skype etc. I can contact you with?

Sure- I think the best way would be just to email me at iceman76tv@gmail.com

Blip · 2014-04-15 15:13:02

MMaster wrote:

You would have to simulate it on server which is the only way to completely get rid of cheats like this, then you can implement things like occlusion culling and so on. But I guess running all clients on single server and doing HTTP request per turn is not really good use of server resources.

This is what I was referring to. It's been mentioned for as long as I can remember, ever since there was the big hacking problem in v5, but it's far too impractical to implement. I wish there was some way to do something similar to this, but with less server load.

MMaster · 2014-04-15 15:17:43

iceman wrote:

You guys are going way beyond what I know about hacking and cheat prevention (which is practically nothing), so I'm just going to step out quietly...
DaVinci243 wrote:
Oh btw, do you have any kind of skype etc. I can contact you with?
Sure- I think the best way would be just to email me at iceman76tv@gmail.com

It's nothing difficult. There is only one rule - everything that's being handled by client can be modified in any way hacker wants. It does not matter if he has the source code or not. He can read and modify memory and he can inject his own code to your code so it does something that your code didn't do. There are things that you can do that can make it harder for him, but not impossible.

So the ultimate solution is to run everything on server and use client only as input/output device. Which is obviously not a good idea so you need to find good compromise.

MMaster · 2014-04-15 15:25:31

Blip wrote:

MMaster wrote:
You would have to simulate it on server which is the only way to completely get rid of cheats like this, then you can implement things like occlusion culling and so on. But I guess running all clients on single server and doing HTTP request per turn is not really good use of server resources.
This is what I was referring to. It's been mentioned for as long as I can remember, ever since there was the big hacking problem in v5, but it's far too impractical to implement. I wish there was some way to do something similar to this, but with less server load.

The thing is that this is already being done partially as the server runs headlessClient for each robbery so maybe it would be possible to run headlessClient simultaneously with the robbery and syncing them (using something more efficient than HTTP/PHP! like UDP with custom binary data protocol). Of course the headlessClient does not calculate shadows or visibility, because that would take too much CPU cycles so it still does not solve the issue with map shots.

cullman · 2014-04-15 15:33:07

MMaster wrote:

Blip wrote:
MMaster wrote:
You would have to simulate it on server which is the only way to completely get rid of cheats like this, then you can implement things like occlusion culling and so on. But I guess running all clients on single server and doing HTTP request per turn is not really good use of server resources.
This is what I was referring to. It's been mentioned for as long as I can remember, ever since there was the big hacking problem in v5, but it's far too impractical to implement. I wish there was some way to do something similar to this, but with less server load.
The thing is that this is already being done partially as the server runs headlessClient for each robbery so maybe it would be possible to run headlessClient simultaneously with the robbery and syncing them (using something more efficient than HTTP/PHP! like UDP with custom binary data protocol). Of course the headlessClient does not calculate shadows or visibility, because that would take too much CPU cycles so it still does not solve the issue with map shots.

Yeah you are on the right track. UDP or HTTP pipelining. The reality is most MMO games have all the logic and stuff happening on the server, it's the only way to have a trusted MMO game. You have to assume the client is completely untrustworthy all the time. That's why things like WOW have tons of servers, because all the state and logic is happening up on the server. The client is a display and input mechanism only. Jason did a good job of band-aiding the movelist hack with the headless client thing, but basically the game won't be fixed until all the pet movements and visible tiles and electronic states are being kept on the server. Honestly, it's a damn simple game in terms of state, you could run 100s maybe 1000s of sessions on a single server no problem. You could reduce lag as I have explained before by sending the 16 different possible tile set views for the next 2 moves for the player every move (ie the UDP packet is sending the tiles you need to see for the next 2 possible moves every time the player moves). This is all highly doable and I keep getting tempted to do it all, but I just don't know if there is going to be enough players to make it worthwhile.

MMaster · 2014-04-15 16:01:28

cullman wrote:

MMaster wrote:
The thing is that this is already being done partially as the server runs headlessClient for each robbery so maybe it would be possible to run headlessClient simultaneously with the robbery and syncing them (using something more efficient than HTTP/PHP! like UDP with custom binary data protocol). Of course the headlessClient does not calculate shadows or visibility, because that would take too much CPU cycles so it still does not solve the issue with map shots.
Yeah you are on the right track. UDP or HTTP pipelining. The reality is most MMO games have all the logic and stuff happening on the server, it's the only way to have a trusted MMO game. You have to assume the client is completely untrustworthy all the time. That's why things like WOW have tons of servers, because all the state and logic is happening up on the server. The client is a display and input mechanism only. Jason did a good job of band-aiding the movelist hack with the headless client thing, but basically the game won't be fixed until all the pet movements and visible tiles and electronic states are being kept on the server. Honestly, it's a damn simple game in terms of state, you could run 100s maybe 1000s of sessions on a single server no problem. You could reduce lag as I have explained before by sending the 16 different possible tile set views for the next 2 moves for the player every move (ie the UDP packet is sending the tiles you need to see for the next 2 possible moves every time the player moves). This is all highly doable and I keep getting tempted to do it all, but I just don't know if there is going to be enough players to make it worthwhile.

Thumbs up for really good explanation. I have already designed and implemented several high-performance server applications and that's why I thought this will never happen. This is just indie game with relatively small community. I think it is too expensive to develop something like that as it needs refactoring of the client code and implementing high-performance server application. I didn't think someone would invest that much time into it, because it is almost like developing completely new game.

GotABigTrap · 2014-04-15 16:06:10

Well, if the source is closed, I think the biggest problem is that the maps are encrypted by a secret key that is readable through a simple hex dump. I havn't looked at the code at all, but I am in software engineering field. That being said, the point was made that the only way to really fix this is for the server to not trust the client. With the current state, anybody could figure out the client/server protocols and design custom clients, especially clients which are based off the original source code, which makes it very easy to do.

Given the facts, I don't think anybody should be surprised that this can be hacked. Probably the only thing you can do in the current state is make things incredibly obscure, but this won't really fix the problem; therefore, I imagine there isn't much point.

I would like to hear what Jason thinks about the feasibility of having the server perform game logic. This sort of thing could be distributed easily across multiple application servers which are sharing a MySQL database. The question is, could such a thing even be feasible. IF not, then we can just eliminate the possibility without thinking about the number of players.

cullman · 2014-04-15 16:39:25

GotABigTrap wrote:

Well, if the source is closed, I think the biggest problem is that the maps are encrypted by a secret key that is readable through a simple hex dump. I havn't looked at the code at all, but I am in software engineering field. That being said, the point was made that the only way to really fix this is for the server to not trust the client. With the current state, anybody could figure out the client/server protocols and design custom clients, especially clients which are based off the original source code, which makes it very easy to do.
Given the facts, I don't think anybody should be surprised that this can be hacked. Probably the only thing you can do in the current state is make things incredibly obscure, but this won't really fix the problem; therefore, I imagine there isn't much point.
I would like to hear what Jason thinks about the feasibility of having the server perform game logic. This sort of thing could be distributed easily across multiple application servers which are sharing a MySQL database. The question is, could such a thing even be feasible. IF not, then we can just eliminate the possibility without thinking about the number of players.

Actually, no decryption is even needed in the client hacks. You just dump the map string as soon as the client decrypts it. It's dead simple. It doesn't matter what is done on the client, that will always be the case.

I don't want to speak for Jason, but he has said that he is already working his next project. I don't think he is going to be doing any major rewrites on CD. That being said, I really don't think it's as hard as people are saying it is to make a server logic version of this. One could knock out a crappy one that just takes the client code and fires it up on it's own thread and uses the client to just send and display. Or even hook a web based front end on it. While a thread per player wouldn't be ideal perf and memory foot print wise. One could get to a 1000s of sessions per server if one was to do a rewrite in something like stackless python or some other language that has a greenlets or microthread capability.

DaVinci243 · 2014-04-16 08:32:12

cullman wrote:

Actually, no decryption is even needed in the client hacks. You just dump the map string as soon as the client decrypts it. It's dead simple. It doesn't matter what is done on the client, that will always be the case.

This is pretty much true since I only hook a function that sets your map to retrieve parameters ( house map ).

The Castle Doctrine Forums

#1 2014-04-15 12:05:54

Hacking Fortress Theory.

#2 2014-04-15 12:14:55

Re: Hacking Fortress Theory.

#3 2014-04-15 12:17:18

Re: Hacking Fortress Theory.

#4 2014-04-15 12:41:03

Re: Hacking Fortress Theory.

#5 2014-04-15 13:45:19

Re: Hacking Fortress Theory.

#6 2014-04-15 13:53:08

Re: Hacking Fortress Theory.

#7 2014-04-15 14:25:10

Re: Hacking Fortress Theory.

#8 2014-04-15 14:32:50

Re: Hacking Fortress Theory.

#9 2014-04-15 14:42:30

Re: Hacking Fortress Theory.

#10 2014-04-15 14:59:47

Re: Hacking Fortress Theory.

#11 2014-04-15 15:00:59

Re: Hacking Fortress Theory.

#12 2014-04-15 15:05:26

Re: Hacking Fortress Theory.

#13 2014-04-15 15:13:02

Re: Hacking Fortress Theory.

#14 2014-04-15 15:17:43

Re: Hacking Fortress Theory.

#15 2014-04-15 15:25:31

Re: Hacking Fortress Theory.

#16 2014-04-15 15:33:07

Re: Hacking Fortress Theory.

#17 2014-04-15 16:01:28

Re: Hacking Fortress Theory.

#18 2014-04-15 16:06:10

Re: Hacking Fortress Theory.

#19 2014-04-15 16:39:25

Re: Hacking Fortress Theory.

#20 2014-04-16 08:32:12

Re: Hacking Fortress Theory.

Board footer