Homebrew [RELEASE] TWLTool - DSi downgrading, save injection, etc multitool

[loco365]

That error sounds like a ticket check failing somewhere - be it verification or just not existing.
I personally can't get my eMMC image to boot. I get notyet32s on ConsoleID reading (which i assume is intended behavior since all the AES keys check out, including the ConsoleID-using ones) and then boot2 throws 'Error: 1-2345-8325'.

EDIT: nevermind! Got it to boot after nopping out the AES keysetting instructions in boot2 that were dependent on the consoleID registers. They were setting bad AES words (0 xor the two different values they xor the consoleID against).

Out of curiosity, how did you set up the NAND image for booting in No$GBA? I haven't found anything as to indicate what needs to be named what, nor what needs to be placed where. I should be getting my DSi back next week so I can dump my BIOS files that are needed, but it'd be nice to know what I need to name them and where they go. Or does No$ issue prompts when it attempts to boot from the DSi BIOS files?

 

[nocash123]

That error sounds like a ticket check failing somewhere - be it verification or just not existing.

Yeah, LAUNCH_RIGHTS sounds somewhat like ticket or region error. But I am sure that I have the tickets & everything in the eMMC image. Only thing that might be wrong is that the bootcode in BIOS ROM might initialize a region flag or some AES keys which I am not aware of yet - that could cause stuff like region/decryption errors.
The error is fired here (in Launcher of european 1.4E firmware):

                   ;------------------
                    ;in: r0 = ptr to title_id,etc (2777800h)
                    ; [r0+00h] = title.id.lsw = "PINH" (for camera)
                    ; [r0+04h] = title.id.msw = 05,00,03,00
                    ; [r0+08h] = 0007h
  026A5778 B5F0     push    r4-r7,r14
  026A577A B085     add     sp,-14h
  026A577C 1C04     mov     r4,r0         ;ptr to title.id, ...and... more info
  026A577E F01EFEBB bl      26C44F8h     ------>  timer? sync? random?
  026A5782 8920     ldrh    r0,[r4,8h]
  026A5784 0700     lsl     r0,r0,1Ch  ;\isolate bit3-1
  026A5786 0F40     lsr     r0,r0,1Dh  ;/
  026A5788 2803     cmp     r0,3h
  026A578A D10D     bne     26A57A8h  ;okay
  026A578C 6820     ldr     r0,[r4]     ;title.id.lsw
  026A578E 6861     ldr     r1,[r4,4h]  ;title.id.msw
  026A5790 F024FDCC bl      26CA32Ch     ------>
  026A5794 2800     cmp     r0,0h
  026A5796 D007     beq     26A57A8h   ;okay
  026A5798 4939     ldr     r1,=2798C40h
  026A579A 6088     str     r0,[r1,8h]
  026A579C 2012     mov     r0,12h ;tok_12h_txt_error_check_title_launch_rights_failed
  026A579E F7FDFE69 bl      26A3474h   ;error

Either bit1-3 of the incoming [r0+08h] value are wrong, or "bl 26CA32Ch" is failing to do whatever it is supposed to do.

I personally can't get my eMMC image to boot. I get notyet32s on ConsoleID reading (which i assume is intended behavior since all the AES keys check out, including the ConsoleID-using ones) and then boot2 throws 'Error: 1-2345-8325'.

The notyet's are warning about unemulated I/O ports, either completely unemulated ones, or, in this case, only 32bit reads being unemulated (normally port 4004D00h is accessed in 16bit units, and I wasn't sure if the hardware does implement 32bit reading at all, although now mention it, I see some functions using 32bit reads for that I/O port).

EDIT: nevermind! Got it to boot after nopping out the AES keysetting instructions in boot2 that were dependent on the consoleID registers. They were setting bad AES words (0 xor the two different values they xor the consoleID against).

