- Joined
- Aug 29, 2008
- Messages
- 6,258
- Trophies
- 2
- Age
- 39
- Location
- Hiatus Hell
- Website
- yourmom.com
- XP
- 4,692
- Country
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.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.
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.Could be, my guess is nobody knows. Let's wait till the Homebrew Bounty and see what he has to sayhmmm does it rhyme with clack?
Maybe I'm being stupid, but what pun?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)
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.
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]
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?
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
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?)
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)
what are the odds of sdk getting leakedIf 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..