I'm no expert on this but I was trying to understand more about the IBM eFUSE and how it works and I came across an xbox 360 cpu datasheet with the eFUSE pinouts. I was thinking about how when you install 8948 and it blows eFUSES or if you have an updated CB and it would blow the eFUSES, would it be possible to take the efuse enable and the efuse vcc pinouts and wire them to a modchip and cut the tracks for the efuses and rewire them so you could send back a different signal and boot an older kernel? Would something of the sort be possible? Why or why not?

Thanks,
bifnewman

The efuses are completely contained inside the CPU chip itself, it does not have a trace leading outside the motherboard.

How does the southbridge know wether to boot the system or not? Also if you were to desolder the cpu from the mobo and wire it or put a chip between the two, would this sort of thing be possible?

No.

Care to explain? thanks for response

There is really not anything to explain. just that what you want to do is just not possible.

The reason is the Efuses are inside the CPU.. Unless you happen to have a fab plant capable of reproducing the same CPU as in the 360 with the Efuses unburnt then there is no way to bypass them once they are burnt.

Even then unless you know what fuses to burn to start with and how to burn the right sequence its pointless.

Not to mention you will end up with IBMs law team coming after you for fabricating their intellectual property.

See No was a nice simple answer that is not super complicated.

ok sorry

unblowing efuses is not financially viable ..

There is a team of people looking at this right now. http://www.xboxhacker.org/index.php?topic=15456.0

Ok I understand that the eFuses are located in side the cpu, but they must send some type of signal out telling the xbox to boot? Or how would the xbox know what kernals to blacklist and not boot?

Theres no external comuncation of it. You ask how it knows it doesnt.
It just eather boots (when has right fuses burnt) or it doesnt boot.

Sort of think of it like a door the lock is the efuses, the kernal is the key. Stick the wrong key in and nothings going to happen the door will stay locked and not open.

Then the xbox will relise and give you a error.

the southbridge doesent decide to boot, the cpu does...

Efuse Document


This is a very good short document on Efuses. Won't give you any hope in faking them, but it will show you that once they are blown they are indeed gone for good, At least in most cases certainly in the case of the Xbox360.

I have an idea - to make off for the bus address 0x8000 0200 0000 0104 on the data bus of the processor to set the 15th bit to 1, and the processor receives an address for the transition is shifted to 0x8000.
At 0x8000 0200 0000 8000 to connect the 32 bit ROM with an alternative 1BL. Solder wires have a lot of ...
In the performance of the program from the ROM, the processor must operate at a reduced rate because ROM is slow.

Your not taking into consideration the LDV.Also changing those values would break the signature of the bootloader and the console would not boot.Its not possible.

Couldn't this be done using a "middle-man" method of using a chip to intercept the data before it hits the cpu and modifying it to match with the current number of burnt e-fuses? I would think that's possible but then again I may be spewing bs...

WTF??

How do you intercept the data before it hits the CPU... when its already built in to the CPU??

You are spewing so much BS I am going to be sick.

Note to the noobs.. Noobie posts go in the noobie forum.. If you are speculating 'might this work' but have no idea what you are talking about, dont post in a technical thread.

Never claimed I was right... calm down on that and since when is the nand that holds the kernel in the cpu? I believe the kernel did the check on the efuses right? If so you could emulate the correct response from the cpu skipping over that check. Now I know that would not be extremely easy but possible and easy are two different things.
Disclaimer: I know nothing nor will I pretend to. Just looking for technical evidence that such a plan is impossible to implement.

If that is true then stop posting in a technical thread.

Let's get this the right way round. You provide technical evidence that it might be possible, then we can have a debate.

Here how about i rephrase a simple question and begone from here once I get a simple but informative answer. Would it not be possible to for example record the exact electrical signals that are sent to and from the cpu at boot up to the point where the efuse checks are done, read and save your nand, update to a newer kernel, record electrical signals going to and from the cpu up to the end of efuse checks, flash old nand back, boot using modchip to emulate recorded signals going to and from the cpu for the newer kernel and emulating signals for the older kernel going to and from north bridge and other things attached to the cpu.

Anyways I'm not posting here again was just hoping someone could point out an obvious flaw with that idea.

