Hacking [Pre-release, WIP] Yet another rxTools?

[duke_srg]

I built your version branch earlier (btw the only problem with it was the need to update libkhax in cakebrah submodule), and I noticed a few things once I ran it through spider:
- I got a black screen, with a grey bar, installing stuff I suppose.. At some point, it got stuck
- I press any button, and I got a screen, with background, but there was no text at all. so I just powered off and tried again
- This time, it worked, and wow you did a fantastic job with the tools!
- I circled through the options, and I noticed the last two options in the dump section are not working, even though they are not greyed out. But I'm guessing you already know that

So, uh, if spider doesn't work, what works then? I doubt there is any usage for mset nowadays

Well, it's not stuck. During initial install font are extracted fron sysnand and then firmware is patched. During this, progress bar increases non-linear and it could looks like it is stuck but it is not.
Yes, those are not implemented nor refactored yet. Current progress described in readme.md here https://github.com/dukesrg/rxTools/tree/master/rxtools
I just tried with spider with no luck.

 

[Madridi]

Well, it's not stuck. During initial install font are extracted fron sysnand and then firmware is patched. During this, progress bar increases non-linear and it could looks like it is stuck but it is not.
Yes, those are not implemented nor refactored yet. Current progress described in readme.md here https://github.com/dukesrg/rxTools/tree/master/rxtools
I just tried with spider with no luck.

Oh I see. Still, if the screen is not moving until something is pressed, and even then I got a background screen without font, I'm guessing it should auto restart or something.
Thanks for the current progress. I'll make sure to read them.

Yeah, I just tried building your new branch, and spider isnt working. I don't like the way the new toolchain is handled. It deletes everything I manually had put there before (like picasso.exe, makerom.exe, curl, etc..)
In any case, I'll be playing with the build from your main branch. Can't wait to see the progress done on this


Edit: Similar to the main rxtools, pasta mode is not working (Black screen). While I understand you have not touched the cfw part of this, it makes sense that the same thing that happened there happens here. But I just want to confirm, that doesn't work for you as well correct? I'm only asking cause your progress page makes it seem like it works?

 

[duke_srg]

Edit: Similar to the main rxtools, pasta mode is not working (Black screen). While I understand you have not touched the cfw part of this, it makes sense that the same thing that happened there happens here. But I just want to confirm, that doesn't work for you as well correct? I'm only asking cause your progress page makes it seem like it works?

Yes, pasta mode was working. Also initial setup should work fine with the font, but sometimes it is indeed failed to load like you described.

Upd: found the cause of boot issue, it is in one of the CakeHax commits. Rolling back changes allows to make a bootable one with the new toolchain, though menu parser looks broken somehow. Will continue by the evening, hope mid-kid could confirm the issue.

 

[Madridi]

Yes, pasta mode was working. Also initial setup should work fine with the font, but sometimes it is indeed failed to load like you described.

Upd: found the cause of boot issue, it is in one of the CakeHax commits. Rolling back changes allows to make a bootable one with the new toolchain, though menu parser looks broken somehow. Will continue by the evening, hope mid-kid could confirm the issue.

Cakehax again? That issue kept happening repeatedly with other projects that uses it (like decrypt9 for example). I'll have to compile the latest commits of these projects to see if spider works with those or not.

About pasta mode, so if it's not working here, what might be the case? Did you try your latest commit to make sure it didn't break at some point?
The only difference between your console and mine is that mine has a9lh, but I doubt that's the issue

 

[duke_srg]

All depends on a toolchain. Now I have the old one with devkitarm45 and the new one with devkitarm46. But libraries also have a different versions. I can only say for sure Pasta mode was working with my old toolchain build, so you'd better check latest available prebuild release of my master branch.
I'll try to cherry-pick a9lh commit to my master branch to finally check if it will work with it.

 

[Madridi]

All depends on a toolchain. Now I have the old one with devkitarm45 and the new one with devkitarm46. But libraries also have a different versions. I can only say for sure Pasta mode was working with my old toolchain build, so you'd better check latest available prebuild release of my master branch.
I'll try to cherry-pick a9lh commit to my master branch to finally check if it will work with it.

Yeah I was talking about the old toolchain (devkitarm45) .. Building from latest commit, pasta mode did not work. So I went ahead with your advice and tried last release, the prealpha, and launching pastamode still gives a black screen. So I'm not sure what's going on.

Good luck with the a9lh implementation. Hope that goes well, and ofcourse, I'll be available to test it out

 

[The Catboy]

If you need a tester, I have both a new3DS and old3DS that I can spare to test on.

 

[Madridi]

If you need a tester, I have both a new3DS and old3DS that I can spare to test on.

For a9lh? Or rxtools in general?
If it's rxtools, you can probably help us with feedback regarding whether pasta mode does indeed work, or if it's broken.

 

[duke_srg]

Well, a9lh merged. At least spider entry is not broken, please test that branch.
Pasta also works. Also experienced troubles with font extraction/firmware decode, which is very strange since it was checked many times before. Reverted to old binary - all fine, first progress is just a font extraction, second one is for firmware and should havea caption if font decryption succeeded.
Anyway a9lh is the first thing to test!

 

[Madridi]

Well, a9lh merged. At least spider entry is not broken, please test that branch.
Pasta also works. Also experienced troubles with font extraction/firmware decode, which is very strange since it was checked many times before. Reverted to old binary - all fine, first progress is just a font extraction, second one is for firmware and should havea caption if font decryption succeeded.
Anyway a9lh is the first thing to test!

