Final Fantasy 1 through 8 (and possibly beyond) have one of the simplest RNGs possible - a table of 256 bytes that advances one every time it is needed.
Meanwhile, Final Fantasy 12's RNG isn't that broken; instead, it's around as broken as Pokémon's. Which means that you can turn on the console, perform some actions, and based on the results walk up to a chest, open it, and get the rare drop. And Final Fantasy 12 is pretty recent.
Advance Wars' RNG is actually one of the better ones, but as far as I know careful input would mean that it just cycles up based on frames spent on a certain frame, which would mean it'd still be manipulable in realtime, just difficult. Perhaps I'll try it for fun someday.
So this is basically turning into the discussion of this thread.
Let me try to summarize:
as Bond697 is saying, the input file is useless for figuring out RNG
there are a lot of information about this RNG on the internet and they are somewhat easy to find
Thus there is no problem in submitting a TAS of a Pokemon game after D/P (not including X and Y because of obvious reasons).
I don't know how any other discussion would fit into this thread, really...
it's almost 100% completely useless, even compared to just using an emulator to follow the battle rng and it's obviously not even close to using a debugger to pick through the code.
the MOST use you could get out of it would be seeing what the seed is on a frame that a move is selected and sort of going "ok, i know this 32-bit number makes a move do X, but why?" which is what you'd be doing on an emulator anyway. so is use is almost 0 there since you're doing the same thing either way.
and there's the point that, as i said, you cannot abuse the battle rng at nationals, regionals, or worlds because it absolutely 100% requires an emulator or action replay.
speaking of debugging, i have a really nice IDA 6.1 database for the battle system for black and white 1 if anyone is interested. lots of info there for anyone who can handle ARM assembly and is interested.
I never believe that exploits 100% require an emulator, and I'm not convinced you're correct in this case. (Also, you forgot about, or didn't mention, the ability to earn byes in Nationals via online play.)
However, I also don't see how releasing the input file would be useful for people intending to cheat.
I never believe that exploits 100% require an emulator, and I'm not convinced you're correct in this case. (Also, you forgot about, or didn't mention, the ability to earn byes in Nationals via online play.)
However, I also don't see how releasing the input file would be useful for people intending to cheat.
Simply stating it's not possible, without evidence, isn't particularly convincing.
If you can press the sequence of keys on an emulator, you can press the sequence of keys in real life too (unless it involves 30Hz mashing, or something like that). If you can calculate the sequence of keys to press via any means at all, you can pre-calculate it and memorize it. If it requires precise timing, you can use a clock or timer to help set it up.
Simply stating it's not possible, without evidence, isn't particularly convincing.
If you can press the sequence of keys on an emulator, you can press the sequence of keys in real life too (unless it involves 30Hz mashing, or something like that). If you can calculate the sequence of keys to press via any means at all, you can pre-calculate it and memorize it. If it requires precise timing, you can use a clock or timer to help set it up.
fine. the entropy data that's passed through the sha-1 function is made from a bunch of different things that i partially listed above.
-vcount is the vertical line counter, 0-262 each vframe
-the current value of timer0, a timer moving at the speed of system bus(16.78 mhz) counting 0-65535
-the mac address
-the current value of the tick system which is a special counter that is part of the sdk and not considered in normal rnging because it's always 0 at that point
-the current vframe number
-the current graphics engine status
-the current realtime clock values for y/m/d and h/m/s
-microphone sampling data result
-address in ram of the last microphone sampling data
-current touch panel status and info- all ranging from 0-65535
-current sel/sta/a/b/udlr/lpad/rpad key input
-current x/y/closed input
-the wireless rssi pool that generates random numbers- depends on wireless module received signal intensity.
you would need to accurately predict every single one of those from when you turn on the console to when you start a battle. and keep in mind they don't all change at the same rate at all. some don't even change consistently.
the only reason rng abuse is possible in gen 5 is that most of those values are 0 when the game creates the seed for the main rng. thankfully someone at gamefreak never read the sdk manual.
When does this seeding happen? If it's at poweron, like the other RNGs, most of those have known values, or typically known values, and so aren't important.
If it's seeded at the start of every battle, then yes, it's going to be rather harder. Many of those are going to be the same every time, though. (Realtime clock and key inputs are trivial to control, you can just not touch the touchpad, the MAC address is fixed, and I think it only samples inputs once a frame so it'll always be at the same point within the vcount?) The microphone is also easy to control, because it's possible to attach an external microphone to the DS, and it could easily be made to always output zeroes.
Dealing with the wireless-related seeding is normally handled by RNGers via simply turning wireless off. I don't believe there's any reason to turn it on at a VGC, either (it uses infrared). The graphics state likely has very low entropy, because the view on screen is particularly simple when starting a battle.
So "all" that you'd need to control would be the various precise timers. That probably does make control very difficult, but because I think the game only acknowledges keys at the transition from one video frame to the next, you could probably find a seed where a range of consecutive frames worked, for all reasonably likely precise-timer values that might happen on those frames.
When does this seeding happen? If it's at poweron, like the other RNGs, most of those have known values, or typically known values, and so aren't important.
If it's seeded at the start of every battle, then yes, it's going to be rather harder. Many of those are going to be the same every time, though. (Realtime clock and key inputs are trivial to control, you can just not touch the touchpad, the MAC address is fixed, and I think it only samples inputs once a frame so it'll always be at the same point within the vcount?) The microphone is also easy to control, because it's possible to attach an external microphone to the DS, and it could easily be made to always output zeroes.
Dealing with the wireless-related seeding is normally handled by RNGers via simply turning wireless off. I don't believe there's any reason to turn it on at a VGC, either (it uses infrared). The graphics state likely has very low entropy, because the view on screen is particularly simple when starting a battle.
So "all" that you'd need to control would be the various precise timers. That probably does make control very difficult, but because I think the game only acknowledges keys at the transition from one video frame to the next, you could probably find a seed where a range of consecutive frames worked, for all reasonably likely precise-timer values that might happen on those frames.
obviously it's seeded at every battle. and keep in mind it's not like doing rng abuse, you can't just start resetting your console over and over until you think you've maybe, possibly hit(remember, you can't check) one of the seeds at 1/16780000 hz that has to line up with the other timers that might work and give you an advantage. you start the game and battle when you're told. and while y/m/d is nothing, h/m/s is something you have to keep up with and pay attention to because you'll need the fight to start at the right time(which the competitors don't get to decide on) so you can maybe hit a seed through all the other timers/counters. another thing to pay attention to while you're trying to concentrate on a couple of high-precision timers and the other counters.
i could see it being possible if there was maybe 1 timer and counter and you had all the time in the world to reset til you liked what you got and could check somehow, but it's not and you can't.
plus, don't they supply the hardware for part of regionals and during at least parts of nats and worlds? which means you can't do anything to stop the microphone, etc. if you end up with their hardware. not to mention, you need to know exactly where the last sample was even if you do manage to force the samples to 00 through.. some means in front of the crowd of people and your opponent watching.
e: and no, the graphics state changes based on where in the room you are(causing new graphics to be queued and the state to change), if there's currently a gx-related callback interrupt executing, when the FIFO changes state, box tests and their results etc. it changes very frequently.
e2: before i forget, the tick system is 64-bit. it doesn't loop for a good, long time. you would also need to estimate where it would be when you're starting the battle. and you need to guess when you'll be starting the battle so you can guess where it'll be.
e3: also, you use the cgear to set up infrared battles. *edit: the vgc battles happen through the competition thing in the main menu. the wifi is on for the normal cgear stuff, but i'm not sure if it's on for that. you don't even get option to go in-game. whether that means wifi is on or not, i'm not sure. i don't really need to know to show that it's really not possible, but i'd like for the info to be right. for the sake of argument, though, let's say it's off.
-microphone sampling data result
-address in ram of the last microphone sampling data
Wait so does microphone actually change the result of the seeding?
Because from my testing the seed didn't change (or the microphone thing in desmume doesn't work, I don't know, I tried random whitenoise).
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
-microphone sampling data result
-address in ram of the last microphone sampling data
Wait so does microphone actually change the result of the seeding?
Because from my testing the seed didn't change (or the microphone thing in desmume doesn't work, I don't know, I tried random whitenoise).
it does for battles. it's not initialized for when the main game seeds. not all of those things are in effect when the main game seeds which is why it's possible to rng.
-microphone sampling data result
-address in ram of the last microphone sampling data
Wait so does microphone actually change the result of the seeding?
Because from my testing the seed didn't change (or the microphone thing in desmume doesn't work, I don't know, I tried random whitenoise).
it does for battles. it's not initialized for when the main game seeds. not all of those things are in effect when the main game seeds which is why it's possible to rng.
well, at least for b2w2 I can confirm that the start seed for a battle is as it is described here. Now I wonder where the microphone is coming in...
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
-microphone sampling data result
-address in ram of the last microphone sampling data
Wait so does microphone actually change the result of the seeding?
Because from my testing the seed didn't change (or the microphone thing in desmume doesn't work, I don't know, I tried random whitenoise).
it does for battles. it's not initialized for when the main game seeds. not all of those things are in effect when the main game seeds which is why it's possible to rng.
well, at least for b2w2 I can confirm that the start seed for a battle is as it is described here. Now I wonder where the microphone is coming in...
you can't use that. what i was describing is the same thing, but it uses more entropy data because things are actually initialized by the time you enter a battle. i'll show you.
this is OS_GetLoEntropyData:
note the comments. mic, vcount, tick counter, vcount, etc etc. when this runs when the main game is seeding, most of those values are 00s. when you do it when you're getting into battle, they are initialized and are used.
this is the output from the array on the stack when the main game is seeding:
02FE36AC 00380761 MEMORY:00380761
02FE36B0 A81F0000 MEMORY:A81F0000
02FE36B4 B4C55689 MEMORY:B4C55689
02FE36B8 05111013 MEMORY:05111013
02FE36BC 00000461 MEMORY:00000461
02FE36C0 00000000 MEMORY:00000000
02FE36C4 00000000 MEMORY:00000000
02FE36C8 00002FFF MEMORY:00002FFF
note all the 0s.
now note the array on the stack when getting into a battle:
02FE3654 00F0C7CA MEMORY:00F0C7CA
02FE3658 A85F3174 MEMORY:A85F3174
02FE365C 3CC424DC MEMORY:3CC424DC
02FE3660 05111013 MEMORY:05111013
02FE3664 00021262 MEMORY:00021262
02FE3668 00000000 MEMORY:00000000
02FE366C 0D600170 MEMORY:0D600170
02FE3670 FC032EDF MEMORY:FC032EDF
much fewer 0s because the hardware and systems are initialized.
and keep in mind, the only reason there's 1 line of 0s in the second array is that the mic just isn't working right in desmume. that's the mic data element. if this was a real DS, that would be set to a couple of values.
this is how i know that:
ARM9:0207C74E E5 20 80 00 MOVS R0, 0x394 ; MIC sampling result
ARM9:0207C752 31 5A LDRH R1, [R6,R0]
ARM9:0207C754 0A 04 LSLS R2, R1, #0x10
ARM9:0207C756 01 1F SUBS R1, R0, #4
ARM9:0207C758 71 58 LDR R1, [R6,R1] ; MIC data storage address
ARM9:0207C75A 51 40 EORS R1, R2
ARM9:0207C75C 69 61 STR R1, [R5,#0x14]
note that the mic data result is stored to r5 + 0x14 and 0x2FE3654 + 0x14 is 02FE3668, which is the 0-ed line.
so to carry this to a conclusion, this array is hashed along with 20 bytes of garbage from the stack. it looks like this: http://pastebin.com/EVxNBAN4
then after the nazos and array are hashed, they take 8 bytes and make that the starting seed.
Wow, that's a huge disappointment that desmumes mic is not working right :(
I think even if it would be working, you could only use one sample for the whole movie (since in the movie file there is just stored if you pressed the hotkey for microphone enable).
So to make desmume really TAS-friendly you would have to edit the source code.
A question I also had was how big is sampling data per frame, so, how many different values can it contain?
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
thinking about it now, maybe the mic does work right and it's just not picking up mine right so it's outputting 0s. if that's the case, the newer versions of desmume have a setting that lets you use a generic mic sample provided by desmume. you could get away with that, i'm sure.
the sizes for the mic data are:
u32 mic_last_address;
u16 mic_sampling_data;
so 4 bytes and 2 bytes- the address is somewhere in 0x2xxxxxx in ram and the sampling data is 0-65535
Well I know that microphone is working, but I don't know if it's working right.
Bond697 wrote:
the newer versions of desmume have a setting that lets you use a generic mic sample provided by desmume. you could get away with that, i'm sure.
To really manipulate in a TAS you would have to enter the 2 bytes of sampling data yourself.
Combining this with the 4096 possible input states, you get 268435456 different possibilities for a seed (not necessarily different seeds, but since it's hashing, probably only a few under 268435456 if not exactly that).
Please correct me if I'm wrong somewhere :)
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
how are you calculating that, exactly? like, can you give me the numbers you multiply together? or do you mean just given different mic data? because that's not nearly enough for total seeds. also, do you mean for the main seeding or for a battle?
also
you can provide a sample that desmume will use. pretty sure that will work.
I thought there are 65536 different values for sample data that gives you 65536 different possibilities for seeds.
And since the seed also depends on the input (which there are 4096 states of) you have to multiply them together. So 65536 * 4096 = 268435456.
edit:
Responding to your picture:
Masterjun wrote:
I think even if it would be working, you could only use one sample for the whole movie (since in the movie file there is just stored if you pressed the hotkey for microphone enable).
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
I thought there are 65536 different values for sample data that gives you 65536 different possibilities for seeds.
And since the seed also depends on the input (which there are 4096 states of) you have to multiply them together. So 65536 * 4096 = 268435456.
edit:
Responding to your picture:
Masterjun wrote:
I think even if it would be working, you could only use one sample for the whole movie (since in the movie file there is just stored if you pressed the hotkey for microphone enable).
indeed, 1 sample for the whole movie. you'd probably have to make it yourself in a hex editor and provide it to desmume as a.raw file.
as for the seed, that's true about those few numbers, but there are others. let's see if we can extend this all the way. we'll start with battle seeding since everything is initialized.
-65536 numbers for sample
-0x3000 for input, minus a few since closing the console and hitting the debug button wouldn't count and a few of the . so let's say 0x2400 values for the sake of argument
-263 for vcount
-65536 for timer0
-MAC is MAC, it doesn't change
-vframe is an unsigned int, so 4294967296 total. that said, it could take months to get that high. for argument's sake, let's say you play/leave the game on for up to 3 hours. that would max the vframe at 38880000.
-gx status will somewhat change. it's a 32-bit number, so it can go up to 4294967296, but some of that is not used in these games. so let's be pretty conservative and say roughly 8 bits are commonly used and say 256 values.
-mic data address in ram- let's constrain it to a 1mb area instead of 4 for the address, so 1048576 there
-wireless rssi pool- this generates randomness based on wireless intensity. it would be extremely hard to get past this randomness, but you could certainly shut off wifi. this is 65536.
-tick system- this is one of the big ones. it's 64-bit and runs faster than vframe, but slower than timer0. it's used for timing things for debugging, random numbers, etc. it's the ds equivalent of a windows api timer or starting a timer in C#. let's do the same thing as vframe and lower the max from 2^64 to 3 hours of play at most. there's 4294967296 ticks in 2 hours 17 minutes, so let's just go with that as the max.
-the clock, which is binary-coded decimal and can be read as decimal in the memory @ 2FFFDE8 and 2FFFDEC, will of course throw things off even more. i'm not going to add this in to the calculation because it's already so big that it illustrates my point. keep in mind that it would need to be factored in, though.
so as you can see, the max possibilities for a seed for a battle are pretty large.
65536 * 0x2400 * 263 * 65536 * 38880000 * 256 * 1048576 * 4294967296 is the max there. (*wifi is assumed off, so we won't count this) to change up the tick system and vframe count, just change 38880000 and 4294967296. still a lot, though.
keep in mind, that's for battle. when starting the game, you get something more reasonable.
(again, each number is the number of values possible)
-1 for sample
-0x2400 for input
-1 for vcount
-4 for timer0
-MAC is MAC
-1 for vframe
-1 for gx status
-1 for mic data location
-1 for wifi
-1 for tick system
-and the clock again, which is constant between each. just keep it in mind.
see the difference? and the stuff that's still got a wide range for the main rng seeding is user controllable very easily- input and clock.
so what i'm getting at after saying all this disparaging shit is that battle rng is possible with the emulator so long as you're set to stand and wait for the values to change and do the math out to check and see if you'll benefit from the outcome. and you may be standing and waiting for a very, very long time. and you can't know what the opponent will do during the battle that might screw up your long-awaited rng seed. if they do something that requires an extra rng call or 1 less, you're kinda stuck again.
plus, don't they supply the hardware for part of regionals and during at least parts of nats and worlds? which means you can't do anything to stop the microphone, etc. if you end up with their hardware. not to mention, you need to know exactly where the last sample was even if you do manage to force the samples to 00 through.. some means in front of the crowd of people and your opponent watching.
They used to, but they don't any more, so that they can get more battles happening at once.
e: and no, the graphics state changes based on where in the room you are(causing new graphics to be queued and the state to change), if there's currently a gx-related callback interrupt executing, when the FIFO changes state, box tests and their results etc. it changes very frequently.
VGC battles are done from the main menu, not from a room at all. It's one of the graphically simplest views in the entire game.
before i forget, the tick system is 64-bit. it doesn't loop for a good, long time. you would also need to estimate where it would be when you're starting the battle. and you need to guess when you'll be starting the battle so you can guess where it'll be.
You could turn off the DS, then turn it on when you're told to start the battle; that's done really frequently to prevent the DS losing power.
also, you use the cgear to set up infrared battles. *edit: the vgc battles happen through the competition thing in the main menu. the wifi is on for the normal cgear stuff, but i'm not sure if it's on for that. you don't even get option to go in-game. whether that means wifi is on or not, i'm not sure. i don't really need to know to show that it's really not possible, but i'd like for the info to be right. for the sake of argument, though, let's say it's off.
It isn't. If it were on, the power light would flicker, and it doesn't.
If you need testing to see how a real DS acts, I currently have a B2/W2 cartridge in VGC mode (from UK nationals 2013; I never bothered to take it out of that mode in case it became useful for testing later). Obviously, I can't start a battle without a second cart in VGC mode (from the same tournament) to connect it to, but I can check what happens on the battle-starting screen. (Cartridges in VGC mode were previously used to analyze the exact tiebreak rules in VGC; they're meant to be public knowledge, but the official explanations of them are somewhat ambiguous.)
I agree with you that abusing this in realtime is going to be basically impossible, certainly much harder than winning a battle legitimately. I love wondering about whether it's possible or not, though, even if I'd never do it myself.
indeed, 1 sample for the whole movie. you'd probably have to make it yourself in a hex editor and provide it to desmume as a.raw file.
as for the seed, that's true about those few numbers, but there are others. let's see if we can extend this all the way. we'll start with battle seeding since everything is initialized.
[...]
so as you can see, the max possibilities for a seed for a battle are pretty large.
65536 * 0x2400 * 263 * 65536 * 38880000 * 256 * 1048576 * 4294967296 is the max there. (*wifi is assumed off, so we won't count this) to change up the tick system and vframe count, just change 38880000 and 4294967296. still a lot, though.
A bunch of these variables you can't actually control without losing more time than it actually saves.
You can change input and microphone the frame it happens so that's more reasonable and also I didn't say that 268435456 different possibilities are the maximum, they are just the easiest to manipulate.
Bond697 wrote:
indeed, 1 sample for the whole movie. you'd probably have to make it yourself in a hex editor and provide it to desmume as a.raw file.
That would mean that you had the same sampling data for every battle! That's very pointless for a TAS because that gives you only 2 out of the 65536 possible states (0 and the one in the file).
Warning: Might glitch to creditsI will finish this ACE soon as possible
(or will I?)
A bunch of these variables you can't actually control without losing more time than it actually saves.
You can change input and microphone the frame it happens so that's more reasonable and also I didn't say that 268435456 different possibilities are the maximum, they are just the easiest to manipulate.
ok, we just had a small miscommunication here. i thought you were saying that that was everything. you're certainly right about that. to make one where you actually take advantage, you would just be sitting there forever slowly advancing frames waiting for the right combination of numbers to come up. so yeah, you'd end up killing tons and tons of time.
Masterjun wrote:
Bond697 wrote:
indeed, 1 sample for the whole movie. you'd probably have to make it yourself in a hex editor and provide it to desmume as a.raw file.
That would mean that you had the same sampling data for every battle! That's very pointless for a TAS because that gives you only 2 out of the 65536 possible states (0 and the one in the file).
you're right. i guess there's really no good way of handling this? and it's not legal for the TAS to disable it in desmume?
it's starting to look like any real manipulation of the battle rng in a TAS would be extremely difficult, if it's possible at all. that's kind of disappointing.
before i forget, the tick system is 64-bit. it doesn't loop for a good, long time. you would also need to estimate where it would be when you're starting the battle. and you need to guess when you'll be starting the battle so you can guess where it'll be.
You could turn off the DS, then turn it on when you're told to start the battle; that's done really frequently to prevent the DS losing power.
i agree with you to a point. the tick system moves at 65536 ticks per 7.5 vframes. so, very fast. so you would really need to know ahead of time down to the second when your battle is starting. or you'd need to guess and make lists of which starting seconds would work and see if you could kind of manipulate things a bit so the battle started when you needed it to. theoretically possible, i suppose. the real pain the ass there is making sure you kind of push things or delay things so the match starts when you need it to.
i agree with you to a point. the tick system moves at 65536 ticks per 7.5 vframes. so, very fast. so you would really need to know ahead of time down to the second when your battle is starting. or you'd need to guess and make lists of which starting seconds would work and see if you could kind of manipulate things a bit so the battle started when you needed it to. theoretically possible, i suppose. the real pain the ass there is making sure you kind of push things or delay things so the match starts when you need it to.
0_o
Kaphotics must've believed the average player have bot-like reflexes and skill to pull it off consistently. :o
anyway, i guess i made my point on the difficulties of manipulating the rng for battles. that said, so how was the "TAS" that was already linked done? and how did it not involve him just standing and waiting for some time for a good seed to show up before a battle starts, but still manipulating the battle rng? well, the simplest answer is correct and also explains the missing input file. i'll just leave it at that.
It has been almost another three years, and Gen 7 is coming out soon.
I guess bond697 was trying to say Kaphotics's TAS was not legit then? It's a shame if that's the case.
Guts is probably less useful if there is no way to manipulate each turn in a fight since it would be too much to make sure the player's Pokemon is not fully paralyzed and Quick Claw is in effect at the same time for the entire fight at once. X items might even be needed in some cases, and a TAS might not look too different from a RTA in this case.
note the comments. mic, vcount, tick counter, vcount, etc etc. when this runs when the main game is seeding, most of those values are 00s. when you do it when you're getting into battle, they are initialized and are used.
this is the output from the array on the stack when the main game is seeding:
02FE36AC 00380761 MEMORY:00380761
02FE36B0 A81F0000 MEMORY:A81F0000
02FE36B4 B4C55689 MEMORY:B4C55689
02FE36B8 05111013 MEMORY:05111013
02FE36BC 00000461 MEMORY:00000461
02FE36C0 00000000 MEMORY:00000000
02FE36C4 00000000 MEMORY:00000000
02FE36C8 00002FFF MEMORY:00002FFF
note all the 0s.
now note the array on the stack when getting into a battle:
02FE3654 00F0C7CA MEMORY:00F0C7CA
02FE3658 A85F3174 MEMORY:A85F3174
02FE365C 3CC424DC MEMORY:3CC424DC
02FE3660 05111013 MEMORY:05111013
02FE3664 00021262 MEMORY:00021262
02FE3668 00000000 MEMORY:00000000
02FE366C 0D600170 MEMORY:0D600170
02FE3670 FC032EDF MEMORY:FC032EDF
much fewer 0s because the hardware and systems are initialized.
and keep in mind, the only reason there's 1 line of 0s in the second array is that the mic just isn't working right in desmume. that's the mic data element. if this was a real DS, that would be set to a couple of values.
this is how i know that:
ARM9:0207C74E E5 20 80 00 MOVS R0, 0x394 ; MIC sampling result
ARM9:0207C752 31 5A LDRH R1, [R6,R0]
ARM9:0207C754 0A 04 LSLS R2, R1, #0x10
ARM9:0207C756 01 1F SUBS R1, R0, #4
ARM9:0207C758 71 58 LDR R1, [R6,R1] ; MIC data storage address
ARM9:0207C75A 51 40 EORS R1, R2
ARM9:0207C75C 69 61 STR R1, [R5,#0x14]
note that the mic data result is stored to r5 + 0x14 and 0x2FE3654 + 0x14 is 02FE3668, which is the 0-ed line.
so to carry this to a conclusion, this array is hashed along with 20 bytes of garbage from the stack. it looks like this: http://pastebin.com/EVxNBAN4
then after the nazos and array are hashed, they take 8 bytes and make that the starting seed.
you can provide a sample that desmume will use. pretty sure that will work.
