%%%%% &&& &&& %%%%%%%% %%%%% %% && %%%%%
%%% &&& &&& %% %% %% %% && %% %%
%%%%%% &&&&& %% %% %% %% && %% %%
%%% &&& &&& %% %%%%% %% %% && %%%%% %%
%%%%% &&& &&& %% %% %% %%%%& && %% %%
&&&
&&& Ascii by Phoenix
&&& www.extalia.com
======================================================
| Target: Games running in a N64 emulator |
| Topic: Hacking Emulated N64 Games |
| Audience: Beginner / Intermediate |
| Author: [Psych] |
| Date: 03-10-08 |
======================================================
------------------------------------------------------
*Best read at 1024x768px or higher with word-wrap on*
------------------------------------------------------
-------
|Intro|
-------
Firstly, how the hell can you possibly classify a tutorial or article
under the 3 common areas (beginner/intermediate/advanced). You can't
really, but suffice to say that this tutorial is not too long, and by
no means complex. Anyone will a little experience in memory searching
will be able to relate to this.
So why have I made this tutorial. Well, I actually installed Project64
a little while ago to assist someone with issues hacking a game running
in it. Why not make a tutorial out of it so more people can benefit?
Besides this, I have discovered a plethora of members on various forums
across the web that struggle to create any working hack for games in
emulated environments. Not necessarily just for N64 ROMs, but others
too. More recently PSP and Wii games. Hopefully this will give ideas.
I will try to make what I type from now on as clear as possible, both
from a grammatical standpoint and a gamehacking standpoint. Basically,
I'll explain what I do as fully as I can without confusing things.
If anyone wishes to translate this tutorial, so long as I can notified
first and the tutorial is kept in its entirety, I do not mind at all.
I am all for this, as its not just the english-speaking world involved
with this stuff of course. Also, as far as distributing it on the web
goes, that is also fine, so long as it is not modified in any way.
Ok, so with all that out of the way lets get started...
--------------
|Stuff Needed|
--------------
- A N64 emulator. There are several around, but I will be using
Project64 for this tutorial. Others could vary, so I would stick to
this if you are new to this sort of thing. Here is the link:
www.pj64-emu.com Grab the most recent one. I have v1.6 for this tut.
- At least one working ROM (game) to run in the emu and later hack.
I will be using 'The Legend of Zelda: Ocarina of Time'. IMO, one of the
best games of all time, period. The exact ROM name follows:
"Legend of Zelda, The - Ocarina of Time (U) (V1.2) [!]" (exclude quotes)
***Keeping things legal though, I cannot provide support/links/downloads
for anything to do with ROMs. Whether they are legal or not, depending
on if you have an original catridge or not, is not my concern. I am not
familiar with the laws surrounding this***
- A memory scanner [I will be using Cheat Engine (www.cheatengine.org),
but you can use whatever you wish (T-Search/MHS etc)].
- A little time and patience, and thats should be it.
------------------------
|(1) Finding our values|
------------------------
So fire up the emulator and load the game. Windowed mode is a good idea.
Also start cheat engine and pick the game process. Both the emulator and
cheat engine have their own help documentation/tutorials/forums, so if
you need help with any aspect of those, refer to those places for it.
I have acquired a Legend of Zelda save file from the web and loaded from
that, so I can skip all of the pre-game movies and stuff and get straight
to work. You might want to google for that to speed things up a bit.
One of the most obvious variables in this game (like most games) is the
cash/money. In this game its the rupees in the bottom left of the screen.
Search for the value you have currently. 500 in my case. Use 2-byte as
the value type in CE (cheat engine). This is because rupees can never
have a value larger than 500, and the max value of a 2-byte/WORD is 65535.
And the emulator may only store values in data-types that are necessary
for it to work, to efficiently handle memory space. To be on the safe side
we will adopt this process from here-on out, so we don't miss any results.
My scan brought up over 500 results, and yours will be similarly large.
We need to filter these results down, and to do so we need to make that
amount change in-game. So find a shop or NPC so we can buy something.
I bought some blue fire, which brought my rupees value down to 200.
Input this second value you find into CE and choose next scan.
This should leave you with the one value. Double-click to add this to the
cheatlist. And then double-click the value in the cheatlist and change it.
Make it 123 for example and watch what happens in game. It should adjust.
Great! So we have hacked a variable in the game. That was the simple bit.
Now the problem is, when we reload the game this address will be different.
This is because all the game data is stored in emulated memory, and this
whole area gets allocated to a different position on each restart. This
process could vary with different emulators, but this is usually the case.
So how can we make it so our hack always works? The clever ones reading
this might be screaming 'code injection', but this is not a feasible
option when hacking emulators. This is because many different game
variables get piped through the same instruction(s). Without a very
in-depth comparision this is impossible to use for single hacks.
It has been stated as 'possible', but I've yet to see someone effectively
do this sort of work.
-------------------------------
|(2) Making the hack permanent|
-------------------------------
I will will show you one method of doing this. It involves finding pointers.
Pointers are essentially memory addresses but they hold another address as
their value, thus 'pointing' to another location. We will find a certain
pointer 'path' through memory which will always lead us to the variable we
want to hack. This is a very simply process with N64 emulation as we don't
have to do all that much work.
In CE, right-click the address we found earlier and choose
'find out what writes to this address'. Go back into game and make the
value change (buy/sell something). In a small 'debug' window we will be
presented with a line of code. This is the game instruction which deals
with the increase and decrease of the rupees. This opcode is also
allocated dynamically along with the game varibles at runtime. Just FYI.
I have this as my result:
7918b79a - 66 89 be 00 00 1b 4e - mov [esi+4e1b0000],edi
Yours will almost certainly be different. Basically, the game has
calculated our new value of rupees and this instruction storing the new
value into memory. The new value is held in the 'edi' register, and the
[esi+4e1b0000] represents our rupees memory address that we found.
Now, when debugging an emulated game, if you see a massive offset
following the register in brackets, like we have here (4e1b0000), that is
a good sign. That offset is actually a memory address, and it just so
happens to be the start of the game's emulated memory where all the stuff
is stored. The 'esi' part actually holds a value, and this value, added
on to the start of emulated memory will give us the current address of
rupees.
Double-click that instruction and i'll show you. In this window, we can
see what each register holds. We are interested purely in the edi and esi
registers. Think of these as temporary holding areas for values and
addresses before they are commited to memory. Take a look at esi.
It holds 11ACB6. Do this: 4E1B0000 + 11ACB6, and you'll end up with
4E2CACB6 which is our rupees address. This will however change on a
restart so we still need to go further to make this hack permanent.
Now, take a look at the line in this window that says:
"The value of the pointer needed to find this address is probably..."
CE is suggesting a value that we can search for in order to find a pointer.
Theoretically, using this pointer will allow us to always find the start
of emulated memory (in our case at least), and we can then add the offset
of 11ACB6 (which will never change) in order to find our rupees address
every time. We can do this based on the fact that games usually store all
of their variables in structures. Health/magic/cash and so on are all
next to each other (relative) in this structure, even though the whole
structure itself changes on a restart.
Don't get that ^, don't worry too much. It'll come to you. Note that
large offset down (the start of emulated memory - 4E1B0000). It will be
different for you, so make sure you take yours not mine. Close the two
windows, and get back to the main CE interface. We will use the scan
again, but this time we need to ensure the value type is '4-byte' and hex
needs to be checked. This is because 4E1B0000 is an address and as a
result is stored in hex notation. Type your offset into the box and hit
the scan button.
I have pulled up a large 137425 addresses on my scan, and you will have an
equally large amount. Notice though, that we have some green addresses,
mostly right at the top of the scan (with the low address values). These
are addresses that CE believes to be static (ie. they never change), even
on a restart. This is not always the case, so never think that it is
foolproof because its not, but on this occasion we will use one, on the
understanding that it will never change.
The very first address should be ideal for our use. Mine is 4FADAC. Yours
could well be the same if your version of project64 is the same as mine.
This address is not stored in emulated memory, as its not part of the game,
its an address in the memory-space of the emulator itself. This will always
hold the value of emulated memory. All we have to do to find our variable
we want to hack is read from this address, and then add the offset of
11ACB6 to this to get it. This doesn't have to be manual, that would get
quite annoying, so we can let CE do it for us.
Choose 'add address manually', and tick 'pointer'. Input the green/static
address we just found (4FADAC in my case) and then for the offset input
the value of esi we found earlier (11ACB6 in my case). Then click ok to
save this entry. It will appear on your cheatlist now along with the other
address we found. Now you might want to save this cheat table at this point.
Restart the emulator now, but keep cheat engine open. We'll need it again.
Its time to test our findings. Load the game again and make sure CE is
properly attached to the process. Check the value of rupees that we found
at the very beginning, it will have changed to ???????? or some other value
that doesn't correspond with rupees in-game. But check the pointer we made.
That still holds the right value of rupees. Notice that the address is
different. The allocated memory has shifted position but the base pointer
still knows where to find it. Combined with our offset, it calculates very
simply the address we always need!
-------
|Outro|
-------
And thats it. That brings this tutorial to a close. I hope you gained
something from this. I'll be making more tutorials, and they will cover
various topics, its just finding the time to do these things thats hard.
Any feedback, suggestions or requests of what you might like to see, send
it all my way (to my super spam-proof email): psych[at]live[dot]co[dot]uk
--------
|Greetz|
--------
Greetz fly out to my Team over at extalia.com and all those that contribute
there. Also, greetz to all those over at gamehacking.com and doxcoding.com.
Personal greetz to RiSiCO, for keeping gamehacking.com running smoothly,
Wiccaan (one of the most resourceful people I have met), Sunbeam, Lab, STN.
Finally, keep up the good work Brewers, ASXDox, Unleashed & Reloaded...
~Psych
domingo, 19 de octubre de 2008
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario