Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Hi there,
There is an issue with role permissions that is being worked on at the moment.
If you are having trouble with access or permissions on regional forums please post here to get access: https://www.boards.ie/discussion/2058365403/you-do-not-have-permission-for-that#latest

If you have updated to dash 8XXX or above - what can you do

  • 25-02-2010 2:10pm
    #1
    nbrady20009
    Registered Users, Registered Users 2 Posts: 260 ✭✭


    If you have updated to dash 8XXX or above - what can you do - read HERE !

    The xell exploit exists and works for the following reasons.
    45xx kernel can be made to boot by applying the patch data to a zeropaired image.
    Once the 45xx kernel is in place, the modified smc patches the kernel (aka king kong exploit) and we take hold of the system to do what we like.

    For historic purposes, I mention that the exploit can ONLY work on the 45xx kernel.
    Also, dashboard updates blow an EFUSE aka LDV (lock down value) which is 1 TYPE of efuse, there are several more.
    There is also a 2nd efuse row which is used for making sure only the type of CB which is meant for your system can be loaded.
    This is present IN ALL VERSIONS OF CB.
    The version of this counter is hard programmed into the CB version and it checks the value in the CPU to make sure it is allowed to boot as soon as it is ran.
    This is what stops a 1920 or below CB running on a >= 1921 CB system (this was when the timing attack was disabled)
    Previously, the version of CB only ever changed at time of manufacture or when a faulty system was sent to a repair centre.

    However, in the summer, the 8xxx update was released which also updated the CB on every console hardware type as well as the dashboard.
    So this means it blows 2 efuses. One on row 1 which is an increment to the LDV, and one to the 2nd fuseline which disables ALL other versions of CB from booting.
    There is NO WAY we can get an unallowed CB version to boot without having the key which M$ signs the code with to enable us to modify the CB, or by removing a blown efuse - either way, it just cant happen.

    What this CB does is specifically revoke all 45xx kernel versions (which are the only ones which contain the HV vulnerability)
    You cannot get 45xx to boot on a console with CB >= 8xxx EVER
    I believe that the jtag ability does exist still, but it is worthless at this point because it cannot do anything (the kk exploit does not exist so we cannot patch or take control of the system)
    In future the jtag ability may be removed completely.

    With some luck this may get read and understood by people who have just updated their vulnerable consoles to 8xxx or beyond.
    The simplest solution if you want to keep an exploitable console, is to remove the R6T3 resistor which permanently disables efuse blowing.



    Credit to Shaun at XBH


Comments

  • #2
    TouchingVirus
    Registered Users, Registered Users 2 Posts: 8,584 ✭✭✭TouchingVirus


    If you remove the R6T3 resistor to prevent an update then won't your console RROD if you ever accidentally update it. This can be a disaster if you have no intention of JTAGing and just remove the resistor to be safe - no nand backup, RROD, problems ahoy! :D

    Obviously it'd be a silly person who removed R6T3 with no intention of JTAGing, but stranger things have happened I'm sure.


  • #3
    Myrddin
    Closed Accounts Posts: 33,733 ✭✭✭✭Myrddin


    Damn, as soon as I seen "READ HERE!" I got my hopes up for a new exploit...:(


  • #4
    docentore
    Registered Users, Registered Users 2 Posts: 1,582 ✭✭✭docentore


    EnterNow wrote: »
    Damn, as soon as I seen "READ HERE!" I got my hopes up for a new exploit...:(

    why? you should have at least 3 jtagged consoles at this stage ;P


  • #5
    TouchingVirus
    Registered Users, Registered Users 2 Posts: 8,584 ✭✭✭TouchingVirus


    EnterNow wrote: »
    Damn, as soon as I seen "READ HERE!" I got my hopes up for a new exploit...:(

    The last one took 4 years to find and exploit properly, don't hold your breath :D


  • #6
    Myrddin
    Closed Accounts Posts: 33,733 ✭✭✭✭Myrddin


    docentore wrote: »
    why? you should have at least 3 jtagged consoles at this stage ;P

    I have one standard with a drive flash and two jtag'able, one is done as per my build log. The other is sitting here about to be heavily violated :p
    TouchingVirus wrote: »
    The last one took 4 years to find and exploit properly, don't hold your breath :D

    Ah I was just kidding, I have two jtags now so Im catered to. Still, these units are getting scarce fast! It would be nice to see an exploit for later Kernels, but as you advised - I wont hold my breath :)

    What exactly is an e-fuse anyway?


  • Advertisement
  • #7
    nbrady20009
    Registered Users, Registered Users 2 Posts: 260 ✭✭nbrady20009


    EnterNow wrote: »
    I have one standard with a drive flash and two jtag'able, one is done as per my build log. The other is sitting here about to be heavily violated :p



    Ah I was just kidding, I have two jtags now so Im catered to. Still, these units are getting scarce fast! It would be nice to see an exploit for later Kernels, but as you advised - I wont hold my breath :)

    What exactly is an e-fuse anyway?

    This should explain.


Advertisement