Jump to content
XCOMUFO & Xenocide

Xcom: Enemy Unknown - Memory Hacking


Recommended Posts

I have been working on an XCOM savegame editor for about a month so far, and I've completed the backend, so from here all that's left is creating a useful GUI and finishing the data entry for the dat file formats. But several days ago, the idea of creating trainers for games started to catch my interest, and so after reading up on it for a while, I began to poke around in XCom's memory.

 

The bad news: XCom doesn't seem to be able to run natively-- it either must be run through windows' dos emulation (NTDVM.EXE) or DOSBox, and DOSBox, as far as I can tell, only interprets the assembler of XCOM's executable. This means that it would be difficult or impossible to hack the games' executable.

 

The good news: I've found that most (if not all) of the dat files are stored in memory in their entirety, meaning that anything you can do to savegames, you can do in REAL TIME to the game's state in memory. Also, the game lacks DMA, so the offsets to these memory chunks do not change.

 

Caveat: Because XCOM is run in DOSBox, it is possible that any future revisions of DOSBox could break a trainer that relied solely on those memory offsets. Even worse, the emulation makes it so that certain DMA-beating methods such as code-caving would be difficult if not impossible, because you cannot discover what modifies the values.

 

Here are the .dat files I have found, and their offset in DOSBox's memory:

 

[cut]

 

What you can do to help: If there are any among you who know more about memory hacking than me, please speak up. If you have any ideas or insight into how to work around the problems I stated above, don't hesitate to speak. If you know how to look around in process memory, you can test my offsets to see if they work in your version of DOSBox, and let me know your DOSBox version, XCOM version, or other information that would be necessary for me to know.

 

Just don't whine about them not working in other emulators (like NTDVM) ;)

 

From what I can see, it seems that one could potentially do any kind of modification to XCOM real-time. All of XCU's operations could be performed while the game is still running, meaning that it could be possible to play multiplayer hotseat games without having to quit out every turn. Or even better yet, it could be possible to play multiplayer games over the internet or network using an application that sent .DAT modifications back and forth between computers.

 

Any input would be appreciated...

~ZeldaFreak

 

EDIT:

 

GEOSCAPE: (alphabetical order)
ACTS		0x03656358
AKNOW		0x035e8a2c
ALIEN		0x03659de8
ASTORE		0x035e87d0
BASE		0x03675128
BPROD		0x036a4204
CRAFT		0x0369c204
DIPLOM		0x0365505c
FACIL		0x03652DA8
IGLOB		0x0365b8d0
INTER		0x035e8c20
LEASE		0x035e07bc
LIGLOB		0x0365b940
LOC		0x035e03d0
MISSIONS		0x035e0874
PRODUCT		0x03652b30
PROJECT		0x036852e8
PURCHASE		0x03652EB8
RESEARCH 	0x036522F0
SAVEINFO		(N/A)
SOLDIER		0x03748058
TRANSFER                 0x035e0b18
UIGLOB		0x0365b910
UP		0x03655c48
XBASES		0x036597e8
XCOM		0x03659818
ZONAL		0x0365634c
-
TACTICAL: (alphabetical order)
BGLOB		0x036712ec
GEODATA		0x0366EFA4
MAP		0x03732058
MISDATA		0x03670B3C
OBPOS		0x03669e94
ROUTES		0x03663aec
SEEMAP		0x0373C058
SMOKBIT		0x03670BE6
SMOKREF		0x03669084
SOURCEMP	0x0372345c
TERMP		0x03726f74
UNITPOS		0x0366a934
UNITREF		0x0366ad94
WGLOB		0x036712b4

Edited by ZeldaFreak
Link to comment
Share on other sites

Interesting. The last time I saw a real-time memory editing programme was a long time ago with cheat terminate and stay resident program called the Infinity Engine. I seem to remember that it could be used to reset some in-memory variables so that they could be set to a fixed value every few game frames. Basically refilling a unit's TUs and energy in real-time.

 

There are definitely going to be some strange consequences of editing the game variables as the game is running, but that's to be expected.

 

Good luck in the endeavour in either case.

 

- NKF

Edited by NKF
Link to comment
Share on other sites

NKF: Sounds interesting. I just realized that I do not know how TSR (terminate-stay resident) apps work, though... hehe... *slaps forehead* But that Infinity Engine sounds interesting. You were a little ambiguous-- was it for XCOM or another game? I'll google it, but if you have any more info on it let me know.

 

As you can see in the first post, I finished my search for the DAT files. I found them all, and their offsets are above.

 

One thing about memory hacking is that it's a hundred times faster than savegame editting. Whereas Hatfarm would have to change a value, load his game, and search for the change, with memory hacking you can just change the variable and look for the change. I've filled in blanks in UNITREF.DAT and OBPOS.DAT just by playing with values, or doing things in-game and looking for the change in the game or in the memory. I think at this point I'm going to try to fill in more blanks in the DAT files while at the same time writing an application to do the tampering for me. Hehe, it will be a learning experience for me, as it will be my first real-time memory hacking application.

 

