Hacking 6.2.0 Key Generation could (POSSIBLY) be UNCRACKABLE.

  • Thread starter Thread starter Essasetic
  • Start date Start date
  • Views Views 66,957
  • Replies Replies 253
  • Likes Likes 3
Status
Not open for further replies.
I wrote a short explanation in another thread so I'll repost it here:

The new key generation explained:

The switch has an Nvidia coprocessor ( a second processor) inside of it called the TSEC or Falcon that handles cryptographic operations like AES and verifying signatures. This processor is ordinarily supplied a firmware when the switch boots and then hands over the TSEC key to the boot loader so it can decrypt and load the rest of the firmware.

What was changed in 6.2 is that the TSEC firmware now derives one of the decryption keys internally rather than letting the boot loader do it. This means that despite having full control over the boot process, the derivation of this key now happens secretly where we cannot see it.

I'm looking at the TSEC firmware now to research this process but it may be simply out of our reach unless we can exploit or trick the TSEC into doing what we want or leaking the info. Here is a screenshot I took of reverse engineering the 6.2 TSEC firmware.

View attachment 149848
 
I wrote a short explanation in another thread so I'll repost it here:

The new key generation explained:

The switch has an Nvidia coprocessor ( a second processor) inside of it called the TSEC or Falcon that handles cryptographic operations like AES and verifying signatures. This processor is ordinarily supplied a firmware when the switch boots and then hands over the TSEC key to the boot loader so it can decrypt and load the rest of the firmware.

What was changed in 6.2 is that the TSEC firmware now derives one of the decryption keys internally rather than letting the boot loader do it. This means that despite having full control over the boot process, the derivation of this key now happens secretly where we cannot see it.

I'm looking at the TSEC firmware now to research this process but it may be simply out of our reach unless we can exploit or trick the TSEC into doing what we want or leaking the info. Here is a screenshot I took of reverse engineering the 6.2 TSEC firmware.

View attachment 149848
Well it's some form of progress :)
 
I wrote a short explanation in another thread so I'll repost it here:

The new key generation explained:

The switch has an Nvidia coprocessor ( a second processor) inside of it called the TSEC or Falcon that handles cryptographic operations like AES and verifying signatures. This processor is ordinarily supplied a firmware when the switch boots and then hands over the TSEC key to the boot loader so it can decrypt and load the rest of the firmware.

What was changed in 6.2 is that the TSEC firmware now derives one of the decryption keys internally rather than letting the boot loader do it. This means that despite having full control over the boot process, the derivation of this key now happens secretly where we cannot see it.

I'm looking at the TSEC firmware now to research this process but it may be simply out of our reach unless we can exploit or trick the TSEC into doing what we want or leaking the info. Here is a screenshot I took of reverse engineering the 6.2 TSEC firmware.

View attachment 149848


Oh! Looks like they finally convinced Nvidia to lend a hand.
I believe cracking 6.2 will bring true CFW.
 
I wrote a short explanation in another thread so I'll repost it here:

The new key generation explained:

The switch has an Nvidia coprocessor ( a second processor) inside of it called the TSEC or Falcon that handles cryptographic operations like AES and verifying signatures. This processor is ordinarily supplied a firmware when the switch boots and then hands over the TSEC key to the boot loader so it can decrypt and load the rest of the firmware.

What was changed in 6.2 is that the TSEC firmware now derives one of the decryption keys internally rather than letting the boot loader do it. This means that despite having full control over the boot process, the derivation of this key now happens secretly where we cannot see it.

I'm looking at the TSEC firmware now to research this process but it may be simply out of our reach unless we can exploit or trick the TSEC into doing what we want or leaking the info. Here is a screenshot I took of reverse engineering the 6.2 TSEC firmware.

View attachment 149848

do the TSEC firmware have to been signed or you can run your own?
 
do the TSEC firmware have to been signed or you can run your own?
You can run your own but you are limited without entering authenticated mode, which needs "unknown secrets" simply said.

I'm looking at the TSEC firmware now to research this process but it may be simply out of our reach unless we can exploit or trick the TSEC into doing what we want or leaking the info
Could maybe do a side channel attack, else... pretty much. Break cauth
 
  • Like
Reactions: iriez and tom95
Smash won't include 6.2.0. The game has gone gold a while ago, which means production has been well underway before 6.2.0 released, so it's impossible for it to come with it or require it. Hell, even Pokemon doesn't require 6.0.0 or 6.1.0, it requires 5.1.0.

As for 2019 games, I am 100% certain 6.2.0 will be cracked long before the first game releases. Unfortunately for Nintendo, pirates having hardware access means there is nothing long term they can do.
 
  • Like
Reactions: matias3ds
I wrote a short explanation in another thread so I'll repost it here:

The new key generation explained:

The switch has an Nvidia coprocessor ( a second processor) inside of it called the TSEC or Falcon that handles cryptographic operations like AES and verifying signatures. This processor is ordinarily supplied a firmware when the switch boots and then hands over the TSEC key to the boot loader so it can decrypt and load the rest of the firmware.

What was changed in 6.2 is that the TSEC firmware now derives one of the decryption keys internally rather than letting the boot loader do it. This means that despite having full control over the boot process, the derivation of this key now happens secretly where we cannot see it.

I'm looking at the TSEC firmware now to research this process but it may be simply out of our reach unless we can exploit or trick the TSEC into doing what we want or leaking the info. Here is a screenshot I took of reverse engineering the 6.2 TSEC firmware.

View attachment 149848

You can run your own but you are limited without entering authenticated mode, which needs "unknown secrets" simply said.


Could maybe do a side channel attack, else... pretty much. Break cauth

also very dumb question, if we have full boot access and the instruction set of tegra is well understood, can this problem be solved by loading a sw layer between cpu and software that intercept all system calls and alterate some to load CFW component?
that would make having the key unnecessary?
 
Last edited by tom95,
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum