|
Hacking programs |
Second, you gotta know where to look. If it`s a code it would probably be in an EXE or OVL file, but you can check other files too. If it`s data it can be packed as constants inside an EXE file or in a outside data structures. You just get yourself a HEX editor, you can use Microsoft Developer Studio as debugger also.
Then you have to search inside a file for a teeny tiny string where all that is written. You can write your own programs to do the job. If you`re not sure if you found the right thang, the best way to figure that out is to corrupt that part. If program freezes, then you`re wrong. If you get expected results, then you`ve hit with the hammer on a nail.
Modify that string ... and voila!
|
|
| I wanted to modify a flight simulation
so, that it would be possible to use nucear weapons.
That required me to change some numbers inside the program. To effectively change a weapon I had to change all data connected to it. That would be:
To write down a number 500 in binary you have a few options. BYTE variable is invalid, cuz it can reach only up to 255. Next one is WORD and then DWORD type variables.
Then you also have an option to write it down in FLOAT or DOUBLE types. Consider this, but it ain`t a real possibility, just in special cases. So, I chose to look at word variables. Be aware, inside the file 0x01F4 is written in opposite order (since variables on stack are ordered from top to bottom, least significant BYTE is at the top of variable`s area in memory and the Most Significant Byte is at the bottom of variable`s area in memory). If you wanna find a number 0x01F4 you have to search for string F401. (Similary, if you have to find a dword 0x12345678 you`d need to look for hex string 78563412. The same stands for floats=32 bit dword-like numbers and doubles=64-bit qword-like numbers). Also keep in mind, that BYTE may be found on every byte-sized part of memory. A WORD, DOWRD, QWORD, float and double can only br found on addresses that are multiples of two/four/eight (WORD/DWORD/QWORD data alignment). When writing programs it is a tendency to align data inside memory on DWORD alignment - multiples of 4. That is, because in 32-bit mode, all the registers are 32-bit. And 32-bit linear addresses are used to address phisical memory. And when you order processor to load a DWORD number into some register, if that number is NOT located on DWORD-alignment position, then processor needs additional time to addres it. So, when you write programs and create data structures, it is not wise to use BYTE variables if you expect numbers only up to 255. Because then, all the folowing variables will not be properly aligned, and if you`ll access such variables often enough, it will slow down your program very much. OK. So now we`re searching for a word string F401. We make a special program, that writes down address of every match. Then we do the same for other weapons. And the manually compare the results. If we find that all the weapons have one of the numbers that could be their weight inside (let`s say -512 + 512 bytes from some center point) radius, then that`ll probably be it. But with this method, you can get A LOT of results and you have to
comare all that stuff.
Well, back to searching. I first searched for weapon weights in them ARMSxxxx files. And found nothing. Zipo. Nada. Then I went looking in the EXE file. And I got a lot of results. So, I tried to predict the order of weapons. I loaded the EXE file into a HEX browser, and quickly looked over it. I ordered the browser to search for words like "AIM-9", a name for an Air-to-Air missile. And it found several hits. I took a look of them and found on one place, all the names of the weapons. I used that order to search for weapon-weights. So I wrote another special short program, which searches for a specific weight. When it finds one, then it looks for the others placed relatively to this one but at various radii. First 2 bytes, then 3 bytes and so on. This kinda calculation takes time. Approx an hour maybe, if the file is long. I got reported hits. I went to check it out with HEX browser, and
found all of the weapons WORD weight values stored in proper order. Well,
not exactly. If yo make a program that searches for a specific order, then
you`ll find nothing. You have to write a program that reports a hit whenever
it finds more than let`s say 3 matches. Then you just look at the number
of matches and check the most probable ones.
OK. I found two places in file that contained weapons weights. So,
which one is the correct one? Let`s corrupt it and we`ll see. I chose a
specific weapon, and increased its weight to max (0xFFFF). Then I went
into the game. When I chose that weapon in Load-Armament window, weapon
data said the bomb weight was -32768 pounds. OK. I corrected it to 0xFF7F
(remember 0x7FFF=32767, in memory stored at opposite order), and loaded
it on the aircraft. I went flyin` and the aircraft took off noramlly!
The first string found was used ONLY by aircraft-armament procedures, the second string ONLY by the aerodynamics procedures. Now I knew the order and where to look for. So, next thing I had
to correct was the weapon aerodynamic drag. Put in the search numbers and
the order and there they were. String of BYTEs. Also on two places. One
for load-armament and one for aerodynamics.
Now I had a bomb of correct weight and drag, instead of Mk-82-1 HDGP, I had a B-43 Thermo Nuclear Weapon. But I could still load 12 of`em on the plane instead of one. So I went looking for the weapon-hardpoint data. Say, F-16 in game has 2 wingtip hardpoints, 6 underwing hardpoints and one under-fuselage hardpoint.
I
So we look for a string (probably bytes) = [00
00 06 06 00 06 06 00 00] or [00 00 06 06 00].
But we still need to modify the energy of weapon. This one`s gonna be tough. It can be a BYTE, a WORD a DWORD or even a FLOAT. I went into a game, and made several tests.
I was looking in all possible ways, and had no luck. I allready knew which part of the EXE file was doing what, so I searched again for the weapons names. And there was one string of names that didn`t fit in my suspected order. Besides, there were also other weapons, used by ground crews (Surface to Air missiles, enemy A-A missiles etc...) Well, I just wanted to be sure. There were some suspicious numbers
folowing that names. They looked like WORD values (y`know: 82 00 4F 00
23 00 12 00 35 02 05 00 E8 01 7F 00 ... where those very small numbers
at even places just cry out that they are the HIGH BYTE of a WORD).
I lined up a column of vehicles and shot weapons at it. Can y`imagine
an AIM-9P air-to-air missile with 20 pounds of explosives torching instantaneously
up a one mile column of armored vehicles?
I expected that the safe drop altitude will be 18000 feet or something. Noooo, it ripped my ass. So I tried again from 25000` then 30000` then I went almost berserk. 35000` and I still suffered a flameout. Well at 40000` with 500 kts I was safe. But from that altitude you cannot aim accurately. So, I setup a friendly flight at 1000 feet flying below me, then I dropped The Bomb, measured drop-time (until the guy below started screaming) and then measured the distance from release-point to crater. And there y`have them Nuclear Bombardment procedures. |
|
|
| Well, you cannot fly the StarWars
X-wing / B-wing or Tie fighter simulation with keys. That`s for sure.
But neither y`can with mouse. Because them clever programmers baked into the program mouse commands that read out mouse velocity insteda mouse position. I wanted to modify a flight simulation so, that it would read out
mouse position instead of mouse movement-velocity.
Every program (well DOS programs) communicates with mouse device through an interrupt. More specificly, that is the INT 33h (0x33). Depending on the task you want the device hadler to perform, you put the number of that task (function) into AX register, if you need to send additional data to interrupt routine you put it into BX or DX or CX register and then you call INT 33. Piece a shit. The assembly code would look something like that:
You can write that down into an ASM file, build an OBJect, and disassemble it again. When you disassembel it, you`ll see exactly into what numbers (machine code) the assembly instructions are coded. But first wee need to find the area in program, where the mouse functions
are. Again, we order the HEX browser to search for hex string CD
33 (0xCD is hex code for INT instruction, and 0x33 is the interrupt
number). Of course we look for them in EXE file. And we find nothing. So
we select all the files (the longer ones are more probable) and run the
scan. And we find some hits in OVL files.
When you know this, you just make a program that copies a part of surrounding code (around the match in OVL file) into this neutral OBJ file. Perserve the neutral OBJ file. The code you need to copy is not long. It will do if you copy -256 to +255 (512 bytes) around offset point. Now`s the time for disassembly. You`ll get a new ASM file, with all
instructions. You have to be carefull to define first whether it is an
16-bit or 32-bit code.
So, now you need to visually identify if the code is right. You need to know assembly very well. If you see a bunch of stupid instructions (just randomly ordered instructions, that do nothing), then you`ve just disassembled a data structure. If you see some sence in it, then you got it.
Check it out here. |
PCGPE
(PC Game Programmer`s Encyclopedia)