Jump to content

Recommended Posts

@Bond697 please correct me if I am wrong on any if this.

I read through most of the code last night and the rng looks like it is seeded by the result of a calculation of magic numbers, possibly time related? X =(1440 * A) + (60 * B) + C. This number is changed before used as a seed by doing this: (X >> 16) ^ (X & 0xFFFF).

Held item uses the same number X. Question is, does A,B,C change? Like from an RTC? Also even if it doesn't, the seeding creates data loss so we can't link held item to the seed regardless.

Link to comment
Share on other sites

37 minutes ago, Sabresite said:

@Bond697 please correct me if I am wrong on any if this.

I read through most of the code last night and the rng looks like it is seeded by the result of a calculation of magic numbers, possibly time related? X =(1440 * A) + (60 * B) + C. This number is changed before used as a seed by doing this: (X >> 16) ^ (X & 0xFFFF).

Held item uses the same number X. Question is, does A,B,C change? Like from an RTC? Also even if it doesn't, the seeding creates data loss so we can't link held item to the seed regardless.

days*1440m/d + hrs*60m/h + m

standard initial seeding for R/S from the RTC storage

Link to comment
Share on other sites

Yeah, so this is what it looks like it is doing (roughly) is this:

seed (RTC minutes like R/S, with the xor high and low bits)
pidh
pidl
if pidh is 0, or it with 0x2003
if pidl is 0, or it with 0x327
-- pid is not used
pidh (again)
pidl (again)
if new pid is shiny, increment pid until not shiny. Increment maxes out at 8.
iv1
iv2

item is based on the original RTC seed calculation, which is indeterminate based on the seed because the RTC seed is xor'd before its sent to seed the RNG.

I never dived into R/S seeding, so I am not sure how the RTC is calculated, like based on minutes from an epoch, a random date, etc.  I also don't know the seed period of GBA games, so maybe someone can chime in with that info.

  • Like 1
Link to comment
Share on other sites

The latest commits of PKHeX support viewing of the saved RTC values, a dry battery yields 5A0 which is 1 day.

Basically it's just an elapsed time since initial power on (iirc).

Wouldn't surprise me if those debug pid values are a date :) 03/27/2003

Link to comment
Share on other sites

11 minutes ago, Kaphotics said:

The latest commits of PKHeX support viewing of the saved RTC values, a dry battery yields 5A0 which is 1 day.

Basically it's just an elapsed time since initial power on (iirc).

Wouldn't surprise me if those debug pid values are a date :) 03/27/2003

Yeah they are a date.  It probably corresponds to when they were writing the code.  I think that was around a month before the first gen 3 event (5th anniv eggs).  We know the first distribution used the same code too.

Also Bond found in R/S a binary encoded decimal representation of the date.  It was in IRAM ~0x3000460.  It looks something like 0x17 0x04 0x19 0x11 0x40 0x00 (for example).  This is used to generate that RTC value you mentioned.

Link to comment
Share on other sites

Meaning 65535 "days" are possible and 65535 possible Jirachis exist because of this logic... Meaning if we can reconstruct the algorithm from what we've got, we could recreate one of the Negaiboshi Jirachi... unless @Purin wants to share us one, that is...

Edited by coltonsmogon
Link to comment
Share on other sites

1 minute ago, coltonsmogon said:

Meaning 65535 "days" are possible and 65535 possible Jirachis exist because of this logic...

If the seed is 16bit then all that has to be done is brute force seeds from day 1 to see the minimum time for a seed. I'm pretty sure it'll be low enough such that all seeds are possible to obtain prior to the event.

Link to comment
Share on other sites

Just now, Kaphotics said:

Doesn't store years either, just keeps ticking. It screws up after 366 days, hence the need for the berry glitch fix (read up on bulbapedia).

Since this particular distribution was in 2003, to find original redemptions, I shouldn't have that issue.

Link to comment
Share on other sites

My question is, can we see about writing some code with this knowledge and our currently known trash byte Info that either takes an RS save and generates a Jirachi based on the RTC value, or B, checks and bruteforces all 65536 Jirachi spreads to see if the  incremental shiny check could ever have hit a wall of 9 or 10 failed incremental PID modifications, resulting in shinyness like on Wishmaker???

Link to comment
Share on other sites

Next up, let's figure out how we're supposed to get a shiny Channel Jirachi since we debunked the shininess of Negaiboshi Jirachi... First, let's see if we can put that data to good use with getting one of them...

Edited by coltonsmogon
Link to comment
Share on other sites

On 4/5/2017 at 5:51 PM, Purin said:

Yeah, it holds one of the usual berries!
I was using the Japanese distribution rom for which I don't have permission to share, sorry. However, iirc the multiboot binary matches sample0519.bin. There might be special things (i.e. handshake?) going on after the slave boots.

Japanese room has leaked?

  • Like 1
Link to comment
Share on other sites

Yeah that is true. recreating a master rom would be a shitshow.

Next step is to test pcjp 2003 eggs (83 of them) and see how many seeds are within the distribution period. Then test the RTC for species/moves.

I have a theory that the pcjp rom was leaked.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...