DSi unlaunch (bootcode exploit)
Re: DSi unlaunch (bootcode exploit)
I'll note here that 1.1 seems to have been successfully installed and is functioning correctly on my 1.4.5A DSi.
Re: DSi unlaunch (bootcode exploit)
Yes, wifiboot (and dslink) are normal NDS tools, you could boot them on any NDS console from flashcart.Banshaku wrote:What I would like to know if the wifiboot exist for something like the ds lite?
Or, without flashcart: You could install the DS Xboo firmware: That's leaving about 200kbytes free space on the firmware chip, which can be used to install a small NDS rom-image in firmware memory (eg. wifiboot). The thing that had kept most people (if not everybody) from doing that is that the installation stuff relies on having a bunch of wires connected to parallel port (and with some more wires you could also upload software via cable, at speeds faster than wifi's 2Mbit/s).
Could be nice... if there are more than a few people having compatible WLAN adaptors. And I guess one would additionally need a flashcart or other hardware for patching the firmware's RSA check (unless there's a way around that, I guess could find exploits in rsa-signed games, or use the rsa-signed menu from demo stations).tepples wrote:There is WiFiMe, usable with a FlashMe'd DS (to skip DS Download Play's RSA check). But I think that requires a USB WLAN adapter with a certain Ralink chipset.
Anyways, the thing that I am interested in would be transfer protocol. Is there any source code for WiFiMe? Or are there homebrew single-cart multiplayer NDS games? It would be nice to know how to make such games (though they would work only when patching the RSA check at receiver side), and it would be nice to implement the receiver side in DS Xboo firmware someday.
Might be because I haven't cleared all vram and palette memory. I could have a look at supporting those flashcarts - if you could upload rom-images for the flashcart bootmenues somewhere.Apache Thunder wrote:Ok noticing a minor graphics issue when booting a cart via the cart loader.
I should probably also clear main ram and wram (though commercial games seem to do that themselves). But I don't like the idea of zerofilling 16Mbytes of memory. I guess something SwiCpuSet could be relative fast, and DMA might be a bit faster, probably clearing 4 bytes per clock cycle at 33MHz, so 16Mbytes would take 125ms, plus some more time for wram & vram : /
- Apache Thunder
- Posts: 24
- Joined: Tue Jul 24, 2018 6:28 pm
Re: DSi unlaunch (bootcode exploit)
I do have a rom of the DS-X (at least 1.2 firmware version of the cart. You probably wouldn't need all of them)
I can rom dump the Cyclo iEvolution but I bet it may be an issue with the game it's pretending to be while in TWL mode. Look to see if you have issues booting the Cooking Coach game it is pretending to be. If the real game works...not sure why the iEvo one wouldn't I could rom dump it but that wouldn't help It would just be the same one the real game uses. (it's exploit code is in the save file. I can probably dump that if you want it)
I have the decrypted boot menu for iEVo too. I was able to boot the cart with that and skip loading the game. But it fails to boot any DSi Enhanced roms though. I think there's something the exploit code in the save file of the spoofed Cooking Coach rom may be setting up first maybe?
Anyways the R4 works fine.
I think you just need to clear VRAM/Palette data and it will be fine. Clearing main ram is probably not a good idea.. It would break the soft-reset data region some apps could use to make Launcher auto boot things.
I've attached the rom dump of the DS-X below: EDIT:
and the iEvo files if you want to look at those:
I uploaded the original iEvo boot menu SRL. I have one I converted to a SRL System Menu can launch, but that's probably not what you want to look at right now.
I can rom dump the Cyclo iEvolution but I bet it may be an issue with the game it's pretending to be while in TWL mode. Look to see if you have issues booting the Cooking Coach game it is pretending to be. If the real game works...not sure why the iEvo one wouldn't I could rom dump it but that wouldn't help It would just be the same one the real game uses. (it's exploit code is in the save file. I can probably dump that if you want it)
I have the decrypted boot menu for iEVo too. I was able to boot the cart with that and skip loading the game. But it fails to boot any DSi Enhanced roms though. I think there's something the exploit code in the save file of the spoofed Cooking Coach rom may be setting up first maybe?
Anyways the R4 works fine.
I think you just need to clear VRAM/Palette data and it will be fine. Clearing main ram is probably not a good idea.. It would break the soft-reset data region some apps could use to make Launcher auto boot things.
I've attached the rom dump of the DS-X below: EDIT:
and the iEvo files if you want to look at those:
I uploaded the original iEvo boot menu SRL. I have one I converted to a SRL System Menu can launch, but that's probably not what you want to look at right now.
Re: DSi unlaunch (bootcode exploit)
So after emailing with nocash about an unkown emmc/cid error with unlaunch, he asked me to take a picture of the chip. i hope i took a picture of the right one, but here it is.
I hope its clear enough.
I hope its clear enough.
Re: DSi unlaunch (bootcode exploit)
Many thanks! I'll remove the unknown chip warning in next version. The picture is clear enough, in fact the resolution is a bit overkill, but the chip's part number is pretty well legible:
ST, NAND02G, AH0LZC5, HH563 8Y, KOR 99 935
Going by similar datasheets (for non-eMMC chips), the "02G" stands for 2 gigabit, and the next some letters should be package/temperature/voltage/bustype and the like.
That ST chips appear to be quite rare. There've been only two people reporting the unknown eMMC warning message showing up in unlaunch; showing these values:
The date code in first byte can be AC or BC (the one in the above photo has value AC), with C meaning year 1997+12=2009, and A/B meaning october/november. So it seems that nintendo has used that ST chips only for a short period, close to the launch of the DSi XL console (unless other people have ST chips with other datecodes).
The differences in the CSD value translate to:
ST, NAND02G, AH0LZC5, HH563 8Y, KOR 99 935
Going by similar datasheets (for non-eMMC chips), the "02G" stands for 2 gigabit, and the next some letters should be package/temperature/voltage/bustype and the like.
That ST chips appear to be quite rare. There've been only two people reporting the unknown eMMC warning message showing up in unlaunch; showing these values:
Code: Select all
AC XX XX XX XX 30 36 35 ;\CID
32 43 4D 4D 4E 01 FE 00 ;/
00 40 8A E0 BF FF 7F F5 ;\CSD
80 59 0F 32 01 2F 90 00 ;/
80 80 FF 80 00 04 00 00 ;OCR etc ...
00 00 00 00 01 00 01 00
00 00 00 00 00 00 00 00
00 09 00 00 00 01 D0 40
00 00 01 00
The differences in the CSD value translate to:
Code: Select all
Samsung Samsung ST
bit name KMAPF0000M KLM5617EFW NAND02GAH0LZC5
112-119 TAAC 26h=1.5ms 27h=15ms 2Fh=20ms
96-103 TRAN_SPEED 2Ah=20MHz 32h=25MHz 32h=25MHz
79 READ_BL_PARTIAL 0=No(?) 0=No(?) 1=Yes
62-73 C_SIZE 77Fh=240MB 77Fh=240MB 3D5h=245.5MB
59-61 VDD_R_CURR_MIN 6=60mA 6=60mA 7=100mA
56-58 VDD_R_CURR_MAX 6=80mA 6=80mA 7=200mA
53-55 VDD_W_CURR_MIN 6=60mA 6=60mA 7=100mA
50-52 VDD_W_CURR_MAX 6=80mA 6=80mA 7=200mA
47-49 C_SIZE_MULT 6=256 6=256 7=512
42-46 ERASE_GRP_SIZE 1Fh=32x32 00h=1x32 1Fh=32x32
32-36 WP_GRP_SIZE 09h=10 1Fh=32 00h=1
26-28 R2W_FACTOR 05h=32x 03h=8x 02h=4x
14 COPY 1=Copy 1=Copy 0=Original
Last edited by nocash on Sun Aug 12, 2018 8:35 am, edited 1 time in total.
Re: DSi unlaunch (bootcode exploit)
Released unlaunch v1.2 - http://problemkaputt.de/unlaunch.htm
I've benchmarked some memory fill methods. Filling the whole VRAM via STMIA opcodes takes around 6ms, which is more or less acceptable. Filling Main RAM is pretty slow, and timings depend on how it's done:
- 120ms for filling 2Mbyte via STMIA opcodes (if destination is uncached)
- 54ms for filling 2Mbyte via STMIA opcodes (if destination is cached-with-writebuffering)
- 49ms for filling 2Mbyte via DMA transfers
So filling 16Mbytes (for DSi titles) would take about 400ms, and filling 4Mbytes (for NDS titles) would take 100ms. That's even slow than I had thought (parts because I forgot that main ram is using 16bit databus, not 32bit, and because there seems to be some further overload, maybe the hardware inserts extra cycles after each 16-byte snippet or so). Anyways, 400ms is too slow.
The three different eMMC chips are now accepted without warning (but the warning is kept in there, in case some consoles have yet different chips).
The unknown camera warning is also kept in there - but so far nobody has reported it being triggered, so it seems that nintendo has never used the unknown camera devices, and all consoles contain the same aptina cameras. But who knows, maybe some rare/early consoles have the unknown cameras in there.
Btw. speaking of those cameras, their initialization sequence is documented here: http://problemkaputt.de/gbatek.htm#dsia ... nufacturer does anybody know a camera/datasheet matching that sequence? Register [03h] is apparently some "bank" registers for accessing more than 256 registers, and there are other characteristic things like writing an array with 22 increasing numbers to [1:8Dh+(0..21)]. I guess anybody who has ever worked with that cameras will immediately recognize them.
I could/should also add warnings about Chinese iQue DSi consoles having an "unknown firmware", as well as early japanese ones with firmware v1.0 (assuming that that version did actually exist). Or, if somebody has already dumped such firmwares, please let me know. I would be mainly interesting in getting a filesystem tree with filenames, filesizes, and crc32's, for checking if there were different or completely missing system files on that consoles.
Code: Select all
v1.2 05 Aug 2018
- rom loader: variable ARM9 secure area size=4000h..1000h, or skips if none
- zerofills vram/oam/palette before starting other titles (takes about 6ms)
- arm7_copy_scfg_state_to_ram_and_wram (passes SCFG_OP to ARM9 side)
- supports twl-debugger (with 80h-byte address shift, without region patches)
- removed forced SFCG_EXT.bit31=1 patches (since they weren't too useful)
- fixed color-flash on patch errors, resumes further patches after keystroke
- added wildcard for anti-black-fill patch (did hang firm v1.4.5 since v0.9)
- moved unknown camera/emmc warnings after dsi-mode check, ie. not in nds-mode
- removed warning on unknown CID/CSD for ST NAND02GAH0LZC5 eMMC chips
- 120ms for filling 2Mbyte via STMIA opcodes (if destination is uncached)
- 54ms for filling 2Mbyte via STMIA opcodes (if destination is cached-with-writebuffering)
- 49ms for filling 2Mbyte via DMA transfers
So filling 16Mbytes (for DSi titles) would take about 400ms, and filling 4Mbytes (for NDS titles) would take 100ms. That's even slow than I had thought (parts because I forgot that main ram is using 16bit databus, not 32bit, and because there seems to be some further overload, maybe the hardware inserts extra cycles after each 16-byte snippet or so). Anyways, 400ms is too slow.
The three different eMMC chips are now accepted without warning (but the warning is kept in there, in case some consoles have yet different chips).
The unknown camera warning is also kept in there - but so far nobody has reported it being triggered, so it seems that nintendo has never used the unknown camera devices, and all consoles contain the same aptina cameras. But who knows, maybe some rare/early consoles have the unknown cameras in there.
Btw. speaking of those cameras, their initialization sequence is documented here: http://problemkaputt.de/gbatek.htm#dsia ... nufacturer does anybody know a camera/datasheet matching that sequence? Register [03h] is apparently some "bank" registers for accessing more than 256 registers, and there are other characteristic things like writing an array with 22 increasing numbers to [1:8Dh+(0..21)]. I guess anybody who has ever worked with that cameras will immediately recognize them.
I could/should also add warnings about Chinese iQue DSi consoles having an "unknown firmware", as well as early japanese ones with firmware v1.0 (assuming that that version did actually exist). Or, if somebody has already dumped such firmwares, please let me know. I would be mainly interesting in getting a filesystem tree with filenames, filesizes, and crc32's, for checking if there were different or completely missing system files on that consoles.
Last edited by nocash on Sun Sep 16, 2018 5:16 pm, edited 1 time in total.
- Apache Thunder
- Posts: 24
- Joined: Tue Jul 24, 2018 6:28 pm
Re: DSi unlaunch (bootcode exploit)
My DS-X still isn't bootable with the cart loader as well as my Cyclo iEvolution when that cart is in DSi mode. (will load the the cart fine if the cart is in NTR mode and is using the NTR rom) I'm guessing you haven't had a chance to look at that for 1.2 yet.
The graphics corruption for R4/Max Media Dock cart is gone so looks like the VRAM/Palette clear fixed it.
Also, tried to run Unlaunch 1.2 installer as bootthis.dsi just blackscreens....Odd. It ran fine as boot.nds from sudokuhax however.
The graphics corruption for R4/Max Media Dock cart is gone so looks like the VRAM/Palette clear fixed it.
Also, tried to run Unlaunch 1.2 installer as bootthis.dsi just blackscreens....Odd. It ran fine as boot.nds from sudokuhax however.
Re: DSi unlaunch (bootcode exploit)
Found a bug when having homebrew named as "bootcode.dsi".
The power button doesn't work, if set to IRQ. It only works when setting it to Auto-Reset.
I don't recall the issue occurring in previous Unlaunch versions.
The power button doesn't work, if set to IRQ. It only works when setting it to Auto-Reset.
I don't recall the issue occurring in previous Unlaunch versions.
Re: DSi unlaunch (bootcode exploit)
Tried the 1.2 and still i get stuck on startup on unlaunch's screen, i also tried the cardboot feature, and i couldn't manage to run some games, and i found that the only difference between those games that boots and the ones that don't is that those games use wifi featuers. I think that probably this is still related to the fact that i cannot boot into system menu with versions after 0.8, interesting fact, i tried some old ones, and while the 0.6 works, the 0.7 has the same issue. Also i tested this version on my nand backup used with no$gba, and it works...
Re: DSi unlaunch (bootcode exploit)
Update, i done another backup of my nand, with unlaunch 1.2 installed (that didn't boot), and on no$gba it does
Re: DSi unlaunch (bootcode exploit)
The last change to power button was in unlaunch v1.0 (switching it power-button-IRQ-mode) (the older versions had it set to power-button-auto-reset mode).Robz8 wrote:Found a bug when having homebrew named as "bootcode.dsi".
The power button doesn't work, if set to IRQ. It only works when setting it to Auto-Reset.
I don't recall the issue occurring in previous Unlaunch versions.
If IRQ mode doesn't work... maybe it does still have an old IRQ pending and refuses to issue a new IRQ until acknowledging the old one... by reading BPTWL register 10h? Or maybe the IRQ and pin-direction isn't configured in GPIO registers? Or something in IE2/IF2 registers?
Do you have a link to some homebrew title that shows the effect?
Re: DSi unlaunch (bootcode exploit)
Cooking Coach is working on my console (showing the game's loading screen, and then triggering the dslink exploit). The exploit used in iEvolution might be a bit different... or, if you don't even see the cooking coach loading screens: Then it must be some hardware issue with the cartridge imperfectly cloning the dsi-cartridge hardware. Not much that I could do about it without having one of those cartridges.Apache Thunder wrote:My DS-X still isn't bootable with the cart loader as well as my Cyclo iEvolution when that cart is in DSi mode. (will load the the cart fine if the cart is in NTR mode and is using the NTR rom) I'm guessing you haven't had a chance to look at that for 1.2 yet.
The "raw" iEvolution menu (without the cooking coach stuff) was interesting because it didn't work with no$gba's low level cart emulation (because it's reading ARM9 code from offset 200h, ie. from within the cart header area - that's actually NOT working on official carts, but custom flashcarts could do so - I've changed the emulation to accepts such reads if the cart header is pointing such offsets).
What is a DS-X, another flashcart? I don't have a ROM-image for testing that.
Odd, that doesn't happen for me. I am normally using wifiboot to upload the installer. But renaming unlaunch.dsi to bootthis.dsi works fine for me, too.Apache Thunder wrote:Also, tried to run Unlaunch 1.2 installer as bootthis.dsi just blackscreens....
Re: DSi unlaunch (bootcode exploit)
Yeah, my launcher patches did hang when loading firmware v1.4.5 in most unlaunch versions. That issue occured in v0.7 and v0.9-v1.1. But it should work okay in unlaunch v1.2. But you have got it installed, and it's showing the correct versions string for v1.2 (NOCASH UNLAUNCH.DSI V1.2) and just hangs there? Well, then that would be some different issue unrelated to the patches...edo9300 wrote:Tried the 1.2 and still i get stuck on startup on unlaunch's screen, i also tried the cardboot feature, and i couldn't manage to run some games, and i found that the only difference between those games that boots and the ones that don't is that those games use wifi featuers. I think that probably this is still related to the fact that i cannot boot into system menu with versions after 0.8, interesting fact, i tried some old ones, and while the 0.6 works, the 0.7 has the same issue. Also i tested this version on my nand backup used with no$gba, and it works...
You have made a eMMC from the non-working state, and that's working in no$gba? And you have the Reset/Startup Entrypoint option set to "GBA/NDS BIOS", so it's showing the Unlaunch loading screen, and then boots into the official boot menu?
If that's working then it seems to be more a hardware issue... I've tested unlaunch with both wifi board versions and they are both working okay. Different eMMC chips probably shouldn't cause problems (but I've only the KMAPF0000M-S998 one for testing). Uhm, or different Console IDs... that might be a problem if you have used a firmware from a different console (like trying to run a european firmware on a japanese console)?
PS. The wifi issues... which games are affected by that? And are that NDS games or DSi(-enhanced) games? And do you know which DWM-W0xx wifi board version you have in the console?
EDIT: Found a terrible mistake: Skipping wifi init was supposed to be done when pressing button Y, but I've somehow assigned it to button B, ie. the same button as for booting from ROM cartridge slot - so that should explain wifi issues for ROM cartridges.
- Apache Thunder
- Posts: 24
- Joined: Tue Jul 24, 2018 6:28 pm
Re: DSi unlaunch (bootcode exploit)
The iEvo SRL I was able to manually rebuild to a version that System Menu can use. It loads arm9 to an address higher then the normal 0x2000000 so I was able to offset it to account for a blank secure area without issue. (By simply having load address 0x800 lower then entry address so the entry address is still at the original location)
Anyways the cart doesn't even show the Cooking Coach boot logos. Just blackscreens. I guess not much can be done about it if you have the original game it's spoofing working. The cart is still going for $40+ on the one flashcart site that's still selling it so yeah it's still expensive to get.
As for my DS-X. I did post the rom image for it in a previous reply. You must have missed it. Here's the link to it I had attached to that reply:
download/file.php?id=13190
Anyways the cart doesn't even show the Cooking Coach boot logos. Just blackscreens. I guess not much can be done about it if you have the original game it's spoofing working. The cart is still going for $40+ on the one flashcart site that's still selling it so yeah it's still expensive to get.
As for my DS-X. I did post the rom image for it in a previous reply. You must have missed it. Here's the link to it I had attached to that reply:
download/file.php?id=13190
Re: DSi unlaunch (bootcode exploit)
Yeah, i too was suspecting it was an hardware issue, now i'm asking myself if it's because of damaged components or some different chips of the ds. As for the firmware, i didn't do nothing of those things, i only installed unlaunch via flipnote and that's all, i didn't modify my nand in other ways. I could send pics of my console if needednocash wrote: If that's working then it seems to be more a hardware issue... I've tested unlaunch with both wifi board versions and they are both working okay. Different eMMC chips probably shouldn't cause problems (but I've only the KMAPF0000M-S998 one for testing). Uhm, or different Console IDs... that might be a problem if you have used a firmware from a different console (like trying to run a european firmware on a japanese console)?