Gen 6/7 PID & Initial Seed Possibilities

[PPUser2018]

As far as I am able to understand the concept based on this early post over at Smogon, the initial seed for 3DS Pokemon games is calculated using 1) the number of CPU ticks that have elapsed since the CPU was powered on, and 2) the number of milliseconds since 00:00:00, 1 Jan 2000. Considering that the initial seed is basically the digest of SHA-256, is it practically impossible for any "Seed to Time" programs to exist? So even if we could somehow manipulate the message (inputs), it wouldn't be much use.

The above train of thought stemmed from wondering whether certain PID/EC/Nature/IV/Gender/Ability combinations are theoretically invalid given a specified met date of a Pokemon, or can every possible initial seed be obtained on any given date? I know in Gens 4 and 5, not every seed is available on every date (some aren't even valid seeds in Seed to Time). Also, unlike Gen 5, where a 64-bit seed is split in half and each 32-bit half can be independently advanced, calls in Gen 6/7 reroll the entire 64-bit value, and I assume (0x41C64E6D * Seed) + 0x6073 doesn't apply anymore.

When genning, I want to be as legal as possible (I know Nintendo doesn't care), which I believe involves using 3DSRNGTool to find a feasible frame with the desired spread and corresponding PID/EC combo.

[Kaphotics]

The RNG for the 3DS pkm games is 128 bit (SFMT) so it allows for any combination.

Gen5's RNG is 64bit, not 2*32bit. There was also a Mersenne Twister which was responsible for IVs (regular pkm; wondercards used the aforementioned PIDRNG).

Legality is based on whether or not the chance of getting that result is possible within the period of the RNG (time before it repeats). Since the period is orders of magnitude larger than the chance of getting a pkm combination, any combo is valid.

[theSLAYER]

10 minutes ago, Kaphotics said:

The RNG for the 3DS pkm games is 128 bit (SFMT) so it allows for any combination.

Gen5's RNG is 64bit, not 2*32bit. There was also a Mersenne Twister which was responsible for IVs (regular pkm; wondercards used the aforementioned PIDRNG).

Legality is based on whether or not the chance of getting that result is possible within the period of the RNG (time before it repeats). Since the period is orders of magnitude larger than the chance of getting a pkm combination, any combo is valid.

I too, have been pondering about this for a while, and I'm grateful that you were able provide such a clear and concise explanation!

[PPUser2018]

9 hours ago, Kaphotics said:

The RNG for the 3DS pkm games is 128 bit (SFMT) so it allows for any combination.

Gen5's RNG is 64bit, not 2*32bit. There was also a Mersenne Twister which was responsible for IVs (regular pkm; wondercards used the aforementioned PIDRNG).

Legality is based on whether or not the chance of getting that result is possible within the period of the RNG (time before it repeats). Since the period is orders of magnitude larger than the chance of getting a pkm combination, any combo is valid.

Thank you for the additional insight Kaphotics. Apologies for my rudimentary understanding as I only just started reading about Pokemon RNG so I'm still trying to grasp the differences between generations. With regards to Gen 5, I think I got confused with Smogon's part 3 write-up which references the Mersenne Twister "half" and the other "half" (PIDRNG), but I see now that it's 64-bit.

If I wanted to RNG a Gen 6/7 wondercard using today's seeds, could the met date of the resulting Pokemon be changed (to a past date within its original distribution period) and still be considered legal? Or is it practically impossible to discern due to the use of SHA-256?

[theSLAYER]

13 minutes ago, PPUser2018 said:

Thank you for the additional insight Kaphotics. Apologies for my rudimentary understanding as I only just started reading about Pokemon RNG so I'm still trying to grasp the differences between generations. With regards to Gen 5, I think I got confused with Smogon's part 3 write-up which references the Mersenne Twister "half" and the other "half" (PIDRNG), but I see now that it's 64-bit.

If I wanted to RNG a Gen 6/7 wondercard using today's seeds, could the met date of the resulting Pokemon be changed (to a past date within its original distribution period) and still be considered legal? Or is it practically impossible to discern due to the use of SHA-256?

Based on how the system works, there is no definite relation between RAW RTC and RTC, since formatting the 3DS resets the RAW RTC (if I'm not mistaken), and people can change the 3DS's RTC freely (which has no impact on the RAW RTC).

Assuming that the 3DS's seeding for the RNG is done using RAW RTC, then it doesn't matter what Met date it has on the Pokemon.
There will be no definite correlation between "Met Date" and "today's seed", since various users can have the same met date,
but seeded differently since RAW RTC will be different across everyone's consoles.

That's what I think.

[PPUser2018]

1 hour ago, theSLAYER said:

Based on how the system works, there is no definite relation between RAW RTC and RTC, since formatting the 3DS resets the RAW RTC (if I'm not mistaken), and people can change the 3DS's RTC freely (which has no impact on the RAW RTC).

Assuming that the 3DS's seeding for the RNG is done using RAW RTC, then it doesn't matter what Met date it has on the Pokemon.
There will be no definite correlation between "Met Date" and "today's seed", since various users can have the same met date,
but seeded differently since RAW RTC will be different across everyone's consoles.

That's what I think.

Ah, I see. Is the default date/time on the RTC chip not 00:00:00 01/01/2000? So getTimeInMilliseconds() would only be different for users who change the Raw RTC of their system. Of course there's also the number of CPU ticks added into the mix, and both values are then hashed to the produce the seed.

My main thought is if I did RNG a Pokemon using a seed I obtained on my system today (based on CPU ticks + milliseconds), and then chose a desired frame (within the set of frames produced from that specific starting state), it's not feasible to ascertain whether that seed could (or could not) have been possible to obtain on a previous date. I suppose the possibilities are so vast compared to Gen 4 that it just doesn't matter.

The thread at Smogon includes the following example: "if GetSystemTick() returns 0x12345678, getTimeInMilliseconds() returns 0x7d349cc000 (that means 00:00:00, 15 Jan 2016), then seed is 0xddcdcba7." I was actually wondering if a seed generator exists. In theory, one could choose a range of dates/times and CPU ticks to produce a list of seeds.

[theSLAYER]

For simplicity sake, I'm gonna call the RTC that users see normally USER RTC.

RAW RTC starts at that time, and User RTC is the one user sets.
both RTC gains time together, but modifying the User RTC won't modify RAW RTC.
(that is how games know that the time has been tempered with, due to change in time difference between User RTC and Raw RTC)


I think the problem is even if you can identify what RAW RTC generated the Seed,
it doesn't matter entirely, since RAW RTC =/= User RTC.
You can't discern whether the Pokemon was obtained legitimately in the correct date range,
since we can't pin down User RTC using Raw RTC.

Once again, this is based on my understanding on the relation between User and Raw RTC. It might not be correct.

[PPUser2018]

Excuse my misunderstanding. I was under the assumption that getTimeInMilliseconds() was based on User RTC, so every "Met Date" would have the same set of results returned (86.4 million of them). As you said, if the function actually utilises Raw RTC (which is different for each system based on date of manufacture and can be reset by formatting), then there would be no direct correlation between "Met Date" and that date's possible seeds.

The following details were what I failed to grasp:

• The RTC chip has the default date of 01/01/2000 00:00:00 set when system is manufactured, and the Raw RTC starts running from there.
• User RTC = Raw RTC + Offset.
• I conflated the default date of the RTC chip as having a direct relationship to the getTimeInMilliseconds() function.

Thank you for resolving my confusion.

Edited February 9, 2018 by PPUser2018