[Announcement:] Several New Gen 3 Jirachi Events Found by me!!

[Sabresite]

Update:

I found the shiny check, which roughly translates to while pid is shiny, pid +=1.

[Sabresite]

@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.

[Kaphotics]

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

[Bond697]

there is no rng seeding code anywhere in there.  if that's a guess based on the code from the original games, then fine, but i'm pretty sure it's not there.  

[Sabresite]

When I converted it to C, that came up. You are right though, I can't find it in the assembly?

[Bond697]

ok, i think we have it down now.  the code is copied and pasted straight from r/s where they had it optimized down to a series of shifts.

[Sabresite]

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.

[Kaphotics]

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

[Sabresite]

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.

[Kaphotics]

Are you sure day is constrained to 31 days? The rtc doesn't store months elapsed, so the day value keeps incrementing. It's a 16bit value!

[coltonsmogon]

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 April 19, 2017 by coltonsmogon

[Sabresite]

10 minutes ago, Kaphotics said:

Are you sure day is constrained to 31 days? The rtc doesn't store months elapsed, so the day value keeps incrementing. It's a 16bit value!

Yeah I am stupid, its day of the year, so 1 -> 365 (leap years?)

[Kaphotics]

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.

[Sabresite]

Yeah you are right and @Admiral_Fish linked me to the code that does that in RNG Reporter.
Thanks guys!

[Kaphotics]

Just now, Sabresite said:

Yeah I am stupid, its day of the year, so 1 -> 365 (leap years?)

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).

[Sabresite]

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.

[coltonsmogon]

Note that this was a JP event so best to do this with JP R/S if you wanna keep at least SOME form of legitimacy...

[St. GIGA]

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???

[Sabresite]

Will never be shiny.  The increment is a for-loop that goes on until it is not shiny.  Only takes up to 8 increments to make any PID not shiny.

[St. GIGA]

OK. That IS sad, but we DO have Wishmaker (maybe even meteor.)

BTW can someone write this code into an online repl.it? Also, are any Jirachi flawless-capable???

Edited April 19, 2017 by St. GIGA
Added questions

[coltonsmogon]

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 April 19, 2017 by coltonsmogon

[Sabresite]

This has wide implications.  If other events (10 ANNIV, etc) are seeded the same way, then we could restrict seeds of events to those distribution periods.

[YoshiMoshi]

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?

[Sabresite]

So I updated Kaphotic's REPL since the seed is xor'd (not or'd): https://repl.it/HRHc/2
It looks like a straight linear seed, just like we predicted it should be.

[Sabresite]

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.