afaict it has been modified, boot0 upto offset 00000220 is usually blank and yours has data - presumaby this is the picofly bootloader/modifications… interestingly it seems slightly different to the SX method. I’m busy atm but I’ll look over it properly within the next couple of days for you.
1 Like
I’ll have to compare to other dumps and see whats what, might just be a case of stripping out that data etc or padding it. afair the version number is at a particular offset but I’ll have to check on that… this info may well be on Switchbrew somewhere or else I’m gonna have to go over my boot0 dumps and find the pattern (unless anyone else knows off the top of their head)
I’ve forgot, is this patched erista or Mariko?
1 Like
I am really thankful about all the effort you are putting on this. Is there anything I can do to help?
Is a V2, Mariko. SN: XKJ1003…
Anyway firmware should be pretty recent, as we were doing updates.
No worries, though don’t get you hopes up, this is really not my area 
I’m more a hardware guy
Your welcome to search around and see if your can find info on the offset which the FW version is at on your boot0 file (viewed in a hex editor) though don’t worry if you can’t, this is pretty niche stuff after all
1 Like
Ok, on closer examination it seems my initial analysis was not quite right. What I mentioned above about the data at offsets etc applies to patched and unpatched Erista only.
I found a Mariko Boot 0, I only have one it seems so if anybody has a boot0 dump from Mariko I’d appreciate it if you could share incase mine is damaged/modified with SX - So a clean dump if possible as I have not labeled my dump whether or not it was “cleaned” prior.
Anyway assuming my dump is clean (stock standard) there is infact data at the offsets I mentioned earlier on Mariko (which I guess makes sense given the hardware differences on the board) It doesn’t seem like NXNandManager is capable of identifying the FW version using the Boot0 of Mariko (again this is assuming my Mariko boot 0 is clean) which likely means the offset/pattern is not known yet.
Looking at your file though does seem to indicate corruption/modification at the start though (maybe the normal header of mariko boot0?)
My boot0
Your Boot0 - with jibberish at the start which I’d oridinarily asscociate with corruption though maybe it’s intentional by picofly (?)
@Calvin @jkyoho
Have you guys got Mariko dumps of boot0 both “clean” (modifications from SX or other removed) and “dirty” (modified by SX or other) So I can compare and see what’s going on here? and if yes, if you know what FW version it’s on
1 Like
Is backup from Hekate dirty BOOT0 or clean?
I can make emmchaccgen BOOT0, presumably clean?
1 Like
I only have Erista NAND Backups. No Mariko ones.
1 Like
Does this editing of BOOT0 means that a Switch hacked with hwfly/picofly will never boot after patching and removing the hwfly/picofly hardware from the Switch?
1 Like
I’m not sure tbh if your using picofly, back on the old SX modchip there was an option to clean the boo0 file and then subsequently dump straight after with Hekate afterwhich it would be modified once again at boot by the SX modchip.
It ill be clean for sure if no modchip has been installed and the parition is dumped directly off the EMMC using another switch or mmcblk
No worries 
Interesting, so seems like this modfication of the the starting data is intentional by picofly (assuming more recent Switch OS/FW versions aren’t doing something very different) - Also suggest this is the same FW version as the OP (data below seems the same)
That’s my thinking though I could well be wrong, unless it clears it and writes again prior to every startup / shutdown 
Does EMMCHacGen GUI work the same as the Choi method IE: able to generate clean boot0/1 files with generic key file but for Mariko?
1 Like
I believe so.
I dont have much knowledge with SX since but since picofly also doing similar bootloader injection to redirect boot0 reading SDroot payload, I guess it never be clean BOOT0 from hekate backup.
1 Like
if you talking about OFW update after initial hwfly/picofly mod and removing, there won’t be affect. You can boot normally.
(As long as mod installation works properly…many ppl complained xxx mod ruined the emmC and yet that’s simply mod failed)
1 Like
I see, then this might be the best path for the OP, basically follow the choi PC guide but using EMMCHacGen gui in place of Choi for boot0/1 and see if he regains boot in stock
I would be curious to see your boot0 Jkyoho from picofly and your generated boot0 from emmchacgen using you console specific keys just to see how the two compare, might also enable me to see if somethings wrong with the OP’s boot0 and potentially fix (though this sort of thing isn’t really my area)
1 Like
does seem to confirm the stripping of the [presumed] header data on the image you posted before and the OPs - subsequent data after the header it seems picofly has modified, I’d imagine the original data is still there at a different offset (00000220 onwards) so this doesn’t confirm this is the same FW version as the OP unfortunately.
1 Like
off the scene now, will look up more when back
2 Likes
Thanks for stepping into this as well!
I am updating myself on the last messages.
In the meantime, I have googled for some information regarding my specific case and the identification of the firmware, but have not had any success yet.
Maybe I’ll start informing myself about using EMMCHacGen. Do I need prod keys from a donor to generate Boot0 and Boot1? Or can it generate them on its own without providing any further information?
This is the million dollar question 
as I’ve never done this on Mariko, back in the day you could use generic key file with choi.
This guy seems to to suggest its the same as prior (ignore the reasoning for him gettin into the situation - Choi is not compatable with Mariko it seems hence his issues but the aftermath is the same)
So I guess you could just attempt to regen the boot0/1 for the last few FW version and see which works (if any at all)
I find it difficult to find the necessary procedure. All the documentation and threads suggest using the prod keys backup from the console.
I have not yet been able to find a guide on choi to generate the key on the pc, if possible for Mariko.
Looking at the @jkyoho dumps, it makes me wonder if maybe the problem is hardware. If maybe it’s the modchip. Or maybe the flat.
But still I don’t understand why previously, by putting the emmc to the slot and booting the console without modchip it was showing blue screen meanwhile, after the issue closing the console I get black screen. Still hoping is not an unrecoverable bad hardware issue.
My case it’s a bit frustrating, at least because I can’t find people with the same problem.
I think this was the guide most people follow.
https://switch.homebrew.guide/usingcfw/manualchoiupgrade.html
back in the day (regular rev switches under a certain FW version) you could basically follow this guide using generic key file to regenerate boot0/1 (and a few other non encrypted partitions - not prodinfo) - so basically, if you had specifically a boot0/1 issue… but if you had a prodinfo/f issue without your specific keys your basically out of luck.(as you need your keys to decrypt andsubsequently rebuild said partitions)
Though just to note, you’d have to pick and choose which sections to follow of this guide specifically relating to boot0/1 etc and of course use EMMCHacGen GUI in place of choi
Hard to say until I see his emmchacgen generation (which should in theory be the same as a clean dump if he’s using his keys) and picofly modified boot0
because in a stock situation a corrupted EMMC can cause a BSOD and given that the modchip modfies the EMMC then that’s the most obvious conclusion (though from my experience it’s usually corruption of the bcpkg partition/s which cause BSOD). Though as you might have seen from the other threads, people who rip the shield frame for the SoC off the board can also cause BSOD which relates to Ram (or Ram lines to the SoC) but I don’t think you did this in your case (?)