Post by: sowa99 on January 08, 2006, 09:06:00 AM
edit
Ooops, sorry, I wanted post this topic here http://forums.xbox-scene.com/index.php?showforum=151 (IMG:style_emoticons/default/unsure.gif)
Sorry
This post has been edited by sowa99: Jan 8 2006, 05:12 PM
Post by: Math1 on January 09, 2006, 06:08:00 PM
Post by: Avenger 2.0 on January 10, 2006, 11:28:00 AM
Post by: deadparrot on January 15, 2006, 09:07:00 AM
Post by: MrDaemon on January 28, 2006, 07:33:00 PM
QUOTE(Avenger 2.0 @ Jan 10 2006, 12:59 PM) 
Everyone says CPU, but I kind of doubt that (it would be very expensive).
It makes absolutly zero sense to say that the BIOS would be in the CPU, I think parrot is on the right track.
Post by: edude03 on April 09, 2006, 04:29:00 PM
Wouldn't THAT be very expensive? if they were gunna spend all that money on custom CPU's
its would make sense to spend a litte more money and get way better security?
Post by: Maverick0984 on April 21, 2006, 12:28:00 PM
if they are installing custom processors already, it is not hard in theory to include the BIOS on the chip itself...it could be loaded in the internal cache of the processor. what this does is require a larger cache, so it will still act like a normal cache, but will allow anything BIOS related to be almost instantaneous since a BIOS load is already pretty quick, but in the first level of cache would allow it to be very quick.
the problem with this however, would be any sort of BIOS update, surely MS didn't get it right on the first try, and there will and probably already have been BIOS updates. it would be nearly impossible to update a BIOS on the processor by downloading an update...installing...and continuting like nothing happened. Reason is, the BIOS would have to be in a protected section of the cache that doesn't allow righting over...hense less hacking potential. in theory, MS could send a signal in saying, "hey we're MS, allow us to rewrite", but it would still almost certainly require a reboot, and even then just creates more potential for screw ups.
To sum up, it probably isn't on the processor simply because it could create problems on the mass production side of things requiring updates, however, it certainly good be the case if they really wanted to and isn't all that more expensive, nor does it make "zero sense" as Mr Daemon says.
Post by: BlueCop on April 21, 2006, 07:52:00 PM
we already know that each flash is different and has to have to different key to decrypt it.
That key is stored in the cpu. a bootloader to load the encrypted code into ram would be embeded in the cpu.
this way the key and the bootloader could be contained within the cpu. that way the encryption key and decryption routine never leaves the cpu so it can't be sniffed on any bus. Bunnie was only able to hack the first xbox because he sniffed a bus that had the rc4 key travel accross it. This was the way the orginal xbox was able to make new hacked bioses. they didn't want a hack once apply everwhere attack so they made each cpu have a different key embedded.
we know the cpu uses efuses to store information in the processor and this would be how the key and bootloader are stored.
if you look up efuses and ibm you will get alot of information.
also cache is volatile memory so can't store permanent information there. if you search there are lots of articles on the processor and how the 360 cpu uses a shared cache. there were several part artcles on this.
this bootloader and key stored in the cpu enables the nand flash to be updated while the bootloader remains safe in the cpu.
plus there are crazy things like checksumed/encrypted ram and hypervisor to deal with.
i don't know what all has been confirmed but i would bet that the bootloader thing is correct.
Maverick0984: i think you are thinking too much simply there can be static code in one place to load dynamic code in another place. the static code would simple be a secure way to load the dynamic one. cpu containing the static code whle the nand flash containing the dynamic. this wouldn't really effect manufactoring and updating. plus using efuses in the cpu allows all the system to have custom keys and individualize each system to eliminate the hero attack and also allow future updates to the bootloader(on the manufactoring level) should a flaw be discovered. they learned flaws in the mcpx in the orginal xbox because they had to have nvidia go through the process of designing a new chip with new mcpx code. with efuses they simplely update the code they first write to the cpu when it is booted.
sorry i rambled. i am not sure of anything but i don't think you guys are ethier.
Later I got to go smoke the hydroponic chronic. i missed the 4/20 celebration so now i have to hit is hard a day late.
This post has been edited by BlueCop: Apr 22 2006, 02:56 AM
Post by: littlestevie360 on May 20, 2006, 08:21:00 AM
Another point that i base this hypothesis off is that if you were to trace the shortest path to the CPU from the NAND flash (TSOP) there is a very big sniff area, Path from TSOP to south bridge, South bridge to GPU, then the final path to the CPU.... GPU to CPU Via the (easily intercepted with an LSA [no guarentee of being readble]) Hypertransport.... if you ask me that would be stupid
read how this CPU works and you will notice that the bootstrap is most likely stored in the secure section of the processor.
PS: running the bootloader through an analogue bus would be dumb wouldnt it? because the only external enty point to the processor is through the PHY, which is an analogue/digital converter and gateway (this has INTERCEPT WITH ME written all over it)
littlestevie360
Post by: rainingdesign on October 15, 2006, 01:52:00 AM
QUOTE(deadparrot @ Jan 15 2006, 09:38 AM) 
Isn't it stored on the NAND Flash (Kernel+Dash) along with the second boot loader which hash checks the kernel on the NAND which in itself is hash checked by the CPU?
would it be hard to find out what the hash of the second boot loader is and then just make it so its always sent to the cpu in return instead of the actaull hash? Im sure if that was possible it would be a great step forward in being able to run homebrew software such as xbmc.