Hacking 3DS Firmware has been decrypted

[DarkShinigami]

well i for one hope the 3ds is closer to being hack but i want it hacked to get arround the region locked

once that happens i will buy the 3ds project diva game in a heartbeat

 

[AdnanMuhammed]

....so we gonna get youtube and flash soon? also maybe some sort of messenger/voice chat homebrew? Cause I'd rather have that over free games.

 

[Slowking]

The common key isn't in the firmware, its somewhere in the hardware. like the wii key where in broadway.

Well the Wii key also was in the firmware, multiple times, since Nintendo sucked at security.

 

[SifJar]

but with a common key you can decrypt cant you? is that not the more important part of the equation ? with p3 there was only decrypt with common key and some fake sign tool right?

No ps3 had a flaw which meant the private key was able to be calculated, so actual signing could be done. That was fixed in 3.60 and above, so private key can't be found anymore, so no more signing. The 3.60 public keys were recently released, meaning 3.60 content can be decrypted, but not encrypted. Anything over 3.60 remains unable to be decrypted.

 

[KiiWii]

Anything over 3.60 remains unable to be decrypted.

Unless its a TB patch, which can now also be decrypted for 3.55 thanks to duplex.

E.g. Max Payne 3

TBH I only think I would buy a 3DS if it gets hacked.

 

[FireGrey]

the possibility exists that some team develop some exploit

already working in some exploit?

No one outside of neimod and maybe a few others knows what's going on, so who knows. Probably not though since no one knows if encryption's been broken....

the possibility exists that some team develop some exploit

we still cant sign anything...(unless of course the common key is just there in the files that were unencrypted..... If thats even happened lol)

No, the common key CANNOT sign anything.
Regardless Nintendo wouldn't leave it so carelessly. Leaving it plaintext in the firmware would be like leaving your house key under the mat.

Maybe they left their key under a fake rock.

 

[Cyan]

Anything over 3.60 remains unable to be decrypted.

Unless its a TB patch, which can now also be decrypted for 3.55 thanks to duplex.
E.g. Max Payne 3

No, the "TB" are not decrypted. They are debug Eboots + DRM.

The recent "TB crack" is only the DRM check which is bypassed.
The eboots are still the one provided by TB team (debug eboots, which are unsigned and run on any cfw able to run unsigned eboots). Duplex didn't provide new eboots that the TB team didn't.

If the release teams (Duplex) don't know how to get or create debug eboots, they are still dependent on the TB team. And I suspect that TB team will stop providing such eboots at all if their DRM is bypassed, unless they make a new DRM.

Well, debug are also decrypted? maybe SifJar can explain it better? I didn't follow the TB hack very closed.

 

[dicamarques]

I think it was the psp common key that was in the ps3 firmware.

The PSP and the PS3 Used the same key (Common and Private) so finding in the psp would also work in the ps3.

 

[LuigiBlood]

The 3DS Common Key is in the hardware. Nintendo learned from its mistakes.

 

[KiiWii]

No, the "TB" are not decrypted. They are debug Eboots + DRM.

The recent "TB crack" is only the DRM check which is bypassed.
The eboots are still the one provided by TB team (debug eboots, which are unsigned and run on any cfw able to run unsigned eboots). Duplex didn't provide new eboots that the TB team didn't.

If the release teams (Duplex) don't know how to get or create debug eboots, they are still dependent on the TB team. And I suspect that TB team will stop providing such eboots at all if their DRM is bypassed, unless they make a new DRM.

Well, debug are also decrypted? maybe SifJar can explain it better? I didn't follow the TB hack very closed.

Correct me if I am wrong:

If this were true how come debug eboots havent proved useful to date? I'm 99% sure people have obtained debug eboots but they wont run on CEX FW.

TB somehow cracked either getting debug eboots to work or found an exploit for cracking some (not all) eboots without keys.

No one knows what the truth is behind TB, but I thought we couldn't run debug eboots on retail cfw's.

 

[SifJar]

No, the "TB" are not decrypted. They are debug Eboots + DRM.

The recent "TB crack" is only the DRM check which is bypassed.
The eboots are still the one provided by TB team (debug eboots, which are unsigned and run on any cfw able to run unsigned eboots). Duplex didn't provide new eboots that the TB team didn't.

If the release teams (Duplex) don't know how to get or create debug eboots, they are still dependent on the TB team. And I suspect that TB team will stop providing such eboots at all if their DRM is bypassed, unless they make a new DRM.

Well, debug are also decrypted? maybe SifJar can explain it better? I didn't follow the TB hack very closed.

My understanding of the topic was that TB were able to decrypt the EBOOTs from games requiring 3.60+, and they then re-encrypted the EBOOTs with their own key, which was stored in their dongle (the results were then released under the release group names "Paradox" and "ParadiSO" or something like that). Their CFW would then use the key from the dongle to decrypt the EBOOTs and play them; without the dongle, their key wasn't present and the EBOOTs couldn't be decrypted. But I haven't really read too much about TB stuff and could be completely wrong. You seem to know more about this than I (as with most PS3 stuff).

