Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search
|
| ||
| Views: 20,008,338 |
Home
| Forums
| Uploader
| Wiki
| Object databases
| IRC
Rules/FAQ | Memberlist | Calendar | Stats | Online users | Last posts | Search |
04-23-24 11:32 AM |
| Guest: | ||
| 0 users reading Tools recomended for doing 'this' | 1 bot |
| Main - Archived forums - General SMG hacking - Tools recomended for doing 'this' | Hide post layouts | New reply |
| Bluma |
| ||
|
Normal user Level: 11 Posts: 10/20 EXP: 5617 Next: 368 Since: 07-06-13 From: London Last post: 3870 days ago Last view: 3865 days ago |
Excuse me if this thread is considered inappropriate, I saw no general threads, and the description of this section is:
Anything about modifying the game's code to do awesome things. --- Basic question, how is this done? And to put it into context, with what? Before I go any further, I'll make this clear: I learned how to program when I was 11, in C+ to be precise. It was only a year before that I got bored one day and decided to 'hack Sonic The Hedgehog 2. It was a piece of cake. That started my video modification hobby. I've mainly been active in PlayStation communities, along with various other games, notably other Genesis games and and DreamCast era and PC games. Then there's the Wii, a new ballfield, something I haven't done yet. Super Mario Galaxy has always interested me, I looked into in back then in 2007, but at that time, no tools or community involving it existed, other than a model viewer. Present day, I dwell back into this subject. --- So I understand assembly, I've got that part down. What's next? How would one de-compile the game, bring it to a state where it's crucial center, then thing that makes it run, is editable in some, non-hex form? I've heard of a program called BrawlBox which can edit the 'Main.dol' of Wii and GaneCube games, but it ultimately fails to load the greater half of the file, making it useless. First off, what program do I use to de-compile the game? Secondly, what is used to re-compile the game? And thirdly, any other important factor that I'm not aware of here? I'd really like to help this community in any way possible, I'd like to rip this game to shreds and gather information on it's inner-workings, modify it, extend it, change it, and such. I see lots of potential in this game, certainly lots. Millions, if not billions, of new possibilities. I first wanted to change the way the game's camera system works, less choppy and more automatic, which is why I first asked this question. So... What's known? |
| Marionumber1 |
| ||
|
Wii U hacker Level: 55 Posts: 251/709 EXP: 1239077 Next: 75112 Since: 07-07-12 Last post: 2214 days ago Last view: 590 days ago |
Currently, we have no way of looking at the game's source code. We have made a few ASM hacks, but we make them by looking the SMG2's assembly code and reverse engineering it. That said, we are working on understanding the game's code more, at which point we might be able to create a C++ representation.
In order to modify the game's code, we use memory patches in order to modify the assembly code. Riivolution, the program that we use to replace files, supports them, and seeing as you understand the Dolphin debugger, that can also do memory patches. Only two people are actively looking at the game's code (myself and Arisotura). We'd love to have someone else to help us with it. |
| Bluma |
| ||
|
Normal user Level: 11 Posts: 11/20 EXP: 5617 Next: 368 Since: 07-06-13 From: London Last post: 3870 days ago Last view: 3865 days ago |
That's fine.
Well tell me, what's needed to view the source as assembly code? And I assume this kind of thing has been done before? I'm pretty sure you're aware of the Super Mario Galaxy 2 multi-player modification. Did that person need a C++ representation, or was it done purely with the assembly code? And surely, either way, I see that this person could be helpful here as well. Are they a member here? And any thing I can do to help, I surely will. I still believe that the assembly representation of the game could be modified and understood well enough to edit it without any conversions. Has anyone written down what's been documented so far? If I could be given access to the source code, and if there's any specific task being worked on at the moment, please let me know. |
| Marionumber1 |
| ||
|
Wii U hacker Level: 55 Posts: 252/709 EXP: 1239077 Next: 75112 Since: 07-07-12 Last post: 2214 days ago Last view: 590 days ago |
In order to disassemble the game's code, I use IDA Pro. It costs $799, but you can All you need to do is open IDA Pro, choose New, and open SMG2's main.dol. That will generate a disassembly of the SMG2. From there, you just need reverse engineering knowledge. The people who worked on the multiplayer mod are Chadderz and MrBean. I would assume they also used a disassembly of the game, since decompiling and then recompiling the game is impossible to do without completely understanding all of the game's code, and having the Wii SDK as well. They aren't active on this forum, though. We have made documentations of some of the game's code. You can find it in ASM Hacking Notes on the Wiki. Currently, I'm focusing on the code for objects and power-ups. |
| Bluma |
| ||
|
Normal user Level: 11 Posts: 12/20 EXP: 5617 Next: 368 Since: 07-06-13 From: London Last post: 3870 days ago Last view: 3865 days ago |
Posted by Marionumber1 I'd really rather not download it illegally, copyright laws from where I'm from are more strict. Is there any place where I can download an already de-compiled source perhaps? And let me get this straight: There's no way to de-compile, then re-compile the game's DOL file? After doing more research, I found that this person also releases a pack called 'CTGP' for Mario Kart Wii. The download reveals several Main.dol files, I assume for separate regions. Does this mean that it is, in fact possible to re compile the DOL after editing? Or did they manually edit the file based on what they learned from the de-compiled code? |
| Marionumber1 |
| ||
|
Wii U hacker Level: 55 Posts: 253/709 EXP: 1239077 Next: 75112 Since: 07-07-12 Last post: 2214 days ago Last view: 590 days ago |
The disassembled source would be huge, and I also don't think it's legal to distribute the code.
They probably edited the assembly code in the DOL after reverse engineering. Decompiling and recompiling isn't impossible, but it's not worth the effort. An automated decompiler would probably produce some incorrect code, and also wouldn't contain any function or variable names. Decompiling on your own would require a complete understanding of all of the game's code, and would not only be hard and time consuming, but unneeded, because often, you just want to modify a small portion of the code. Recompiling the code, as I said, would first require you to decompile it, and then you'd need the Wii SDK to compile the code. |
| Arisotura |
| ||
 Star Mario in this room you have a pile of apple pies Level: 163 
