Hacking CiTRUS development

[MelodieOctavia]

Ah. That makes a lot of sense. Cool.

 

[CollosalPokemon]

This is pretty old news. And just for clarification, Xcution's colleagues didn't seem too amused by his contributions.
http://3dbrew.org/wiki/Talk:CiTRUS

It was mostly Trap15 talking trash...Yellows8 (Team Twiizers) didn't make a bad comment about it. But most of the comments were from his first beta anyways...
He actually updated his CXI though; it's not really old news.

Xcution's homebrew tool requires the RSA keys to work, therefore he is dependent on the hardware guys to find them for him. That's why I don't consider his contributions important right now. He's a software guy, it's the hardware guys who will crack this open if it is to be at all.

Or an exploit. I think it is more of a lib3ds. It's important for homebrew, but it does require an exploit. If an exploit comes the RSA wouldn't matter.
I still think it's good that this is getting done ahead of time, 'cause the 3DS scene doesn't exactly know everything about CXIs yet. (even though you're right, the hardware guys will be the ones to exploit/allow exploits to be made)

 

[SifJar]

I don't think it's really a "lib3ds", more of just a compiler as I understand. In other words, you provide it with all the raw materials, and it'll turn them into a CXI. lib3ds implies an SDK with a bunch of functions specific for the 3DS etc. I don't think there's such a library with any such functions.

 

[Foxi4]

I'm just wondering why he assumes that this image is actually correctly compiled code. Sure, it falls right into the categories, but he can't test it on actual hardware since he can't encrypt or sign it.

What about hardware adresses? How does he even know that the binary would run if signed if he has no idea what exactly he's coding? Hell, even the CPU appears to be custom-made for Nintendo, even if he used ARM Assembly, he has no guarantee that the code would actually work.

At this point, this is sort of... "junk", really.

It's like taking some random code, slapping a DS header onto it and calling it an .nds binary. It's not - it's junk code with a header on it.

 

[Rydian]

Yeah this isn't a library, it's about the executable format itself.

And yeah the project in general is old news, this is just an update, but it's not an exploit. In order for it to be usable, an exploit would have to be made, then we'd have to make proper programs, this is step 2 with no step 1. A good thing still.

 

[Cyan]

I merged the new "CiTRUS update" topic into the main Citrus development topic.

 

[Deltaechoe]

Neimod is going to have to finish his work before these teams are going to be able to contribute anything useful. However once the system keys are spit out, the scene will explode from what I have seen (pun not intended)

 

[ferofax]

hmmm does it rhyme with clack?

Could be, my guess is nobody knows. Let's wait till the Homebrew Bounty and see what he has to say

if it's for Homebrew Bounty, it means it's a homebrew. which means he probably managed to crack a window. i don't see how an exploit can qualify as homebrew though.

 

[SifJar]

Neimod is going to have to finish his work before these teams are going to be able to contribute anything useful. However once the system keys are spit out, the scene will explode from what I have seen (pun not intended)

Maybe I'm being stupid, but what pun?

 

[Deltaechoe]

scene -> seen(pun)

(yes seen is a member function of scene rawr)

 

[reaper527]

I'm just wondering why he assumes that this image is actually correctly compiled code. Sure, it falls right into the categories, but he can't test it on actual hardware since he can't encrypt or sign it.

What about hardware adresses? How does he even know that the binary would run if signed if he has no idea what exactly he's coding? Hell, even the CPU appears to be custom-made for Nintendo, even if he used ARM Assembly, he has no guarantee that the code would actually work.

At this point, this is sort of... "junk", really.

It's like taking some random code, slapping a DS header onto it and calling it an .nds binary. It's not - it's junk code with a header on it.

do we know for a fact that he can't run his compiled code? more specifically, while he can't just put his output on a retail 3ds and go to town with it, he might able to make some verifications using a 3ds dev unit if he has access to one. [/hypothetical]

 

[Sicklyboy]

I'm just wondering why he assumes that this image is actually correctly compiled code. Sure, it falls right into the categories, but he can't test it on actual hardware since he can't encrypt or sign it.

