Homebrew So still no news on hiyacfw or rocket launcher

Swampat

The swamp monster that pats the ground
OP
Member
Joined
May 25, 2017
Messages
238
Trophies
0
Age
27
XP
230
Country
United States
its not like its the nintendo switch or whatever... its a dead console, who cares about people bricking their dsi's its their own risk...
This is what the 3ds scene is more like when a project is functional for public use they will warn you to use at your own risk and complaining wont do any good. So of we look at the point of when all this was announced a large majority of those who have downgraded understand the consequences so what exactly needs to be added to rocket launcher at this point to make it safe? He hasn't really l said its unstable, instead he says he is waiting.

--------------------- MERGED ---------------------------
 
  • Like
Reactions: siamese

Swampat

The swamp monster that pats the ground
OP
Member
Joined
May 25, 2017
Messages
238
Trophies
0
Age
27
XP
230
Country
United States
The DSi scene is quite small, so no need to rush it. Over time, it will become more and more developed.
Well I guess your right maybe when rocket launcher is released more developers will start to create homebrew for it. Hopefully some news or updates are announced.
 

Deleted member 424658

Annoying Weaboo Girl
Member
Joined
Jun 4, 2017
Messages
499
Trophies
0
Age
24
Website
www.reddit.com
XP
677
Country
United States
The DSi scene is quite small, so no need to rush it. Over time, it will become more and more developed.
Pretty ironic since you're the one who rushed to make a guide before anyone else could. And instead of calling it a downgrade guide, you call it "A complete guide to DSi hacking,
from stock to RocketLauncher + HiyaCFW."
 

incidentallyscribble

Well-Known Member
Member
Joined
Apr 24, 2016
Messages
863
Trophies
0
Age
38
XP
1,467
Country
United States
Pretty ironic since you're the one who rushed to make a guide before anyone else could. And instead of calling it a downgrade guide, you call it "A complete guide to DSi hacking,
from stock to RocketLauncher + HiyaCFW."
I admit defeat on that aspect, but the point is that even if there isn't a good reason that Hiya isn't released yet, I'm sure Apache Thunder is not planning on never releasing what people want.
Aka- hiya confirmed release is not Never™
 
Last edited by incidentallyscribble,

wicksand420

Well-Known Member
Member
Joined
Nov 13, 2016
Messages
2,787
Trophies
1
Age
39
XP
2,295
Country
United States
I was on the rocketlauncher thread a few days ago asking what exactly needed to be patched in the whitelist, and instead of someone giving me an answer, i just got some asshat saying the thread should be closed.
 

thom_tl

Well-Known Member
Member
Joined
Aug 18, 2017
Messages
180
Trophies
0
Location
Behind my desk.
XP
210
Country
Netherlands
I was on the rocketlauncher thread a few days ago asking what exactly needed to be patched in the whitelist, and instead of someone giving me an answer, i just got some asshat saying the thread should be closed.
He explains a bit of it here: .
in short in 1.4 nintendo doesn't check the rsa signature of the whitelist so we can install a modified one. they also added a third check which loads a few bytes of the first sector of the card into memory, where the signature and other validating parts of the card would be stored. but since we can modify the whitelist we can let it take in more bytes than arm7 expects and that causes a buffer overflow with arm7 sfcg unlocked then you could direct the buffer overflow to a payload loaded in memory and execute it. becouse arm7 sfcg is unlocked we have acces to nand, sd, and the card slot so we have full access.
 

mariogamer

Well-Known Member
Member
Joined
Aug 12, 2015
Messages
1,256
Trophies
0
Age
28
XP
790
Country
Canada
I believe the devs planned the whole thing very badly.... The leak also doesn't help....

There was no reason to actually say so much about the exploit but not releasing it.... And thiking about it, I'm not hyped about a possible dsi cfw (and maybe that's the reason why no one re-implemented RocketLauncher)

--------------------- MERGED ---------------------------

