RWP Hacking Class #1

Welcome to the first RWP Hacking Class.
Thank you for coming. I'd like to first say that the point of this class, is so that as many people as possible in the RWP community can learn how to hack, what it is, and be better informed, from the ground up. Even if you don't want to do anything advanced, it is still very worthwhile to learn these techniques for at least discussion. Hacking is not necessarily difficult, but most of what you learn is by experience, and working with others. PLEASE PLEASE stop me at any time and ask questions. It's boring for me, and boring for you (and you learn worse) if you do not stop me and ask questions. And I won't know if you are learning if you don't say anything at all. Do, however, try to avoid unnecessary or irrelevant conversation in the chat channel. I recommend you log this chat so you can relook at it later, but I will release a transcript. With that, class 1 has begun.

The first thing I will talk about are codetypes, and what they mean. When you go to do a search, on the actual N64 you can only choose between "8-bit" and "16-bit", however, on Renegade 64 by Viper you can also do "32-bit" (which is very useful). So what does this mean? If you have programming knowledge, it will help here, but it's not required. Lets start with 8-bit codes, or first bits in general. A "bit" means information stored as either a 0 or a 1. It can really hold any information, for example 0 means it is day, 1 means it is night. Don't be fooled, it is perfectly fine to have 0 mean it is night, and 1 mean it is day. 8-bits, means 8 of them in a row. 16-bits, means 16 in a row, 32-bits, means 32, etc. Computer programs stored data primarily in these sizes, and so do your n64 games

First of all, unlike with our normal numbers, we view everything in base 16, in a form called hexadecimal.Hexadecimal is much like the normal number system, but instead of only being 0 to 9, it it is 0-9, then A, B, C, D, E, F. A (hex) = 10 (decimal), B (hex) = 11 (decimal), C = 12, D = 13, E = 14, F = 15. It works similar to our numbering system.
So if you want to express for example 20 in decimal, it's expressed in hexadecimal as 14. Why 14? It's equal to 1 * 16 + 4. However, you don't need to do this manually, since you can use Windows Calculator to convert (choose advanced mode, then there is a setting for hexademical). If you type a number in decimal, then move over it will show you. Lets all do that now. Start -> Accessories -> Calculator. View -> Scientific. Choose Dec in the top. Now type in a value, lets say 100. Click Hex now. It should turn into 64. This value is in hexademical, base 16. Click C in the top right to clear the calculator, then type FF, now click dec. It should show as 255. Great, we'll use this knowledge later

Now, back to the choice between 8, 16, or 32 bits, remember I mentioned them, because these bits are in a row, you can use them for a variety of purposes. 8-bits means the values in hexadecimal are integers between 00 and FF (255). This is called a byte or char. If it's used as "unsigned", it stores between 0 and 255. If the value includes negative numbers, it can store between -127 and 127. 8-bit is considered a byte or also a char (short for character), 16-bit is a short (0000 - FFFF or 65535), and 32-bit is a long (00000000 - FFFFFFFF) [use windows calculator to convert]. These are the three methods when we search for codes. This is what we call the memory viewer - because it shows contents of memory. Here's a picture of what it should look like:
The address is shown on the left side. Then the contents starting at that address are in that line. So in the picture it shows 80306520 is one address (up top). So across the line you have the address starting at 80306520 to 8030652F (remember it is always in hex). Now what you are seeing is the data. We can view the data as 16 "8-bits", 8 "16-bits", or 4 "32-bits". The 8-bit code of that address is 26 (this is hex remember). The 16-bit code is 2607. The 32-bit code is 26070002. What's the 16-bit value at 8030652C? Anyone?

One interesting and important thing to also be aware of are floating point numbers, are 32-bit values. These are not stored typically as above. Most games use these a lot. These floating points values allow for the storing of decimal points. Previously, we could only do integers (whole numbers). So with a floating point value you could store the value 3.124 or 4.50. With integers you can only store like 0, 100, 50023, etc.
This converts between hexademical and floating point. Lets try one conversion
The best value to know is 3F800000 which equals 1. Type 3F800000 into the hex box there and click compute. It should say 1. Now try 40000000. It should say 2. Once you play around a little, you'll learn to notice what is a floating point value by inspection, and what is signed, and what is unsigned. The most important thing to know is just that if you think an object uses decimal points, it probably is 32-bit.

