Jump to content


Photo

Possible Efuse Faker?


  • Please log in to reply
25 replies to this topic

#16 hobosrock696

hobosrock696

    X-S Enthusiast

  • Members
  • 21 posts

Posted 20 June 2011 - 09:06 PM

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...

#17 No_Name

No_Name

    X-S Freak

  • Members
  • PipPipPipPipPip
  • 1,154 posts

Posted 20 June 2011 - 10:19 PM

QUOTE(hobosrock696 @ Jun 20 2011, 01:06 PM) View Post

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.

#18 hobosrock696

hobosrock696

    X-S Enthusiast

  • Members
  • 21 posts

Posted 21 June 2011 - 02:14 AM

QUOTE(No_Name @ Jun 20 2011, 01:19 PM) View Post

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.

#19 Heimdall

Heimdall

    X-S Legend

  • Members
  • PipPipPipPipPipPipPipPipPip
  • 5,749 posts
  • Location:UK
  • Xbox Version:v1.4
  • 360 version:v4.0 (jasper)

Posted 21 June 2011 - 02:26 AM

QUOTE(hobosrock696 @ Jun 21 2011, 02:14 AM) View Post
I know nothing nor will I pretend to.

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

QUOTE(hobosrock696 @ Jun 21 2011, 02:14 AM) View Post
Just looking for technical evidence that such a plan is impossible to implement.
Let's get this the right way round. You provide technical evidence that it might be possible, then we can have a debate.


#20 hobosrock696

hobosrock696

    X-S Enthusiast

  • Members
  • 21 posts

Posted 21 June 2011 - 02:52 AM

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.

#21 No_Name

No_Name

    X-S Freak

  • Members
  • PipPipPipPipPip
  • 1,154 posts

Posted 21 June 2011 - 10:31 PM

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.

Edited by No_Name, 21 June 2011 - 10:32 PM.


#22 hobosrock696

hobosrock696

    X-S Enthusiast

  • Members
  • 21 posts

Posted 22 June 2011 - 08:36 PM

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?

Edited by hobosrock696, 22 June 2011 - 08:56 PM.


#23 No_Name

No_Name

    X-S Freak

  • Members
  • PipPipPipPipPip
  • 1,154 posts

Posted 22 June 2011 - 11:18 PM

QUOTE(hobosrock696 @ Jun 22 2011, 12:36 PM) View Post

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.


#24 juggahax0r

juggahax0r

    X-S Expert

  • Members
  • PipPipPip
  • 603 posts
  • Location:Dayton, OH
  • Xbox Version:none
  • 360 version:v5.0 (360S - trinity)

Posted 24 June 2011 - 04:12 AM

QUOTE(hobosrock696 @ Jun 22 2011, 03:36 PM) View Post

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?


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.

#25 hobosrock696

hobosrock696

    X-S Enthusiast

  • Members
  • 21 posts

Posted 24 June 2011 - 04:38 AM

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 biggrin.gif

Edited by hobosrock696, 24 June 2011 - 04:53 AM.


#26 juggahax0r

juggahax0r

    X-S Expert

  • Members
  • PipPipPip
  • 603 posts
  • Location:Dayton, OH
  • Xbox Version:none
  • 360 version:v5.0 (360S - trinity)

Posted 24 June 2011 - 05:18 AM

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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users