RenegadeEX2 - EX Plus 0wnage Disclaimer Version History Features Hook Tab Code Search Tab Results Tab Memory Editor (WIP) Cheat/Trainer (WIP) Settings Tab File Utility Tab Future Plans/ToDo List Project History Credits/Contact Disclaimer The author is NOT responsible for any damage caused to you computer by this program, the usage of it, etc. or any damge caused to your brain while trying to understand it. This program in no way encourages piracy and the utilities in the program are intended only for those who have themselves legitimately created archival copies of their own games. </Obligatory Legal Bullshit> Version History Version 2.03 5-31-2015 The more issues I run into with comparing files, the more this pisses me off. It's always something. This version has a few more fixes, which hopefully won't break anything new, and auto refresh options are enabled in the memory editor. Version 2.02 5-6-2015 A couple little fixes for comparing files. The memory editor tab is enabled now, and should be mostly functional. I really only finished it because I didn't want to fuck with outdated source fixing other things. Only took me 2 years. ;) Changes: Memory Editor Enabled A few fixes related to comparing files Version 2.011 3-28-2013 I challenge anyone to fix the commented code for shrinking search area on the fly located in the RunSearchThread in tab_search.c. I've tried this countless times throughout the history of Renegade, PS2CC, etc and it never fucking works. Changes: Little status bar fix Fixed the default font actually being applied to value boxes. Version 2.01 3-28-2013 Quickie update. The Artemis winsock comms library isn't as clean as I'd like, but it damn well works and didn't take much to impliment. Also Added GCN to the systems. See more info in the auto hook section. Changes: Artemis hook type implimented GCN System Option When searching multiple areas, the status bar now indicates X/X so you know how many it's running through. Version 2.00 3-27-2013 A new begining. (cue the Star Wars music) Features This version is a complete rewrite (still in C/Win32API) using both RenegadeEX and PS2CC as references. Most of the important stuff has made a return. The memory editor will hopefully come back soon, along with other goodies. You may notice a few additions/changes, as well as a somewhat better GUI. The Hook tab has been completely reworked, and I'm hoping it'll be more functional this way. If you're into C, be sure to check out the rather insane source. The original source was a complete an utter disaster. My goal in rewriting this was to make things cleaner, a little more organized, more flexible, and allow for certain things that I was just breaking the original source trying to do. Current Features: Code Search Byteswap/Endian Tool Probably the only Readme you'll ever see that's valid XHTML 1.1. ;-) Hook Tab This version Renegade features a different editor for attaching to processes. In some ways, it's simpler. It's meant to fix some of the hooking problems in the past and hopefully be a little less complicated. The ongoing problem is that emulators running on different machines and different versions of windows can end up storing the systsem's RAM anywhere in their process memory or even be different everytime you run them on the same machine. The Auto Hook button is meant to deal with this problem, at least for common emulators. Hook Types: File Mode: For comparing files (duh). You can set offsets and area sizes. Area size being FFFFFFFF indicates the whole file from offset on. You'll be asked to choose a file each time you click the search button. Dump from Process: Hack an emulator/PC game. This is one can be tricky to setup if there's no preset for what you need. Artemis: Hack using a PS2 connected to your network via network adapter. Project Artemis (and PS2rd) was made possible mostly by misfire and jimmikaelkael. LazyBastard got me involved with the project to make the PC side search tool (PS2CC). This is currently READ ONLY. No cheat testing. Set the PS2 IP in the settings. Snake Remote: Not implimented. This is my own little idea spun from a combination of Tmk Search's remote option and Parasyte's SRDP talk. The point would be to write a little console app that could be run natively on an OS like linux without completely porting the program and making a new GUI. The user could then run Renegade in WINE and set it to communiate with the machine itself (127.0.0.1) and demand process info and dumps from the native app. After seeing how winsock works a bit setting up PS2CC, it seems perfectly doable. Endian Endian is the order the bytes are being read in for comparison. Different systems read their memory different ways. PC is little endian, but some game systems like N64 are big endian. What further complicates things is that when grabbing PC memory, you're grabbing it in the PC (little endian) byte order, but the emulator may be showing it to the console CPU flipped to big endian. I'll try to describe the endian options I've implimented. This option effects the way the values to read from the memory dump for comparison. Little Endian (System): The dump is in little endian and is for a little endian system. Little Endian (Big Endian System): The dump is in little endian, but the system would be seeing it in big endian (like copying N64 memory from an emulator). "Aren't we still filpping 44332211 in the file to see it as 11223344 either way?" Well, yes, BUT... if the system is big endian and it reads the 3rd byte, it would read 33, but a little endian system would read the 3rd byte being 22. Fuckin confusing, right? Try coding this shit. Big Endian: The dump is to be read in exact byte order like a ram dump from the N64 itself. 11223344 in the file is 11223344 for compare. 16-Bit Little Endian (V64): This is the format V64 ROMs are in (and possibly other obscure things). Instead of 11223344 appearing in the file as 44332211, only the 16-bit values are swapped, so 11223344 is 22114433 in the file. Auto Hook This idea was inspired by my method of finding the NDS RAM in No$GBA (mostly figured out due to the nagging of a certain ancient sage every time a new version of No$GBA came about ;)). The idea here is to find a method of isolating the game system ram within the emulator for a given system. Some systems have some static code/headers at the start of their RAM, some require more creative means of identification. The time to click auto hook is after you select the process form the drop-down list. There should be a ROM actually running when you attempt to auto hook. The function behaves as follows for the supported systems: PC Games: Lists all readable regions of the process' memory. N64/PS1: This should work for nearly any N64 or PS1 emulator. It looks for some MIPS that always appears in the early parts of the RAM on each system. Tested on Nemu, PJ64, Mupen, and PCSX 1.5 Debugger. PS2: Nothing yet. PCSX2 v1.0.0 seems to pretty much map the PS2 RAM in its process memory to PS2 addresses, so that proc address in the preset isn't a typo, odd as it seems. I'll need people to confirm it though. GBA: No$GBA and VisualBoy Advance specific, but shouldn't be version specific. I've tested on No$GBA 2.6a and VBA 1.7.2. This method actually looks for a block of data in the process memory consisting of pointers to the GBA memory. It's identified because the pointers are followed by values indicating the size of each GBA memory/system region. NDS: This is the strange one. There's a block of data at the beginning of RAM that's always the same. Problem is it's a copy of the goddamn ROM header, so it appears twice in process memory. I included the GBA pointer method in the search to identify the right spot on No$GBA, but I couldn't find a pointer block in DesMuME. Auto hooking DeSmuME or another NDS emulator will likely result in a popup dialog giving you 2 addresses to choose from (RAM and ROM). I'm fairly sure DeSmuME always has the RAM loaded first, so try the first address. Pretty sure NoGBA was opposite, but you shouldn't have to worry about it. GCN: Best I can do for now is narrow it down. You'll get a dialog popup listing of about 7 areas that could be the GCN RAM. 64-Bit Dolphin not supported, only 32-bit. Memory Map The memory map is my solution to systems with more than one block of memory (like GBA). All values are HEX. The columns should be somewhat self-explanaory... Area Name - Do I really need to go into detail on this one? System Address - The address on the game system where the memory block starts (i.e. 80000000 for N64 RAM) Process Pointer - Address in Process memory where a pointer to the console memory block is located if needed. Process Address - Address in Process memory where the console memory starts. You need this OR a pointer to accurately hack codes for a specific system Point/File Offset - This goes along with the Process Pointer. If using a process pointer and the pointer doesn't point to the exact location of console memory start, you can use this to add/subtract from the pointer that's loaded (32-bit signed hex value). When in File Mode, this is the offset to the region of the file. Used to ignore headers, or handle multiple blocks of memory stored to the same file. Area Size - Guess. You can still setup hooks manually as well. It's not meant for total n00bs, but people with a reasonable understanding of hacking and offsets shouldn't be overly confused by it. Attaching to a PC Game This isn't complicated at all. Select the PC preset, pick a process, and Auto Hook. Attaching to an Emulator If there's a preset, you can just select it, pick a process, and Auto Hook. If not, you have to do it the hard way. No, you can't just use the force. The "hard way" is finding start offsets/pointers. What you need to find out about your emulator before you can hack console codes is where exactly the console RAM is located within the emulator's RAM. Start by loading a game in the emulator that we already have codes for and setting up a plain old PC game hook; you can also use other PC hacking tools if desired. Now hack a code you already know the console address for. I'll use Goldeneye running on PJ64 1.6 as an example. I hacked ammo for my right gun on the Dam level. Came up with 3B1737FC. The console address is D37FC. Can you subtract? Good. The N64 RAM begins at 3B0A0000. Are we done? Well, some emulators always load console RAM to the same place, some don't. Open the emulator again with a different game loaded and do the same thing again. If you come up with the same starting address (3B0A0000 in our case), you're set; that's your "Process Address." Otherwise, we need to go a step farther and look for a pointer to the start address. This is really simple, believe it or not. Find your start address again. Once again, we'll say we figured it out to be 3B0A0000 for the start of console RAM. Now, do a 32-bit search for that value. Yes, SEARCH FOR '3B0A0000' NOOBS. You'll probably see 20 or so results. A lot of times, the first one is all you need. Record them all to a text file though. First one on my list is 4D6A1C. To check this, load up the emulators again and find a start address AGAIN. If this address is once again found at that location (4D6A1C) then the pointer should be good. Now hack something. Code Search Tab This has most of the same options as the original RenegadeEX. You'll notice options to change the type of input for value searches. You'll also notice a progress bar. You should be aware that hacking PC games is slowest because there's a lot to dump and compare. After the first search or two, it should speed up though. Searches will also tend to be slightly slower when applying certain extra filtering options from the extended options list. There are some slight changes from RenegadeEX. EX Filtering options can still be applied with the regular search options, but instead of a button to aplpy the EX filter to the current results, you'll see EX filter listed on the search types list explicitly. There's now a reset button to unlock the parts of the GUI that I tried to at least partially idiot proof once a search has been started. Results Tab Beware. When you have a lot of reulsts and/or are hacking a PC game, it might take a moment for this tab to load because it's loading all the results. Clicking any result will copy the address and the value from the column you click on to the input boxes for activating. Doubleclicking will add it straight to the active list with that value. The value copied (and exported) is determined by the "Use Search" dropdown list. You can also click a result and press Delete to turn it off. One new feature is the Jump To box. If you enter an address here and hit Enter or click GO, it will search the results list and jump to the page where the next result from that location appears. i.e. 801000000 would jump to the page of the first result with an address equal or higher than 80100000). Keyboard shortcuts: Page Up/Down Keys: Advance the results page up/down. Settings Tab Hook Settings: Auto Update Presets: This will attempt to track all changes you make to presets and store them. Otherwise, each preset edited needs to be updated manually. Auto Save Presets on Exit: If this is off, it will ask before exiting. Otherwise, it'll just save. Search Settings: Search Results/Dumps Folder: This is the directory/folder where dumps and search results are to be saved to during searches. Search Access: I made it possible to perform searches by loading both entire dumps OR by only opening the files and reading each value. Reading directly from the file is slow as hell, but you don't want to try to put a 4 gig file in RAM, right? Hence, the Auto option. Any file/region over 100 megs is relegated to the slower direct read access. This number can be changed or you can force one or the other. Not really something you should need to fuck with though. Reults Settings: Results Tester Write Rate: This is how often the "Active Results" (test codes) get written to the process memory. File Utility Tab ByteSwap / Endian Allows you convert a file from one byte order to another. Future Plans/ToDo List I have an extensive backlog of Xbox360 games I have yet to play. I'd like to get into 360/PS3/PC save modding and make a new tool for that. ELF Mutilator could likely use a rewrite/update but that won't be for a while. I'd also like to write my own ad filtering type tool if I can figure out an easy way to do it. I have a bad neck and all this typing is really screwing with it though. ToDo: PS2rd Support Memory Editor Cheat Tab Checksum Calculator Snake Remote app/protocol EX Search Filter to ignore results in blocks of MIPS Float Convert Tool: I think the old VB6 Renegade had one. Dunno why I never added one to the C rewrites. Project History This started out as a simple file compare tool written in VB6 to compare save states and dumps (GG/SMS Super Search and Cheater64). The shit was slow in VB6 though, and "Viper's Insane File Compare Tool" was written in C as a command line app. It was followed by a more complete VB6 tool with a C DLL for searching (Renegade64) to handle emulators and save states, etc. A couple other MIPS based tools were written int VB6 around that time as well. Once I finally got into Win32API, I did RenegadeEX and ELF Mutilator. I won't bother listing some of the other random little tools I've made in the past. Credits/Contact Written by Viper187 of GameHacking.org, Kodewerx and The Snake Pit. Originally of GSCentral.com (NOT to be confused with the other steaming pile of shit currently posing as GSCentral) Special Thanks To: Parasyte - For all the coding help and random snippets of awesomeness over the years. Everyone else that's helped me with hacking/programming throughout the years.