That sounds like this code (from ARM7 boot sectors):

  37B81A8 E59F0148 ldr     r0,=3FFC400h
  37B81AC E5D00220 ldrb    r0,[r0,220h] ;[3FFC620h]
  37B81B0 E3500000 cmp     r0,0h
  37B81B4 0A000000 beq     37B81BCh ;@@keep_keys
  37B81B8 EB00065E bl      37B9B38h ;set_aes_key1x_and_key3_parts ;-AES (CPU ID)
                  @@keep_keys:

3FFC620h would contain keys relocated from the upper half of the BIOS ROM (to get emulated properly, you would need those keys in the BIOS ROM image). Whereas, I am not absolutely sure what should be stored at 3FFC620h, it could be either one:
1) it could contain the correct keys, then "bl 37B9B38h" would initialize some AES words.
2) it could be zerofilled, then "bl 37B9B38h" would be skipped (and the ROM bootcode be required to have already initialized that AES keys).
Either one should work on hardware (and no$gba). Not sure what happened in your case, sounds as if [3FFC620h] was nonzero, but also not containing the correct XOR values.

 

[WulfyStylez]

Yeah, LAUNCH_RIGHTS sounds somewhat like ticket or region error. But I am sure that I have the tickets & everything in the eMMC image. Only thing that might be wrong is that the bootcode in BIOS ROM might initialize a region flag or some AES keys which I am not aware of yet - that could cause stuff like region/decryption errors.
The error is fired here (in Launcher of european 1.4E firmware):

                   ;------------------
                    ;in: r0 = ptr to title_id,etc (2777800h)
                    ; [r0+00h] = title.id.lsw = "PINH" (for camera)
                    ; [r0+04h] = title.id.msw = 05,00,03,00
                    ; [r0+08h] = 0007h
  026A5778 B5F0     push    r4-r7,r14
  026A577A B085     add     sp,-14h
  026A577C 1C04     mov     r4,r0         ;ptr to title.id, ...and... more info
  026A577E F01EFEBB bl      26C44F8h     ------>  timer? sync? random?
  026A5782 8920     ldrh    r0,[r4,8h]
  026A5784 0700     lsl     r0,r0,1Ch  ;\isolate bit3-1
  026A5786 0F40     lsr     r0,r0,1Dh  ;/
  026A5788 2803     cmp     r0,3h
  026A578A D10D     bne     26A57A8h  ;okay
  026A578C 6820     ldr     r0,[r4]     ;title.id.lsw
  026A578E 6861     ldr     r1,[r4,4h]  ;title.id.msw
  026A5790 F024FDCC bl      26CA32Ch     ------>
  026A5794 2800     cmp     r0,0h
  026A5796 D007     beq     26A57A8h   ;okay
  026A5798 4939     ldr     r1,=2798C40h
  026A579A 6088     str     r0,[r1,8h]
  026A579C 2012     mov     r0,12h ;tok_12h_txt_error_check_title_launch_rights_failed
  026A579E F7FDFE69 bl      26A3474h   ;error

Either bit1-3 of the incoming [r0+08h] value are wrong, or "bl 26CA32Ch" is failing to do whatever it is supposed to do.


The notyet's are warning about unemulated I/O ports, either completely unemulated ones, or, in this case, only 32bit reads being unemulated (normally port 4004D00h is accessed in 16bit units, and I wasn't sure if the hardware does implement 32bit reading at all, although now mention it, I see some functions using 32bit reads for that I/O port).


That sounds like this code (from ARM7 boot sectors):

  37B81A8 E59F0148 ldr     r0,=3FFC400h
  37B81AC E5D00220 ldrb    r0,[r0,220h] ;[3FFC620h]
  37B81B0 E3500000 cmp     r0,0h
  37B81B4 0A000000 beq     37B81BCh ;@@keep_keys
  37B81B8 EB00065E bl      37B9B38h ;set_aes_key1x_and_key3_parts ;-AES (CPU ID)
                  @@keep_keys:

