Jump to content


Photo

Xcom: Enemy Unknown - Memory Hacking


  • Please log in to reply
8 replies to this topic

#1 ZeldaFreak

ZeldaFreak

    Squaddie

  • Forum Members
  • PipPip
  • 2 posts

Posted 04 May 2007 - 07:22 AM

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		0x03656358AKNOW		0x035e8a2cALIEN		0x03659de8ASTORE		0x035e87d0BASE		0x03675128BPROD		0x036a4204CRAFT		0x0369c204DIPLOM		0x0365505cFACIL		0x03652DA8IGLOB		0x0365b8d0INTER		0x035e8c20LEASE		0x035e07bcLIGLOB		0x0365b940LOC		0x035e03d0MISSIONS		0x035e0874PRODUCT		0x03652b30PROJECT		0x036852e8PURCHASE		0x03652EB8RESEARCH 	0x036522F0SAVEINFO		(N/A)SOLDIER		0x03748058TRANSFER                 0x035e0b18UIGLOB		0x0365b910UP		0x03655c48XBASES		0x036597e8XCOM		0x03659818ZONAL		0x0365634c-TACTICAL: (alphabetical order)BGLOB		0x036712ecGEODATA		0x0366EFA4MAP		0x03732058MISDATA		0x03670B3COBPOS		0x03669e94ROUTES		0x03663aecSEEMAP		0x0373C058SMOKBIT		0x03670BE6SMOKREF		0x03669084SOURCEMP	0x0372345cTERMP		0x03726f74UNITPOS		0x0366a934UNITREF		0x0366ad94WGLOB		0x036712b4

Edited by ZeldaFreak, 05 May 2007 - 08:01 AM.


#2 NKF

NKF

    Commander

  • [Global Moderators]
  • PipPipPipPipPipPip
  • 4,798 posts

Posted 04 May 2007 - 01:15 PM

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, 04 May 2007 - 04:07 PM.

Lord High Generalissimo Ruler Supreme of Norm's Anti Pedant Society (NAPS).

Number of members: 1

#3 mrnikosia

mrnikosia

    Squaddie

  • Forum Members
  • PipPip
  • 8 posts

Posted 04 May 2007 - 04:03 PM

Yeah in the good old dos days it was much simpeler to write a trainer!
Now you have to crawl through the jungle of Win32 api calls :)
But i know probably less than you do about this,
sounds interesting good luck!

#4 ZeldaFreak

ZeldaFreak

    Squaddie

  • Forum Members
  • PipPip
  • 2 posts

Posted 05 May 2007 - 08:04 AM

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, 05 May 2007 - 08:18 AM.


#5 NKF

NKF

    Commander

  • [Global Moderators]
  • PipPipPipPipPipPip
  • 4,798 posts

Posted 07 May 2007 - 09:32 PM

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, 07 May 2007 - 10:28 PM.

Lord High Generalissimo Ruler Supreme of Norm's Anti Pedant Society (NAPS).

Number of members: 1

#6 ZeldaFreak

ZeldaFreak

    Squaddie

  • Forum Members
  • PipPip
  • 2 posts

Posted 09 May 2007 - 11:47 AM

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

#7 Hexer

Hexer

    Rookie

  • New Forum Members
  • Pip
  • 0 posts

Posted 27 April 2008 - 07:30 PM

I just finished making an XCOM TFTD memory trainer. I used the Windows (Gold) version of the game.
http://www.xcomufo.c...topic=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.

#8 Hexer

Hexer

    Rookie

  • New Forum Members
  • Pip
  • 0 posts

Posted 27 April 2008 - 08:09 PM

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

#9 ZeldaFreak

ZeldaFreak

    Squaddie

  • Forum Members
  • PipPip
  • 2 posts

Posted 28 April 2008 - 08:49 AM

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, 28 April 2008 - 08:50 AM.