- 精华
- 0
- 帖子
- 2381
- 威望
- 0 点
- 积分
- 2729 点
- 种子
- 5 点
- 注册时间
- 2006-1-13
- 最后登录
- 2020-12-5
|
发表于 2011-9-2 02:39 · 加拿大
|
显示全部楼层
本帖最后由 snailium 于 2011-9-1 14:04 编辑
几位大人息怒，吵了这么多楼没见到有翻译的
小弟不才，斗胆翻译一下，顺便纠正之前我犯的错误
建设中，请暂时不要引用
tmbinc said it himself, software based approaches of running unsigned code on the 360 mostly don't work, it was designed to be secure from a software point of view.
tmbinc说过，在软件层面上破解360来运行未签名的代码 这条路基本上走不通。360的软件层设计得很安全。
The processor starts running code from ROM (1bl) , which then starts loading a RSA signed and RC4 crypted piece of code from NAND (CB).
CPU从ROM（1BL）引导，然后由1BL从NAND载入经过RSA签名和RC4加密的二级引导程序CB。
CB then initialises the processor security engine, its task will be to do real time encryption and hash check of physical DRAM memory. From what we found, it's using AES128 for crypto and strong (Toeplitz ?) hashing. The crypto is different each boot because it is seeded at least from:
然后，CB开始引导CPU安全引擎。这个安全引擎的作用是进行实时加密运算和检查DRAM内存的特征值。目前为止，我们发现安全引擎使用AES128算法进行加密，同时使用另外一种算法计算强特征值（疑似Toeplitz算法）。每次引导之后，加密的数据都不一样，因为加密时使用的种子数来自于以下几点，甚至更多：
- A hash of the entire fuseset.
- 整个fuseset的特征值
- The timebase counter value.
- 一个基于时间的计数器值
- A truly random value that comes from the hardware random number generator the processor embeds. on fats, that RNG could be electronically deactivated, but there's a check for "apparent randomness" (merely a count of 1 bits) in CB, it just waits for a seemingly proper random number.
- 一个硬件产生的真随机数（注：无法重新产生的数）。在老版360上，硬件随机数生成器可以关闭，但是CB中还要检查一下这个随机数是否“看上去是随机的”（可能是查一下随机数中“1”的数量），CB只是需要一个“看上去随机”的数。
CB can then run some kind of simple bytecode based software engine whose task will mainly be to initialise DRAM, CB can then load the next bootloader (CD) from NAND into it, and run it.
之后，CB就可以运行一些简单的引擎，来初始化DRAM内存。然后，CB从NAND导入下一级引导程序CD，并运行之。
Basically, CD will load a base kernel from NAND, patch it and run it.
CD会从NAND导入底层内核，在此之上做一些更新并运行之。
That kernel contains a small privileged piece of code (hypervisor), when the console runs, this is the only code that would have enough rights to run unsigned code. In kernel versions 4532/4548, a critical flaw in it appeared, and all known 360 hacks needed to run one of those kernels and exploit that flaw to run unsigned code. On current 360s, CD contains a hash of those 2 kernels and will stop the boot process if you try to load them. The hypervisor is a relatively small piece of code to check for flaws and apparently no newer ones has any flaws that could allow running unsigned code.
这个内核包含有一个带特权的小程序（hypervisor）。当主机运行时，只有这个小程序才有权运行未签名的代码（亦作“非法程序”）。在4532/4548版本的内核中，hypervisor还有一个严重缺陷，所有目前的360破解（注：指自制系统）都需要运行这个版本的内核才能激活这个缺陷，从而运行“非法程序”。在当前这批360主机中，CD中存有这两个版本的内核特征值，并且能据此停止执行这两个版本的内核程序。hypervisor只是一个小程序而已，所以之前的缺陷很快就被补上了，后续的版本都没有任何缺陷。
On the other hand, tmbinc said the 360 wasn't designed to withstand certain hardware attacks such as the timing attack and "glitching".
从另外一个角度，tmbinc说，360的设计并没有考虑去防止来此硬件层面的攻击，比如说时序攻击和glitching（注：这个不好翻译，基本上是扰动、杂波的意思）
Glitching here is basically the process of triggering processor bugs by electronical means.
在这里，glitching就是从硬件角度触发芯片缺陷的手段。
This is the way we used to be able to run unsigned code.
这就是我们用来运行“非法程序”的手段。
The reset glitch in a few words
简单介绍一下reset glitch
We found that by sending a tiny reset pulse to the processor while it is slowed down does not reset it but instead changes the way the code runs, it seems it's very efficient at making bootloaders memcmp functions always return "no differences". memcmp is often used to check the next bootloader SHA hash against a stored one, allowing it to run if they are the same. So we can put a bootloader that would fail hash check in NAND, glitch the previous one and that bootloader will run, allowing almost any code to run.
我们发现，CPU在低速运行的时候，向CPU发送一个短促的重置信号并不会重置CPU，相反，这会改变程序运行的结果。基本上，这是目前为止可以干扰memcmp函数结果，让其返回“对比一致”结果的最有效手段。memcmp常用来比对引导程序特征值，如果跟已知的特征值一致，引导程序就能获准继续运行（不一致则拒绝运行）。因此，我们可以在NAND上面放上任意的引导程序，哪怕特征值不一致，只要触发glitch，引导程序照样能获准运行，从而引导任何（我们想要的）程序。
Details for the fat hack
老版360破解细节
On fats, the bootloader we glitch is CB, so we can run the CD we want.
在老版360上，我们将要glitch的引导部分是CB，然后我们就能运行任意的CD。
cjak found that by asserting the CPU_PLL_BYPASS signal, the CPU clock is slowed down a lot, there's a test point on the motherboard that's a fraction of CPU speed, it's 200Mhz when the dash runs, 66.6Mhz when the console boots, and 520Khz when that signal is asserted.
cjak发现，在将CPU_PLL_BYPASS信号设为高电平后，CPU时钟大大减慢。在主板上有一个测试点，可以检测到CPU速度。在进入360界面之后，时钟频率为200Mhz；在主机启动的时候，时钟频率为66.6Mhz；将CPU_PLL_BYPASS信号设为高电平之后，时钟频率只有520Khz。
So it goes like that:
因此，我们可以这么做：
- We assert CPU_PLL_BYPASS around POST code 36 (hex).
- 在得到POST代码0x36的时候，将CPU_PLL_BYPASS设为高电平
- We wait for POST 39 start (POST 39 is the memcmp between stored hash and image hash), and start a counter.
- 等待POST代码0x39（这个信号代表memcmp正在比对特征值），然后启动计数器
- When that counter has reached a precise value (it's often around 62% of entire POST 39 length), we send a 100ns pulse on CPU_RESET.
- 当计数器到达一个数值的时候（一般来说是POST代码停留在0x39的总时间的62%），发送一个100ns长度的CPU_RESET信号。（注：按时钟周期为520Khz算，2us为一个时钟周期，100ns还不到半个时钟周期）
- We wait some time and then we deassert CPU_PLL_BYPASS.
- 稍等一会儿，然后重新将CPU_PLL_BYPASS置为底电平
- The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error AD, the boot process continues and CB runs our custom CD.
- CPU速度恢复正常，如果幸运的话，我们不会得到POST错误代码0xAD，启动过程将继续，CB将会启动我们植入的CD
The NAND contains a zero-paired CB, our payload in a custom CD, and a modified SMC image. A glitch being unreliable by nature, we use a modified SMC image that reboots infinitely (ie stock images reboot 5 times and then go RROD) until the console has booted properly. In most cases, the glitch succeeds in less than 30 seconds from power on that way.
NAND中需要有zero-paired CB，我们修改过的CD，以及修改过的SMC代码。有些时候，一次glitch并不会成功，所以我们需要一段修改过的代码让主机无限重启（官方固件只允许重启五次，不成功就会亮红灯），直到成功为止。大多数情况下，glitch会在开机后30秒之内完成一次成功的引导。
Details for the slim hack
The bootloader we glitch is CB_A, so we can run the CB_B we want.
On slims, we weren't able to find a motherboard track for CPU_PLL_BYPASS. Our first idea was to remove the 27Mhz master 360 crystal and generate our own clock instead but it was a diffi*** modification and it didn't yield good results. We then looked for other ways to slow the CPU clock down and found that the HANA chip had configurable PLL registers for the 100Mhz clock that feeds CPU and GPU differential pairs. Apparently those registers are written by the SMC through an I2C bus. I2C bus can be freely accessed, it's even available on a header (J2C3). So the HANA chip will now become our weapon of choice to slow the CPU down (sorry tmbinc, you can't always be right, it isn't boring and it does sit on an interesting bus ;)
So it goes like that:
We send an i2c command to the HANA to slow down the CPU at POST code D8 .
We wait for POST DA start (POST DA is the memcmp between stored hash and image hash), and start a counter.
When that counter has reached a precise value, we send a 20ns pulse on CPU_RESET.
We wait some time and then we send an i2c command to the HANA to restore regular CPU clock.
The cpu speed goes back to normal, and with a bit of luck, instead of getting POST error F2, the boot process continues and CB_A runs our custom CB_B.
When CB_B starts, DRAM isn't initialised so we chose to only apply a few patches to it so that it can run any CD, the patches are:
Always activate zero-paired mode, so that we can use a modified SMC image.
Don't decrypt CD, instead expect a plaintext CD in NAND.
Don't stop the boot process if CD hash isn't good.
CB_B is RC4 crypted, the key comes from the CPU key, so how do we patch CB_B without knowing the CPU key? RC4 is basically:
crypted = plaintext xor pseudo-random-keystream
So if we know plaintext and crypted, we can get the keystream, and with the keystream, we can encrypt our own code. It goes like that:
guessed-pseudo-random-keystream = crypted xor plaintext
new-crypted = guessed-pseudo-random-keystream xor plaintext-patch
You could think there's a chicken and egg problem, how did we get plaintext in the first place? Easy: we had plaintext CBs from fat consoles, and we thought the first few bytes of code would be the same as the new CB_B, so we could encrypt a tiny piece of code to dump the CPU key and decrypt CB_B!
The NAND contains CB_A, a patched CB_B, our payload in a custom plaintext CD, and a modified SMC image. The SMC image is modified to have infinite reboot, and to prevent it from periodically sending I2C commands while we send ours.
Now, maybe you haven't realised yet, but CB_A contains no checks on revocation fuses, so it's an unpatchable hack ! |
|
楼主: lovesum666
川公网安备 51019002005286号
发表于 2011-9-1 16:39 · 天津
