[PS3 ] JuanNadie left but had us a gift

[cassine (Savannah)]

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
推 fuj:有看有推~~
推 ericno1:可以請問一下 現在新機版本都是多少呢? 二手機價格一直居
→ ericno1:高不下 想說乾脆買新的 可是又怕不能改自製系統
→ cassine:最好選 2507 以前的主機才保證有 bootldr 漏洞可以用
→ cassine:像我的雷姐機 2007 FF 雖然也是在 4.20 上，但只要韌體更
→ cassine:新這邊破解了，應該馬上又可以換回自製韌體
→ cassine:至於要不要升級到最新的 4.21 CFW ，我個人建議是能不要就
→ cassine:一則是韌體更新那邊還沒破解，再來則是可能之後重刷有磚掉
→ cassine:的可能，不過有 E3 Flasher 這種東西的人倒是可以試試看
→ hpo14:這種dump 法真的很意外的聰明!!!!