Obscure game text in the exec
issueid=1393 12-07-2012 01:47 PM
Ancient Member
Number of reported issues by Grey: 58
Obscure game text in the exec
Prevent exec scrying for that game mysteries are preserved

Currently it's quite easy to open the ADOM executable up in a text editor and read much of the in-game text, revealing or half-revealing many mysteries from the game. Some clever chaps can go further and use (or create) some very clever tools to get access to more data, and more easily. There are a couple of problems with this:

1. It ruins the mystery of the game when secrets get out from simple file analysis. Once a secret's out it's hard to ignore.
2. It makes it difficult to differentiate on the forums between spoilers and super spoilers.
3. Sometimes information gleaned in this way is misleading or inaccurate, leading to false assumptions that make themselves into wikis and guidebooks. Generally experienced players can distinguish between the facts and the assumptions, but for newer players this is a serious trap as they are the ones most likely to read and believe the guides ("improved" or not). There are many examples of mistakes from this already.

Now, assuming it's believed that this is a problem (some will surely object) it would be nice if it could be prevented, by somehow obscuring the text in the executable. I have no idea how that could be done, but if there is some special compiler trick that could be brought to fore then that would be handy.

This won't fully stop the memory address readers and such, but it at least makes things a little harder, and pushes such secrets from the hands of the many to an educated few who might be more sensible about interpreting and spreading their discoveries.
Issue Details
Issue Number 1393
Issue Type Feature
Project ADOM (Ancient Domains Of Mystery)
Category All
Status Rejected
Priority 8
Suggested Version ADOM 1.2.0 pre 6
Implemented Version (none)
Milestone (none)
Votes for this feature 5
Votes against this feature 8
Assigned Users (none)
Tags (none)




12-07-2012 03:40 PM
Ancient Member
While I'm not a defender of these "mild reverse engineering" techniques, as a programmer I think that this kind of things is not usually worth it. It's more work for the developer, and people with enough interest is going to break it anyway (even record labels and big software companies can't get an actually working encryption...). I think developer time is better spent adding new features or squishing bugs than doing this.

12-07-2012 05:41 PM
Ancient Member
Quote Originally Posted by Al-Khwarizmi
While I'm not a defender of these "mild reverse engineering" techniques, as a programmer I think that this kind of things is not usually worth it. It's more work for the developer, and people with enough interest is going to break it anyway (even record labels and big software companies can't get an actually working encryption...). I think developer time is better spent adding new features or squishing bugs than doing this.
100% agreed. You don't even need a full unpack to extract the strings.

If I recall correctly, Thomas himself has stated (in the old RFE database) he will not go to great lengths like this to prevent hacking, because sufficiently determined people will always find their way through.

12-07-2012 06:42 PM
Ancient Member
I dislike this notion of debating over developer time spent on x or y. Opposing an idea is fine, but let TB decide his time priorities.

12-07-2012 10:08 PM
Pim Pim is offline
Member
Well spoken Grey. However I still vote against this feature, it is too similar to the occasional requests to make save scumming more difficult. I think we can all agree that reading strings from the executable is code diving. In my humble opinion, it is each individual's responsibility to decide whether or not to cheat.

If we were talking about software piracy, that would be very different. But although it may be technically illegal for someone to publish their code dived information, I'm guessing it isn't worth prosecuting. I don't know. In general, the risk doesn't seem very high to me.

12-07-2012 11:28 PM
Ancient Member
Quote Originally Posted by anon123
100% agreed. You don't even need a full unpack to extract the strings.

If I recall correctly, Thomas himself has stated (in the old RFE database) he will not go to great lengths like this to prevent hacking, because sufficiently determined people will always find their way through.
If you encrypt the exec, we'll read the in-memory executable. Or just set our STR to 90 in memory. Or just fake a YAVP. Or buy clear d20s and claim we rolled a 19. Again.

"Screen door" security is intended to keep mostly honest people honest, not to stop the dedicated crackers away. If the save file was plain old text / json / xml, I know I would be tempted to

uh...

adjust things. But by making it obvious that there is a boundary being crossed when you do something cheat-ish, you get 95% of the way there.

12-08-2012 12:24 AM
Ancient Member
Exactly. It can't be stopped, but it can be at least discouraged. If there's an easy way to do this then it should be done. Jochen seems like rather a smart chap with the code so perhaps he might have some thoughts on this.

12-08-2012 09:17 AM
I don't think it would even occur to most people to do this. I haven't looked for strings in an executable since I was 13.

12-08-2012 09:26 AM
Ancient Member
For me it is very boring to play a game spoiled, I don't see the point really. Maybe some people enjoy it. I don't know what they get out of it, maybe they are just psychopaths that want to spoil other's fun, but I think those individuals will find a way anyway.
So I don't think TB, JT should spend time on this, they have their hands full already.

Edit - sorry Grey, I only read the comments after posting. It remains for the developers to decide ultimately, not any of us. We just raise our opinions.

12-08-2012 07:33 PM
The Creator
I'm afraid there's no easy way to do this.

12-08-2012 07:51 PM
Ancient Member
Quote Originally Posted by Mobius
If you encrypt the exec, we'll read the in-memory executable.
Dumping the executable image in memory to a file and running strings on that was what I had in mind - but I didn't want to give anyone ideas :p

+ Reply