重編譯啟動合法持有的NP-DRM遊戲 - 改機

ps3hax.net論壇上有關於NP-DRM版權保護機制的技術討論，有興趣的可以看下去
http://www.ps3hax.net/showthread.php?t=28303

THIS DOES NOT ALLOW TO OBTAIN 3.60+ keys
以下的討論跟獲取 3.60+的解密金鑰無關

On NPDRM self decryption all the security levels of the PS3 are
involved: user space (vsh), kernel space(lv2), hypervisor( lv1) and
isolated SPU (metldr + appldr)
關於NP-DRM保護的解密，可以說整台主機提供的加解密機制都用到了，包括使用
者介面的vsh.self、系統核心相關的lv2.self 、管家婆相關的 lv1.self，還有
獨立在 SPU裡頭的metldr與appldr。

The process start on vsh.elf...
所以讓我們從vsh.self開始

VSH:
vsh.self部份：

Once the vsh detects that user is trying to start a self, it looks
for the appinfo header type. If the type is 8, then the control
digest element type 3 (NPD element) is located. From this NPD header
the vsh gets the license type (free, local or network license).
當vsh.self偵測到使用者要載入一個加密的self執行檔時，它會先去查看檔頭的
標記，讀取相關加密資訊（版本、方式等），如果加密類別的標記是 8，就代表
是一個NP-DRM加密的程式，所以繼續讀取NP-DRM的訊息，取得授權資訊（免費、
可以在本機執行或僅能連網執行）。

If a free content(type 3) is detected then a generic klicense will be
use for further steps (go to LV2). That klicensee is already public
(see geohot npdrm_omac_key_1).
如果授權是免費（授權類別 3），那就會直接引用通用的klicense，然後直接丟
給lv2.self去繼續解密。通用的klicense拜geohot所賜，早已經廣為人知。請參
照geohot的npdrm_omac_key_1。

However if a paid content is to be loaded the vsh loads the act.dat
and the rif associated to the content (if local it will locate a file
with the same titleid on NPD element, if remote it will download to
vsh process memory)
如果是付費授權，則vsh.self還會繼續載入 act.dat檔案與 rif檔案（如果是本
機授權，則會載入一個有相同titleid 的檔案，若是遠端授權，則會將檔案自
PSN主機下載後存在記憶體中）

Then the signature is checked (last 0x28 bytes of both RIF and
act.dat). The curves used are on vsh.self. It is a 3 element table,
having the first curve nulled. The curve index for rif/act is 2. The
curve values are negated as in the apploader and has the following
structure
最後會檢查數位簽章（ act.dat與 rif檔案尾巴長度為0x28的資訊），曲線類別
都存放在vsh.self中〔譯註：應指橢圓曲線加密的曲線類別〕，此為一個三個元
素的表格，第一個曲線為空。 rif/act所使用的曲線索引號為 2。如同在appldr
中，曲線的值是無意義並具有以下結構：〔不是很懂這段話的意思〕

struct curve {
uint8_t p[0x14];
uint8_t a[0x14];
uint8_t b[0x14];
uint8_t N[0x14];
uint8_t Gx[0x14];
uint8_t Gy[0x14];
};

If the curve checks then vsh will process the rif:
檢查完曲線後vsh.self會繼續檢查 rif與 act.dat檔案，結構如下：

struct rif {
uint8_t unk1[0x10]; //version, license type and user number
uint8_t titleid[0x30]; //Content ID
uint8 padding[0xC]; //Padding for randomness
uint32_t actDatIndex; //Key index on act.dat between 0x00 and 0x7F
uint8 key[0x10]; //encrypted klicensee
uint64_t unk2; //timestamp??
uint64_t unk3; //Always 0
uint8_t rs[0x28];
};

struct ACTDAT {
uint8_t unk1[0x10]; //Version, User number
uint8_t keyTable[0x800]; //Key Table
......
uint8_t signature[0x28];
};

Using the RIF_KEY it will obtain the actdatIndex:
然後使用rifKey去解密 act.dat裡面加密的部份：

AES_KEY rifKey;
int result = AES_set_decrypt_key(RIF_KEY, 0x80, &rifKey);
AES_decrypt(&rif->padding, &rif->padding, &rifKey);

And finally having the actDat key index the execution pass to LV2
syscall 471
解密後會得到actDat的金鑰索引，然後傳給 LV2 syscall 471。

LV2
lv2.self的部份：

Lv2 is accessed using syscall471 which haves the following syntax:
lv2.self將相關參數用以下格式傳給syscall 471：

int syscall_471(uint32_t type, char* titleID, void* klicensee,
uint8_t* actdat, uint8_t* rif, int32_t licenseType,
uint8_t* magicVersion);

The function has different parameters depending if the content is
debug, free or paid:
依照內容是除錯授權、免費授權或是付費授權，此一函式有不同的參數。

FREE: syscall471(npd.type, &npd.titleID, freeklicensee, NULL, NULL,
npd.license, &npd);
免費授權的參數。

PAID: syscall471(npd.type, &npd.titleID, NULL,
&actdat.keyTable[rif.actDatIndex*0x10], &rif.key,
npd.license, &npd);
付費授權的參數。