Posts: 1557/9019 EXP: 56247223 Next: 240421 Since: 07-03-12 From: in a box 
Last post: 11 days ago Last view: 15 hours ago |
And even if we gave you a disassembly of the code, you'd need IDA Pro to open it.
Just relax. Usually we have a strong stance against piracy, but unless you're a rich company you don't want to pay a three-digit sum for software. Just go ahead. Unless your ISP/government/whatever spies on you in a borderline illegal manner, you won't get caught. I also don't know about that CTGP thing, but distributing .dol's like that would be illegal. It's Nintendo's code. ____________________ NSMBHD - Kafuka - Jul melonDS the most fruity DS emulator there is zafkflzdasd |
| Treeki |
| ||
|
Newcomer Normal user Level: 7 Posts: 3/7 EXP: 1162 Next: 286 Since: 07-07-13 Last post: 3798 days ago Last view: 3732 days ago |
Without IDA, you won't have much luck :< You can disassemble GC/Wii code with devkitPPC's objdump and some understanding of the .dol format... but working with a text disassembly is a monstrous pain. Trust me.
Anyhow, as to what you ask.. I suppose you could do some magic to disassemble the .dol to a gigantic ASM file and then reassemble it. Not sure how well this would work though. The method I took for Newer was to patch the game after it's been loaded, which is the only thing you can do if you want to support Riivolution (which doesn't allow you to replace the .dol). You cannot automatically decompile C++ code. I guess you could do it by hand if you have a few years to spare :p There's some tools that can decompile code to an extent, like the Hex-Rays Decompiler (written by the IDA developers), but afaik none support PPC. And you won't get code that's good enough to feed straight into a C++ compiler; these tools are made with the purpose of analysing and understanding code, not for creating something that you can modify and recompile. Have I dashed your hopes enough yet? :p Also, while working on Newer, I realised very early on that writing assembly code directly is... not fun. Seriously. What I ended up doing was writing more complex things like new enemies/sprites in C++ and dropping down to assembly when I needed to make small changes or when writing ASM would be faster than putting together C++ headers (class/struct definitions, etc) for whatever I needed. |
| shibboleet |
| ||
 Fire Mario DROP TABLE users; Level: 123 Posts: 1606/4661 EXP: 20885832 Next: 345434 Since: 07-07-12 Last post: 1347 days ago Last view: 360 days ago |