What about hardware adresses? How does he even know that the binary would run if signed if he has no idea what exactly he's coding? Hell, even the CPU appears to be custom-made for Nintendo, even if he used ARM Assembly, he has no guarantee that the code would actually work.

At this point, this is sort of... "junk", really.

It's like taking some random code, slapping a DS header onto it and calling it an .nds binary. It's not - it's junk code with a header on it.

do we know for a fact that he can't run his compiled code? more specifically, while he can't just put his output on a retail 3ds and go to town with it, he might able to make some verifications using a 3ds dev unit if he has access to one. [/hypothetical]

Allow me to retort.

How do you propose one runs unsigned code?

 

[reaper527]

I'm just wondering why he assumes that this image is actually correctly compiled code. Sure, it falls right into the categories, but he can't test it on actual hardware since he can't encrypt or sign it.

What about hardware adresses? How does he even know that the binary would run if signed if he has no idea what exactly he's coding? Hell, even the CPU appears to be custom-made for Nintendo, even if he used ARM Assembly, he has no guarantee that the code would actually work.

At this point, this is sort of... "junk", really.

It's like taking some random code, slapping a DS header onto it and calling it an .nds binary. It's not - it's junk code with a header on it.

do we know for a fact that he can't run his compiled code? more specifically, while he can't just put his output on a retail 3ds and go to town with it, he might able to make some verifications using a 3ds dev unit if he has access to one. [/hypothetical]

Allow me to retort.

How do you propose one runs unsigned code?

it was a hypothetical question because i am uncertain about the security on a dev unit (which realistically probably does run unsigned code). i was hoping someone more familiar with those kits could chime in with an answer about if he would be able to test his output on a dev unit

 

[CollosalPokemon]

I'm just wondering why he assumes that this image is actually correctly compiled code. Sure, it falls right into the categories, but he can't test it on actual hardware since he can't encrypt or sign it.

What about hardware adresses? How does he even know that the binary would run if signed if he has no idea what exactly he's coding? Hell, even the CPU appears to be custom-made for Nintendo, even if he used ARM Assembly, he has no guarantee that the code would actually work.

At this point, this is sort of... "junk", really.

It's like taking some random code, slapping a DS header onto it and calling it an .nds binary. It's not - it's junk code with a header on it.

do we know for a fact that he can't run his compiled code? more specifically, while he can't just put his output on a retail 3ds and go to town with it, he might able to make some verifications using a 3ds dev unit if he has access to one. [/hypothetical]

Allow me to retort.

How do you propose one runs unsigned code?

it was a hypothetical question because i am uncertain about the security on a dev unit (which realistically probably does run unsigned code). i was hoping someone more familiar with those kits could chime in with an answer about if he would be able to test his output on a dev unit

Nope. They still need signed code. (of course the signing and encryption keys for Dev-Units are different than retail units' keys)

However, all CTR (3DS) SDK software contains universal SD card signing keys. (Dev-Unit NAND signing keys (different than Retail-Unit NAND signing keys) have to be obtained separately, but not terribly difficult to obtain for Dev-Units)
The Dev-Unit NAND keys are also universal, it's just most developers don't need NAND access so it's not included in the SDK by default.

 

[reaper527]

i see, so in other words, since we have a universal signing key, the dev unit may require signed code, but we can sign it ourselves? (meaning the main point of my post was accurate?)

 

[CollosalPokemon]

i see, so in other words, since we have a universal signing key, the dev unit may require signed code, but we can sign it ourselves? (meaning the main point of my post was accurate?)

Well yes, provided a developer leaks his keys (or the SDK is leaked because it also contains Dev SD keys - DIFFERENT THAN RETAIL SD KEYS)
The Dev NAND keys, well, only a handful of them are distributed so those are less likely to be leaked. It could happen, but not every developer has the NAND keys. And actually there are several different NAND keys for different purposes. I heard a few of those Dev NAND keys aren't really distributed much, if at all. (I assume the NAND keys to make firmware for the DevUnit are very rarely distributed to Developers, for instance)

Basically:

1 key for DevUnit SD import
(3? Maybe more?) keys for DevUnit NAND importing

The DevUnit NAND keys all allow importing to the NAND, but depending on which one was used to sign it may import for different purposes. (NAND Application, NAND System, Firmware, ect)
The keys are indeed universal for DEV UNITS ONLY. The keys CANNOT be used on retail units. So, I could, for example, have a friend with a dev unit and send him an application I make and it'll work on both my unit and his without changing signing keys. The only exception is older dev units cannot import to the SD card (but they can be upgraded with software to newer revs and after they're upgraded they can import to the SD) so if I had a unit that could import to the SD, and my friend had an older unit where SD importing wasn't available, I would have to have and resign my application to import to the NAND so he could use my application.

