Editing game saves with a Hex Editor

If it wasn't for videogames, I'd probably never have got into the career path I have, and a lot of that also comes from my other habit of taking stuff apart to see how it works.

Back in the days of the original Playstation, I had one of these Xplorer cheat cartridges.

This allowed the use of game cheats that weren't necessarily part of the actual game code.

In addition, the cartridge allowed the user to create new codes, by essentially searching for values in an existing game.

My understanding of it is that it effectively was a memory scanner, that would find values in the systems RAM, and allowed values to be rewritten (constantly rewriting the memory location of the health variable to read 100% would effectively be an infinite health cheat, for example).

Similar application shave been released for PC games, but to be honest, they went to involve running unchecked code and tend to have an air of shadiness about them.

Plus they tend to just be a very directed tool for a specific game title, so blinding running one might help you out with a game, but you're not getting anything useful from it.

This project is to demonstrate that similar results can be produced using standard tools, which have uses beyond games, so while cheating at the game won't make you any good at the game, you might instead learn something that is useful in the real world.

Tools
The tool being used is a Hex Editor (wikipedia). I'm using GHex, but the most commonly known editor is WinHex for windows.

Process

There are several approaches that can be taken, there are some who will painstakingly sit and work out the whole format of the file.

While this is probably the most technically sound approach, it's incredibly time consuming and laborious, particularly if you're only looking to change one or two values.

Another approach is to load a game, make a note of some key values in the game you'd like to amend - ammo, health, cash, etc. The more unique the value, then in theory the easier it will be to find in the file.

For this example we're using Saints Row 3, and in particular we're looking at ammo.

Note that there the process does involve a certain amount of trial and error, so for conciseness I'm not going to cover all of the missteps along the way, just what I did right. Of course it goes without saying making backups of the save before editing is worth doing just in case.

These are the ammo balances of the save I'm using:

The first thing to do is to convert some of these values to hexadecimal so that we know what to look for in the hex editor.

So starting with 265 - this converts to 109 in hex, or in the notation used with most hex editors, this will appear as "01 09", so use the find function in the hex editor to look for all instances of that. There are two likely outcomes, either:

• You'll find multiple instances, so the next step becomes figuring out which one is the one you want to change.
  
• You'll find nothing. In which case the endian ordering of the file could be an issue - this refers to the order in which the bytes are used to create the actual number. In layman's terms, you can think of it as reading from left-to-right or right-to-left. Simply reverse the order of the bytes above - e.g. "01 09" becomes "09 01" and search for that. If you continue to find nothing, it could well be there's some additional encoding or perhaps simple encryption on the file. There's ways around that but it's a bit of of scope for this project - I might do a follow up post later dealing with those things.
  

As it happened, with the pistol ammo amount I lucked out, there was only the one instance.:

The bytes representing the pistol ammo highlighted in red (click to enlarge)

So, let's change these two bytes to FF (the largest 2-character hexadecimal value - like 99 is in decimal), reload the game, and see what happens.

The pistol ammo is now 65535
(which is the decimal equivalent of hex value FFFF)

So, where to go from here? We can repeat the above exercise with the other values to find them, but we can help to deduce the whereabouts by adding some logic to what we already know - in this instance, we're looking for ammo values, we've found one, and we can reason that it's quite likely that these values will be grouped together.

For example, the SMG ammo value (70 00) was found nearby

The 2 values (pistol value in blue, SMG value in red). Click to enlarge.

From there we can deduce further - The pistol value starts at byte 19104. The SMG value starts at 19132 - 28 bytes apart.

So what if we look forward another 28 bytes at 19160? We find "30 00" - decimal value 48, the value of shotgun ammo. And again, another 28 bytes later we get hex "77 00" - decimal 119, the rifle ammo.

The other ammo values. Click to enlarge

So lets test it and change all of those to "FF FF"
So did it work?

Yes.

SR3 save file 'cheat flag'
Although it's not really in the spirit of this post, if you're here to just cheat at this one particular game, there's a byte in the save file that identifies if cheats were used in the game. It's the byte at 0x000000C8. You can play with cheats, then just change this flag to zero and it'll be as if you hadn't.


A final note on using cheats in games
Using cheats in games is obviously a polarising subject. I am very much opposed to using cheats in multiplayer games where doing so will affect the experience of others.
I am also generally opposed to using them in single player games - whether they're keycodes put in deliberately by the games developers or third party tools that you've just downloaded and ran.
In my opinion you should at least do a playthrough 'as the developers intended', however, they can be a good way of extending the re-playability of the game and getting more life out of your purchase afterwards, and by instead using techniques that I've covered in this post, you can learn and practise techniques that can be useful in the real world, and in my opinion the benefits of that outweigh the drawbacks.

