#145617 - yellowstar - Mon Nov 19, 2007 4:18 am
Goto this post for the latest question/problem.
Last edited by yellowstar on Sun Apr 20, 2008 8:29 pm; edited 11 times in total
#145618 - dualscreenman - Mon Nov 19, 2007 4:28 am
Using the SDK if you haven't bought it is illegal, and the RSA key is kept by Nintendo's security ninjas.
_________________
| dualscreenman wrote: |
| What about Gaim DS? Gaim pretty much has support for all IM programs. |
| tepples wrote: |
| "Goshdammit, the DS is not a Gaim-boy! It's a third pillar!" |
#145620 - tepples - Mon Nov 19, 2007 4:43 am
Similar to what yellowstar is trying to describe is a theoretical exploit that I have called WiFiMe2. In this, a modified version of wmb would exploit the second stage of a commercial game's DS Download Play loader and use it as a boot loader for homebrew. We analyzed the DS Download Station loader, but it ended up using RSA in the second stage too.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#145621 - HyperHacker - Mon Nov 19, 2007 6:00 am
Nintendo isn't going to sign anything that will load unsigned code, and they're the only ones that can do it. So your options are 1) steal the key (highly illegal and probably extremely difficult), 2) find the key yourself (which could take a few million years with current technology), or 3) find an exploit in the firmware or a signed binary (WifiMe2). I suggest instead, you simply pass the person your homebrew device and let them load up the app there. That app could even download unsigned code if you wanted it to.
_________________
I'm a PSP hacker now, but I still <3 DS.
#145625 - TJ - Mon Nov 19, 2007 9:28 am
In the early days of DS homebrew this idea might have been compelling (though no less difficult), but there is really no need to muck around with WMB anymore. Devices to boot unsigned code on the DS are so readily available that you would have more trouble finding a compatible WLAN card to host the WMB then you would getting a SLOT1 flash card online.
#145628 - OSW - Mon Nov 19, 2007 2:11 pm
well yes, but it would be neat to be able to expose multiple people at once without the necessary equipment to homebrew through a download play type server.
#145629 - melw - Mon Nov 19, 2007 3:32 pm
Basically what Tepples said...
But on a contrary I believe we should think what good a download play program that works only on homebrew enabled DS's could offer: One obvious feature that comes to my mind is ability to save data to flash adapter, whereas official download play content is being erased when the DS is shut down. In other words a DLDI enabled software that does not only transfer but is also able to save the application.
One could always skip the download play part and do a separate file transfer program, but download play is nice in that sense it's available on every DS.
#145643 - tepples - Mon Nov 19, 2007 8:40 pm
| melw wrote: |
| One obvious feature that comes to my mind is ability to save data to flash adapter, whereas official download play content is being erased when the DS is shut down. In other words a DLDI enabled software that does not only transfer but is also able to save the application. |
I have an R4, my cousin has a SuperCard SD, and my sister has a GnM. Under your proposal, which do I patch the download play for?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#145646 - melw - Mon Nov 19, 2007 9:14 pm
| tepples wrote: |
| I have an R4, my cousin has a SuperCard SD, and my sister has a GnM. Under your proposal, which do I patch the download play for? |
Hmm... No bullet proof method for this, I guess. Multipatching for the most common adapters? Full scale file DS<->DS file transfer program would make things easier in the end, or at least a homebrew version download play that patches the downloaded .nds with correct dldi driver before saving and launching.
#145654 - HyperHacker - Mon Nov 19, 2007 11:55 pm
You send a stub first that reports back the adapter type, then you patch for that type and send.
_________________
I'm a PSP hacker now, but I still <3 DS.
#145658 - yellowstar - Tue Nov 20, 2007 1:16 am
Oh well...
I guess NoFlashMe users
like me will be left in the dark
when the homebrew local wireless revolution happens.
(That would only include software that only
supports download play.)
(That is, the point at which Mighty Max
decides that the lib is ready for everybody to use.)
What about the RSA Questions?
(The one about the location and length of the RSA.)
(And the one about modding Juglak's WMB Host
to send the RSA.)
#145671 - Lynx - Tue Nov 20, 2007 5:34 am
| melw wrote: |
| tepples wrote: | | I have an R4, my cousin has a SuperCard SD, and my sister has a GnM. Under your proposal, which do I patch the download play for? |
Hmm... No bullet proof method for this, I guess. Multipatching for the most common adapters? Full scale file DS<->DS file transfer program would make things easier in the end, or at least a homebrew version download play that patches the downloaded .nds with correct dldi driver before saving and launching. |
Well, if you are downloading and running a homebrew app, make it "autodetect" the device and load/patch with that DLDI driver. The DLDI patches aren't really all that big, so you could probably put them all in a file without much issues, I would think.
_________________
NDS Homebrew Roms & Reviews
#145723 - yellowstar - Tue Nov 20, 2007 11:33 pm
I could use download play clients,
but that defies the point.(it would need booted from a card.)
#146711 - yellowstar - Fri Dec 07, 2007 11:12 pm
Once a DP bootstub,(from the official games)
was sent,
would it be possible to crash it
with malformed packets?
(Make the bootstub boot homebrew somehow?)
(And then transfer, and boot,
homebrew?)
Would it be possible,
to hack an bootstub,
to boot/run homebrew,(to transfer and boot homebrew)
without voiding the RSA?
(That is, without making
the binary fail the RSA check?)
What sections of the .nds does
RSA cover?
(That is,
what sections wouldn't void the RSA,
once changed?)
| Quote: |
The RSA Questions:
1.
Where in a .nds is the RSA located?
And what is it's length?
2.
How would I modify Juglak's WMB Host
to send the RSA?(I know the wireless lib
will do download play soon...)
(Only demos would be sent.)
|
#146725 - tepples - Sat Dec 08, 2007 1:44 am
| yellowstar wrote: |
Once a DP bootstub,(from the official games)
was sent,
would it be possible to crash it
with malformed packets?
(Make the bootstub boot homebrew somehow?)
(And then transfer, and boot,
homebrew?) |
That's likely, and the name "WiFiMe2" has been reserved for this.
| Quote: |
Would it be possible,
to hack an bootstub,
to boot/run homebrew,(to transfer and boot homebrew)
without voiding the RSA?
(That is, without making
the binary fail the RSA check?) |
First you'd have to have someone who has 1. the knowledge to reverse engineer a bootstub and more importantly 2. the motivation to reverse engineer a bootstub.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#146789 - yellowstar - Sun Dec 09, 2007 4:08 am
| tepples wrote: |
| Quote: | Would it be possible,
to hack an bootstub,
to boot/run homebrew,(to transfer and boot homebrew)
without voiding the RSA?
(That is, without making
the binary fail the RSA check?) |
First you'd have to have someone who has 1. the knowledge to reverse engineer a bootstub and more importantly 2. the motivation to reverse engineer a bootstub. |
I now realize that
that having hb handle the transfer
probably wouldn't work.(RSA)
Where do
the bootloaders,(In the official Download Play client)
do the RSA check?
I'd assume that is done in
the bootstub.(Not the app sent in DP)
Either the bootloader
could be hacked,(to get around RSA)
or use a homebrew one.
#147579 - yellowstar - Sun Dec 23, 2007 10:20 pm
Where in a .nds is the RSA signature?
(To grab the signature,
to mod Juglak's WMB host to send official demos.)
#148969 - yellowstar - Sat Jan 12, 2008 8:58 pm
Anybody?
What is the byte index of the RSA signature?(Like, is it 20, 0x00020, 30, or what??? I prefer the answer in integer if possible, but I can still use hex)
If it's so secretive, please PM me with the answer.
Or, somebody post links to captures of a official Download Play session, with a compilation of the captures into a .nds.
Maybe I should try PMing another member, whom would know about this...
#149145 - yellowstar - Wed Jan 16, 2008 12:29 am
I found where that rsa signature is. It's at the end of the .nds. To get that byte index, read address 0x80 in the .nds, as an int, and that will tell you where the signature is.
| Code: |
int *irsa_sig = (unsigned int*)&nds_data[0x80];//nds_data should be unsigned char *
unsigned char *rsa_sig = &nds_data[*irsa_sig];
|
(I found it in the source for that homebrew ndsrsa signer, which obviously can't do what it's intended for)(Nothing signed with it can pass the RSA check, since we don't know the private RSA key)
| NDSTech Wiki wrote: |
.. but it is my understanding that the signature is a 128 byte public key and an 8 byte SHA-1 message digest over the NDS header, ARM9 binary, and ARM7 binary. |
The section in bold is the problem: the SHA-1 message digest. Sending the SHA-1 message digest, from the .nds RSA signature, won't work.(modding Juglak's WMB host)
Apparently, the official Download Play client in original/official firmware, is rigged to terminate the connection during data transfer, if the SHA-1 message digest is wrong. The transfer is fine if the digest isn't copied to the WMB data. How do I calculate this digest?(With OpenSSL, if needed)
I'm trying to capture the WMB transfer for this demo, to check that digest.
But, I can only do it with DSes, since I don't have a WiFi adapter. But,
the other two systems, which are needed for this, are extremely difficult
to get access to.(I don't own those)
#149226 - yellowstar - Thu Jan 17, 2008 12:18 am
I noticed there's some null data, between the end of the demos' header,
and the arm9 code. I found out that changing this data will not invalidate
the RSA signature. Is it possible extend this to a decent size? (Normally, it's only 8KB...)
I think it could be done, without screwing the RSA, but WMB hosts and the official client might have a problem with that...(I want to use that section for a homebrew WMB bootloader)
I did some WMB captures last night. But, it seems it only captured the
beacon packets, and nothing else. I'm going to change the code and try again.
The demo I'm using is Meteos.(I'm going to use a different game for this bootloader if it can be done.)
I'm going to find out if using different demos does anything.
#149235 - yellowstar - Thu Jan 17, 2008 1:17 am
It worked! I tried using the Poluriam demo, instead of the Meteos demo,
and it worked! Apparently, something went wrong with the Meteos capture,
and that corrupted the RSA signature... Is it possible to fix this, without doing another capture to grab that RSA?
#149296 - yellowstar - Fri Jan 18, 2008 12:32 am
For some reason, this mod of this WMB host is acting up again, and it fails to complete the transfer, like when SHA-1 is wrong. But, I checked where it's getting the RSA data from, and it's the right place. I have it rigged so it grabs that data based on the size of the nds_data, instead of the value of 0x80.(Maybe switching it back would fix it)
I figured out a way to get homebrew to boot with the official WMB bootloaders. There would be some homebrew code in that unsigned section of the WMB data. The execute address would be set to this. The homebrew code would overwrite some opcodes in the official bootloader code, so it wouldn't care if the binary fails the RSA check. Then, the homebrew code would cause a jump to the official code, to the same address as if the execute address wasn't modified. Then, a homebrew app would send this bootloader over WMB, and follow the protocol for it, and send the homebrew. It would work, as long as the opcode overwriting worked.
I could get rid of this WMB host whenever somebody figures out how to
use the Multicast functionality in liblobby...
#151737 - yellowstar - Tue Mar 04, 2008 1:47 am
Has anybody successfully cracked the official WMB bootloaders?(Or, the "second-stage loaders?")
That is, the bootloader protocol.
#153882 - yellowstar - Mon Apr 07, 2008 8:59 pm
Here's the hacking battle plan, in a new form:
WMB official bootloader hacking for homebrew plan:
Step 1. Finish that WMB capture assembler. Please help with that WMB beacon topic of mine. Right now I can't put together the icon and such. This isn't really important for this hack, but I still need this tool to be finished so I can get a .nds of the Mario Kart bootloader. I'm not finishing the tool 'till beacons are fixed.
2. Obtain packet captures of the whole Mario Kart WMB process. Till the WMB beacons, to the end of the transfer when the game starts.(Where P1 chooses his character and ect)
3. Assemble the captures, and test the bootloader by sending it via WMB.
4. Reverse Engineer the Mario Kart bootloader transfer protocol.
5. Test it by sending the Mario Kart game with the RE'd protocol, which was originally sent by the Mario Kart game, after the bootloader was sent.
6. The sent addresses sent in the RSA frame would be modified to point to a unsigned section in the header. The code in the header would overwrite some code in the RSA-checking, so the bootloader doesn't care about RSA anymore. Next, the code would jump to wherever the code would have began execution normally.
7. Do the test in step 5 again, except nullify the RSA so the binary seems to be homebrew to the bootloader. If that works, yippee! Otherwise, something went wrong with either step 6, or the protocol.
8. Now, for the big moment: We send some homebrew, instead of the MK game. If that works, EUREKA!
#154711 - yellowstar - Sun Apr 20, 2008 8:28 pm
My idea is toasted. I was tinkering with a test WMB app, to see if I would get some hb code running via WMB, and with no success. Modding the run addresses in the RSA frame didn't help. Changing addrs in the header obvously screwed RSA when I tried that. And today I found this, a hb booting document by tepples. Apparently, in the past the WMB client used to only use the run addrs in the RSA frame. But now, it only uses the addrs in the header, rendering my plan useless.
#154954 - HyperHacker - Wed Apr 23, 2008 6:36 am
Didn't you say you were able to inject arbitrary data between the header and the data or something? Couldn't you pad it out so the run addresses in the header point to somewhere in that data?
_________________
I'm a PSP hacker now, but I still <3 DS.
#155025 - yellowstar - Thu Apr 24, 2008 12:53 am
| HyperHacker wrote: |
| Didn't you say you were able to inject arbitrary data between the header and the data or something? Couldn't you pad it out so the run addresses in the header point to somewhere in that data? |
No, I don't think so. That would invalidate the RSA-signature.
I thought WMB sent the whole 0x1FF header. But, when I was tinkering as in that previous post, I found it only sends sends 0x160. That clobbers the reserved 160 byte section at the end of the header I was using.(No, that's not the section you're referring to)
Strangely, the client WMB DS had a hissey fit when I modified address 0x160 though 0x1FF. And WMB doesn't send data in that section in the header. So it must be sending from 0x160, to the end of the Arm9 binary. Maybe? I really don't know. My DS-X is totaled, won't work even with my trick anymore, or I'd try some experiments.