Will be home in about an hour to test.
I think the font extraction/firmware decoding is the issue I talked about? Since it never really gives any sign of that process ending. Unless you are talking about it failing entirely. Anyway, will report in a while

 

[laharl22]

where is the source with a9lh branch ?

 

[duke_srg]

Will be home in about an hour to test.
I think the font extraction/firmware decoding is the issue I talked about? Since it never really gives any sign of that process ending. Unless you are talking about it failing entirely. Anyway, will report in a while

Yes, exaclty. While it is still stable for me with master branch, it becomes unstable with a9lh branch.
Normal process is like that:
- first, untagged progress bar with several non-linear progress changes - it is a font extraction
- second, 'Dectypting firmware' progress bar just like before.
If it hangs on the first step, /rxTools/Data/cbf_std.bcfnt might be partly extracted, and with the next boot text will work, but font is partly broken. Please check its size must be 3124592 bytes.
upd: checked several times - always for old version, never for al9h. Looks like unstable, since no changes with that branch affecting the actual extraction code. Well, maybe the memory allocation issue.

where is the source with a9lh branch ?

https://github.com/dukesrg/rxTools/network
All is here, fell free to test. Be warned that initial setup (font,firmware extraction) most probably works only with spider/mset entry. Most likely tools itself may be parly working because of possible sd/nand mount issues.

 

[Madridi]

Yes, exaclty. While it is still stable for me with master branch, it becomes unstable with a9lh branch.
Normal process is like that:
- first, untagged progress bar with several non-linear progress changes - it is a font extraction
- second, 'Dectypting firmware' progress bar just like before.
If it hangs on the first step, /rxTools/Data/cbf_std.bcfnt might be partly extracted, and with the next boot text will work, but font is partly broken. Please check its size must be 3124592 bytes.
upd: checked several times - always for old version, never for al9h. Looks like unstable, since no changes with that branch affecting the actual extraction code. Well, maybe the memory allocation issue.

Alright, that took me a while to compile for 2 reasons:
- Didn't realize this compiled with the old toolchain. I kept getting errors with the new one, until I used the old one
- Once I did that, we are back to the libkhax issue in cakebrah. Had to manually remove that and git clone a working one

Anyway, so compiled now.. went ahead and fired the 3ds up. Result? Red screen.
So, I thought maybe it's due to the expected initial setup failure, so I launched it through spider to do the setup with the intention to try a9lh again after set up. After several bar changes in the setup, it got stuck on one of them. I would like to believe that it's the second step (firmware decryption) but honestly, no idea.

Now what

Edit: Took the SD out to see what's actually inside the data folder, and it's just a 940kb "0004013800000002.bin" file, which is interesting, given that the same bin file in the firm folder is 943kb. And no, there is no sign of cbf_std.bcfnt

 

[duke_srg]

Alright, that took me a while to compile for 2 reasons

Better run
git clone --recursive
in new folder and build.
You can get font and decrypted firmware from the previous installetion just to check a9lh booting first.

 

[Madridi]

Better run
git clone --recursive
in new folder and build.
You can get font and decrypted firmware from the previous installetion just to check a9lh booting first.

Yeah that is how I get my stuff to compile, with git clone --recursive command. Your cakebrah submodule used is old, that's why it libkhax needs to be updated manually (There is an open issue actually on github about that)

Oh ok I can use the previous one's data folder? Ok trying now

Edit: Ok, pasted the data folder, ran it through spider to make sure it works fine, and it did. Then I ran a9lh again. Red screen again (both top and bottom screens)

 

[duke_srg]

Red screens means sysnand access failed ether way. rxTools 3 could ignore file system mount issues, but in this branch this is strictly checked.
Here it is:
https://github.com/dukesrg/rxTools/blob/master/rxtools/source/main.c#L234

No CTR key found
https://github.com/dukesrg/rxTools/blob/master/rxtools/source/lib/nand.c#L114
Sysnand partitions not found
https://github.com/dukesrg/rxTools/blob/master/rxtools/source/lib/nand.c#L123
Maybe even this was not meant to work with a9lh
https://github.com/dukesrg/rxTools/blob/master/rxtools/source/lib/nand.c#L119

 

[duke_srg]

Just committed a quick fix with color encoding for different possible init errors. Please check with a9lh to make sure where to search compatibility issue.
Aqua(Cyan) - (A)ES (C)TR key search failed
Navy - TMIO (N)AND init failed
Salmon - TMIO (S)D init failed
Navy + Purple - (N)AND (P)artition table not found (NCSD signature)
Salmon + Fuchsia - (S)D (F)ile system mount failed

 

[Madridi]

Just committed a quick fix with color encoding for different possible init errors. Please check with a9lh to make sure where to search compatibility issue.

Will do in about 30 minutes and report back

 

[Madridi]

@duke_srg
Sorry it took so long, just compiled and tested it. The result is Aqua(Cyan)

 

[duke_srg]

@duke_srg
Sorry it took so long, just compiled and tested it. The result is Aqua(Cyan)

Damn. AES CTR init vector is got in rxTools from memory, which is pretty sure not initialized in case of a9lh. The real vector looks like must be calculated and based on sd/eMMC ID, which is not accessible since smdc module was replaced with tmio.

UPD: will take some time to add implementation into tmio. 173210 mage a great job rewriting Normmatt's sdmc driver wiping hardcoded eMMC commands, but only inclyded a needed minimum of command and definitions.