I would still like to see if someone with a different DOSBox version than me (mine is 0.65) to test and see if those DAT files are in the same place for their version. Regardless, I've already written code that would load the offsets from an XML file. Hopefully someone who knows more than I do will come along and say, "You idiot! You can just find those offsets by doing this codeside!" and then we wouldn't need the offset lists :) But for now I'll just keep with what I know works.

 

Thanks for the blessing, peeps!

Edited by ZeldaFreak
Link to comment
Share on other sites

It was either Infinity Engine or Infinity Machine (not to be confused with the Bitmap Brother's game of the same name).

 

I only fiddled it a bit many eons ago while the floppies (yes, the 5" variety!) were making its way around my classmates. From what little I remember, it was a general TSR that you could run in the background and then use it on any game that you want. Or any dos program, for that matter.

 

Lets say you wanted to edit a particular variable in the current game you're playing. Get the value that it currently holds then bring up the editor and do a search for that value. The program then does dumps all matching memory locations for you to pick through. You then go back into the game, change the value you want to look for, go back to the infinity machine and do a new search on the previous matches. You just repeat this until you find the exact memory spot that holds the value you want to edit.

 

Once found, you can then edit to your liking, or even lock it so that it resets it back to the locked value each game frame. So if you were to lock your cash, every time you increase or decrease your cash, it'll reset back to the value that it was locked on.

 

This changed from session to session, so you had to relocate the memory locations each time.

 

Because you could literally edit anything in memory in any program, this was quite a dangerous program, actually. Imagine messing with the area of memory holding the kernel!

 

One thing I did like about it was that it acted as a slow-down or speed-up (probably by way of frame skipping) program. Worked wonders on ye-olde 80386's where things were too slow.

 

---

 

But enough of that.

 

There are a few flags held in memory that the game never stores to the save files. The one I have in mind is the proximity mine flag that tells that it has been armed. This is only present in memory and never stored. It would be nice to be able to get access to this for the purpose of disabling or re-enabling dud mines (i.e. mines that were armed before making a save, and turned into spent-blanks when the game is reloaded at a later time).

 

- NKF

Edited by NKF
Link to comment
Share on other sites

Been two days... woulda gotten here sooner but the forums didn't notify me there was a reply!

 

Wow... 5" floppies-- that would be a little before my time (or before time itself, depending on perspective), but I actually have a 5" floppy on my desk right now-- the original Star Flight from EA. My dad even has a 5" floppy drive at work, but I resorted instead to downloading Star Flight off the internet rather than using it... I think it has input connectors older than the dinosaurs...

 

For as long as I've had XCOM, I've never noticed that after arming they become duds-- perhaps because I rarely use proximity mines, which in turn may be due to the fact that when I was younger, I killed more of my own units with them than I did aliens. It may be possible for me to find it and see what I can do. At this point I'm still working on extending the original code of the application to incorporate more broad and open-ended editting tasks; for instance, I'd like TFTD and the various XCOM versions to be only XML files away from being edittable, and thus have had to extend plugin importation, etc.

 

If you have any more recommendations or things like the "proximity grenade armed" flag, let me know.

 

~zf

Link to comment
Share on other sites

  • 11 months later...

I just finished making an XCOM TFTD memory trainer. I used the Windows (Gold) version of the game.

http://www.xcomufo.com/forums/index.php?showtopic=242028699

 

 

 

I am probably going to make one for Enemy Unknown as well. This will also be for the windows version of the game.

 

I haven't looked into making memory hacks for dos games that run on DosBox, probably will not do that because I am mainly interested in modern 32bit development.

Link to comment
Share on other sites

You know what, I've been thinking about it some more and one of the things you could do is write a dos TSR trainer. That's pretty old school way of doing it but it will be able to do cool stuff like code injections. Whereas if you were writing a windows trainer for a dos application running on dosbox, it would probably be tricky to find out where the process is and patch it correctly..

 

anyways just a thought

Link to comment
Share on other sites

Well, I kinda abandoned the project in favor of a more advanced and larger-scale project...

 

I thought that the "windows" version just used DOSBox? Maybe I'm confusing it with the Sierra adventure game rereleases?

 

You mention that it would be tricky to find the process and patch it correctly. What I had done (and it worked well) was use a calibration step when you first load the application. Basically, I replaced one of the saved games with a tactical game save and changed the DAT files' data to some kind of string and the file name of the DAT file. In this way, the application knew where all the DAT files were in memory and could patch them. The process took a short amount of time. Of course, that was a year ago... today I'm sure I could find a better way to do it, but I imagine that there isn't high demand for this.

 

A DOS trainer? Yes, I imagine that could work. But you can't write DOS code in C# :) I mean, I could write it in C++ (in fact, I imagine it would be easier than C# due to the fact that C++ just doesn't have as many restrictions as C# when it comes to tampering with process memory) but I'm lazy...

Edited by ZeldaFreak
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...