1LB is built in to the CPU, its on the CPU die. This kicks off the chain of trust.

2LB and so on are loaded from the nand and are secured in sequence.

The 360 boot chain is a fortress that had one flaw that has not been fixes, locked down and reenforced.

This is why this idea is dead in the water and why I aggressively shot down your idea.

The information is out there, its not hard to find out about the boot chain and why its quickly evident why such an idea could work hence me saying stick to the noob forums with random ideas like this.

Well I said I would not post again however.... 2BL is not the kernel its just the vm the kernel and hypervisor combine in 5BL I believe and the check for the kernel version is in 2BL so could you not just fake it in 2BL before the vm is loaded and everything is in encrypted memory?

EDIT: I am assuming it is possible to load a valid 2BL and later pair it with a valid kernel of a different version. If you cannot do that then this definitely does not work...

EDIT2: Nono I see 2BL checks the 2BL version and 4BL ensures you do not load an older kernel.

Last question then, would it be possible to pass 4BL what seems like the correct kernel to verify and then switch it out for an older kernel when its being loaded? That is what I was getting at if it was not clear. Or does it load the kernel into memory and then verify making it impossible to modify?

No as the who thing is located in encrypted memory plus you have to deal with an already running hyper vision by that time.

Like I said, the boot chain is a fortress it is a very very secure system to prevent what you are thinking of trying.

The eFuses are checked as early as 2BL , line 2 in the fuseset is the 2BL fuseline , this is why we can't downgrade 2BL to run an exploit again , they burned a 2BL fuse when they updated it making that impossible.
Unless a new exploit is found in the hypervisor , or in one of the bootloaders CD for example , there will be no new exploits for the Xbox 360. If an exploit were found in 4BL allowing what you said then yes that would possibly be able to be exploited , but not on it's own , and probably not without the CPU key which would also require an exploit.

eFuses are a difficult concept to fully understand , but you should do some more reading , years of research can be found on Xboxhacker. Burning the 2nd fuseline is really what killed the hack , well aside from what they actually put in the code to prevent the old kernel from running , if the CB had not changed the exploit would still be running , the new one blacklists the 4532/4548 kernel patches so without downgrading CB there is no way to exploit the old bug , without an exploit there is also no way to get a CPU key so that also hurts although even with that you still can't do anything, because CB is RSA signed not CPU key signed, you modify CB you break the signature.

As it was said , it is pretty much an impenetrable fortress of security at this point, unless some fatal bug is found in the newer hypervisor , or even in a bootloader , there will be no new exploit. Don't think it always has to be in the hypervisor, it just has to be able to exploit the old bug unless a new one is found , running of the old kernels would allow for a new way to exploit. The hackers who developed the Jtag hack thought way outside the box , but they did so much research they knew what wouldn't work , in the end think of what they came up with , an exploit in the GPU , just some access to the PCIe bus was needed to write into memory the same memory writes that the shader accomplished.

You would need the per console cpu key? I know now why it is impossible, this exploit, at least right now. I do not however understand what is signed by the cpu key. I was under the impression the only thing signed by the cpu key was the keyvault.

EDIT: Actually I think I'll go read some and find out more of what I've missed. Thanks to everyone who responded to disprove me

I don't remember everything that is CPU key signed but it is not only the KV. The CPU key would be needed if you wanted to increment the LDV value for example. Xboxhacker "what happened to important links and threads" would be the place to start your reading , it has all the important information consolidated into one area. The CPU key may not be required for certain exploits , the Jtag exploit for example at the heart of it does not require the CPU key , but to run a rebooter you need it , the Jtag lets you run Xell which gives you the CPU key. I know you need the CPU key too extract the base kernel and filesystem from a nand dump so something else has to be CPU key signed in there.

To answer the main question of the thread no you can't fake the eFuses with any type of attack. There were experiments with glitching the CPU to skip the check , but they were unsuccessful , even this was not an attempt at something which would have been able to be re created because glitching isn't something you can do every boot reliably. A new hypervisor exploit would be a godsend , as it would make the need to run the old kernel obsolete, MS is unlikely to make any mistakes like that again.