The DSi scene is quite small, so no need to rush it. Over time, it will become more and more developed.
That's not true or very unlikely... Unlike the 3ds who blowed up pretty quickly. The ds got exploited way too late....
 
  • Like
Reactions: Deleted User

Apache Thunder

I have cameras in your head!
Member
Joined
Oct 7, 2007
Messages
4,402
Trophies
3
Age
36
Location
Levelland, Texas
Website
www.mariopc.co.nr
XP
6,744
Country
United States
... they also added a third check which loads a few bytes of the first sector of the card into memory, where the signature and other validating parts of the card would be stored. but since we can modify the whitelist we can let it take in more bytes than arm7 expects and that causes a buffer overflow with arm7 sfcg unlocked then you could direct the buffer overflow to a payload loaded in memory and execute it. becouse arm7 sfcg is unlocked we have acces to nand, sd, and the card slot so we have full access.

Actually not quite how that third check works with the whitelist. The 3rd section of the white list was introduced in firmware 1.4 and it seems they rushed it as they forgot to reimplement the RSA sig checks for the white list SRL. The new section they added was supposed to work by loading in specific sections of the cart rom into ram so that arm9 can verify if those sections match a specific hash. (an HMAC-SHA1 hash I believe). They added this to protect against flashcarts that used exploited game roms to fool the DSi into booting it. (was a way around the hash checks the DSI did with the first 2 sections which hash checked the header + arm binaries and the second section which hashed the icon/banner data).

The flaw is that they didn't put bounds checks on how much rom data you can load in. So it overflows. For whatever reason Nintendo decided to have arm7 load in the cart data instead of arm9 despite the fact that arm9 was what was going to do the actual hash checks. So as a result there is no MPU protections to worry about as arm7 doesn't have an MPU. So we can overwrite data anywhere we want so long as it's not in DTCM/ITCM range (as that is internal CPU cache ram only accessible on arm9)

There are actually 2 ways to do this exploit. The current way RocketLauncher payload that we plan to eventually release will overflow into the arm7 interrupt vector address. This tells Arm7 where to jump when it crashes/is interrupted. Refer to gbatek documentation on how that works. The second method is currently undeveloped but also possible. You could instead take over arm9 first by only overwriting into arm9's exception vector. The only real benefit to doing it this way is having a slightly shorter boot time for your exploit since the overflow size is smaller. (it can take over 10+ seconds to actually boot the exploit. Over 7+MB of rom data has to be read before the payload is fully in ram and the arm7 irq vector is overwritten!) The only benefit for taking over arm9 first besides the negligible change in boot time is that a lot of arm7 ram won't be wiped out by the overflow so a special payload could be built to dump a few encryption keys arm7 puts in certain ram ranges in early boot. Even No$GBA doesn't have these keys and normally you needed an expensive physical mod that involved resoldering bypass wires over the ram which was quite an involved process.

Normmatt initially attempted to make a payload for this but arm9 didn't seem to want to cooperate with his initial attempts and haven't seen much further on this. StuckPixel is going to attempt dumping bootrom soon so it may not be needed anyways. :P

Also StuckPixel was who wrote the RocketLauncher payloads so it's ultimately his decision on when RocketLauncher gets released not mine. I only discovered the exploit and helped do the first beta tests of stuff Stuckpixel wrote to attempt exploiting it. There's not a lot of interest in DSi right now so have no good devs/coders to write the rest of the stuff we need for RocketLauncher to be user friendly.

We need something that can automatically downgrade DSi + install whitelist to nand. Something that doesn't requite dumping nand and writing it back like the older fwtool program that is floating around. Something more akin to GodMode9 on 3DS. We also need a program for PC that will automatically add custom section 3 entries to a white list file for setting up the retail cart method and for future flashcart support. (though already have the major ones setup. DSTT and it's compatible clones and AceKard 2i we've already got supported)