The keys are universal, but the code isn't unsigned. (you'd still need to obtain the keys though, with DevUnit SD being the "easiest" to get) The main point of your post was that DevUnits can run unsigned code, which isn't accurate.
Also we don't have the universal signing keys for DevUnits yet, though. Or at least they aren't leaked publicly. Even if we did have them they wouldn't work on a retail unit.

This doesn't mean Xcution's contribution is worthless; it just means he's getting a head start so by the time an exploit comes we'll already be able to make homebrew. (an exploit would not check the signing keys)

 

[reaper527]

i see, so in other words, since we have a universal signing key, the dev unit may require signed code, but we can sign it ourselves? (meaning the main point of my post was accurate?)

Well yes, provided a developer leaks his keys (or the SDK is leaked because it also contains Dev SD keys - DIFFERENT THAN RETAIL SD KEYS)
The Dev NAND keys, well, only a handful of them are distributed so those are less likely to be leaked. It could happen, but not every developer has the NAND keys. And actually there are several different NAND keys for different purposes. I heard a few of those Dev NAND keys aren't really distributed much, if at all. (I assume the NAND keys to make firmware for the DevUnit are very rarely distributed to Developers, for instance)

Basically:

1 key for DevUnit SD import
(3? Maybe more?) keys for DevUnit NAND importing

The DevUnit NAND keys all allow importing to the NAND, but depending on which one was used to sign it may import for different purposes. (NAND Application, NAND System, Firmware, ect)
The keys are indeed universal for DEV UNITS ONLY. The keys CANNOT be used on retail units. So, I could, for example, have a friend with a dev unit and send him an application I make and it'll work on both my unit and his without changing signing keys. The only exception is older dev units cannot import to the SD card (but they can be upgraded with software to newer revs and after they're upgraded they can import to the SD) so if I had a unit that could import to the SD, and my friend had an older unit where SD importing wasn't available, I would have to have and resign my application to import to the NAND so he could use my application.

The keys are universal, but the code isn't unsigned. (you'd still need to obtain the keys though, with DevUnit SD being the "easiest" to get) The main point of your post was that DevUnits can run unsigned code, which isn't accurate.
Also we don't have the universal signing keys for DevUnits yet, though. Or at least they aren't leaked publicly. Even if we did have them they wouldn't work on a retail unit.

This doesn't mean Xcution's contribution is worthless; it just means he's getting a head start so by the time an exploit comes we'll already be able to make homebrew. (an exploit would not check the signing keys)

i see, thanks for elaborating. (my main point was actually if it was possible for him to test his work on a dev unit, the whole unsigned code aspect was just the premise i incorrectly used to reach that conclusion). i hadn't realized that the universal signing key hadn't leaked. when i saw your first post mentioning a universal signing key, i assumed it is something that had been leaked and made available.

i also wasn't necessarily referring to the average user being able to use Xcution's work on retail (because obviously an exploit would be needed for that), but just if there was some feasible way for him to test it at all to verify that it does what its supposed to do (since my post was in response to someone saying there is no way for him to test it). since the universal signing keys aren't available, i guess using a dev unit to test would be out of the question.

 

[Rydian]

The lack of ability to test is what called this project into question a few times before.

 

[shawnanastasio]

If the SDK comes with a 3DS emulator (It most likely does), and is able to run unsigned code, thats a way to test it... That is, if the SDK gets leaked..

 

[nukeboy95]

If the SDK comes with a 3DS emulator (It most likely does), and is able to run unsigned code, thats a way to test it... That is, if the SDK gets leaked..

what are the odds of sdk getting leaked

nintendo wud never let that get leaked and who ever leaked it nintendo wud kill