Author
|
Topic: Some document by InVerse...? (Read 2 times)
|
Black_Phantom
Guest
|
 |
« on: February 16, 2009, 02:12:02 pm » |
|
In "The Definitive Guide to ROM Hacking for Complete Beginners" by InVerse there was a mention of consulting "Basic ROM Corruption by InVerse". Just out of interest, was this document made and/or released to people?
|
|
|
|
|
Disch
Guest
|
|
« Reply #1 on: February 16, 2009, 02:19:31 pm » |
|
|
|
|
|
|
Black_Phantom
Guest
|
|
« Reply #2 on: February 16, 2009, 02:23:47 pm » |
|
Argh. Well, thanks anyway!
|
|
|
|
|
InVerse
Guest
|
|
« Reply #3 on: February 16, 2009, 08:57:25 pm » |
|
For the record, ROM corruption is extremely easy. Just grab a corrupter (several to choose from right here at RHDN, I believe) and start breaking shit. Most, if not all, of the corrupters should be pretty much self-explanatory. Really, all I planned to explain in the document was patterns to use to isolate the data you're looking for and a few important tips such as not bothering to corrupt headers because that's just going to make the ROM not run at all. But, yeah, you're probably the 5th person in the last year that's asked about this. I never would have believed the FAQ would have had such staying power. It absolutely needs to be updated.
|
|
|
|
|
Tauwasser
Guest
|
|
« Reply #4 on: February 16, 2009, 09:14:17 pm » |
|
Seriously, for some reason, I don't really have much respect for people who call corrupting a part of rom hacking...
ï¿ 2
cYa,
Tauwasser
|
|
|
|
|
InVerse
Guest
|
|
« Reply #5 on: February 16, 2009, 11:39:28 pm » |
|
If you can't respect a proven technique that works, then you're not a hacker.
|
|
|
|
|
Tauwasser
Guest
|
|
« Reply #6 on: February 17, 2009, 01:58:31 am » |
|
In all seriousness, it's technique that's crap. Just learn the assembly for the stuff you're doing and do it the proper way, which will also spare your time and nerves. I don't have time to corrupt stuff, especially for newer systems. Corrupting 32 MiB, anyone? I don't think so.
cYa,
Tauwasser
|
|
|
|
|
Black_Phantom
Guest
|
|
« Reply #7 on: February 17, 2009, 05:58:48 am » |
|
Yes, I know that learning ASM for the system will usually help speed things up. It's not a life or death matter that I find anything at this moment in time. I just find reading about ROM hacking stuff interesting, sometimes.
|
|
|
|
|
InVerse
Guest
|
|
« Reply #8 on: February 17, 2009, 07:38:44 am » |
|
In all seriousness, it's technique that's crap. Just learn the assembly for the stuff you're doing and do it the proper way, which will also spare your time and nerves. I don't have time to corrupt stuff, especially for newer systems. Corrupting 32 MiB, anyone? I don't think so.
Perhaps Disch can stop by and re-tell the story he's related on this board before about the time someone challenged him to a race and found a particular bit of data via corruption before he could do so with a debugger. Personally, I'd rather be raped by a pack of wild hyenas than learn assembly language. It has nothing to do with being "too hard", I simply have absolutely no interest. If I wanted to deal with code on that level, I'd just write my own games. Corruption, on the other hand, I actually enjoy doing from time to time. You seem to be one of those children who hasn't yet learned that there's a difference between something you personally dislike and something that's "crap". |
|
|
|
|
GenoBlast
Guest
|
|
« Reply #9 on: February 17, 2009, 10:17:38 am » |
|
If you think about the meaning of the term, there's really no wrong way to hack as long as you get the job done. That's why it's called "hacking" and not "The Scientific Method".
|
|
|
|
|
Tauwasser
Guest
|
|
« Reply #10 on: February 17, 2009, 10:33:58 am » |
|
You seem to be one of those children who hasn't yet learned that there's a difference between something you personally dislike and something that's "crap".
§$%&§$"! I'm just saying it's unprecise and makes you usually take longer. You could instead of the right routine in part of the rom just corrupt a simple call and then say "Yeah, I got it!". Takes time and effort to read anything meaningful into that. As for finding specific bytes that represent anything useful, it's probably much more the problem with then figuring out what you changed and and only then you can tell how where it is and how it works. Did you just mumbe the tileset routine to always load tileset 0x13? Did you really find the attributes for this one map and changed it's tileset to 0x13? Maybe you just corrupted the pointers and my cheer luck got to 0x13 instead? Or maybe you hit the routine that interprets those chunks of data. Or maybe just a call to that it starts off with stuff left in memory in the accumulator? But then again, maybe I'm just an ignorant child and really the one who tries to start a flame war in here and not you, thankyouverymuch. cYa, Tauwasser |
|
|
|
|
Disch
Guest
|
|
« Reply #11 on: February 17, 2009, 11:08:57 am » |
|
I'm just saying it's unprecise and makes you usually take longer.
Corruption is an artform. I didn't use to think so -- I used to think it was tedious and took too long and all that. Pretty much I used to have the exact same stance on it as you appear to have. Then maybe a year or two back, in IRC someone was looking for something in a game (but for the life of me I can't remember what game it was or what they were looking for). So I decided to try and look for it to help out, doing my usual approach: find relevent variables in RAM, put breakpoints on them, trace back to find the data. At the same time, someone else (I think it was Jigglysaint) started looking for the data as well, using his usual approach (which involved corruption). At the time, he did not know any assembly (though he's since been learning). Well I found the data easily enough, and when I went back to IRC to report my findings, not only did Jiggly find it in like half the time but also outlined the entire format of the data structure (whereas I had only just found the start of data structure and didn't yet decipher it) True it won't always be faster. True it might be considered tedious. But in the hands of someone that really knows how to do it well -- it's a very powerful tool, and one I sometimes really wish I had mastered. And as has been mentioned -- the learning curve for it is a lot easier than the learning curve for assembly. So yeah -- I'm with InVerse. Don't knock it just because it's not your preferred approach.  Although I wouldnt've been so crass about it. |
|
|
|
« Last Edit: February 17, 2009, 11:32:12 am by Disch »
|
|
|
|
Jigglysaint
Guest
|
|
« Reply #12 on: February 18, 2009, 03:09:52 pm » |
|
Rom Corruption is my bitch. Of course now that I know ASM, I can do the tracing and stuff, but the best part of corruption is that you can study the game, create a theory about how data is stored, then look for that data. It doesn't always work, but games are programmed logically, so it's logical to reason out how things should be stored. As for that value we were racing to find, I believe it was DahrkDaiz, and we were looking for the TSA for the locks in Super Mario 3. Disch did a trace, but I just got the values I knew, then looked for them. To corrupt effectively, you need to be fast, and you need to be able to know where to look. Basically, I search the rom, corrupting about 2 banks at a time untill I find an effect that alters the target data. Then, I home in on it. If, for example, the target data was $26a59, I would start by corrupting $20000 to $30000. If I got an effect, I would then cut in in half by seaching from $20000 to $28000. I would try all 4 combinations untill I find the one that yields the result. If I run into game breaking data, I find it, then start the search afterwards, noting any instances of game breaking code. Let's say then that I corrupted $20000 to $28000 and found the data. Let's say I found out that between $20000 and $24000, the game crashes. I start from $24000 to $28000. I go from $24000 to $26000 and get nothing. Now I try $26000 to $28000 and find it. I back up and try $27000 to $28000 because my experience has taught me that the data is ALWAYS in the last place you look. I find nothing, so I repeat with 26-27 K range. I find data, so what I do then is I halve it. I search 268k to 27k and find the data. Now I just keep narrowing it down untill I find the answer.
Now, you may be thinking that wouldn't it be kind of long to just corrupt, start the emulator, find the area, rince and repeat? Well yes it can, but that's what save states are for. Stating in the right spot can make the difference. Since you are looking for one particular spot that changes, you need to only spend maybe 5 seconds tops in the emulator before you know if you found data or not. If you keep narrowing down the searches, you will find that data eventually. Corruption though, is a tool best used when you either cannot find what you are looking for via tracing, or if you are starting a new rom and need a foothold on things.
Edit: I also fogot to mention that when doing hacks, a corruptor is a pretty cheap way of clearing data fields. All you do is find the start and finish position of the block of data, corrupt it to all 00
s or FF's, and then make sure you don't revert after you are done.
Also, look at my title. There is a reason why my title is called "Corruptomancer". I am the God of Corruption!
|
|
|
|
« Last Edit: February 18, 2009, 03:16:09 pm by Jigglysaint »
|
|
|
|
|
RHDN Forum Archive
