Open zal16 opened 3 years ago
I don't have a mariko console to extract anything from and test values against, so this makes it incredibly difficult for me to develop such a thing. Maybe in the future, but for now no
Let me tell you my full story ...
I already own a console, unpatched erista model, but I bought a mariko briked console, to try to fix it.
He has no hardware problems, but analyzing the NAND, I found that the GPT, the SYSTEM and USER partitions were corrupted.
The GPT was easy to fix, the SX menu itself has the option of fixing it, but both partitions needed their biskeys so I could do something with them. Recently shchmue released Lockpick RCM in version 1.9.0 that supports Mariko consoles, so I got my prod.keys.
with the keys, I just formatted the USER partition and then used Emmchaccgen (your program) to create the firmware for the SYSTEM partition. I mounted the partition (with its proper keys) and copied all the files generated by your program. I used firmware 10.1.0 because, after using Emmchaccgen, it generates BCPKG2 partitions 1 to 4, with exactly the same CRC hash of the partitions present in NAND (From Hekate, I saw that the fuse count was 13, indicating that it was in some version 10.xx before bricking).
Here we come to my problem, your program correctly generates the "registered" folder with the appropriate .NCAs, but apparently the save 80000000000120 generated is not being accepted by the console (it remains in dark screen, after the Nintendo logo)
I did something different, deleted the save folder and started the console (obviously it didn't go beyond the nintendo logo, as expected), but when I mounted the SYSTEM partition again, the save folder reappeared with another 80000000000120 file, a quick comparison with the file generated by Emmchaccgen shows a difference in size.
the emmchaccgen save is 1,146,880 bytes the save "created" by the console is 1,212,416 bytes
they seem to be random sizes but I got the NAND save from my Erista console and it has exactly the same 1,146,880 bytes.
So I imagine that the Mariko consoles manipulate this save in a different way from the Erista consoles.
I would like to contact you privately, if you are interested, so that I can provide you with the saves "created" by the console, the save that was generated by Emmchaccgen and, if necessary, my prod.keys.
I repeated (four times) the process of starting the console without save folder and always generate the file 8000000000120 with 1,212,416 bytes, but with different CRC Hashes.
I also tried to see some differences with a hex editor, but my knowledgement about this is very limited
finished, I hope you read it calmly
The 120 save creating behavior is the same as erista. Those are pretty useless (i never really looked into them, but, i suspect they're just the save without the data.arc). What you could try is to take that generated save, rename it to save.stub, putting it next to emmchaccgen, and re-generating the 120 save with it.
Also again, i don't know what the differences are between erista and mariko. I know for sure boot is generated differently, but that's about it. What would really help if you could provide a working 120 mariko save, but you don't have that, so i really doubt you can help me much here
I tried to rename the my file to save.stub, but the program throws an error.
I'm having extreme difficulty of getting that save from someone, because they do not have enough good will to devote five minutes to enter the tinfoil, enter the file manager, enter the system partition and copy the file i need.
would you like to look at my files anyway?
"An error" i can't see what the error is. I doubt it would've worked anyway but it was worth a shot.
Also note tinfoil is a closed source shady as fuck tool, no wonder why nobody wants to help you with that.
I doubt your files are at issue here. I have severe doubts about being able to help, especially with my lack of mariko knowledge
I've got a working 120 file from mariko console on HOS v10.0.4, hope it will help. 8000000000000120.zip
@KazushiMe I will thank you forever. your file was able to save my console.
my suspicions were correct, save provided by you is exactly the same size as those generated on my console (and different from Erista consoles)
it was just enough to rename your file to save.stub and Emmchaccgen managed to handle it without errors. Then I copied it to the save folder on my console and ...... pow! it worked. I am so happy.
I can't forget to thank @suchmememanyskill , because without this program, it would not be possible to rebuild my NAND
Oh fuck, alright. I was in talk with peeps already about this, interesting stuff. Will do further research on this. Thanks
I think i have a straightforward way to add mariko support now
@zal16 Good to know it helps.
Actually, I've come across some RCM exploitable Erista consoles (some serials start with XAJ4005-4007, potentially patched) that generates 1,212,416 bytes save file just like mariko.
I suppose this has something to do with DISF version (offset 0x106)
1,146,880 bytes ---- 04 (EmmcHaccGen, Erista)
1,212,416 bytes ---- 05 (Some Erista, Mariko)
And a friend of mine discovered a solution yesterday that doesn't require 120 save from other consoles to rebuild for your own console:
Extract the 120 save that EmmcHaccGen generates (1,146,880 bytes)
hactoolnet.exe -t save -k prod.keys 8000000000000120 --outdir 120
In outdir 120
there will be a folder meta
and imkvdb.arc
file in meta
.
Repack 120
dir into the 120 save that your console auto generates (1,212,416 bytes)
hactoolnet.exe -t save -k prod.keys 8000000000000120 --repack 120
and place the file back to the console.
He succeeded in recovering from the brick(RCM Exploitable XAJ4007A1). But now I don't have a console by hand so I'm not able to test. Maybe you can try this?
@KazushiMe you can skip step 1 here, launching emmchaccgen with the --debug arg will dump the imkvdb.arc (as data.arc).
Also this is interesting, hm. I'll look further into this.
i tested this way works too.
if i had known this before, i wouldn't have begged for this file to the four corners of the world kkkkk
do not share any keys. Currently emmchaccgen does not support generating boot files for mariko units. I'll add support for it when i have time to do so
(deleted the comment for sharing/posting a drive link for keys)
This is off-topic for this issue. If you believe this is an issue, please open a new issue (i can gen 11.0.0 just fine though)
Hi, i've made a commit to the dev branch that adds 3 parameters: --no-autorcm --save-v5 (use this if you're using a patched erista console) --mariko (use this if you're using a mariko console)
Would anyone mind testing this build on a mariko unit? Restoring Boot0, bcpkg2, and the 120 system save? If you need a command example: EmmcHaccGen.exe --fw path/to/fw --keys path/to/keys --mariko
(i don't think fucking with boot1 is a good idea as iirc the modchips use boot1 to boot. i don't want to accidentally brick switches here!)
@suchmememanyskill thanks, I'll try it on 2 mariko consoles, I'll write about the result later
@suchmememanyskill after the NINTENDO logo, a black screen, does not load further ,. added the generated SBK and T SEK KEY to the list of keys
Are you using the keys specifically from your console? Did you specifiy --mariko? What did you flash to the system?
@suchmememanyskill I got 2 keys 14 - secure_boot_key (console unique - this isn't needed for further key derivation than what Lockpick_RCM does but might be nice to have for your records) 15 - Secure storage key (console unique - this is not used on retail or dev consoles and there's nothing useful to do with it) added them as SBK and TCEK to the prod.keys file, then tried to get 11.0.1, added in the line - -mariko
You missed 2 out of 3 questions. Also worth checking if you boot into tegraexplorer v3.0.1 and going into show keys, if the save mac key from your prod.keys matches with what tegraexplorer says
@suchmememanyskill after starting, I checked the system partition, one file appeared only https://sun9-25.userapi.com/impg/q_lZ7_Inf5RiyUrm3KnDQbQ_2BENPKaHZYfvxw/5dLJUgsYnFU.jpg?size=862x685&quality=96&proxy=1&sign=b777f29357e643aadc4799c801a42a42&type=album answering past questions.
You missed 2 out of 3 questions. Also worth checking if you boot into tegraexplorer v3.0.1 and going into show keys, if the save mac key from your prod.keys matches with what tegraexplorer says
I write to Emmc using the console of the first revision with a vulnerability, then I put emmc in the mariko board
@suchmememanyskill Thanks for your work! it helped friend! found some bugs and everything works "! https://sun9-5.userapi.com/impg/gBWH4epdlH-A1omSHGdsXlvfBKIEFTZ9VDde-g/WOWjlJijpZ4.jpg?size=1600x900&quality=96&proxy=1&sign=dfb095714fad9dc826f84f84a2ccb9a7&type=album
So it works? What did you change?
So it works? What did you change?
I didn't sign the keys correctly for the mariko. instead of mariko_kek mariko_bek entered tsec, but it is not needed for mariko
pinning it so more people will see it. I want more people to test this.
See here for how to test on mariko
Hi there, I generated a new nand for patched erista from scratch using b1f233d.zip
and it worked well. Thanks!
Would anyone mind testing this build on a mariko unit? Restoring Boot0, bcpkg2, and the 120 system save? If you need a command example:
EmmcHaccGen.exe --fw path/to/fw --keys path/to/keys --mariko
(i don't think fucking with boot1 is a good idea as iirc the modchips use boot1 to boot. i don't want to accidentally brick switches here!)
Tested the DG on a Switch Lite from FW 11.0.1 to FW 9.0.0. And it works 👍
i'll leave this issue open for a bit, but i've made a pre-release with a build that supports mariko
Emmchaccgen only generate erista's boot 0/1. You wiil make support for mariko's boot 0/1 someday?