3FFC620h would contain keys relocated from the upper half of the BIOS ROM (to get emulated properly, you would need those keys in the BIOS ROM image). Whereas, I am not absolutely sure what should be stored at 3FFC620h, it could be either one:
1) it could contain the correct keys, then "bl 37B9B38h" would initialize some AES words.
2) it could be zerofilled, then "bl 37B9B38h" would be skipped (and the ROM bootcode be required to have already initialized that AES keys).
Either one should work on hardware (and no$gba). Not sure what happened in your case, sounds as if [3FFC620h] was nonzero, but also not containing the correct XOR values.

I've actually already modified my BIOSes with keys where they should be, thus why I was able to boot at all. The issue was specifically in boot2, at 0x37bB4c and 0x37b9b60. Then, if both of those were nopped to not write the invalid keyX parts, another would be thrown at 0x37B9B74. Patching that last one would finally give me a successful boot to the menu.

As for the menu failing out, I may look into it myself and tell you if I find anything interesting.

 

[loco365]

Don't want to spoil the fun, but I think the region is stored here (and cannot be changed):

FAT16:\sys\HWINFO_S.dat (aka Serial/Barcode) (16Kbytes)
  0000h 80h   RSA-SHA1-HMAC across entries [0088h..00A3h]
              (with RSA key from Launcher)
              (with SHA1-HMAC key = SHA1([4004D00h..4004D07h])
  0080h 4     Header, Version or so (00000001h)
  0084h 4     Header, Size of entries at [0088h..00A3h] (0000001Ch)
  0088h 4     Bitmask for Supported Languages (3Eh for Europe) (as wifi_flash)
  0088h 4     Unknown (00,00,00,00)  (bit0=flag for 4004020h.bit0 ?)
  0090h 1     Console Region (0=JPN, 1=USA, 2=EUR, 3=AUS, 4=CHN, 5=KOR)
  0091h 12    Serial/Barcode (ASCII, 11-12 characters; see console sticker)
  009Dh 3     Unknown (00,00,3C)                     ;"<"
  00A0h 4     String "PANH" (aka HNAP=Launcher spelled backwards?)
  00A4h 3F5Ch Unused (FFh-filled)
Entries [0088h..009Fh] are copied to [2FFFD68h..2FFFD7Fh].

Should be impossible to modify the file (due to missing RSA private key), and also impossible to copy the file to/from other consoles (due to the Port 4004D00h console ID).
Patching the launcher or other executables won't work either (since they are RSA signed, too). Only chance would be finding an exploit in the launcher or other system utilities (eg. corruping a .sav or .jpg file, which could be done since that files aren't RSA signed). I am hoping that no$gba might get useful for that stuff.

Ah, that'd be an issue and a half to solve then. We'd probably have to wait for this RSA signing to be reverse-engineered, if it ever does happen. I do have some ideas as to how to work around it, but I highly doubt it'd work.

 

[nocash123]

I've actually already modified my BIOSes with keys where they should be, thus why I was able to boot at all. The issue was specifically in boot2, at 0x37bB4c and 0x37b9b60. Then, if both of those were nopped to not write the invalid keyX parts, another would be thrown at 0x37B9B74. Patching that last one would finally give me a successful boot to the menu.

Yes, that's in the function I talked of above. Ah, now I got it, you do probably have the correct keys in ROM/RAM (ie. are probably having a better dump than myself, I am only having zeroes at [3FFC620h..3FFC62Fh] , and then the non-emulated port 4004D00h reads are causing the problem.

If you could look into the menu problem would be fantastic!

Ah, that'd be an issue and a half to solve then. We'd probably have to wait for this RSA signing to be reverse-engineered, if it ever does happen. I do have some ideas as to how to work around it, but I highly doubt it'd work.

