http://www.ps3hax.net/showthread.php?p=459578 如何读出 bootloader ，会想到这种方法真的蛮聪明的 DUMPING THE BOOTLDR As you know the bootldr is one of the two loaders that are signed per console and it was the only part of the system that haven't been hacked. Once you load it the same way as metldr (via SigNotify) it would start requesting different addresses that we don't control. You can take a look on my user page to the dma sequence that it produces. As you see it access a lot of different addresses and we don't have control of any of them so the first objective was to control the input/output. The sandbox: The objective was to redirect the flows of data to our controlled buffers so we know what is written or read. To achieve that a driver was created. This driver performs two functions: - the first is creating lv1 peek/poke using the patched lv114 that comes with OtherOs++ and other CFW. - the second is reserve a block of consecutive memory that would be used as an HTAB. The SPU is told to use our HTAB which in turns redirects to our user buffers. To get the physical address... the user pages are locked on memory and then using an old trick found by geohot their real address is retrieved. At this point we have control of what the SPU reads BUT if consecutive small accesses are done we have no control if we want to change something in between. The first exploit: I'm calling this an exploit but actually is a bad implementation of a feature cause it should be disabled on isolation. The feature is called the MFCLSACMP. Basically is a register on the spu that is checked before doing a dma op. If the source/target address on the SPU is inside the mask defined by this register then dma is stopped and an interruption is reported. Until this interrupt is cleared the dma is not started. SONY 在实做 SPU 指令集时候没有把一个叫 MFCLSACMP 的指令关掉，原则上 SPU 是 用不到这个功能的。这个功能启动时， SPU 在进行 DMA 存取动作之前，都会先进行 查核，待查核通过後，才会继续执行，否则暂停。 所以这个指令变成可以利用的中断旗标，只要我们用硬体方式把这个暂存器的值设成 1，就可以轻而易举的让 SPU 暂停，然後趁这个时候去修改记忆体里面的资料。为何 要改资料，因为这样才能实做接下来要处发的那个漏洞。 Great, so we control what it reads and when it is read... the first objective was achieved total control of the I/O. That is what you can see on my user page on wiki. However this all so allowed me to find the biggest problem on using the booldr as an oracle.... the config ring. The config ring is a series of bits that syscon sends to the cell before during the power up.... On this cell implementation the config ring is accessible from inside the spu as a read once channel. So unless I could find a way to refill the channel the bootldr couldn't be used as oracle. Even worse at this point I didn't know how the config ring was read (although an undocumented channel was on top of the list). I spent a couple weeks trying to figure the problem. Finally I posted the log on the wiki looking for help. Obviously some approach. We exchanged info. I gave then the tools and they gave me means of validating my hypothesis (those on the log) We worked a lot of time on this. Remember that I was trying to get an oracle not an exploit so filling the config was a must... several thing were tried but none worked. After a month or so I started checking other projects while thinking of what to do. Then after several months I decided to try to exploit it instead of using it.... given the log the entry point was clear... The bootldr exploit: bootldr 漏洞说明： If you see the log you'll see a lot of data exchanging between the spu and the syscon. graf had described it on his bible so it was known... but the log also said that the data was read twice once to read the header and once to read header + data. 你去读纪录档的话，可以看到 syscon 跟 spu 之间是频繁地在交换资料，注意到 资料的部份是要读两次才会读入，第一次先读标头，第二次才读标头跟资料本身 On the header was a variable length. So I decided to change the len between both reads.... didn't work until i corrected also the chksum... and then BINGO! unexpected behavior... a possible exploit was found. 这个标头里面有一个地方记载资料的长度，所以我在两次读取之间改变了这个值， 经过尝试後失败了。最後我把检核码改正之後，才成功让两次的标头都正确读入。 译注：简单说，第一次读标头之後决定要在记忆体中开多少空间来存放接下来要读 的资料，然後第二次就把刚刚记下来的长度一口气读进去，当然会用检核码验证资 料的正确性。但是呢，我们可以把一笔很短资料，比如说才 256 bytes 长的资料的 标头里面纪录长度的地方填入一个很大的值，例如 FFFF ，於是主机就会去记忆体 里面开 65536 bytes 的空间，但第二次读取前，又把长度改回原来大小，但主机没 有再去确认（根本想不到会有人这样搞）资料长度，所以就一口气读了 65536 bytes 的资料进去，形成违规存取。 这个违规存取有什麽好处呢，也许我们原来 256 bytes 这笔短资料後面跟着存放 的是 bootloader ，长度才 16384 bytes ，我们就有很高的机会把原本读不到的 bootloader 读到我们可以控制的记忆体区块中（ PS3 主机里面核心专用的记忆体 和使用者可用的记忆体虽然有划分开来，但在位址上是连续的），然後 dump 出来 。 The advantage of this exploit is that it gave us a lot of points to test. The info was shared and two of us friendly raced one against the other to find the correct possibility. I won the race of finding the execution point although I lost the one for dumping. The winner was command 0x20 which is an info message... casually the config error message... so their own protection had given us the bootldr. That's the story of the exploit... it was then decided that I got the ultimate decision of releasing the exploit and any of us could leak the keys... however they asked me too hold it until SONY has reacted to the dex conversion and I told them that I would not release them until I got the appldr keys by myself. I suppose they passed the keys to others and them at some point the keys probably arrived to EXETrimAll and N0DRM (I don't think they exploited trublue...). Meanwhile i was in the middle of my holidays and when I come back they were releasing non-stop so I didn't see that it was necessary to leak them. Unfortunately they also leaked to a scoundrel that sell the key to discblu. That forced some one that have the key to make it public. You said that I'm angry cause someone leak the key... nope. I was angry with discblu... and with some hacker that reappeared just to say that he already knew how to do it. As you can see the method is completely software and does not use the signature bug (except for installing the cfw... but then all the apps need to credit them). If you persist I'll tell you that this can also be done on a 3.15 with geohot pulse exploit. The code: http://www.sendspace.com/file/wvknol I have attached the code of a working version for latest exploitable slim. I know that also works on other version but I don't know which ones. It is only valid for NOR consoles cause it expects a full NOR flash as one of the parameters. It has two programs. One is a kernel module so it must be load with insmod. The second its a user program that takes as parameter the speID (i recommend using 0 that is normally enabled), the flash file and the output file. The dump is shifted by as a side effect of the bug. For me it was 0x800 bytes... but others got different result. The start function must be at 0x400 once shift is corrected BTW the code is ugly and there is a lot of data that is not used so if someone has questions please ask me (on this or other ps3 related things)... I'll be available until sunday... then I'll definitely leave. Now I'll explain my idea for the hardware solution. Improving the exploit 如何改进这个漏洞（让漏洞更稳定或是触发方式更简便） THE FOLLOWING IS ALL THEORETICAL AND IT WILL PROBABLY NOT WORK (I'M NOT A HARDWARE EXPERT AND THAT'S THE MOST DIFFICULT PART) In this case the objective is not dumping the bootldr but get code execution. Using an small payload a program will be copied to spu. That program will just copy a patched unencrypted lv0 to the memory and tell the PPU that code was loaded successfully. 反正我们只是想要执行自己的程式而已，要不要把 bootldr 读出来反而是其次。把 一小段程式丢进去 spu ，这段程式的作用只是把解密而且修改後的 lv0 丢到主记 忆体然後告知 ppu 说，正确载入 lv0 By achieving that we would have full control of the system. Our patched lv0, will load an original lv1ldr (required to get the ATA keys) which will load an original lv1 but before giving control to level1 our level0 will patch it so we still have control. Same with lv2 and vsh. 所以 ppu 就会载入我们自己的 lv0 ，自然取得整台主机的权限。我们修改过後的 lv0 会载入原本的 lv1ldr ，但是再把控制权交给 lv1 前，我们又会修改 lv1 ，因此主机 控制权换到 lv1 时候我们还是有完整的存取权限。同样的方法我们可以用来载入自己 的 lv2 跟 vsh 。 As I said basically the bug consist of changing the response len between the first read and the second. That is easily done if you control the buffer where the data is located (exploitable consoles). But we want to do this before anything is loaded So we need to change the comm between syscon and cell before any software outside the cell is loaded... the only option is a hardware interceptor. This hardware will intercept the communications and change it so the exploit is triggered (This is called a man in the middle attack). The payload will be sent as part of the 0x20 command reply... if the bug is trigger properly we know that our payload will start around 0x3E010. In addition to this I recommend adding a second flash chip that will contain the patched firmware. That will allow the user to go from patched to official with a switch As you see the device I propose is not a drm device... it actually triggers an exploit similar to the ODE device that whats announced (BTW that is perfectly done with the info that glevand posted). The questions is: Is all of this possible?... well from the software part I'm pretty sure but I don't know if the hardware can be build or if the cost will be too much. In any case if it is possible, there is enough info on this post to make it... Unfortunately there is also a enough info to patch the bug (if they didn't already). However it would only be patchable on factory... 当然，要修复这些漏洞不是不可能的，只是只能在生产阶段做，卖出去後就没办法了 -- ○ ____ _ _ _ _ ____ _ _ ____ _____ ____ 。 ★(_ _)( \( )( \/ )( ___)( \( )(_ _)( _ )( _ \ ｏ _)(_ ) ( \ / )__) ) ( )( )(_)( ) / ● ‧ (____)(_)\_) \/ (____)(_)\_) (__) (_____)(_)\_) ★ ｏ --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 98.159.211.240