How To Fix ANY Bug Using Hex Editor!

Le pug · Sep 22, 2014

How To Fix Any Bug With Hex Editor

Hello, I have another tutorial lined up this time teaching you how to fix any bug you might have. The only requirements necessary are 1) A hex editor and 2) A backup that is working (can even be a clean rom version depending on what you're trying to fix).

Of course I made a video tutorial so here it is:
[hd]JB2ujb2-EOA[/hd]
Here is another video player (where you can also download the video in better quality)

The above video uses an actual bug I had with my own hack that I had never worked on fixing before. I fixed the bug while making the tutorial so know that it genuinely works. I've used this so far to fix an entire Fairy Type patch, a glitch where I couldn't get past the intro scene without the game restarting, the interior building glitch as you see in the above video, a pokedex issue where when you try to view the pokedex the game just breaks entirely, and a glitch where no numbers appeared next to the "Lv" text and PP text and any text in the pokedex area. So I've had my fair share of bugs, but it ended up being just a pointer or two that messed up (except for the fairy type patch which required some more extensive fixing).

So for right now the video will be the only tutorial. When I find another bug, I'll gladly post it here in text format so you have two different methods of learning. Hope the video helps you out and if you have any questions or problems, just post here in the thread! Thanks.

Here are some example half-splits to fix the bugs (feel free to PM me if you want your list here to show for an example also):

Spoiler:

As time goes on, I'll add other example tutorials I come with. If you have any you'd like me to add, let me know. Or if you are having troubles learning or what help, post below.

Written Example I: Fixing A Water Reflection Bug

Spoiler:

So I'll be writing out how to use this method, using one of the bugs I'm about to fix. Never have I fixed this bug before! I'm fixing it with you guys right now.

So here is the bug itself in a gif:

As you can see, all sorts of wonder are going on. Some people would fix this particular bug in different ways, but I'm going to use the way I've been using to do it since it really doesn't take that much time as long as you're adept at doing it like me.

So first order of business, what it's supposed to look like:

(Yeah, I know I still need to update the reflection palette ...)

So what's the set up requirement for the roms?
You need the broken rom that you want to fix, a copy of this rom, and an older working rom backup. Your older rom can be empty as could be compared to the new rom, as long as the feature you're trying to restore works on the old rom.

So here is how I have the setup of my roms:

Now the copy of 0.3.6 is what we'll edit to figure out where our bug is. There will be times you will have to delete this copy and remake another copy from 0.3.6. The only time you have to do that though, is if you've gone too far in the rom to make the bug go away. For example, if the bug was at 0x300000 and I copy and pasted the older rom from 0x0 to 0x900000 into the newer rom ... well that's going to overwrite a lot of data that we worked so hard on and we don't want that, so we need to move down in offsets until we find the bug. So you'd have to delete the rom and recreate a new one to do so.

Now open up your hex editor (I use HxDen). Using the image below, 1) Go to Analysis > File Compare > Compare then 2) choose the copy of the broken rom and then 3) You should see both files being compared.

Spoiler:

So in the image above you can see that it will automatically start tracking the differences between the two roms. the first one being at the offset inside the image at 0x300D81. So in your head you can already eliminate any offset before that as being where the bug is since simply there are no differences in the rom and we know the older rom's water reflection is working fine.

To start off, I'm going to select from 0x0 to 0x900000 in the older rom. You could technically do 0x300D81 to 0x900000 if you wanted to, but it's just easier to paste in the newer rom from offset 0x0. Once I've done this, I will copy the bytes and WRITE (CTRL + B) into the new rom at the same offsets.

Spoiler:

So in the above image you see that first of all, make sure you have the correct rom selected for selecting the bytes! Otherwise you're gonna just overwrite your working rom with the broken rom lol. In the window you see that I wrote 0 and 900000 to select that range. In the bottom red box you see that indeed offsets 0x0 - 0x900000 are selected. To select a block, either (Ctrl + E) or go to Edit > Select Block. Now go to offset 0x0 in the broken rom (which is the bottom file on my screen) and CTRL + B WRITE. Once you're done and see the red text that the space has been overwritten, make sure that the offsets look like they match and then save (Ctrl + S).

Spoiler:

