Hacking Question How To Launch Hekate From SX Core?

SciresM

Developer
Developer
Joined
Mar 21, 2014
Messages
973
Trophies
3
Age
33
XP
8,294
Country
United States
I meant more to help prevent people from distributing Nintendo code in packs they might make.

Implementing that kind of thing (while nice) is mostly a waste of my time tbh.

Is it legal to embed the keyblob from Nintendo's package1 1:1 ?

Can't be decrypted without compromising the hardware to get BEK/KEK, no technical measure's being circumvented via its inclusion.

Atmosphere's been following a policy of key-sources-are-okay, keys-are-not under that rationale for forever. It's all legally gray, but there's some safety to be found in the fact that the keyblob is completely useless without the compromised console that has KEK in the engine.

Same key sources as N using same data in engine as N also lends itself better towards interoperability arguments.
 
Last edited by SciresM,
  • Like
Reactions: RednaxelaNnamtra

gudenau

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,882
Trophies
2
Location
/dev/random
Website
www.gudenau.net
XP
5,376
Country
United States
Packs are going to be a thing. For sure.

Is it legal to embed the keyblob from Nintendo's package1 1:1 ?

I think that's gray area, but they can definitely use DMCA for that. Would be a hard case to fight, especially since people don't know what crypto really is.

Implementing that kind of thing (while nice) is mostly a waste of my time tbh.

Fair enough.
 
D

Deleted User

Guest
Implementing that kind of thing (while nice) is mostly a waste of my time tbh.



Can't be decrypted without compromising the hardware to get BEK/KEK, no technical measure's being circumvented via its inclusion.

Atmosphere's been following a policy of key-sources-are-okay, keys-are-not under that rationale for forever. It's all legally gray, but there's some safety to be found in the fact that the keyblob is completely useless without the compromised console that has KEK in the engine.

Same key sources as N using same data in engine as N also lends itself better towards interoperability arguments.

Since TX already has the proper fuse-matching warmboot in their boot.dat, can't you ask TX to place the warmboot firmware in a specific spot in memory so it can be used by exosphere? This would be way easier for users without fiddling with a cache.
 

SciresM

Developer
Developer
Joined
Mar 21, 2014
Messages
973
Trophies
3
Age
33
XP
8,294
Country
United States
Since TX already has the proper fuse-matching warmboot in their boot.dat, can't you ask TX to place the warmboot firmware in a specific spot in memory so it can be used by exosphere? This would be way easier for users without fiddling with a cache.

Not really a good option given how fusee's memory layout/heap works. Not infeasible in practice, but honestly I expect "you can wake/sleep assuming you have ever booted into the firmware corresponding to your fuses" is a trivial ask for users. I'm sure hekate/ams can collaborate to make sure cache management requires no real effort from user/is painless. That's preferable to me than loading firmware from hardcoded memory layout.

Doesn't solve the KEK problem, either. I really don't understand why SX OS a) overwrites those keys with their custom PRNG-derived ones, and then b) clears their PRNG-derived keys from the engine before jumping to payloads.
 
  • Like
Reactions: RednaxelaNnamtra

gudenau

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,882
Trophies
2
Location
/dev/random
Website
www.gudenau.net
XP
5,376
Country
United States
Not really a good option given how fusee's memory layout/heap works. Not infeasible in practice, but honestly I expect "you can wake/sleep assuming you have ever booted into the firmware corresponding to your fuses" is a trivial ask for users. I'm sure hekate/ams can collaborate to make sure cache management requires no real effort from user/is painless. That's preferable to me than loading firmware from hardcoded memory layout.

Doesn't solve the KEK problem, either. I really don't understand why SX OS a) overwrites those keys with their custom PRNG-derived ones, and then b) clears their PRNG-derived keys from the engine before jumping to payloads.

Just ask them to stop being butts about it. That will clearly work. /s

Edit:
I asked them via the contact form that they have, I was polite and asked for a reason and why it matters to me. I am sure nothing will come of this, but it is worth a shot.
 
Last edited by gudenau,
  • Like
Reactions: RednaxelaNnamtra

smf

Well-Known Member
Member
Joined
Feb 23, 2009
Messages
6,642
Trophies
2
XP
5,860
Country
United Kingdom
Is it legal to embed the keyblob from Nintendo's package1 1:1 ?

Which law? Which country? In most (all?) countries you can't copyright a key.

In the US if it is part of an access control used to prevent unauthorised access to content then any equivalent operation (deriving it at runtime, asking the key to source it etc) is also a DMCA violation. In the US they specifically name games consoles as not getting a DMCA exemption for repairing or running homebrew. Mobile phone do get an exemption, but weirdly tablets don't.
 
Last edited by smf,

SciresM

Developer
Developer
Joined
Mar 21, 2014
Messages
973
Trophies
3
Age
33
XP
8,294
Country
United States
@json SX OS 3.0.3 no longer clears KEK, but still clears BEK. Still insufficient to do boot (and prevents booting stock with hekate, and breaks wake-from-sleep still).

The code in the bootloader no longer clears keyslots before handing over...but the BOOT.dat header specifies to overwrite keyslots 0x2FFF, which is keyslots 0-11 and 13. 13 is the BEK, so this overwrites it with garbage.
 

gudenau

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,882
Trophies
2
Location
/dev/random
Website
www.gudenau.net
XP
5,376
Country
United States
@json SX OS 3.0.3 no longer clears KEK, but still clears BEK. Still insufficient to do boot (and prevents booting stock with hekate, and breaks wake-from-sleep still).

The code in the bootloader no longer clears keyslots before handing over...but the BOOT.dat header specifies to overwrite keyslots 0x2FFF, which is keyslots 0-11 and 13. 13 is the BEK, so this overwrites it with garbage.

That's an improvement at least. How much of it has been reverse engineered? Any chance the FPGA/CPLD could be flashed with a custom bitstream? Would it be possible to load the keys from a RCM mode key dump that I already have?

Sorry for all the stupid questions.
 

bibititou

Member
Newcomer
Joined
Aug 30, 2020
Messages
18
Trophies
0
Age
26
XP
102
Country
France
Hekate works on chipped erista, and you can run Atmosphere after clean-up in SX CORE menu.

Are you sure about that ? I am searching about using Atmosphère under an Erista Ipatched and SX Core, but someone told me we cannot run Hekate without RCM mode...
 

HenryMin

Well-Known Member
Member
Joined
Jun 19, 2020
Messages
141
Trophies
0
XP
1,136
Country
Korea, South
Are you sure about that ? I am searching about using Atmosphère under an Erista Ipatched and SX Core, but someone told me we cannot run Hekate without RCM mode...

Yes I'm sure about that.

Hekate itself works without any modification.
And if you want to boot AMS, you have to run 'Clean Up' in SX CORE menu before fusee or hekate injection.
 
Last edited by HenryMin,
  • Like
Reactions: masbass and Kioku

PapaHelmeritus

Active Member
Newcomer
Joined
Sep 3, 2020
Messages
41
Trophies
0
Age
41
XP
79
Country
Finland
SX OS 3.0.5 with SX Core needs support to be built into Hekate to be able to boot it and with that for Lockpick_RMC.

Hopefully it would be coming so I can get my keys and continue using eshop.
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    Psionic Roshambo @ Psionic Roshambo: There is some really odd DS games I liked but not sure others would like them lol