I haven't heard of "debug EBOOTs" before, but that seems plausible to me. I may look into it more later if I get a chance.

EDIT: Although this all has nothing to do with the 3DS...
EDIT: A little research later...Looks like Cyan is right about them being debug EBOOTs. And the TB CFW contains patches to run debug EBOOTs, patches which I don't believe are present in other FWs. Debug EBOOTs can be obtained using a modified PS3 and downloading via a proxy. Apparently they are also signed using TB's own keys, presumably so that even if someone else does figure out the patches for another CFW, the TB EBOOTs can't be used (i.e. debug EBOOTs would be needed to be obtained/released independently from TB's releases).

Note that I am still not 100% clear on the whole thing, so this post could be slightly inaccurate. I still intend to look into this further at a later date, and may update this post again at some time.

EDIT: OK, from reading here, it would appear that what is happening is this: TB get the debug EBOOTs for games (for disc based games, I assume these are updates, so it will only work for games that have an update I guess?), which are unencrypted, they then encrypt these EBOOTs with keys that only work with their CFW, which in turn only works (fully) with their dongle present because of the DRM in the dongle.

 

[Seratonin]

Anything over 3.60 remains unable to be decrypted.

Unless its a TB patch, which can now also be decrypted for 3.55 thanks to duplex.

E.g. Max Payne 3

TBH I only think I would buy a 3DS if it gets hacked.

Are you saying that we will only see 3ds's with hardware mods is it gets hacked?

 

[3DSGuy]

Anything over 3.60 remains unable to be decrypted.

Unless its a TB patch, which can now also be decrypted for 3.55 thanks to duplex.
E.g. Max Payne 3

No, the "TB" are not decrypted. They are debug Eboots + DRM.

The recent "TB crack" is only the DRM check which is bypassed.
The eboots are still the one provided by TB team (debug eboots, which are unsigned and run on any cfw able to run unsigned eboots). Duplex didn't provide new eboots that the TB team didn't.

If the release teams (Duplex) don't know how to get or create debug eboots, they are still dependent on the TB team. And I suspect that TB team will stop providing such eboots at all if their DRM is bypassed, unless they make a new DRM.

Well, debug are also decrypted? maybe SifJar can explain it better? I didn't follow the TB hack very closed.

No they weren't debug (un-encrypted) eboots, TB eboots are just flagged as fself (fake self/debug self), probably so the TB dongle would be notified to intervene and decrypt the eboot when a TB eboot is played. And TB wasn't relying on debug game updates, to get unencrypted eboots, 99% of TB eboots were fixes of the original disc eboot.

Also just to clarify, proper Debug eboots(fself) are not encrypted, and anyone can make debug eboots. The PS3 SDK has been leaked numerous times, which can make debug eboots.

 

[SifJar]

No they weren't debug (un-encrypted) eboots, TB eboots are just flagged as fself (fake self/debug self), probably so the TB dongle would be notified to intervene and decrypt the eboot when a TB eboot is played. And TB wasn't relying on debug game updates, to get unencrypted eboots, 99% of TB eboots were fixes of the original disc eboot.

Also just to clarify, proper Debug eboots(fself) are not encrypted, and anyone can make debug eboots. The PS3 SDK has been leaked numerous times, which can make debug eboots.

According to this page, they are debug EBOOTs, which are then encrypted with the TB keys so that they only work with the TB CFW, which in turn only works with the TB dongle inserted. The same could be done with the regular 3.55 keys and the results could be played on a regular 3.55 console apparently. If you have a better source of information, please share it as I'm rather interested in reading about it. (I find the whole "piracy dongles with DRM" thing from the PS3 rather interesting).

 

[3DSGuy]

No they weren't debug (un-encrypted) eboots, TB eboots are just flagged as fself (fake self/debug self), probably so the TB dongle would be notified to intervene and decrypt the eboot when a TB eboot is played. And TB wasn't relying on debug game updates, to get unencrypted eboots, 99% of TB eboots were fixes of the original disc eboot.

Also just to clarify, proper Debug eboots(fself) are not encrypted, and anyone can make debug eboots. The PS3 SDK has been leaked numerous times, which can make debug eboots.

According to this page, they are debug EBOOTs, which are then encrypted with the TB keys so that they only work with the TB CFW, which in turn only works with the TB dongle inserted. The same could be done with the regular 3.55 keys and the results could be played on a regular 3.55 console apparently. If you have a better source of information, please share it as I'm rather interested in reading about it. (I find the whole "piracy dongles with DRM" thing from the PS3 rather interesting).

Source:Myself/Knowledge of PS3/looking at TB eboots. There are many speculated methods on obtaining decrypted eboots, which mostly surrounds dumping the RAM, in some form (and having the keys, but having the keys is unlikely). Nothing confirmed of course. But they are re-encrypted versions of the original disc eboots, I haven't checked Duplex's 'anti-drmed' TB eboots, but they should be the same size as the disc original eboot. When they say debug eboot, they mean an eboot flagged as debug in the SCE header. Again TB obtain decrypted eboots (to which they apply DRM to) from a source other than debug fselfs(that is unless they get debug copies of every game they've patched again unlikely). What you see when you look at a TB eboot, is simply the result of their DRM process. The fself flag among other things in the SCE Header, is simply a way for the DRM distinguish between regular eboots and TB eboots(after all, all a SCE header does(for selfs) is tell the PS3 what the eboot is). Especially since fselfs are treated differently by the PS3 simply for been an fself(it has to be modified to accept them). And of course the encryption of TB eboots is part of the DRM.

EDIT: If you don't believe me, here's a quote from the dev wiki regarding the 'fself nature' of TB eboots:

Real FSELFs are never encrypted. You can extract it with official unfself tool from SDK.
But, in this FSELF I looked into (driver sf) ELF inside IS encrypted. You can say this because it's masterdisc fself, but I really doubt it.
It doesn't look like a proper fself to me at all, in header it says that sections unecrypted, but it's not true.
Another thing - Masterdisc Generator tool from Sony gives errors with this EBOOT (if it's a masterdisc eboot as stated, why?).

 

[SifJar]

Source:Myself/Knowledge of PS3/looking at TB eboots. There are many speculated methods on obtaining decrypted eboots, which mostly surrounds dumping the RAM, in some form (and having the keys, but having the keys is unlikely). Nothing confirmed of course. But they are re-encrypted versions of the original disc eboots, I haven't checked Duplex's 'anti-drmed' TB eboots, but they should be the same size as the disc original eboot. When they say debug eboot, they mean an eboot flagged as debug in the SCE header. Again TB obtain decrypted eboots (to which they apply DRM to) from a source other than debug fselfs(that is unless they get debug copies of every game they've patched again unlikely). What you see when you look at a TB eboot, is simply the result of their DRM process. The fself flag among other things in the SCE Header, is simply a way for the DRM distinguish between regular eboots and TB eboots(after all, all a SCE header does(for selfs) is tell the PS3 what the eboot is). Especially since fselfs are treated differently by the PS3 simply for been an fself(it has to be modified to accept them). And of course the encryption of TB eboots is part of the DRM.

EDIT: If you don't believe me, here's a quote from the dev wiki regarding the 'fself nature' of TB eboots:

I get what you're saying, true FSLEFs aren't encrypted. But that doesn't mean that the decrypted EBOOTs TB have access to aren't the debug EBOOTs (i.e. FSELFs). As I see it, it is perfectly possible they have access to the FSELFs (debug EBOOTs) of the games they release "patches" for, and they apply their DRM to those (including the encryption with their own keys) so they only work with the dongle. I see no other way for them to obtain decrypted EBOOTs for newer games unless they had all the newer keys, in which case they could release far more fixed games than they do. They could possibly also create some sort of software to allow users to fix games themselves (without giving the keys away; that part could be tricky, but they've managed to protect their EBOOTs this far, they could probably have a decent attempt at protecting the keys also). AFAIK, the only way to get unencrypted EBOOTs is debug EBOOTs (FSELFs), so that must be their "starting point" for each fix, right?

EDIT: The quote from the dev wiki you posted is found under this header:

old talk

(seems obsolete and incorrect in many ways)

I wouldn't put too much faith in that quote...

EDIT: Just found this post above:

The PSP and the PS3 Used the same key (Common and Private) so finding in the psp would also work in the ps3.

No they didn't. The PS3 firmware just contained (some of) the keys needed to (sort of) sign stuff for the PSP.

 

[ZombiePosessor]

Why is there all this talk of old PS3 eboots and shit instead of what the topic is about? Who gives a shit about PS3 stuff, there's a PS3 section where you guys can talk about that shit.

 

[Ace Overclocked]

Why is there all this talk of old PS3 eboots and shit instead of what the topic is about? Who gives a shit about PS3 stuff, there's a PS3 section where you guys can talk about that shit.

Because people are thinking of the possibility of using those methods on a 3ds.

 

[Fudge]

Why is there all this talk of old PS3 eboots and shit instead of what the topic is about? Who gives a shit about PS3 stuff, there's a PS3 section where you guys can talk about that shit.

Because people are thinking of the possibility of using those methods on a 3ds.

No.

 

[Rydian]

Why is there all this talk of old PS3 eboots and shit instead of what the topic is about? Who gives a shit about PS3 stuff, there's a PS3 section where you guys can talk about that shit.

Yeah, 'cause we all know that the 3DS and PS3 have absolutely no technology or security methods in common whatsoever.

Oh wait.