In terms of gameshark codes, an 8-bit value is shown by 80XXXXXX 00YY. When you see an 80, it means 8-bit code. The XXXXXX is the address of where your code is [in hexadecimal], and YY is the value you are forcing to ALWAYS be in that spot. (remember, these are both in hexadecimal). What does this mean? Well, if you have a value that stores how much ammo you have, if the game tries to store a value to it, it will always be overwritten to whatever you want there. In other words, lets say you shoot a bullet. If you have 7 bullets, the game wants to say now you have 6 bullets, but instead we overwrite it with our value. What's an address? An address is a location where a certain value is stored. You don't need to know much more than that except that when you are hacking, you are looking for an address of a particular 8-bit/16-bit/32-bit value.
81XXXXXX YYYY is a 16-bit gameshark value. XXXXXX is again the address, and now instead of only having a byte to work with, you have 16-bits (YYYY) that you can force to always be on. There is no code for 32-bit values, but there should be.
Instead, you need to represent them as 2 16-bit values. So if you have a location, say 012344, and you want to put 32-bits of information (say 00112234). You would need to form it as 81012344 0011 and 81012346 2234. It is important to note that addresses for 16-bit codes MUST end with a 0,2,4,6,8,A,C, or E. Just remember this for now and take my word for it that this is the case (or not). 32-bit values must end in a 0,4,8, or C
64-bit values would end in a 0 or 8, but they are very rare.

When you are hacking any code, you need to guess what kind of value the programmer's would've used for it. For example, if you are trying to hack a size modifier or coordinate modifier for something, it's very likely it's stored as a floating point number because it needs those decimal points (32-bits).
If you want to hack infinite ammo, it's likely stored based on the maximum ammo possible. So if you can only shoot 10 bullets, it would only 8-bits. If you could shoot 1000 bullets, it's probably a short and is 16-bits. This comes from experience, Don't be discouraged, keep trying 8-bits, 16-bits, then 32-bits if you can't find a code.
If you are trying to find a value, and it's a low value, such as lets say 0, 1, or 2.
It may very well be stored as a long (32-bits - ex, 00000001). HOWEVER, small 32-bit values, such as the value of 0, 1, and 2 will be found using any search, 8-bit, 16-bit, or 32-bit. Why? Can someone answer this? It's usually best to start with 8-bit searches, and then try 16-bit, then 32-bit, if you are completely unsure.

Before we finally start to hack, lets just talk about known and unknown searches. Known searches mean you search by exact values. Renegade 64 searches using hexadecimal to search for these known values. If you want to search for decimal values, you'll need to convert to hex using windows calculator as we did before. So use known search to search for specific values. For example, if you know a timer is at 105, you will search for hex value 69

Unknown search, however, is different. It's for searches where you don't know any specific values. Instead, you grab "dumps" of the memory, and compare them. So lets say you do the first dump. Now you want to either do a Less than, Greater than, or Equal to. Equal to means your value is equal to last search. Less than means the value is less, etc
You would use this if you don't know anything about your value. For example, if you want to hack out infinite health. You don't really know what the health value, but when you get shot, it is likely your health goes down (less than), and is equal if you have not been shot since last dump.

Lets talk about how to hack now. What you are doing is scanning where the game stores all of its data. We are trying to find out the location of a value (also called a variable) that has the information we are seeking. If we are seeking a code that does infinite ammo, that's what's what value we are looking for.

Lets now jointly hack an infinite ammo code for Goldeneye. Start up Project 64, open Goldeneye, now enter dam and pause (press F2) when the level is loaded. Open Renegade 64. Choose Cheating -> Attach to Emulator. Choose Project64 1.6 then click Attach (it should say running, if not, that's bad). Now choose Cheating -> Code Search
This is where you will do all of your hacking.

Now go back to Project 64 for a moment. If you look, you have 7 bullets in your pp7.
We want to hack an infinite ammo code. Press F2 to pause the Project 64 emulation. This seems like we should do a known search, because we actually know the value of # of bullets. Is this 8-bit, 16-bit, or 32-bit? We don't really know, but lets guess 8-bit because no guns shoot above 255 bullets, and it's silly to have negative bullets (so likely "unsigned"). You should be in the Code Search menu in Renegade64
Now, enter in the value 7 in the value, and make sure the search type is set to Known value. Click Search in the upper right. There are too many possibilities shown to narrow it down
Shoot a bullet in Goldeneye, so you have 6. Press F2 to pause the Project 64 emulation. Now search for 6 in the search box in Renegade. Repeat for 5, and you should have enough codes. Renegade will show the possibilities in a pop-up box. As a general rule, you won't really want to analyze the results until it's less than 100 possibilities, but sometimes you can't narrow it down and must. You will need to test these codes one by one in Project64. To make things faster, I will you tell that the correct address is 800D37FF. To test in Project 64, set the value for example, to 100 in decimal. What is this in hex? It's 64. So you want to enter 800D37FF 0064. Try it out. It works, great!

OK, that was easy. Now lets do an infinite health code. Close the Code Search page and reopen it (Cheating -> Code Search) to start a new search. We don't know much about it, except I will tell you most health values are floating point (32-bits). So we will do a 32-bit *unknown* search. We don't know the health value (no clue at all), but we do know if you lose health it goes down (make sure you always press F2 to pause before you move to Renegade). So we now do the first grab. Choose the == right above the value spot from before. It will automatically choose the unknown search mode. Now we've done our first ram dump. Get shot by the first guard. Your health has now gone down. So go back to Renegade 64 and choose the "<" symbol, which means less than last search. If you can manage to not get shot, do an == search (equal to last search), if not, get shot, and do another < search. If you want, you can try restarting the level, and now choosing a greater than search (tricky! sometimes removes a lot of codes).

Try this repeatedly until you get down to only a small amount of codes, say < 30. You will need to test these codes in the emulator. To test, you know that 3F800000 = 1.0 (since this is a floating point). It actually doesn't matter what you fix your health to, as long as it is positive (not negative and not zero). Remember, that the gameshark codes fix a spot in memory. So no matter what, the game cannot overwrite this value. Even if your health is set to 0.1, it will always be at 0.1 so you can't die. Still I recommend setting your health to the original max, 3F800000 = 1.0 (or whatever the game would be). I narrowed it down to two possibilities: 800D303C and 800D304C. So try the code one by one: Remember we have a 32-bit value, but you can only input 16-bit codes to Project 64 or a GameShark. 810D303C 3F80, 810D303E 0000 is one test. 810D304C 3F80, 810D304E 0000 is other. Try one at a time, and get shot, and you'll notice with one of them your health won't go down!

One final useful thing we will cover is the memory editor. Notice before we blindly tested codes. Now we want to look in memory at all of the addresses and make a more educated decision. You can use either the Project64 Debug version that I posted, or also renegade64. Can you guys get the debug version going? I can show you either way.
If you use renegade64, choose Cheating -> Memory Editor. Then enter the memory location into the menu and click Goto. Your memory location should be 80XXXXXX (XXXXXX = address). If you are using Project64 Debug, choose Debugger -> Memory, and do the same thing. It's also useful to find similar codes in the same area. When it shows you the address, you can look on the left side and find the new location.

For example, if you find an object's size, it's likely the object's coordinates and health are nearby.Also, if any data is actual text, you can see the text on the right side. Hope this has not been too fast, and you learned enough to start playing around. I recommend you save this chat and reread it and go along with the tutorials again, trying again. Your homework is to hack a walkthrough a crate code in Goldeneye (it's ok if you don't succeed). Hint: It's an 8-bit value, and it is uses only 00 and 01 (means use known search)

Next week we will hack some slightly more advanced codes!
%s1 / %s2