The lv2 keeps a memory table with contentID and the associated key.
When it receives a free content (r5 is not null) then copies the
titleID and the klicensee to the table. For a paid content the
rif.key is converted to the klicensee using:
lv2.self會將 contentID與相關的金鑰用表格的形式存在記憶體中，若是免費的
內容（r5非空），則把titleID與klicense 填入表格。若是付費的內容，則會將
rif.key 轉換成klicense的形式。

AES_KEY IDPSKey, ConstKey, ActDatKey;
uint8_t encrConst[0x10];
uint8_t decryptedActDat[0x10];
uint8_t klicensee[0x10];
int result = AES_set_encrypt_key(&IDPSVariation, 0x80, &IDPSKey);
AES_encrypt(&CONSTACTDAT, &encrConst, &IDPSKey);
result = AES_set_decrypt_key(&encrConst,0x80,&ConstKey);
AES_decrypt(actDat,&decryptedActDat,&ConstKey);
result = AES_set_decrypt_key(&decryptedActDat,0x80,&ActDatKey);
AES_decrypt(rif,&klicensee,&ActDatKey);

where CONSTACTDAT is a constant value on lv2, IDPSVaritaion appears
to be IDPS (not checked but DRM_Manager_initialize (see
graf_chokolo's "bible") to something with the same structure), actdat
are the 0x10bytes selected by rif keyIndex, and rif is rif.key (bytes
0x50-0x5f).
其中CONSTACTDAT是lv2 裡頭的一個常數值、IDPSVariation顯然就是主機的IDPS
訊息（雖然沒用到，但DRM_Manager_initialize還是有載入，請參閱graf_chokolo
的 PS3百科）、actdat是一個透過rif 金鑰索引指定，長度為0x10的變數、 rif
自然就是 rif.key（裡頭位址為0x50到0x5f的部份）

Once transformed it is stored on memory table...
轉換完成後，就會存在記憶體的表格裡面……。

I haven't check further steps on vsh nor lv2 so perhaps there are
further transformations on the paid case (NOT FOR THE FREE AS I HAVE
DECRYPTED THOSE) so we are jumping directly to the appldr
在vsh 跟lv2 更詳細的解密步驟我就沒仔細研究了，也許付費的場合中還有更多
的轉換（在免費的場合沒見到，因為我已經把免費的都解密了），既然如此，就
讓我們進到appldr這邊。

AppLdr

As you can see from graf_chokolo payloads a parameter is passed on
spu_args.field60. That parameter is the previously stored klicensee.
如果你有仔細研究過graf_chokolo的酬載〔譯註：graf_chokolo曾經利用3.41版
韌體的漏洞，用PSGroove工具透過自己的酬載把所有的 PSN遊戲全部解密〕，會
發現他的程式送了一個東西到spu_args.field60去，這個東西就是前一步驟中得
到的klicense。

However this key must be transformed (again) even for the free case.
The transformation is:
然而，這個金鑰還得再度轉換，就算是免費授權的也一樣，轉換方式如下：

uint8_t decryptedKLicensee[0x10]
AES_KEY KLicenseeKey
int result =
AES_set_decrypt_key(&KLicenseeDecryptKey,0x80,&KLICENSEEKEY);
AES_decrypt(klicensee,&decryptedKLicensee,&KLicenseeKey);

EY is another key located inside the apploader and klicensee is the
parameter.
其中的EY是appldr裡頭的另一個金鑰。

Then we can finally remove the NPDRM layer using:
所以我們就可以移除整個NP-DRM的防護，步驟如下：

AES_KEY key;
uint8_t iv[0x10];
memset(&iv[0],0,0x10);
int result = AES_set_decrypt_key(&KLicenseeDecryptKey,0x80,&key);
AES_cbc_encrypt(self + self->metaoffset + 0x20, self +
self->metaoffset + 0x20,0x40,&key,&iv,0);

Once that layer is removed we proceed as normal:
一旦NP-DRM防護移除後，事情就很簡單了：
-Decrypt using AESCBC256 with the NPDRM keys to obtain the metadata
keys
使用NP-DRM解密金鑰搭配AESCBC256演算法解密獲得metadata金鑰
-Decrypt using AESCTR128 the data sha, hmac, iv keys
利用data sha、hmac、iv金鑰透過AESCTR128演算法解密
-Decrypt the data.
解密所有的資料。

PD: I WILL NOT PROVIDE ANY OF THE KEYS MENTIONED ABOVE
注意：本人將不提供相關金鑰。

Credits to euss (documentation, keys and testing),
mallory(testing,code), jester(testing)
致謝：euss負責整個文件結構、金鑰與測試
mallory 負責測試與寫程式
jester負責測試

******

本文轉錄前請先徵得本人同意

--

○ ____ _ _ _ _ ____ _ _ ____ _____ ____
。 ★(_ _)( \( )( \/ )( ___)( \( )(_ _)( _ )( _ \
ｏ _)(_ ) ( \ / )__) ) ( )( )(_)( ) / ● ‧
(____)(_)\_) \/ (____)(_)\_) (__) (_____)(_)\_) ★
ｏ

--
※ 發信站 :批踢踢實業坊(ptt.cc)
◆ From: 140.120.31.137