Sweet you've successfully overwritten over half your rom. So it should definitely work now. To test it, open the copy of the rom we're working on (so I'll open up 0.3.6 - Copy) in GBA.

Interestingly enough, the problem still exists. So right now, you don't have to recreate the copy of the rom since it's still not working. We'll just select something bigger and overwrite again. I'll do 0x0 to 0xE00000. Now if I were you, I'd start a .txt file or something to keep track where you've been. For example:

Spoiler:

So go ahead and select your new block if the error is still there and CTRL B WRITE again.

Spoiler:

Save and test your rom once more.

So even though there are tile bugs going crazy, we see that we fixed the actual bug itself. We now have our max offset at 0xE00000. The bug is between 0x0 and 0xE00000. Now since the bug is gone and the rom is "working" we have to delete the copy and recreate a new one. After you're done and have your new copy of the broken rom, simply again go to Analysis > File Compare > Compare and choose your newly created broken rom copy:

Spoiler:

Once your new copy is being compared now we can start half-splitting. This just means we're going to split the offset in half and test to see if it's working still. Since it's between 0x900000 and 0xE00000, what I'll do is take (E00000 - 900000)/2 = 280000 and add that to 900000 which becomes B80000 which is the offset exactly in the middle of the ends of our band we're searching in. Now I'll copy 0x0 to 0xB80000 and CTRL B WRITE into the new copy file:

Spoiler:

This is pretty much where the process starts to get repetitive just to figure out where the bug is. Now that we have our bytes written, go ahead and save the rom and test it once again.

Interesting now I can't even test it. Since I'm not sure if it's fixed or not, I'll go a little before this and try again. So I'm going to delete the copy, recreate one and compare and try from 0xA00000. ..... Hmm same error. Let's go further back shall we? Let's try ... 0x950000. Same thing occurs! Does this mean we should give up? No, just means that something else is happening with the map offsets and since it's not verifiable what is going on, we'll just research in the rom a bit. .... So to summarize this step, since everyone's case will be different and I'm expecting some questions... but because of this error, it means the maps are different and simply we need to fix THIS new "bug" before we can fix the bug we want to fix simply because we can't SEE the bug we are trying to fix. So what I did was select from the offset 0x300D81 to 0x600000 and tried it, still got the same image as above. Trying 0x450000 then 0x400000 and same thing. Then I did 0x350000 and finally I could see again. So now what I'm trying to do is figure out where the map changes to be that crappy image from above and I'll start copying bytes from AFTER that location to prevent the map changing. Tried 0x3C0000 and the map still works ... tried 0x3F0000 and it doesn't. So effectively what we are doing now is going between 0x3C0000 and 0x3F0000 and seeing where the map bug is. So it's like halfsplitting to fix the bug to halfsplit to fix the bug we want to fix. Halfsplitception, if you will. So using the advanced header (CTRL + H in AdvanceMap) I can see an offset used between the range I'm looking in:

Spoiler:

It's sort of like a helpful hint on how to fix it. So I'm going to select from 0x3F0000 to 0x500000 just to see if the problem lies within 0x3D0000. ....... And bam, it works. So apparently the map difference bug was due to the tileset differences in 0.3.0 and 0.3.6. Now that we're back on track for our bug we WANT to fix, our new end offsets are 0x3F0000 to 0xE00000. So I'll redo from the beginning.

I select from 0x3F0000 to 0x900000 and CTRL B WRITE to the broken rom to find that the problem is now fixed with no map errors. So this means the bug is somewhere inside of this range. So now I'm going to just do a quick scan through this range to see if I notice any major changes. Now remember, the older version is the top and the newer version of the hack is the bottom. So if you see a bunch of 00s or FFs randomly in the newer one, it might be a patch issue. You could've accidentally overwritten data or just repointed something horribly, who knows. For example, I quick noticed that between the range of 0x3F575C - 0x3F833C my new rom has a bunch of 00s. That can't be good ... so I'll go ahead and fix that by CTRL B WRITE the old data in that empty spot. I opened up my rom to test and see if the error was fixed and no, it wasn't. But I can guarantee with the amount of bugs I've had due to 00 spots lately, that probably just fixed a bug I didn't know about! So I'll continue scanning. (To do this F6 to go forward, and shift +F6 to go backwards). Another scan found another 00'd spot between 0x404350 and 0x4049D7. A quick update and test shows that the map still isn't working. Another range of 00s at 0x427228 to 0x42778B. Bug still isn't fixed! Now I know what you're probably thinking. Either WTF is going on or WTF is wrong with my hack to have so many 00 spaces patched. Well, I'm wondering the same thing LOL but I'm fixing them so a good advantage of using this compare feature.
So I noticed another range of 00s from 0x50D070 to 0x50D28F:

Spoiler:

In the above image you can clearly see the space that was erased. So I simply selected the range in a block and overwrite the area:

Spoiler:

Save the data and try it out in the rom and:

There you have it! The error for this bug wasn't a pointer issue or a few mixed up bytes, but simply an area that was 00'd out possibly by a patch. I hope you can take something from this example tutorial and if you have any questions or if you are running into a in-game probably such as this, let me know and I'll try to help you out.

Spoiler:

Sefuree · Oct 11, 2014

That's cool! I've fixed a few things in my ROM with this! Thanks.

AtecainCorp. · Oct 11, 2014

So if you think that you can slove all bugs. Can you help me with sloving glitchy pokemon nature names in Pokemon Ruby? It was appeared when I expanded move list.

HidoranBlaze · Oct 11, 2014

Ksiazek Bartlomiej said:
So if you think that you can slove all bugs. Can you help me with sloving glitchy pokemon nature names in Pokemon Ruby? It was appeared when I expanded move list.

Did you repoint your moves description table? If you didn't, that's probably why your natures are glitched.

UmbreonNo. · Oct 28, 2014

Can you help me fixing an error when adding new healing places to a fire red rom? I've already tried all i can do.

mbcn10ww · Oct 10, 2016

I want to fix a bug, but can't find it. When I defeat a trainer's PKMN I can make infinite shifts. I think there is a shift when I defeat a PKMN (because the fainted PKMN remais attacking) and a shift when the trainer would use another PKMN (the default shift method). I think it is a doubled code.

How To Fix ANY Bug Using Hex Editor!

More options

Le pug

Creator of Pokémon: Discovery / Fat Kid

Sefuree

Canada Goose

AtecainCorp.

Rejishan awake...

HidoranBlaze

UmbreonNo.

mbcn10ww