Well we don't care about if you really got it for free or not, trinket m0 is $8.95, and SX OS Core price is ~$45, so you tell me, only reason to go for Core/Lite if you got a patched unit/Mariko or switch lite. You just going have to wait until support is drop for the sx core if you want to use other CFW/ bootloader
- Joined
- Jul 23, 2018
- Messages
- 6,060
- Trophies
- 1
- Age
- 29
- Location
- Lampukistan
- Website
- hmpg.net
- XP
- 6,172
- Country
I think i worded it a bit wrong. Mariko, the name, is a fork from the tegra x1. And the codename from the x1 is erista. It has nothing to do with the different revisions. Technically it's the same. So, i don't know where you read this, but tx is telling shit.
Wat? SX core costs 50 bucks. So, the trinket is cheaper.
D
Deleted User
Guest
D
Deleted User
Guest
SX Core loads SXOS boot menu. SXOS boot menu can launch payload such as hekate. So.. yeah, sx core can load hekate.
How are you not understanding this?
- Joined
- Jul 23, 2018
- Messages
- 6,060
- Trophies
- 1
- Age
- 29
- Location
- Lampukistan
- Website
- hmpg.net
- XP
- 6,172
- Country
Because the payloads and tools are not updated for newer revisions? Retard. But if you read completely, you should know that op has an unpatched model. That makes sx core obsolete because he can install an trinket m0 chip.
D
Deleted User
Guest
Try helping OP for a change. He does not have a Mariko unit, ergo my answer helps him on how to launch hekate with SX Core. You on the other hand deflect and try to pursuade him into something he does not want.
Quite ironic for you to say that considering that you haven't read OP's statement that he already owns the SX Core as a gift and doesn't want to spend money buying the trinket.
@gudenau as previously mentioned here, you ought to boot sx menu via the sx core then from there you can boot to payload located on your sdcard. It's worth a shot.
However, it's important that you make a nand backup first since what you'll be doing isn't tested yet.
Sent from my SM-N975F using Tapatalk
@json the modchip doesn't really work with hekate/ams on erista anyway. Normal boot flow does several reboots (including one to reset system state before running N's tsec firmware). The modchip detects reboot and starts trying to do its thing, which breaks.
This also interferes with reboot to payload, which is kind of critical/can't be replaced for erista debugging infra. On Mariko you have an extra 192K of tzram so whatever, but erista really can't rearchitect to avoid rebooting.
Dunno how to deal with that tbh, given the modchip doesn't provide a way to signal that a pmc reboot is going to do warmboothax (or provide any documentation on how to control it at all
).
It's also like how ams/hekate boot on Mariko can't support chainloading from sx os, because they clear the keys needed to boot for no reason -- and so users will have to be instructed on how to bypass the modchip drm instead. Silly.
This also interferes with reboot to payload, which is kind of critical/can't be replaced for erista debugging infra. On Mariko you have an extra 192K of tzram so whatever, but erista really can't rearchitect to avoid rebooting.
Dunno how to deal with that tbh, given the modchip doesn't provide a way to signal that a pmc reboot is going to do warmboothax (or provide any documentation on how to control it at all
).It's also like how ams/hekate boot on Mariko can't support chainloading from sx os, because they clear the keys needed to boot for no reason -- and so users will have to be instructed on how to bypass the modchip drm instead. Silly.
Last edited by SciresM,
D
Deleted User
Guest
@SciresM Sorry but this is bullshit. You're talking out of your ass dude. Try doing some actual research first before speculating on this without even testing your claims.
Let's talk about patched Erista using SXOS 3.0.2 boot.dat:
hekate v5.3.0: boots up, shows menu just fine. no interference from modchip
reboot to payload: Just booted up hekate payload from SXOS. works fine
With some custom payloads:
PMC reboot: works, no interference from modchip
warmboothax: works, no interference from modchip
So, you were saying? Try doing actual testing first.
For Mariko, what keys do you need to boot? There's at most one key you need to be able to boot Mariko with (future) exosphere and it's available. Have you asked TX and the reason why you need them?
Let's talk about patched Erista using SXOS 3.0.2 boot.dat:
hekate v5.3.0: boots up, shows menu just fine. no interference from modchip
reboot to payload: Just booted up hekate payload from SXOS. works fine
With some custom payloads:
PMC reboot: works, no interference from modchip
warmboothax: works, no interference from modchip
So, you were saying? Try doing actual testing first.
For Mariko, what keys do you need to boot? There's at most one key you need to be able to boot Mariko with (future) exosphere and it's available. Have you asked TX and the reason why you need them?
<-- only tested myself on Mariko. I was going off of a report from a third party tester whose reported results when given payloads was consistent with this.
I'm willing to believe bad testing/communication, pending my actually getting to test that stuff myself.
--
This isn't true.
Mariko doesn't have warmboothax, so you need Nintendo's warmboot firmware.
This requires the BEK, which SX OS clears from the security engine.
In addition, deriving master keys requires the KEK, which SX OS also clears from the engine.
These keys are available when DRM is bypassed, and so my current intent with exosphere is to perform key derivation the same way as real secmon on mariko.
Last edited by SciresM,
- Joined
- Jul 7, 2010
- Messages
- 3,882
- Trophies
- 2
- Location
- /dev/random
- Website
- www.gudenau.net
- XP
- 5,379
- Country
Well, it should be possible to remove the modchip so if it can't be made to work I can remove it.
Once I get that installed I will be more than happy to help debug Hekate/Atmosphere on it with you guys.
D
Deleted User
Guest
This key is only required if you want to extract the warmboot firmware from a package1. Where will you pull the right package1 from that matches the fuses? Can't extract it from eMMC. At that point you are better off pulling the right warmboot firmware from sdcard, ready to use.
So, key not needed.
Only if you intend to use the exact same keyblob present in each package1 that Nintendo recrypts with a different seed for each firmware. I doubt you want to copy those 1:1 in exosphere.
At that point you might just build a proper masterkey table that can be derived more easily.
So, key not needed.
Disagree on both points.
We can't embed Nintendo warmboot firmwares, they need to be extracted. The current plan is to cache any warmboot firmware we've extracted in the past to disk; BEK is needed to decrypt from current fw so that the cache can be maintained and built on each boot.
And I do indeed intend to use the exact same keyblob, actually. Exosphere supports having newest master key in engine on older firmware; exosphere on mariko will always embed the seed for the latest master key, which will be used to derive the older ones as Nintendo does it.
So yeah, atmosphere won't boot without both of those keys.
If SX OS doesn't have them in the engine I'll just direct people to break the DRM
- Joined
- Jul 7, 2010
- Messages
- 3,882
- Trophies
- 2
- Location
- /dev/random
- Website
- www.gudenau.net
- XP
- 5,379
- Country
Disagree on both points.
We can't embed Nintendo warmboot firmwares, they need to be extracted. The current plan is to cache any warmboot firmware we've extracted in the past to disk; BEK is needed to decrypt from current fw so that the cache can be maintained and built on each boot.
And I do indeed intend to use the exact same keyblob, actually. Exosphere supports having newest master key in engine on older firmware; exosphere on mariko will always embed the seed for the latest master key, which will be used to derive the older ones as Nintendo does it.
So yeah, atmosphere won't boot without both of those keys.
If SX OS doesn't have them in the engine I'll just direct people to break the DRM
I mean, this is the correct way to do it. But caching it might not be a great idea because it would allow people to just plop it on the SD card. Maybe encrypt it with the serial number or something?
Preventing people from tampering with the cache isn't important; atmosphere just can't distribute the firmwares and must extract/unpack them on device.
- Joined
- Jul 7, 2010
- Messages
- 3,882
- Trophies
- 2
- Location
- /dev/random
- Website
- www.gudenau.net
- XP
- 5,379
- Country
I meant more to help prevent people from distributing Nintendo code in packs they might make.
D
Deleted User
Guest
Packs are going to be a thing. For sure.
Is it legal to embed the keyblob from Nintendo's package1 1:1 ?
Is it legal to embed the keyblob from Nintendo's package1 1:1 ?
Last edited by ,
Similar threads
- Solved
- No one is chatting at the moment.
-
-
@
Sonic Angel Knight:
Or, I also heard that if you use flash memory, it can act as more "RAM" at least windows tell me when I stick a flash drive into it. -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
K3Nv2:
I can think of the design teams process another joystick and no audio or a joystick and mono audio -
-
-
-
-
-
-
-