My understanding is that RSA cannot be reversed. We are only having the public key (so we can decrypt/verify the signatures), but not the private key (so we cannot encrypt/generate signatures). Options would be stealing the private key from Nintendo, or brute-forcing the key, both unlikely to happen in next some centuries.
But you could probably use sudokuhax to load the launcher/shop manually, and then patch and execute it (eg. first use the unpatched launcher to start sudoku, then use the patched launcher to start an import game). One problem might be that the ARM7 SCFG registers are disabled, and the launcher might refuse to work state.

 

[loco365]

My understanding is that RSA cannot be reversed. We are only having the public key (so we can decrypt/verify the signatures), but not the private key (so we cannot encrypt/generate signatures). Options would be stealing the private key from Nintendo, or brute-forcing the key, both unlikely to happen in next some centuries.
But you could probably use sudokuhax to load the launcher/shop manually, and then patch and execute it (eg. first use the unpatched launcher to start sudoku, then use the patched launcher to start an import game). One problem might be that the ARM7 SCFG registers are disabled, and the launcher might refuse to work state.

That's definitely a possibility. I'll play around with that once I get my DSi back next week and see what happens. I also happen to have a few tools that may do something, but I don't even know if they'll run let alone be of any use.

Edit: An interesting note I should perhaps make, but I was fooling around with a DSi I had a few years ago when the AceKard 2i was a thing, and I changed the language setting by using the DS BIOS rom through my AK2i, and for some reason some DSiWare actually failed to start even though I bought them (I think it was Mario Clock and Calculator that did this) although the DSi Main Menu was unaffected. Perhaps with this advent into the DSi I can investigate this and see if I can identify what caused it.

Edit 2: And it's shit like this why we should have a DSi section here.

 

[nocash123]

I seem to have got the "LAUNCH_RIGHTS" error to disappear after adding some parital/fake emulation for the atheros wifi firmware upload. But after passing the "LAUNCH_RIGHTS" check, I am still getting "an error has occurred" displayed on the screen (maybe because the wifi firmware upload stuff is still incomplete, or maybe for some other reason).
Anyways, at the moment it doesn't make sense to debug what is going on in no$gba (v2.8b) since the current unreleased version is already fixed some of the problems.

 

[VinsCool]

I got my dsi back with a nice hardmod

Thanks @Gadorach

 

[loco365]

I seem to have got the "LAUNCH_RIGHTS" error to disappear after adding some parital/fake emulation for the atheros wifi firmware upload. But after passing the "LAUNCH_RIGHTS" check, I am still getting "an error has occurred" displayed on the screen (maybe because the wifi firmware upload stuff is still incomplete, or maybe for some other reason).
Anyways, at the moment it doesn't make sense to debug what is going on in no$gba (v2.8b) since the current unreleased version is already fixed some of the problems.

Well, I'm looking forward to the next version to take a look at DSiWare. Also, I'm predicting that my DSi will be back next week so I can take a look at WinterMute's BIOS dumping utility. Out of curiosity, what size of BIOS files do you have, and what size should I expect them to be if they're a proper, full dump with both upper and lower regions?

 

[Gadorach]

Well, I'm looking forward to the next version to take a look at DSiWare. Also, I'm predicting that my DSi will be back next week so I can take a look at WinterMute's BIOS dumping utility. Out of curiosity, what size of BIOS files do you have, and what size should I expect them to be if they're a proper, full dump with both upper and lower regions?

Yup, it'll be heading on its way to you Monday morning.

 

[tozevleal]

Im hopeing for someone can find a vunerability on the DSi system with this new thing ... Maybe in the future Team twiizers will make a bannerbomb dsi edition...

 

[nocash123]

