Trying to figure out Password system

[abishur]

I've been translating a game and run into a snag.  I can't figure out how to correctly implement the password system!

In the Japanese version it "randomly" selects characters from 0x9EBD to 0x9F03 for a total of 71 possible characters.  However on the password screen only 46 characters are shown, with an " and a ° modifier that can be placed on certain characters for 25 extra characters (for a total of 71 characters).

So here you can see I used the same base character, but the second modified with the " is the difference between the hex 2A and the hex 5B



I noticed in my script area there's a line called when a character gives you a password followed by 21 rows of random Hex code.  I *think* that the first 20 lines each represents a possible combination of characters to generate what appears to be random passwords. And the last line (only 4 characters long plus a stop command) is used as a hash check of some kind?

I tried to replace the area with characters with only A-Z, 0-9 characters, and while it displayed on screen correctly, it failed to give a valid passcode.  I suspect that while I visually got the characters correct, it was checked against a code area and found the numbers didn't add up producing a failure.

I think I have three options at this point in time. 
1) Recognizing that it looks at the 77 characters from hex characters 24 to 79 (with a few skips) I could change my map to have capital "A" to start at 24 instead of 0A, and then use the " and ° to signify their lowercase equivalent.
2) Try changing what I suspect is the area generating the password and see if it starts producing different passwords in an effort to backwards engineer the area and eventually limit the code generation to only 0-9, A-Z characters
3) Give up and accept you won't be able to use passwords

I don't like 1, 3 seems unacceptable.  Can anyone give me some pointers for working out 2?  I've done a ton of documenting for things I've discovered so far.  I just don't know how much is useful and how much is "anyone who has spent 5 minutes rom hacking knows that, duh"

[FAST6191]

If it is that much data (that could possibly be the most I have seen for a password in any game, and if it is not then it is right up there, certainly way more than most)n on a NES game then likely something is encoded within it pertaining to the character vs just being a level they got to unlock type deal. Some later stuff might do something silly with the text but still be unlocks ( https://gamefaqs.gamespot.com/pc/47995-worms-2/cheats ) but NES likely not so much.

To that end unless you are going to use a simple substitution or addition cipher on the password then 2) might be tricky. It might well already do something to effect this kind of limitation (one would suspect a random state for a character or something will run from 00 to FF to parts).
That said how random is random? Can you save, use a potion (basically some minor action), save again and see the difference? Or take a savestate before you generate a password, do some minor thing different and compare the two runs (it might not be simple but timers, step counters, save counters and more are things that some games will include).

Anyway I would probably start by disabling the hash check (I would be stunned if this did not have one but with NES stuff we have been surprised). This should be a simple compare between two values and branch accordingly which you force to always take the "password correct" route (and have some fun breaking the game after that). You might even learn what it is -- NES stuff is not going to be doing MD5, even CRC16 would be a stretch so more likely a bytesum or parity which is good info to know (such things are not secure but they do solve the simple cheater and incorrect password issues).

If you would rather not play with assembly right away (though you might also use this as part of it) then before that if you want to find where it is stashing the code in RAM as it is being typed in then that might be a good idea. At this point you can check between your versions to see what entry might have been different. Such things are also quite good for figuring out encodings in games as you are literally controlling what is on screen but it sounds like you have that already.

[abishur]

Random is definitely fake.  You talk to a guy and he generates a password.  Without moving I just kept talking to him around 60 times and received 31 unique passwords.  I noticed that each password started with 2 repeated characters that would dictate the rest of the password, the 9th and 10th, 11th, 13th, 15th, 17th, and 29th (final) characters were always the same.  If the first two characters were the same then the entire password would be the same.

Here's a link to a google doc I made with screenshots of the different passwords it generated https://drive.google.com/file/d/1eeBsBPN4pQLDS_-zT2AKol1idMLsks7P/view?usp=sharing
September 30, 2020, 02:25:36 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
I did a test and put in absolute garbage except for the 9th and 10th, 11th, 13th, 15th, 17th, and 29th characters and it worked!  Now I just need to figure out how those characters are assigned and we'll be one step closer!
October 01, 2020, 04:51:15 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
Okay I've done some tracing.  The characters I previously mentioned are a control for the password being correct.  Everything else appears to dictate who is in my party and possibly upgrades?  I'm doing more research and will post as I find out differences.  For instance I loaded the game using one of the passwords, and tried a few different things but each time got the same pool of passwords, but when I had someone join my party the first 13 characters along with the last character remained the same, but characters 14-28 changed moving 2 control characters from 15 and 17 to 16 and 18.

When I hit submit on the password it goes through a basic routine.

Starting with an X index of zero, it takes the first character and compares it with the value in register 9EAD with an offset of X.  If it doesn't match it increments X by one and checks again.  As a result this goes through that area I previously mentioned from 0x9EBD to 0x9F03 (which yes, after I strip the 10 for the NES header is 0x9EAD to 0x9EF3) until it gets a match. 

When it gets a match it stores the match starting at 065E and checks to see if it's reached the end of the password (Hex value 7F).  If the end isn't found it goes through the process again with the next character in the password until the end is found at which point it jumps to DF08 and begins a series of shift lefts and rotate rights that has me utterly lost.

I've made a paste bin with the tracelog that only shows unique entries any help I could get deciphering it while I continue to examine the changes would be much appreciated!

October 02, 2020, 01:32:25 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
I'm still working on trying to find WHERE the actual generation of the code begins.  I've done a trace on the dialog that prompts it but my knowledge is insufficient to figure out how the generation of the code occurs.

On some good news, I have at least been able to get the password system to work... in a fashion.  I've left the " and o character modifiers in place and it actually worked.



It's not ideal, but at least it's functioning.