ROM Hack General AP questions.

  • Thread starter Thread starter AetherSolace
  • Start date Start date
  • Views Views 2,569
  • Replies Replies 14

AetherSolace

Member
Newcomer
Joined
Apr 2, 2010
Messages
10
Reaction score
0
Trophies
0
XP
-10
Country
United States
Hey there, I'm currently working on cracking the AP of Shin Megami Tensei: Strange Journey. I'd like to work on others but I yet lack experience. So I'm looking here to ask those who have worked on AP fixes before about how you came to your conclusions on which Hex codes to alter.

And I don't mean by comparing a Rom that's already been fixed like the JP version, We already know that won't work given their overlay files are different. The source of the USA AP is most likely still within that file based on my findings and others.

Anyway, What this comes down to is. How do you usually find what code to alter? How do you find which new values to put in. Because as it stands for me right now Hex is mostly unreadable, I can search through the entire page and look for similiarities as much as I like. But unless I know what types of commands or what other lines of hex within the page each line is interacting with I have no way of finding a fix outside of playing the guessing game and trial and error.

There must be some sort of tool or some sort of language i'm missing out on.

-Unpacking Roms with DSlazy gives me a look at it split into sections, which is nice but does little to interpret the hex code of the overlay file, My culprit.
-Hex Comparisons and searching for specific lines has yielded the location of the Japanese AP fix, A line that shows up in Desmu's debugger(USA,+J)
-Desmu's Memory viewer can show me changes to specific lines but it's little use if I can't see which line issues those changes.
-I've read a little bit into how the DS programming works and how it's processors handle information but not enough for it to make sense to me yet.


What i'm looking for is other people's examples of how they came to their conclusions and fixes, The Japanese fix had to be found somehow. It would be great if there was a way to view an emulator's memory and then view all the connected hex lines that are effecting the line you're watching. Please share any information with me.
 
There is usually a trigger or a switch or something else that causes the AP.

Don't know if it works for NDS games, but you could always use some program to watch what parts of the code are used when the AP activates, and then try to find out which part of it is AP.
 
mipe said:
There is usually a trigger or a switch or something else that causes the AP.

Don't know if it works for NDS games, but you could always use some program to watch what parts of the code are used when the AP activates, and then try to find out which part of it is AP.


I've done something of that using Desmu's debugger and Memory viewer. The Debugger comes up with an error at 021781c4 In the USA version when entering the save menu. While watching that line we can see what the values change to when entering/Saving.

Original values of that line:
1c d1 5d e3 dd 1b 02 98 e5 01 13 00 bb ac 5c 00

Changed values in Desmu(Enter Menu)
9C 6d 5d E3 BE 8E 98 E5 01 13 00 BB A3 0A 5D E1

Changed values in Desmu(Saving)
E8 9B FB EB 05 00 A0 E1 B1 10 D9 E5 07 20 A0 E3

Desmu currently works with this game, So we can't know if it changes the hex to a fixed version from the get go. All we know is changing the rom file's values to anything similar listed here yields no results besides a black screen. Logic suggests that the changes are being made from another line, and we have no way of finding this line. But there's a good chance it's inside overlay_0000.bin
 
I'm starting to wonder how many people are actually responsible for the serious Romhacking and anti piracy patches. Most of the forum goers on Gbatemp and Romulation seem to be here to discuss roms and fixes but have no idea where those fixes actually come from.
 
AetherSolace said:
I'm starting to wonder how many people are actually responsible for the serious Romhacking and anti piracy patches. Most of the forum goers on Gbatemp and Romulation seem to be here to discuss roms and fixes but have no idea where those fixes actually come from.

Translation ! don't forget the translation ^^
 
AetherSolace said:
I'm starting to wonder how many people are actually responsible for the serious Romhacking and anti piracy patches. Most of the forum goers on Gbatemp and Romulation seem to be here to discuss roms and fixes but have no idea where those fixes actually come from.
You pretty much hit the nail on the head there. If you're looking for some kind of Shangri-La of incredible hackers I don't think you're gonna find one.

Maybe I'm making unwarranted generalizations here but these people are in all likelihood very self-sufficient and don't need or want any place to gather and discuss.