The autoboot method is the best method as you can boot into ROcketLauncher from cold boot with it and even bypass the health and safety screen (as the console doesn't load that until the cart is authenticated and is approved to be booted. But we crash the system and run are exploit during that process. :P ) But it requires having a flashcart where you can overwrite the rom it shows to the DSi. But most of the flashcarts known to be compatible with NTRBootHax on 3DS will also be supported with this exploit.

In other cases though you can use the retail cart boot method that involves putting our payload in a section of ram that isn't cleared on warmboot/soft-reset. Then put some special data at a specific ram offset and then call a reboot. That was something we gleaned from code meant for dev units for soft resetting into specific game titles. Not sure if this was ever used in SDK with any software eventually released. Might have ever been for testing on dev units or on special koisk units meant for demos in stores. But the support for it was retained in normal retail firmware. Long story short we overflow a retail game's rom data into ram until a specific part of that rom ends up in our arm7 irq jump vector like with how our auto boot method works. Unlike autoboot method though we can't control the data retail cart's present to the system. So instead we put our payload in ram like mentioned above and find a section of rom that happens to have a little endian value that tells arm7 to jump to that address value we found in the rom data. We found a string that's super common that almost every game has somewhere in it's rom. So we just align the overflow so that part of the game's rom ends up in the irq jump vector. So that's how the retail cart method works.


But yeah long story short we need more work done on the user side tools. What we have now isn't really suitable for release yet. Even HiyaCFW I feel needs a reworking with how that works. Currently it's crude and needs to load a hacked together SRL that has the stage2 binaries from DSI's nand (equilivent to FIRM partitions on 3DS mostly. Just more primitive/simpler in design) which is prepached to allow booting Launcher from SD instead of NAND. It has the RSA/SHA1 hash checks patched out. Then after that we use a pre patched Launcher on SD.

So not only do we need to make an autopatcher for the stage2 bootloader we need one for Launcher too. Though for Launcher it won't be that bad as all regions (except maybe Korea/China?) versions of Launcher are virtually identical. Only dev Launcher is different.

We have all the patches for Launcher (and the SD redirect patch that works sorta like emunand is super simple and easy to patch. Plus it's not las hard to use as emunand as you don't even have to setup a hidden partition on your SD card like with 3DS emunands of the past. You can just drop the your extracted nand files on SD and point Launcher to it instead of nand. :P)

Just need a few tools prepared and we can release RocketLauncher. (and eventually a proper release of HiyaCFW). So until then StuckPixel has been waiting. When he's had free time he has attempted to write the nand tools I mentioned. Not sure where he is on that though. He might not get back to that after he's done with his bootrom dump attempt though. May also be busy with Switch stuff. So yeah DSI isn't a priority among the dev community right now. So no one around to help us with it. :(
 

Billy Acuña

Well-Known Member
Member
Joined
Oct 10, 2015
Messages
3,126
Trophies
1
Age
31
XP
3,701
Country
Mexico
Actually not quite how that third check works with the whitelist. The 3rd section of the white list was introduced in firmware 1.4 and it seems they rushed it as they forgot to reimplement the RSA sig checks for the white list SRL. The new section they added was supposed to work by loading in specific sections of the cart rom into ram so that arm9 can verify if those sections match a specific hash. (an HMAC-SHA1 hash I believe). They added this to protect against flashcarts that used exploited game roms to fool the DSi into booting it. (was a way around the hash checks the DSI did with the first 2 sections which hash checked the header + arm binaries and the second section which hashed the icon/banner data).

The flaw is that they didn't put bounds checks on how much rom data you can load in. So it overflows. For whatever reason Nintendo decided to have arm7 load in the cart data instead of arm9 despite the fact that arm9 was what was going to do the actual hash checks. So as a result there is no MPU protections to worry about as arm7 doesn't have an MPU. So we can overwrite data anywhere we want so long as it's not in DTCM/ITCM range (as that is internal CPU cache ram only accessible on arm9)

There are actually 2 ways to do this exploit. The current way RocketLauncher payload that we plan to eventually release will overflow into the arm7 interrupt vector address. This tells Arm7 where to jump when it crashes/is interrupted. Refer to gbatek documentation on how that works. The second method is currently undeveloped but also possible. You could instead take over arm9 first by only overwriting into arm9's exception vector. The only real benefit to doing it this way is having a slightly shorter boot time for your exploit since the overflow size is smaller. (it can take over 10+ seconds to actually boot the exploit. Over 7+MB of rom data has to be read before the payload is fully in ram and the arm7 irq vector is overwritten!) The only benefit for taking over arm9 first besides the negligible change in boot time is that a lot of arm7 ram won't be wiped out by the overflow so a special payload could be built to dump a few encryption keys arm7 puts in certain ram ranges in early boot. Even No$GBA doesn't have these keys and normally you needed an expensive physical mod that involved resoldering bypass wires over the ram which was quite an involved process.

Normmatt initially attempted to make a payload for this but arm9 didn't seem to want to cooperate with his initial attempts and haven't seen much further on this. StuckPixel is going to attempt dumping bootrom soon so it may not be needed anyways. [emoji14]

Also StuckPixel was who wrote the RocketLauncher payloads so it's ultimately his decision on when RocketLauncher gets released not mine. I only discovered the exploit and helped do the first beta tests of stuff Stuckpixel wrote to attempt exploiting it. There's not a lot of interest in DSi right now so have no good devs/coders to write the rest of the stuff we need for RocketLauncher to be user friendly.

We need something that can automatically downgrade DSi + install whitelist to nand. Something that doesn't requite dumping nand and writing it back like the older fwtool program that is floating around. Something more akin to GodMode9 on 3DS. We also need a program for PC that will automatically add custom section 3 entries to a white list file for setting up the retail cart method and for future flashcart support. (though already have the major ones setup. DSTT and it's compatible clones and AceKard 2i we've already got supported)

The autoboot method is the best method as you can boot into ROcketLauncher from cold boot with it and even bypass the health and safety screen (as the console doesn't load that until the cart is authenticated and is approved to be booted. But we crash the system and run are exploit during that process. [emoji14] ) But it requires having a flashcart where you can overwrite the rom it shows to the DSi. But most of the flashcarts known to be compatible with NTRBootHax on 3DS will also be supported with this exploit.

In other cases though you can use the retail cart boot method that involves putting our payload in a section of ram that isn't cleared on warmboot/soft-reset. Then put some special data at a specific ram offset and then call a reboot. That was something we gleaned from code meant for dev units for soft resetting into specific game titles. Not sure if this was ever used in SDK with any software eventually released. Might have ever been for testing on dev units or on special koisk units meant for demos in stores. But the support for it was retained in normal retail firmware. Long story short we overflow a retail game's rom data into ram until a specific part of that rom ends up in our arm7 irq jump vector like with how our auto boot method works. Unlike autoboot method though we can't control the data retail cart's present to the system. So instead we put our payload in ram like mentioned above and find a section of rom that happens to have a little endian value that tells arm7 to jump to that address value we found in the rom data. We found a string that's super common that almost every game has somewhere in it's rom. So we just align the overflow so that part of the game's rom ends up in the irq jump vector. So that's how the retail cart method works.


But yeah long story short we need more work done on the user side tools. What we have now isn't really suitable for release yet. Even HiyaCFW I feel needs a reworking with how that works. Currently it's crude and needs to load a hacked together SRL that has the stage2 binaries from DSI's nand (equilivent to FIRM partitions on 3DS mostly. Just more primitive/simpler in design) which is prepached to allow booting Launcher from SD instead of NAND. It has the RSA/SHA1 hash checks patched out. Then after that we use a pre patched Launcher on SD.

So not only do we need to make an autopatcher for the stage2 bootloader we need one for Launcher too. Though for Launcher it won't be that bad as all regions (except maybe Korea/China?) versions of Launcher are virtually identical. Only dev Launcher is different.

We have all the patches for Launcher (and the SD redirect patch that works sorta like emunand is super simple and easy to patch. Plus it's not las hard to use as emunand as you don't even have to setup a hidden partition on your SD card like with 3DS emunands of the past. You can just drop the your extracted nand files on SD and point Launcher to it instead of nand. :P)

Just need a few tools prepared and we can release RocketLauncher. (and eventually a proper release of HiyaCFW). So until then StuckPixel has been waiting. When he's had free time he has attempted to write the nand tools I mentioned. Not sure where he is on that though. He might not get back to that after he's done with his bootrom dump attempt though. May also be busy with Switch stuff. So yeah DSI isn't a priority among the dev community right now. So no one around to help us with it. :(
You know, since ugopw was released/leaked, some people with scripting skills Made scripts which makes the whole downgrade + dsiwarehax proccesw simplier, heck, even there is a scripting tool that works on the console, I mean, if you guys actually release the whole whitelist editing proccess + the source code of the payloads (not binaries). Other guys can help making this simplier.
If you guys are afraid about user-error bricks, you shouldn't, is the DSi after all with lot of lack of an user base and most of them alreally have other homebrewed consoles (the 3ds in the 99% of the cases), so I don't think they could get mad because their old and obsolete DSi got bricked by messing with the whitelist (yes, I said the whitelist only since all the users interested on the DSi alreally downgraded and have dsiwarehax installed.
 
Last edited by Billy Acuña,

redunka

Well-Known Member
Member
Joined
Nov 26, 2014
Messages
423
Trophies
0
Age
29
XP
2,519
Country
Russia
It has the RSA/SHA1 hash checks patched out.
I'm sorry if this is kinda offtopic, but I have a question, if you don't mind.
Would it be possible to have the patches for SHA1-HMAC checks for TWL_FIRM?
Almost every single CFW for 3DS has RSA checks for SRLs patched out, but SHA1-HMAC hashes still have to be valid, which provides additional difficulties for romhack makers.
Sure, since SRL header's sig isn't verified, one can just recalculate all those hashes, it's not that hard, but it's somewhat annoying.
Even if there doesn't seem to be that many people that are interested in DSiWare romhacking, I sure am, but I don't have enough knowledge for anything more complex than this.
 

thom_tl

Well-Known Member
Member
Joined
Aug 18, 2017
Messages
180
Trophies
0
Location
Behind my desk.
XP
210
Country
Netherlands
Actually not quite how that third check works with the whitelist. The 3rd section of the white list was introduced in firmware 1.4 and it seems they rushed it as they forgot to reimplement the RSA sig checks for the white list SRL. The new section they added was supposed to work by loading in specific sections of the cart rom into ram so that arm9 can verify if those sections match a specific hash. (an HMAC-SHA1 hash I believe). They added this to protect against flashcarts that used exploited game roms to fool the DSi into booting it. (was a way around the hash checks the DSI did with the first 2 sections which hash checked the header + arm binaries and the second section which hashed the icon/banner data).

The flaw is that they didn't put bounds checks on how much rom data you can load in. So it overflows. For whatever reason Nintendo decided to have arm7 load in the cart data instead of arm9 despite the fact that arm9 was what was going to do the actual hash checks. So as a result there is no MPU protections to worry about as arm7 doesn't have an MPU. So we can overwrite data anywhere we want so long as it's not in DTCM/ITCM range (as that is internal CPU cache ram only accessible on arm9)

There are actually 2 ways to do this exploit. The current way RocketLauncher payload that we plan to eventually release will overflow into the arm7 interrupt vector address. This tells Arm7 where to jump when it crashes/is interrupted. Refer to gbatek documentation on how that works. The second method is currently undeveloped but also possible. You could instead take over arm9 first by only overwriting into arm9's exception vector. The only real benefit to doing it this way is having a slightly shorter boot time for your exploit since the overflow size is smaller. (it can take over 10+ seconds to actually boot the exploit. Over 7+MB of rom data has to be read before the payload is fully in ram and the arm7 irq vector is overwritten!) The only benefit for taking over arm9 first besides the negligible change in boot time is that a lot of arm7 ram won't be wiped out by the overflow so a special payload could be built to dump a few encryption keys arm7 puts in certain ram ranges in early boot. Even No$GBA doesn't have these keys and normally you needed an expensive physical mod that involved resoldering bypass wires over the ram which was quite an involved process.

Normmatt initially attempted to make a payload for this but arm9 didn't seem to want to cooperate with his initial attempts and haven't seen much further on this. StuckPixel is going to attempt dumping bootrom soon so it may not be needed anyways. :P

Also StuckPixel was who wrote the RocketLauncher payloads so it's ultimately his decision on when RocketLauncher gets released not mine. I only discovered the exploit and helped do the first beta tests of stuff Stuckpixel wrote to attempt exploiting it. There's not a lot of interest in DSi right now so have no good devs/coders to write the rest of the stuff we need for RocketLauncher to be user friendly.

We need something that can automatically downgrade DSi + install whitelist to nand. Something that doesn't requite dumping nand and writing it back like the older fwtool program that is floating around. Something more akin to GodMode9 on 3DS. We also need a program for PC that will automatically add custom section 3 entries to a white list file for setting up the retail cart method and for future flashcart support. (though already have the major ones setup. DSTT and it's compatible clones and AceKard 2i we've already got supported)

The autoboot method is the best method as you can boot into ROcketLauncher from cold boot with it and even bypass the health and safety screen (as the console doesn't load that until the cart is authenticated and is approved to be booted. But we crash the system and run are exploit during that process. :P ) But it requires having a flashcart where you can overwrite the rom it shows to the DSi. But most of the flashcarts known to be compatible with NTRBootHax on 3DS will also be supported with this exploit.

In other cases though you can use the retail cart boot method that involves putting our payload in a section of ram that isn't cleared on warmboot/soft-reset. Then put some special data at a specific ram offset and then call a reboot. That was something we gleaned from code meant for dev units for soft resetting into specific game titles. Not sure if this was ever used in SDK with any software eventually released. Might have ever been for testing on dev units or on special koisk units meant for demos in stores. But the support for it was retained in normal retail firmware. Long story short we overflow a retail game's rom data into ram until a specific part of that rom ends up in our arm7 irq jump vector like with how our auto boot method works. Unlike autoboot method though we can't control the data retail cart's present to the system. So instead we put our payload in ram like mentioned above and find a section of rom that happens to have a little endian value that tells arm7 to jump to that address value we found in the rom data. We found a string that's super common that almost every game has somewhere in it's rom. So we just align the overflow so that part of the game's rom ends up in the irq jump vector. So that's how the retail cart method works.


But yeah long story short we need more work done on the user side tools. What we have now isn't really suitable for release yet. Even HiyaCFW I feel needs a reworking with how that works. Currently it's crude and needs to load a hacked together SRL that has the stage2 binaries from DSI's nand (equilivent to FIRM partitions on 3DS mostly. Just more primitive/simpler in design) which is prepached to allow booting Launcher from SD instead of NAND. It has the RSA/SHA1 hash checks patched out. Then after that we use a pre patched Launcher on SD.

So not only do we need to make an autopatcher for the stage2 bootloader we need one for Launcher too. Though for Launcher it won't be that bad as all regions (except maybe Korea/China?) versions of Launcher are virtually identical. Only dev Launcher is different.

We have all the patches for Launcher (and the SD redirect patch that works sorta like emunand is super simple and easy to patch. Plus it's not las hard to use as emunand as you don't even have to setup a hidden partition on your SD card like with 3DS emunands of the past. You can just drop the your extracted nand files on SD and point Launcher to it instead of nand. :P)

Just need a few tools prepared and we can release RocketLauncher. (and eventually a proper release of HiyaCFW). So until then StuckPixel has been waiting. When he's had free time he has attempted to write the nand tools I mentioned. Not sure where he is on that though. He might not get back to that after he's done with his bootrom dump attempt though. May also be busy with Switch stuff. So yeah DSI isn't a priority among the dev community right now. So no one around to help us with it. :(
Thanks for the detailed explenation, there is actually a lot more going on than shown in the video. I'm sure you've already heard this alot but twlNF is kinda like Godmode9. http://gbatemp.net/threads/wip-twlnf-dsi-nand-file-thing-testers-with-hardmod-wanted.484690/ . Also if the bootrom is dumped will it be decrypted or encrypted, and did nintendo restore nands when the warrenty still exist if so something like NTRboothax might exist on the DSi.
 

Swampat

The swamp monster that pats the ground
OP
Member
Joined
May 25, 2017
Messages
238
Trophies
0
Age
27
XP
230
Country
United States
Hmm guess I will keep waiting my 2ds isn't working and it had cfw on it so I am counting on cfw being released here.
 

Apache Thunder

I have cameras in your head!
Member
Joined
Oct 7, 2007
Messages
4,402
Trophies
3
Age
36
Location
Levelland, Texas
Website
www.mariopc.co.nr
XP
6,744
Country
United States
I'm sorry if this is kinda offtopic, but I have a question, if you don't mind.
Would it be possible to have the patches for SHA1-HMAC checks for TWL_FIRM?
Almost every single CFW for 3DS has RSA checks for SRLs patched out, but SHA1-HMAC hashes still have to be valid, which provides additional difficulties for romhack makers.
Sure, since SRL header's sig isn't verified, one can just recalculate all those hashes, it's not that hard, but it's somewhat annoying.
Even if there doesn't seem to be that many people that are interested in DSiWare romhacking, I sure am, but I don't have enough knowledge for anything more complex than this.

CFW already patches that out of TWL_FIRM. I believe Arm9 of TWL_FIRM was what checked that stuff and I've been able to run custom TWL mode SRLs before. What you are running into is the digest hash table stuff that retail TWL titles use. That is handled by the game itself I believe. (unless Launcher/dev launcher verifies this?) If you get white screen after booting the attempted rom hack then it means that it got past arm9 checks of TWL_FIRM and attempted to boot the game. But the digest table stuff pervents modifications to the NitroFS stuff among other things. Most likely have to patch it out of the game. I think Shutterbug2000 managed to do this at one point. Ask him about it. ;)

Thanks for the detailed explenation, there is actually a lot more going on than shown in the video. I'm sure you've already heard this alot but twlNF is kinda like Godmode9. http://gbatemp.net/threads/wip-twlnf-dsi-nand-file-thing-testers-with-hardmod-wanted.484690/ . Also if the bootrom is dumped will it be decrypted or encrypted, and did nintendo restore nands when the warrenty still exist if so something like NTRboothax might exist on the DSi.

Bootrom won't be encrypted. What you are mixing it up with is the boot1/boot2 stuff on Switch or Wii-U? I believe one or both those consoles use a bootloader section that is encrypted. But bootrom itself isn't encrypted. You can't run encrypted code directly so bootrom has to be in plain text. Nintendo might high additional code behind an encryption layer in a manner similar to boot1 on Wii-U, but DSi is a pretty simple architecture compared to Wii-U so no bootrom isn't encrypted. The only encrypted part of the early boot chain on DSi is the stage2 binaries stored on NAND but those operate in a manner similar to 3DS's FIRM partitions and the encryption has already been cracked on that. ;)
 
  • Like
Reactions: redunka and thom_tl

Swampat

The swamp monster that pats the ground
OP
Member
Joined
May 25, 2017
Messages
238
Trophies
0
Age
27
XP
230
Country
United States
CFW already patches that out of TWL_FIRM. I believe Arm9 of TWL_FIRM was what checked that stuff and I've been able to run custom TWL mode SRLs before. What you are running into is the digest hash table stuff that retail TWL titles use. That is handled by the game itself I believe. (unless Launcher/dev launcher verifies this?) If you get white screen after booting the attempted rom hack then it means that it got past arm9 checks of TWL_FIRM and attempted to boot the game. But the digest table stuff pervents modifications to the NitroFS stuff among other things. Most likely have to patch it out of the game. I think Shutterbug2000 managed to do this at one point. Ask him about it. ;)



Bootrom won't be encrypted. What you are mixing it up with is the boot1/boot2 stuff on Switch or Wii-U? I believe one or both those consoles use a bootloader section that is encrypted. But bootrom itself isn't encrypted. You can't run encrypted code directly so bootrom has to be in plain text. Nintendo might high additional code behind an encryption layer in a manner similar to boot1 on Wii-U, but DSi is a pretty simple architecture compared to Wii-U so no bootrom isn't encrypted. The only encrypted part of the early boot chain on DSi is the stage2 binaries stored on NAND but those operate in a manner similar to 3DS's FIRM partitions and the encryption has already been cracked on that. ;)
Seems the switch will be updated automatically for games on a newer firmware so anything being release soon maybe longer than people want. But what do I know I cant even afford a switch.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
  • ZeroT21 @ ZeroT21:
    it wasn't a question, it was fact
  • BigOnYa @ BigOnYa:
    He said he had 3 different doctors apt this week, so he prob there. Something about gerbal extraction, I don't know.
    +1
  • ZeroT21 @ ZeroT21:
    bored, guess i'll spread more democracy
  • LeoTCK @ LeoTCK:
    @K3Nv2 one more time you say such bs to @BakerMan and I'll smack you across the whole planet
  • K3Nv2 @ K3Nv2:
    Make sure you smack my booty daddy
    +1
  • LeoTCK @ LeoTCK:
    telling him that my partner is luke...does he look like someone with such big ne
    eds?
  • LeoTCK @ LeoTCK:
    do you really think I could stand living with someone like luke?
  • LeoTCK @ LeoTCK:
    I suppose luke has "special needs" but he's not my partner, did you just say that to piss me off again?
  • LeoTCK @ LeoTCK:
    besides I had bigger worries today
  • LeoTCK @ LeoTCK:
    but what do you know about that, you won't believe me anyways
  • K3Nv2 @ K3Nv2:
    @BigOnYa can answer that
  • BigOnYa @ BigOnYa:
    BigOnYa already left the chat
  • K3Nv2 @ K3Nv2:
    Biginya
  • BigOnYa @ BigOnYa:
    Auto correct got me, I'm on my tablet, i need to turn that shit off
  • K3Nv2 @ K3Nv2:
    With other tabs open you perv
  • BigOnYa @ BigOnYa:
    I'm actually in my shed, bout to cut 2-3 acres of grass, my back yard.
  • K3Nv2 @ K3Nv2:
    I use to have a guy for that thanks richard
  • BigOnYa @ BigOnYa:
    I use my tablet to stream to a bluetooth speaker when in shed. iHeartRadio, FlyNation
  • K3Nv2 @ K3Nv2:
    While the victims are being buried
  • K3Nv2 @ K3Nv2:
    Grave shovel
  • BigOnYa @ BigOnYa:
    Nuh those goto the edge of the property (maybe just on the other side of)
  • K3Nv2 @ K3Nv2:
    On the neighbors side
    +1
  • BigOnYa @ BigOnYa:
    Yup, by the weird smelly green bushy looking plants.
    K3Nv2 @ K3Nv2: https://www.the-sun.com/news/10907833/self-checkout-complaints-new-target-dollar-general-policies...