Update Jtaggable, but not jtag it?

[xbrguy]

Is it possible to update a jtaggable console to the current dashboard, but do it manually. I mean read the nand, apply the changes, and write the nand back. The idea is that the CPU fuse will not be blown. Is it possible?

[Blackaddr]

Remove R6T3 or use the solder bridging method to disable the fuse burning circuit.  These are the only safe methods to ensure you don't lock out your console.

And no, you can't update in the way you suggested.  A rebooter like XBR or Freeboot first has to boost into the KK exploitable kernel, executes the exploit then custom loads a newer dashboard after it has taken control.  If you want 9199, use freeboot.  You'll have to wait to see if freeboot gets updated to support the Kinect dash.

[Xumpy]

Blackaddr I was wondering, if you know your cpu key... Is'nt it possible (at least on a xenon without hash check) to rebuild a kinect dashboard with your own cpu key and change the ldv values inside the nand to let it boot...

It wouldn't let you run homebrew but you could always downgrade your dashboard if you want it to...

[xbrguy]

Thats what I was thinking also. Just like if i get a console with the 6690 dashboard and jump straight to the lastest, the ldv values are not the same as if i install each dashboard. It leads me to believe that if you do know your CPU key this could be done.

It could be a way to use the features of the lastest dashboard without losing the jtag hack for some.

[Keihanzo]

Sorry but what you suggest is not possible. We all have to wait to a new rebooter in order to keep using our jtagged consoles as usual.

BTW: I´ve heard that there could be some issues about us getting an updated rebooter. Just hope there are wrong 

[Blackaddr]

I am by no means an expert on the kernel so I'm sure someone can explain much better, but my understanding is based on the following:

Firstly, without executing the exploit to run unsigned code, all code must be correctly signed and any changes to the BLs wil break the signature (including changing the expected LDV).  It's not the CPU key that's the problem, it's the digital signature.

Read happy_bunny's post here http://www.xboxhacker.org/index.php?topic=15665.msg114334#msg114334

His psuedo-code indicates the LDV must EXACTLY match the fuseline count.  I interpret this to mean that your fuseline count doesn't count by 1 per update per say, it means that it is burned up to the value required to match the CB you are updating too.  I admit this seems to contradict what has been previously posted about how the LDV counts work.

This is why you don't have an exploitable kernel if you go straight from launch kernel to 9199.

As for the rebooter, Ikari has designed freeBOOT to launch the 9199 dashboard after booting the exploitable KK kernel.  The dash needs to be signed with your CPU key because the much of the chainloading still applies with regards to encryption, however the sig check is bypassed.

In order for you to modify your exploited console to boot into a newer dash, you must modify the rebooter appropriately.

So, you don't need your CPU key to run unsigned code on an exploitable CB.  You DO need your CPU key to run an actual MS dashboard, such as rebooting into 9199.

In summary, without exploiting the console, you cannot modify ANYTHING in the system that is digitally signed.  This includes ALL the bootloaders, but does not include the SMC code (which is why you can modify it before exploiting).

Once you have exploited the console and are running unsigned code, you can do whatever you want.  If you have the expertise to reboot into a newer kernel, then you can do so.

So far only the freeBOOT and XBR teams have publicly demonstrated the ability to reboot properly.  If freeBOOT and XBR teams decide to no longer make new releases, we are stuck on 9199 until someone else updates the rebooter and releases it.

I have not tried, but I don't think dropping a kinect dash nand into ibuild is all that's required to update freeBOOT to a different dash.

[Shaun]

the LDV values are hashed in the header to CB and CF/CG i think which are not signed at they can be unique per console.  The hash is generated using CPUKEY amongst others.
I very much suspect the NEWER dashboards which revoke the old exploitable CB also have kernels which check if they booted from the newer CB.
If so, then you will never be able to boot a NEW dash from an old CB without modifying the kernel to skip the check, which can only be done with a modified kernel so catch 22

[Keihanzo]

So far only the freeBOOT and XBR teams have publicly demonstrated the ability to reboot properly.  If freeBOOT and XBR teams decide to no longer make new releases, we are stuck on 9199 until someone else updates the rebooter and releases it.

I have not tried, but I don't think dropping a kinect dash nand into ibuild is all that's required to update freeBOOT to a different dash.

Back in the day we adapted 8507 dash to run on 8498 original rebooter, some months later we tried to do the same with 9199 but it didn´t worked. I think that you need the source of the rebooter or some other tool in order to adapt it to other dashes. Something related to different memory addresses I think.

Afaik, the development of a new rebooter is something that very few people can do, so let´s hope somebody willing to work at it have the source of the original ones if it´s true that original teams decided to quit.

[inspuration]

Rebooting is easier said than done, but it might be impossible if the freeboot source is never released.