Yep, MrBean and Chadderz release a main.dol with their CTGP to prevent Nintendo from banning them, and use the Custom Tracks Worldwide Page. Plus it's used to keep hackers out of the online CTGP races.
Anyways, yeah. If you really want IDA pro that badly, you have to...well download it illegally. ____________________ a |
| Bluma |
| ||
|
Normal user Level: 11 Posts: 13/20 EXP: 5617 Next: 368 Since: 07-06-13 From: London Last post: 3870 days ago Last view: 3865 days ago |
Well... I suppose I'll download it that way then. Not that I could even afford it, and I see no financial gain on my behalf.
I was under the impression that it required modifying and re distributing this Main.dol file. So if that's not the case, then memory patches? In the context of the Wii and 'Riivolution', I'm not entirely sure what that means. Do these memory patches work in a way similar to Gecko codes? And these patches, they're written in C++... If you can only read the game in assembly, then how do you know what you're writing in another language would work? By examining the assembly code and writing what seems right? I'm a bit curious as to how you completely re-programed the world map for Newer Super Mario Bros., Treeki. How exactly did debugging something like that go? Excuse me if I'm misinterpreting what's been said. |
| Treeki |
| ||
|
Newcomer Normal user Level: 7 Posts: 4/7 EXP: 1162 Next: 286 Since: 07-07-13 Last post: 3798 days ago Last view: 3732 days ago |
The original game is written in C++, so writing compatible code is possible. With practice, you learn to identify patterns, and you can put together compatible versions of structs, classes, function signatures, ... which you can add to header files so your code can interoperate with the game.
The other big hurdle you'll encounter is that CodeWarrior on PPC (the compiler Nintendo uses) doesn't use the Itanium C++ ABI, which is the standard that most other compilers - including GCC - use. This means that a bunch of C++ features are implemented differently behind the scenes (destructors and virtual functions are the two big ones that come to mind right now) and if you compile code with GCC that uses these, it won't be binary compatible with stuff compiled with CodeWarrior. Which includes mostly everything cool you could do for NSMBW and SMG, including custom objects, etc. Great, right?! I solved this for Newer by modifying the Clang compiler. I'll be releasing this along with my other tools for injecting code/patches later this year, but I need to do a decent amount of cleaning up and refactoring before I'm comfortable putting them out there. Here's an example from the NSMBW headers if you're curious about what this kind of thing looks like: http://pastie.org/private/u596vxc9ki5cbtaikzva - These are the base classes for processes, actors and scenes, and I put these together entirely through reverse-engineering the data layouts and method signatures (that's why some fields and method arguments have placeholder names). Yep, except that Gecko codes are reapplied every frame- Riiv's memory patches are applied at the very beginning of the game, after the .dol has been loaded into RAM, but before any code from it has been executed. For Newer, the path I took was to have a tiny bit of "bootstrap" code which detects the running game version and loads the correct version of the patches + code. This code is loaded using memory patches on Riivolution and injected into a modified .dol when loading the game through an ISO. This has a few benefits: - No need to prepare separate copies of the patches/code for ISOs and Riivolution - No need to worry about different game versions - Patches can be easily updated just by popping a few files into a folder - Patches can be loaded after the game is booted, which is necessary for NSMBW (because over half of its code is in .rel files which are all loaded during the Wrist Strap warning screen) Tons and tons of OSReports. (The Wii SDK's version of printf.) Coding for Newer has got me so used to debugging that way that I rarely bother with actual debuggers when I'm working on regular PC stuff now :| |
| Bluma |
| ||
|
Normal user Level: 11 Posts: 14/20 EXP: 5617 Next: 368 Since: 07-06-13 From: London Last post: 3870 days ago Last view: 3865 days ago |
Posted by Treeki In the meantime then, what do you recommend I use until these tools are complete? Posted by Treeki This is also very interesting. I guess I didn't realize that you had to write separate patches for different versions and regions. So you wrote a program that detects the game version? Is Riivolution capable of executing code like that before booting the game? Posted by Treeki How did you get a hold of a development kit? I was only able to locate one for Wii Opera applications. --- This is all very exciting, it's completely different from anything I've done. Usually it required re-distrubuting the entire 'engine' if you will, or creating a sort of ISO patch you applied yourself. How exactly do you apply these memory patches with Riivolution? Excuse me for all the questions, this seems to have a process entirely different from what I imagined. |
| Treeki |
| ||
|
Newcomer Normal user Level: 7 Posts: 5/7 EXP: 1162 Next: 286 Since: 07-07-13 Last post: 3798 days ago Last view: 3732 days ago |
Posted by BlumaYou have two choices, and both are pretty awful... you can use the CodeWarrior compiler (a version has been leaked before, from the GC SDK) to compile your code, or you can use GCC if you avoid the features I mentioned. The latter is doable, it just makes writing code more difficult and error-prone because you have to put together your own vtables, write constructors/destructors and make sure you call all the appropriate functions, etc. Posted by BlumaKind of. There's a section in RAM which is unused by games; 6kb at 0x80001800 - this is where the stuff for applying Ocarina/Gecko codes goes, btw - which you can use to place some code. Load it in using a memory patch, and modify some of the game's bootup code so it will call whatever you place there. These are the relevant patches in the Newer Riivolution XML: http://pastie.org/private/vbriuoge14rmm3os5x0g And this is the source code for said loader: http://pastie.org/private/lcn1ueryxjtgmo61ho3xa Writing the same patches for different game versions is incredibly tedious and there are minimal changes between the different NSMBW versions, so I compared RAM dumps from each version to find out exactly where code and data was added/removed. I then wrote a small bit of code that used this info to automatically convert addresses between different versions, and used it to automatically compile 6 different versions of the patches. Posted by BlumaA couple of versions of RVL_SDK have been leaked, but you don't need them for this. There are various Wii games and apps where the developers have inadvertently included .sel or .map files which include names for every function linked into that game's binary. (One developer left in an unstripped .elf. Oops.) You can use these to find out the names of most of the SDK functions, and with some - admittedly, tedious - work you can locate them in whichever game you're modding. You can then call them from your own code! |
| Bluma |
| ||
|
Normal user Level: 11 Posts: 15/20 EXP: 5617 Next: 368 Since: 07-06-13 From: London Last post: 3870 days ago Last view: 3865 days ago |
Excuse me for such a lengthy absence, the day I last posted also happened to be the day summer classes began, so I was unable to reply. Please forgive me for posting on such an old topic.
--- I've had little time lately to dedicate to looking into this. I've done some minor research, which ultimately failed to provide anything useful. Posted by Treeki Firstly, I was unable to locate the software which you spoke of (The one leaked from the GC Development Kit). I believe I've located the GCC which you speak of:http://gcc.gnu.org/ , but one line in your quote confuses me: Posted by Treeki I was unable to locate any 'cracked' version of IDA Pro. I instead examined several Ocarina Codes (For New Super Mario Bros. Wii, to be exact) And I was able to pull enough information out of that to do minor things (In Ocarina code form). The earliest IDA pro crack I could find would be for V5, two versions too old. So far, I've been un able to create memory patches, due to a lack of a proper source code to work with, or a proper compiler. Several things said have left me confused (Mainly being told that patches are written, and compiled in C++, but as an example I was shown assembly code.). I'm not entirely sure how these memory patches work too well either, anything I've been told, shown, or I've found has been pretty sketchy, or atleast not informative enough. |
| Phantom Wings |
| ||
|
Normal user Level: 17 Posts: 36/46 EXP: 20475 Next: 4268 Since: 07-08-12 Last post: 3740 days ago Last view: 3740 days ago |
Perhaps this may be on a slight tangent from what has already been discussed, but a large majority of low level hacking - assembly or otherwise - is done using a remote debugger. Moreover, the early stages of most mods are more often than not established using neither the games source code or a compiler/decompiler.
Effective hacking is usually done in steps. The first and most important being analysis. Most remote debuggers (in this case, either WiiRD or Dolphin Debug) will come with a code search feature to allow you to search for patterns in memory that reflect the happenings in the game. Memory searching - sometimes referred to as code searching - can reveal a lot about the game data - basic things like the world coordinates of in game objects and player health can usually be found fairly easily using a code search. After you have discovered a couple of values of interest, it is possible to create Ocarina codes to manipulate these values to create unique and interesting effects. There's more to hacking than just searching randomly for values of interest. If you are familiar with C++, then you are familiar with both pointers and structures. Often times, discovering a good data pointer will reveal a lot about how data structures are stored in the game's memory. Understanding these structures in turn allows you to create more complicated codes. Once you have a fair understanding of in game structures, it might be a good idea to place a few debugger breakpoints on some of the values of interest to view the assembly code that controls them. In understanding the game's assembly code, you may also come to understand some of the data files that the game utilizes to store content. This knowledge can be used to create editing tools allowing others to create customized content for the game. Only once you have a reasonably concrete understanding of internal assembly should you start trying to write assembly patches. For simple things it isn't so hard, but as the complexity of your idea grows, so too do the factors that need to be taken into consideration. Simple assembly hacks can be made using an assembler and regular assembly injections. Only if you want to build a large scale hack requiring one or more modules do you really need a compiler. Anyways, hopefully you found this quick summary useful. I'm not sure if you can still buy WiiRD units, but you should still be able to get by using Dolphin Debug - it just doesn't have as many features as WiiRD. |
| Main - Archived forums - General SMG hacking - Tools recomended for doing 'this' | Hide post layouts | New reply |
|
Page rendered in 0.074 seconds. (2048KB of memory used) MySQL - queries: 30, rows: 227/227, time: 0.017 seconds. ![[powered by Acmlm]](img/poweredbyacmlm.png "powering nostalgia")
Acmlmboard 2.064 (2018-07-20)© 2005-2008 Acmlm, Xkeeper, blackhole89 et al. |