Metro 2033 inspired "Trench" lighter

In Metro 2033 the main character, Artyom, carries a lighter fashioned from a bullet that can be used to light the way in dark areas and burn away obstacles such as cobwebs:

At a local country show I found an army surplus stand selling brass cartridge cases and saw an opportunity to make Artyoms lighter for real.

There is some real world history to this style of lighter. Known as a Trench lighter, items like this were quite common amongst troops in the trenches of the first World War, and relates to a wider concept of "Trench Art".

The case, I'm not sure what it's from.
It's approx .50" diameter at the neck,
but has stamp "SB 13"
 It seems too short to be a
standard .50 calibre round.

So with the case sorted, the next things to consider are:

• Cap/means of extinguishing the flame
• Wick
• Fuelling & refuelling.
• Ignition

Cap

I wanted to keep the lid of the lighter as a bullet style like in the game, but firearms law and lead content make the idea of using a real one infeasible and undesirable.

Instead I opted to grind the end of a copper bar down to a bullet shape, and hollow the inside slightly to make a cap.

The rounded copper bar.

Creating a hinge for the cap
The next stage is to create a hinge. A copper pipe clip was wrapped around the base of the cap, and secured with Araldite.

A second pipe clip was bent into a 'P' Shape and a bolt used to create the hinge (see gif below)

To attach this to the case, a brass olive from a pipe compression fitting (see pic.) was placed around the neck of the case, and the bottom half of the hinge was squeezed between it can the case to provide a frictional fit for now - it would later be further secured with epoxy.

Part two continues here

PC case notification screen

I've mentioned before how my interest in electronics spawned from PC modding.

Now that I've built a new desktop for the first time in a while, I've been keen to return to PC modding and come up with some projects for my new machine.

Thing is, these days PCs are designed much more aesthetically than the old beige boxes, and so there's a lot less that needs doing - the case I have has a large glass window, the motherboard already has some RGB LEDs built in - the graphics card even has some too.

I wanted to add some case lights - thought that might be a nice throwback project, but I noticed the motherboard already has pin headers for a 5050 LED strip. Don't get me wrong, I think it's a good thing that manufacturers are taking the initiative, but all it involved was little more than soldering some wires to a length of LED strip and plugging it in - hardly a project worth writing about.

So I thought about doing a new take on the case-front notification screen. In the past this would be a basic HD44780-type LCD that could display basic text - currently playing track, system temperature etc.
My plan is to use a small, full colour screen to fit with the more colourful style of the new desktop.

Other requirements are that as I dual boot Windows and Linux, it needs to work in both environments, so I'm aiming for minimal overhead on the computer itself.

Setting up the Raspberry Pi

In order to meet that goal, I plan for it to be a completely separate device that the PC can just pipe data to, and the device itself handle the processing and display. I started with a Raspberry Pi A and a clean install of Raspbian ("Stretch Lite"), and booted to the terminal using the serial console GPIO pins.

Getting connected & installing Java
I'll need to get the Pi connected to the internet temporarily to get everything setup and installed. I used a USB wifi adapter then edited

/etc/network/interfaces
 
with the following, replacing the ssid and password as necessary.

auto lo iface lo inet loopback iface eth0 inet dhcp allow-hotplug wlan0 auto wlan0 iface wlan0 inet dhcp wpa-ssid "ssid" wpa-psk "password"

then of course started with the usual update/upgrade

sudo apt-get update sudo apt-get upgrade sudo apt-get install openjdk-8-jdk
 
and reboot if necessary.

The display
As the display is to be mounted in a desktop computer case, there are some rather specific requirements.

• Size - it needs to be small enough to fit in the case
• Power - it can't use too much, and needs to be able to be powered from the computers PSU
• Connectivity - HDMI would probably be overkill, after all, it's for system stats and notifications, not a extra monitor, and it needs to connect to the Pi, so Composite video seems appropriate.

The display and its connections

After examining and ruling out various options - netbook screen, digital photo frame, etc. I came across some reversing camera kits on eBay. For a fairly reasonable price, these kits contain a small camera for the rear of the car, and a small display to view the video on.

It fits the bill nicely - small, composite video connection, and runs of 12v, which can be provided by the PSU. Perfect. The camera the kit includes is unnecessary for this project, but I'm sure I'll find a use for it someday.



Adding a GUI
The Raspbian 'Lite' distribution doesn't come with a GUI, so I needed to install one - I went with RPD.
This is installed with

apt-get install xserver-xorg xinit raspberrypi-ui-mods lxterminal gvfs
 
As the pi will be running without user interaction, it needs to be configured to automatically login to the desktop. This can be done with:

raspi-config
 
We also need it to stop going to screensaver. The easiest way to do this is to just uninstall the screensaver with apt-get remove xscreensaver.
We also need to stop the screen blanking, this can be done by adding the following lines to /home/pi/.config/lxsession/LXDE-pi/autostart

@xset s noblank 
@xset s off 
@xset -dpms

And finally we need to hide the mouse cursor:

apt-get install unclutter
 
Once installed, we need to add the line unclutter -idle 0 & to /etc/profile.
 
Setting up serial communication
The Pi will be without internet connection, so to get data from the PC to it, we'll be sending it over the GPIO pins.

Firstly, use raspi-config again to disable the serial port console, as this can interfere with the data transfer.

Then run
sudo stty -F /dev/ttyAMA0 speed 115200 cs8 -cstopb -parenb to setup the serial port.

Run the same command on the desktop - just change the /dev/ttyAMA0 part to whatever the serial port on the machine is - most likely /dev/ttyUSB0 if you're using a USB to serial adapter or Arduino. (Currently I'm using an Arduino with a 5v to 3.3v level converter, though will come up with a more permanent solution when installing the screen in the case).

Installing the software
Take the compiled jar and move it over to the Pi - I put it in /home/pi.
Create a file in /home/pi/runPi.sh containing this command

cat /dev/ttyAMA0 | java -jar /home/pi/PiScreen.jar

Edit the /etc/profile and add this command to the bottom

sh /home/pi/runPi.sh &
 
This will cause the software to run on boot, and pipe input to the serial port to the application. That's it for the Pi setup.

Setting up the desktop
The software is designed to take its input from the 'sensors' command which is part of the lx_sensors package, so install this if it's not already installed on your system.

To test the display, with it booted and running, on the desktop send the comman

  sensors > /dev/ttyUSB0

you should see the dial on the display change to show the system temperature.
Send it a couple of times with the system under different loads to see the number change.

To automate this, simply add it to cron to run at set intervals, of if you want it run more frequently, add the below to ~/.bashrc (the 5 indicates 5 second intervals, adjust as necessary)

startSensors() { while true ; do sensors > /dev/ttyUSB0 2>/dev/null & sleep 5; done } 

This will allow the sensors to be started by using the command "startSensors &" in a terminal.

The next steps will be tidying up the wiring, and mounting it in the case itself.



The UI is quite basic at the moment, but I intend to expand on it to include other stats and publish the source so that others can add their own widgets to the display.

LAN-party in a box, part 3

Part 3: The software side

• Part 1
• Part 2

Finally got round to tidying up the code. There's the arduino sketch which powers the lights, and a java application that runs in the background on the server, reads the server logs and will produce the serial commands that are sent to the arduino.

It uses the RXTX serial library, and the code itself is available on GitHub at https://github.com/darkmidnight/UnrealLANBox

There's still room for plenty of improvement, like getting the lights to flash when a flag has been taken.

I also put together a video showing the build process and a demo of it in action, see below

LAN-party in a box part 2

Part 2 - A new case

• Part 1

When thinking of a new case for the LAN box, I wanted to ensure it was easy to setup, and as portable as possible. As portable typically means 'small', it was necessary to consider the heat that would be generated by the computer when it was in use.

I purchased this ammo box from the local army surplus years ago, and it's only been used for storage, but it fits the bill nicely, it's fairly small in relation to the flight case I'd used before, has a handle for portability, and being metal should help dissipate the servers heat during use.

On top of all that, being an ammo tin, it fits the military/industrial aesthetic of Unreal well, but I wanted to do something to set it apart.

While I was planning this project, we were joking during our weekly games that we needed some kind of trophy that each weeks winner could keep on their desk, so I was looking at options for that, and I was toying with the idea of creating the iconic Unreal logo in brass, to create a shield-type trophy.

Then I figured we could combine the two ideas.


To start with I printed the logo to fit the 20x20cm brass that I ordered, and stuck the logo to the sheet to use as a template.

My original intent was to cut the brass on the bandsaw, but after a bit of testing, it was incredibly slow, and I found it easier to start by drilling around the logo, and then use a Dremel to cut out the shape by joining the holes together. From there it was just a case of grinding and filing down the edges.

The same process was used to cut a hole in the side of the ammo box for the window to be mounted, though as the metal was quite a bit thicker, I used an angle grinder for grinding down the edges.

The brass was glued and sandwiched between two sheets of clear acrylic, and mounted into the hole.

A post shared by Anthony (@darkmidnight_diy) on Jun 27, 2017 at 5:39am PDT

The original netbook that I used was too wide to fit the box, but I found another that just about fit - although I had to remove the screen, the battery, and pretty much anything else I could get away with ditching.

The next step was to add a band of WS2812 LEDs on the inside of the case, around the window, so that the logo could be backlit. To control them I used an Arduino Pro Micro, which I can in turn from the netbooks serial port. All the code will be covered in part 3.

