xboxscene.org forums

Pages: 1 [2]

Author Topic: InFeCtuS Programmer 0.0.3.4.D and Infectus Tool 1.1  (Read 238 times)

The Prankster

  • Archived User
  • Full Member
  • *
  • Posts: 127
InFeCtuS Programmer 0.0.3.4.D and Infectus Tool 1.1
« Reply #15 on: May 24, 2007, 09:48:00 PM »

Unless you have a previous backup of your NAND, then no. NAND is per-box.
Logged

The Prankster

  • Archived User
  • Full Member
  • *
  • Posts: 127
InFeCtuS Programmer 0.0.3.4.D and Infectus Tool 1.1
« Reply #16 on: May 24, 2007, 11:44:00 PM »

QUOTE
This is what makes it interesting.

When 10 People read out their NAND with the same Kernel Version and 10 with another Kernel Version,
we should get enough data to exactly work out the differences on a Binary Level.

Those differences on the same Kernal can be seen as the unique identifier. The comparism with the other Kernal helps to identify the position of this information bit. Given that this identifier follows certain pattern it should be possible to adjust a generic kernal to it's own mobo.

Anyone with an Infectus interested on a test run?


That poses quite an interesting view. Would be cool if it was plausible, though it's all signed by M$, thus not allowing any altering, so if we removed the per-box key, and replaced with another, it would not be signed and would not work and not bootup.
Logged

caster420

  • Archived User
  • Hero Member
  • *
  • Posts: 938
InFeCtuS Programmer 0.0.3.4.D and Infectus Tool 1.1
« Reply #17 on: May 25, 2007, 05:03:00 AM »

QUOTE(Infinium @ May 25 2007, 01:51 AM) View Post

Those differences on the same Kernal can be seen as the unique identifier. The comparism with the other Kernal helps to identify the position of this information bit. Given that this identifier follows certain pattern it should be possible to adjust a generic kernal to it's own mobo.


You will find difference but there will be no pattern.  Those sections of the NAND that are encrypted per-box are done so using the fuseset values.  Thus, there be sectors that are encrypted differently per box and you can figure that out but you will not be able to 'adjust' a generic kernel to another motherboard without the fuseset values.  The only way to get these values currently is to have an exploitable kernel.  If you have already upgraded to 4552 or later, you can't get these values.  So, there will be no downgrading at this point.  All of the encryption of the NAND is pretty much figured out, you just need to read the proper threads.

For those hoping to downgrade, if you already have 4552, you can't go back to a kernel prior to it at this point.  I am not sure about 5759.  They may have done the same as the 4552 upgrade, which you can't corrupt the applied patches and downgrade.

As for the user who asked about cutting traces, etc... The NAND has a pinout on the bottom of the motherboard.  Very easy to solder too if you can solder.

QUOTE(The Prankster @ May 25 2007, 02:20 AM) View Post


That poses quite an interesting view. Would be cool if it was plausible, though it's all signed by M$, thus not allowing any altering, so if we removed the per-box key, and replaced with another, it would not be signed and would not work and not bootup.


If you could reverse the encryption of the per-box sections, had your fuseset values, you could in theory re-encrypt those sections and have it boot.  No need for it to be signed.

Caster.
Logged
Pages: 1 [2]