What OS is twltool-v1.1.zip intended to be used with? I tried twltool.exe, and Win98 is telling me that I need a newer version of windows. Then I tried on a Win7 notebook, and that is telling me that I must find out if my OS is 32bit or 64bit (after doing that, I assume that I will then know if I am having a 32bit OS or 64bit OS, and that twltool doesn't work on it either way).

 

[atkfromabove]

What OS is twltool-v1.1.zip intended to be used with? I tried twltool.exe, and Win98 is telling me that I need a newer version of windows. Then I tried on a Win7 notebook, and that is telling me that I must find out if my OS is 32bit or 64bit (after doing that, I assume that I will then know if I am having a 32bit OS or 64bit OS, and that twltool doesn't work on it either way).

I am using win7 64bit with no issues... might I ask why on earth you are using Win98?

 

[Flame]

What OS is twltool-v1.1.zip intended to be used with? I tried twltool.exe, and Win98 is telling me that I need a newer version of windows. Then I tried on a Win7 notebook, and that is telling me that I must find out if my OS is 32bit or 64bit (after doing that, I assume that I will then know if I am having a 32bit OS or 64bit OS, and that twltool doesn't work on it either way).

Are you martin the creator of no$gba?

 

[drwhojan]

Are you martin the creator of no$gba?

No S**t yes he is, give people here a clap! xd , He picked up on my PM Jhon591 from NGemu and was interested in this topic here for good reasons.

nocash, on win7s notebook right click on my computer see properties, it will tell you what the OS is under System type .

EDIT, don't forget if a system is 64bit and you are using a copy of 32bit windows you will have the same issue, Windows also has to match the PC max like 64bit windows for 64bit system, 32bit windows on 64bit pc no go, I'll check when I get home, my pc is 64 bit + win, Just a tip .

 

[piratesephiroth]

What OS is twltool-v1.1.zip intended to be used with? I tried twltool.exe, and Win98 is telling me that I need a newer version of windows. Then I tried on a Win7 notebook, and that is telling me that I must find out if my OS is 32bit or 64bit (after doing that, I assume that I will then know if I am having a 32bit OS or 64bit OS, and that twltool doesn't work on it either way).

Yeah, it's a x64 executable. You need a 64 bit windows. Or just ask @WulfyStylez to compile a 32 bit version.

 

[Gadorach]

Yeah, it's a x64 executable. You need a 64 bit windows. Or just ask @WulfyStylez to compile a 32 bit version.

Source code should be with TWLTool, compiling a 32bit executable shouldn't be an issue, unless the cases aren't set up in the makefile. I'd try and compile a 32bit version myself, but I'm running VS2010, and I'm too lazy to update it right now. TWLTool was built in VS2012 without compatibility set so I can't open its solution file, ha ha

 

[drwhojan]

OK got it loaded, But Also has to be ran in CMD Command promote, mood .

 

[Gadorach]

OK got it loaded, But Also has to be ran in CMD Command promote, mood .

Ha ha, auto-correct strikes again.

 

[piratesephiroth]

What OS is twltool-v1.1.zip intended to be used with? I tried twltool.exe, and Win98 is telling me that I need a newer version of windows. Then I tried on a Win7 notebook, and that is telling me that I must find out if my OS is 32bit or 64bit (after doing that, I assume that I will then know if I am having a 32bit OS or 64bit OS, and that twltool doesn't work on it either way).

No S**t yes he is, give people here a clap! xd , He picked up on my PM Jhon591 from NGemu and was interested in this topic here for good reasons.

nocash, on win7s notebook right click on my computer see properties, it will tell you what the OS is under System type .

EDIT, don't forget if a system is 64bit and you are using a copy of 32bit windows you will have the same issue, Windows also has to match the PC max like 64bit windows for 64bit system, 32bit windows on 64bit pc no go, I'll check when I get home, my pc is 64 bit + win, Just a tip .

Source code should be with TWLTool, compiling a 32bit executable shouldn't be an issue, unless the cases aren't set up in the makefile. I'd try and compile a 32bit version myself, but I'm running VS2010, and I'm too lazy to update it right now. TWLTool was built in VS2012 without compatibility set so I can't open its solution file, ha ha

OK, compiled a 32 bit version. Uploaded the whole updated zip here.
EDIT: no longer needs the vs2013 dlls