101w ago - Today PlayStation 3 hacker
Slynk has posted on his new
blog some basic PS3 NPDRM information alongside a PS3 IDA (Interactive Disassembler) Tutorial for developers.
Download:
IDA PS3 Plug-Ins & Loaders /
IDA
Recently he has been
working on some
PS3 QA Flag developments, and below those interested can find both the PS3 IDA Tutorial and NPDRM details.
From his page:
PS3 + IDA Tutorial
Extract the contents into your IDA folder. I don't take credit for these plugins and loaders.
Loading a File
There are two file types I'll teach you to load. SPU and ELF files.
SPU files can only loaded in IDA 32bit mode. When you load IDA choose "Go" and drag the file onto IDA. Make sure elf is highlighted at the top. In processor type, choose "IBM SPU Cell Processor: spu." Click set. Click OK. "Undefined or unknown...blabla" yes. You should be good to go.
Elf files can be loaded in either 32 or 64 bit mode. When you load IDA choose "Go" and drag the file onto IDA. Make sure PlayStation 3 ELF is highlighted at the top. Don't mess with the processor type. Kernel option 1 check "Create function if data xref data-> code32 exists.
Optional: I don't know what these do but I turn them on anyways XD In kernel option 2 choose "Coagulate data segments in the final pass", "Perform 'no-return' analysis", and "Perform full stack pointer analysis."
Click OK. Sometimes you get a better result from running the analyze_self script. (File->IDC File->C:/Program Files/IDA/idc/analyze_self.idc) Hit yes, copy the TOC Address it shows you and click OK. Go to Options->General->Analysis->Processor specific analysis options. Type the TOC address in (I use 0: instead of 0x to be safe. No clue if it makes a difference.) While you're at it click "Create subi instructions. Click OK. Click Reanalyze Program. Click OK. And wait.
You'll know when a script is done because at the bottom left it's say "AU: idle".
IDA Basics
Just a few things. The program is expansive and I'd love to get to know more about it but here's a few things I know. Hex view and IDA view are connected. That means if you find a string in hex view, you can see it in IDA view. This won't show you magically where it's used at but sometimes, that string is xrefed. If under the string you see "# DATA XREF: " you can right click the ": off_XXXX" at the end, and choose XREF To or From. To, will give you a graph of any functions that have a call "to" that offset. From give's a graph of offset's called "from" that offset (mostly only useful for viewing a graph of where all a function leads to.)
In IDA view, you can search for either an immediate value, a string, or a byte sequence. I've never "not" checked "find all occurrences." Don't know why you wouldn't want to. It'll return a list of occurrences in its own window.
If you're lucky, the file you scanned will have some of the functions named (something other than sub_, nullsub_, or start). These are known functions that are defined in the ps3 sdk.
When exiting, always make sure, unless you WANT to re analyze the whole file again, to choose one of the Pack database options and Collect garbage.
NPDRM Basic Info
NPDRM Types
NP 3 is a free licensed app. It has no license check. No edata/riff. Just install and use. This can be trial software as well.
NP 2 is a locally licensed app. First time activation must take place online. After which you'll have an edata/riff for that app and somehow this is connected to your act.dat.
NP1 is a network licensed app. It requires network authentication every time it is launched.
The offset for determining the NPDRM type of a self is at the NPDRM Header offset + 0x1C.
NPDRM Security
NPDRM as well as edata use AES, ECDSA, and CMAC for authenticity. These keys, with the exception of the CMAC key, are out there in the ether and can be found without much effort for someone who knows what they're doing. The specifics of the algorithm are still being researched but a few people have already figured it out; but of course they won't share their info.
AES and ECDSA are handle by appldr like always. CMAC is handle by one of vsh's modules. (Don't know which one, just adding it for completeness.)
Another form of security used in NPDRM is called a k_license. This is a 16 byte key that the developer makes that functions as sort of a "project key". It's used in all npdrm encrypted files within the project to prevent one of the files from being replaced by another project's file. It is also referred to as an SCE NPDRM Key.
NPDRM Header
The current known structure of the NPDRM Header:
typedef struct
{
byte[4] block_type; // this is 3(NPDRM)
byte[4] block_size; // this is 0x90(sizeof(Self_NPDRM))
byte[4] unknown1; // So far always 0
byte[4] unknown2; // So far always 0
byte[4] magic; // 0x4E504400(NPD)
byte[4] unknown3; // So far always 1
byte[4] license; // 1 Network License, 2 Local License, 3 Free
byte[4] type; // 1 Executable, 21 Update for Disc Based Game
byte[2] titleid[0x30];
byte[2] hash_unknown[0x10];
byte[2] hash1[0x10];
byte[2] hash2[0x10];
byte[2] padding[0x10];
} Self_NPDRM
I hear there's plenty of more info in the official sdk for anyone who legally owns it as well. Anyway, I'll post more if anything else comes to light. ^^
5 Comments - Go to Forum Thread »
No.
Will you be traveling out your home country in the next week?...