FAST6191 has a lot of good stuff here. You've probably seen it but meh. I'm not sure you'll get anything better.
 
You don't work with hex values when debugging. You work with assembly code.
Desmume doesn't have a debugger in it (AFAIK), it has a disassembler. You need a proper debugger, with breakpoints and tracing etc. I don't think you can tell anything by looking at hex only. But I guess you could look at exisiting AP fixes and see what they change in the code.

Example:

Removed it, it wasn't correct.
 
Here's the example:

From patch for Pokemon SS:

Code:
00004300:ÂÂ-> 1C 00 9F E5 00 10 90 E5 18 20 9F E5 02 00 51 E1
00004310:ÂÂ-> 72 10 A0 03 08 10 C0 05 8E 10 A0 03 C4 10 C0 05
00004320:ÂÂ-> 1E FF 2F E1 A0 F0 25 02 34 5D 09 E0
00004A18: 1E FF 2F E1 -> 38 FE FF EA


So, what does the patch change:

Code:
0200300: E59F001CÂÂÂÂLDR R0,[02000324]ÂÂÂÂ | Loads 0225F0A0 to R0
0200304: E5901000ÂÂÂÂLDR R1,[R0,#0]ÂÂÂÂÂÂÂÂ| Loads the value at 0225F0A0 to R1
0200308: E59F2018ÂÂÂÂLDR R2,[02000328]ÂÂÂÂ | Loads E0095D34 to R2
020030C: E1510002ÂÂÂÂCMP R1,R2ÂÂÂÂÂÂÂÂÂÂÂÂ | Compares R1 and R2
0200310: 03A01072ÂÂÂÂMOVEQ R1,#72ÂÂÂÂÂÂÂÂÂÂ| 
0200314: 05C01008ÂÂÂÂSTRBEQ R1,[R0,#8]ÂÂÂÂ | If equal, store byte 72 to 0225F0A8
0200318: 03A0108EÂÂÂÂMOVEQ R1,#8EÂÂÂÂÂÂÂÂÂÂ|
020031C: 05C010C4ÂÂÂÂSTRBEQ R1,[R0,#C4]ÂÂÂÂ| If equal, store byte 8E to 0225F164
0200320: E12FFF1EÂÂÂÂBX LRÂÂÂÂÂÂÂÂÂÂ ÂÂÂÂÂÂ| Return to LR
0200324: 0225F0A0ÂÂÂÂEOREQ PC,R5,#A0
0200328: E0095D34ÂÂÂÂAND R5,R9,R4,LSR SP


0200A18: E12FFF1EÂÂÂÂBX LRÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ | Return to LR
->
0200A18: EAFFFE38ÂÂÂÂB 02000300ÂÂÂÂÂÂÂÂÂÂÂÂ| Jump to 02000300

That's what it looks like it does anyway. I could also be wrong, I don't know much about this.
Don't know if it's significant at all, but seems like quite alot of these anti-piracy patches are similar to this, only the addresses differ.
 
Telling the game to just skip over the AP code makes sense to me.
tongue.gif
 
I love ASM
wub.gif


Rydian should be right. You just probably have to skip over the AP lines althoghter jumping after the check addresses.

Obviously, if the game has later checks, it'd just be easier to make the AP check report the correct values everytime.
 
Miser said:
You don't work with hex values when debugging. You work with assembly code.
Desmume doesn't have a debugger in it (AFAIK), it has a disassembler. You need a proper debugger, with breakpoints and tracing etc. I don't think you can tell anything by looking at hex only. But I guess you could look at exisiting AP fixes and see what they change in the code.

Example:

Removed it, it wasn't correct.

I should have clarified, I'm using the Dev version of Desmume and a script it came with for Devkitpro that enables a debugger. Also from what I'm seeing here understanding ASM would be a big jump in my ability to get somewhere when looking for fixes right?

From what I've heard about it so far we can see where the information is being sent, but there are also other commands and scripts we can make once we understand it? As in we could maybe add our own lines to the rom file to skip over or get around things? I am looking to learn here, so all help is appreciated.
 

Site & Scene News

Popular threads in this forum