A post shared by Anthony (@darkmidnight_diy) on Jul 24, 2017 at 7:55am PDT

Update: Part 3 available here

LAN-party in a box, part 1

Part 1 - The Story So Far
 
The title’s pretty much self-explanatory. My colleague, Ray, and I were talking about “The good old days” of online gaming – before Call of Duty, when the dominant games were Unreal Tournament, Quake 3, Counterstrike and the like.

We were toying with the idea of trying to run a LAN game over the work network, but figured the bureaucratic headache that would cause wasn’t worth it.

Then I got to thinking about how to cram everything we’d need for a LAN game into a single portable box, and could easily be set-up, used and torn down again within a lunch hour.

The great thing about returning to older games is that the system requirements, that once required hi-end PCs will now run on pretty much any old commodity hardware. What once meant lugging around heavy, bulky desktops, separate monitors and keyboards, could be replaced with a modern, lightweight laptop.

Ray was bringing in his laptop, and I setup an old laptop for me to use.

I installed Fedora 25 from a live CD (no particular reason for this distro, other than I had a live CD for it to hand – I’m sure others will work fine) Installed WINE, and the game.

We also wanted to use a dedicated server, so I dug through my stack of old hardware to find something to use - and I setup the server using an old netbook.

The networking was provided by an old home router of mine, which supplied DHCP configuration, making the network a straightforward plug and play.

This whole setup was stuffed into a metal flight-case for taking into work, and worked well for a spot of lunchtime multi-player, but there were a few downsides:

• Cabling – lots of mains plugs and network cables.
• Size - it's quite a substantial amount of gear to lug around - the flight case measures 33x46x15 cm and is packed pretty full.
• Although UT runs quite well in WINE, there is definitely some latency. The server seems fine, but graphically on the client machine, it's noticeable
  

The original setup - the netbook in the background is the current server.

Obviously something needs to be done to address the shortcomings, so this will form the basis of my next project - it should be a nice mix of DIY (for the case) and tech (hardware, software config, networking etc).

Update: Part 2 is now here

Remastering Tiny Core Linux

Tiny Core Linux is a lightweight Linux distribution designed for Live CD usage. Its low system requirements and small footprint also make it a good candidate for reviving older computers or as a base for building virtual machine appliances.

Unfortunately the remaster tool it includes, which is meant to allow for custom Live CDs to be created with chosen software pre-installed, seems to be buggy, and continually failed when I tried using it, so this is the alternative way I found to remaster TCL.

Step 1
Create a basic virtual machine and boot with the TCL Live CD. I used the CorePlus-current.iso, which has some extra software on there, but is still sub 100MB.






Once it's booted to the desktop select TC Install.

Select USB-HDD, whole disk and 'sda' options on the first screen.

Click through the next two screens (formatting options and boot options)

On the install type I checked the Installer Application option as I might need it in my intended application later, but it's optional.

Click through to the next screen where you're selected options will be repeated back to you, and select Proceed.

When it's done installing, shutdown the VM, remove the Live CD image and restart, so that it boots from the HD.

Step 2
Go to apps, and install the software that you require. In my case I installed Open JDK and Filezilla. (Filezilla also requires libiconv to be installed)

Reboot using the TC Exit options (from the menu go to Logout). The backup options there will essentially create a blank mydata.tgz file structure for you to use later.

Once rebooted, copy the /mnt/sda/tce1 folder off the VM to the host system/memory stick whatever (As I installed filezilla I FTP'd it to another server on my network.)

Step 3 (Optional)
On the host system, edit the mydata.tgz that you copied over, and add in any necessary files that you want on the Live CD. Thanks to the reboot that you did in step 2, mydata.tgz will have a basic file structure in place, that maps to the home and opt directories of the live CD. Also it puts in a couple of SH scripts, bootlocal.sh and shutdown.sh - these handle things that you want to execute on boot and shutdown respectively, edit those if you need to.

Step 4
Use an ISO editor (I used ISO Master).
Open the LiveCD, and navigate to it's 'cde' directory
Copy your mydata.tgz to the ISO, and replace its onboot.lst, and 'optional' directory with your own.

Navigate back to the ISOs /boot/isolinux directory and edit the isolinux.cfg file.
Find the line

TIMEOUT 600

This line causes it to sit on the bootloader screen for 60 seconds, unless the user selects and option.
I want my live CD to boot without user interaction, and that delay is redundant, so I edited it to

TIMEOUT 10

which allows a 1 second delay before continuing to boot the default option.


Save the edited ISO. To test, setup a blank VM like you did in step 1, and select the edited ISO as the boot medium. TCL should load, with your apps and files already there.