Xbox 360 的 PowerPC CPU 具有 768 位（bit） eFUSE，这是母公司 IBM 发明的一项技术，并可以在某些处理器中实现。
eFUSE 是 CPU 上的硬件保险丝，以“熔断”为二进制值
（1 熔断，0 未熔断），在 Xbox 360 中，有 768 个熔丝，每四个bit组成一位数字，每十六位数字组成一组保险丝组。
4bit*16位*12行＝768bit
虽然每个熔丝都可以单独熔断，但它们以 8 个为一位，为 CPU Key 和 fuseset 00 生成二进制值，而不是 XeLL 实际显示的十六进制值，XeLL显示的十六进制值需要四个四个看才对应实际二进制。从技术上讲，可查看的保险丝只有 192 个，也就是每一位的头部。

原文链接/free60.org/Hardware/Fusesets

当你（从 Linux 中的 XeLL 或 dump32）请求 Fuseset 熔丝值时，它们看起来像这样：

但是他们的真实二进制值不一样
如果您实际上直接读取保险丝，它们看起来像这样（0 是未烧毁的保险丝，1 是烧毁的保险丝）这里应该有 768 个 1 和 0，因此 eFUSE 是“768 位”。
这没有任何意义，只是为了展示 eFUSE 的实际设置方式。

Fuseset 00
所有机器只要出厂进行烧录，都是一样的值
c0后面全是f，c0代表jtag接口锁定位。是的，所有cpu从物理性质上都支持jtag

Fuseset 01
这些是在工厂烧录的，在游戏机制造后，它们显示游戏机是否是开发套件。在对游戏机的闪存进行刷写后，如果是Retail零售主机，它还会禁用开发机 CPU 无连线直接调用 JTAG 接口的特性，也就使得 JTAG 破解主机需要焊接连线，以及刷写 SMC 南桥固件。

Fuseset 02
这是 2BL/CB（第二个引导加载程序，存储在 NAND 闪存中）的锁定计数器。
每次游戏机更新其 CB 引导加载程序时，其中之一都会被烧毁（这种情况并不常见），这就是无法恢复已更新至 2.0.8***.0 的 JTAG 破解的原因，即使您拥有 CPU 密钥
（2BL 使用 CPU/1BL 密钥加密，但使用 Microsoft 私钥签名，因此您无法更改 NAND 中锁定的计数器，计数器不匹配即出现 SMC 与 CPU 配对失败的0022三红代码。或者即使您更改了 NAND 中的计数器成为匹配熔丝位，引导加载程序也将无法通过签名检查，并出现崩溃）
但是主机只检查最后一位熔丝f 的位置
所以就出现可替换Xenon的可JTAG CPU至Zephyr
Falcon的可JTAG CPU至Jasper的骚操作，只需烧写一下熔丝
可进行JTAG破解的f位置：
Xenon 第二位
Zephyr 第三位
Falcon 第四位
Jasper 第五位
从第六位开始如果被烧写，只能使用RGH了

任意厚机主板应该都能实现jtag破解

Fusesets 03-06
这些构成了CPU Key。
一开始都是零，并且在游戏机出厂前通过网卡烧录。
第一次启动时会随机烧录，它们用于加密密钥库和引导加载程序部分。
每个主机的 CPU 密钥都是唯一的，有时称为“每主机独特的密钥”。
要查找 CPU Key，请看向保险丝组 03 和 05，或 04 和 06。例如，此控制台的 CPU密钥将为 9FB0174015744DAFD569BAD6958DAE9D。

Fuseset 07-11
这些组成了游戏机的“锁定计数器”。
从 4532/4548 系统更新到 4598 这一次开始，每次系统更新后它们都会被烧录一位。
它们会阻止旧版本的Dash在更新之后的游戏机上运行。
此部分中有足够的 eFUSE，可供 Microsoft 更新游戏机系统 80 次。该控制台的锁定计数器为 FFFF00000...，这意味着自 2.0.4548.0 运行以来，它已收到 4 次更新。
Microsoft 最初打算仅在系统更新修补关键漏洞（例如 4532 和 4548 中的虚拟机管理程序，KK漏洞）时才烧毁 eFUSE，但现在决定自更新到 4598 以来的每次更新都会烧毁 eFUSE。
在 NAND 的 6BL(CF) 中部分，还有另一个锁定计数器应该（在正常情况下）与CPU上的熔丝相匹配。如果不匹配，控制台将在启动时出现紧急情况，并显示 RRoD 0022三红。
现在，这反而是最好的部分！如果我们知道游戏机的 CPU Key，我们可以解密 6BL，并更改 NAND 中的锁定计数器以匹配游戏机上的Fuseset中的位数，从而运行较旧的系统。
由于 6BL 没有用微软的私钥签名，所以只要我们有 CPU 密钥，我们就可以随意编辑它。

获取CPU熔丝的程序代码
这就是BL获取它的方法