I been a while since Mathieulh first released a Youtube video showing a PS3 Console, that been QA Flagged and all the extra Debug options that appear after pushing a series of buttons on the controller.

Since then people have been flaming back and forth, trolling on many ‘scene’ sites, and down right mud-slinging at people in forums that if they had met in person most likely would be sharing laughs and drinks instead of trading racist remarks and out right total rudeness.

But thru all this total out-right chaos, one person by the nickname Slynk has taken a real heart-warmed interest in figuring out this puzzle that Mathieulh started with his lame video, and was very early on able to discover on his own the actual DECRYPTION KEY that allows for the QA Flag Token to be decrypted correctly (well on older consoles using v3.41 and v3.55 firmwares, as the process been changed on later models).

Quote:
erk: 0×34, 0×18, 0×12, 0×37, 0×62, 0×91, 0×37, 0x1C, 0x8B, 0xC7, 0×56, 0xFF, 0xFC, 0×61, 0×15, 0×25, 0×40, 0x3F, 0×95, 0xA8, 0xEF, 0x9D, 0x0C, 0×99, 0×64, 0×82, 0xEE, 0xC2, 0×16, 0xB5, 0×62, 0xED

iv: 0xE8, 0×66, 0x3A, 0×69, 0xCD, 0x1A, 0x5C, 0×45, 0x4A, 0×76, 0x1E, 0×72, 0x8C, 0x7C, 0×25, 0x4E

hmac: 0xCC, 0×30, 0xC4, 0×22, 0×91, 0×13, 0xDB, 0×25, 0×73, 0×35, 0×53, 0xAF, 0xD0, 0x6E, 0×87, 0×62, 0xB3, 0×72, 0x9D, 0x9E, 0xFA, 0xA6, 0xD5, 0xF3, 0x5A, 0x6F, 0×58, 0xBF, 0×38, 0xFF, 0x8B, 0x5F,0×58, 0xA2, 0x5B, 0xD9, 0xC9, 0xB5, 0x0B, 0×01, 0xD1, 0xAB, 0×40, 0×28, 0×67, 0×69, 0×68, 0xEA, 0xC7, 0xF8, 0×88, 0×33, 0xB6, 0×62, 0×93, 0x5D, 0×75, 0×06, 0xA6, 0xB5, 0xE0, 0xF9, 0xD9, 0x7A

*runs away before the lawsuits come flooding in*

hmac to make the 20 byte digest at the end of the token and erk/iv to decrypt/encrypt it with aes256cbc.

2 more steps to go. Need the button combo and what to change in the dummy token.
Now you my ask why am I reporting on this now, since his original post on PSX-SCENE (QA Flags discussion) is now almost two weeks old, because you see in my next two articles that Slynk has now started posting in his blog, and it contains alot of useful information and maybe he will get more people to start exploring the depths of the PS3 that still have not been open to the general public, and instead kept for various out-right lame reasons to themselves and their elite crew of followers.

Just my two cents rant on the QA Flag subject, but I do very much recommend checking out Slynk’s Revenge on your PS3 journeys.

-=(/GriFFin)=-

Recently there has been alot of chatter on various warez trading forums, that NPDRM keys more then what has already been published in various forms like this shit piece of artwork by Mathieulh back in April, which has long been replaced with newer keysets by Sony in their packing of the retail game updates for later firmwares above v3.55.

This NPDRM decryption chatter of retail EBOOT’s started up recently because a warez group called DUPLEX released an re-packed game update for CFW users and v3.41 dongle owners for a certain hot game that would had in no way shape or form be possible at all, unless more private NPDRM signing keys have been found by the so-called elite underground crew members that want to keep their little secrets and ways to discover them all to their lame elite group.

No problem, along comes Slynk again, recently made famous for figuring out one of the three parts needed for the making a PS3 Console QA Flagged, and he has recently start blogging about the NPDRM keys and plans to put all the information in one place and maybe then others outside of this warez elite will have the guts to publish more information, maybe even Slynk himself will, like he did with the QA Key that he found.

Quote:
I'd like to begin this post with a few comments.


1.Only a little bit of this is my own findings, a lot of this info was found from other sources.
2.NPDRM discussion does not have to be a topic of piracy, it can be used in conjunction with signing/encrypting homebrew if it is fully documented one day.
3.This is mostly to bring together the bits of info scattered across the interwebs.
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. ^^

One of the first steps in exploring the PS3 internal code, is to get yourself a program called IDA Pro, now it is very costly, but well worth it’s own weight in gold, if you wish to learn more about the PS3.

First, all ‘scene’ developers have used this same program to get the internal information either they needed in their research which they in turn released to the public, or by others that use it just kept to all themselves and to made lame youtube videos with bragging to the world what they can do, but no one else can. HaHa!

Second, alot of information for new up and coming developers just joining the PS3 world or for just people that want to learn is really missing, there is no good tutorials on how to use IDA PRO, you just know it or you don’t, no-one is going to help you, even tho their is ton of information out there it is not in one easy to find place or just out-of-reach to those not in the “elite core”, or worse ones that have previously made IDA plugins in the past out of fear of Sony’s MIB legal team, have deleted their blogs along with their tools.

No more need to worry, along has come Slynk and he is out for revenge against this Elite non-sharing group of lame developers, that only keep stating “I will not help you!”, “Go screw yourself!”, and he has put together a very good and complete collection of plugins for usage in IDA, and has written up a basic tutorial to get you going, in the world of PS3 internal exploring!

Quote:
First off, I will not help you obtain a copy of IDA. Go buy it.

IDA.7z

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 "ff_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.
Our many thanks to Slynk, and my hat is off to him in honor, to have the guts to stand up against these non-sharing Elite’ers, and to try and help out the little noobie that just might, you never know become the next Geohot and share his amazing new PS3 discoverys, and open even more doors to the PS3 owners!

The hint I gave you, is pretty much the solution to your dilemma, I am surprised none of you have figured it out yet.

If I told you more than this, I’d rather release the whole hack myself then, because it’d be no different.

Let’s just say I don’t like playing with fire, I risk great by simply helping you, Sony could sue me on bogus grounds and drawn me in legal fees if they so much see fit.

have you looked at VSH in a disassembler? it’s really not that easy to just “find” the function when there are litterally ten’s of thousands of functions in that elf alone, like 60% of them are not even labeled with a useful name. the only way for someone to find it is if they know PPC and SPU inside and out (like the people who already have found it) the only way anyone is going to find anything more is if they study up on ppc and spu, which will take an enormous amount of time.

Or you could design your debugger and perform some live debugging on the thing, that’s what I’ve done. Gets the job easier by 10 folds.

which of course you will not share with us.

math, let’s be honest. How do you think someone not being able to use IDA (or any other disassembler) could design his own debugger?

Actually, this debugger thing came into my mind when someone posted a picture of a register dump a few pages back. The name of that “debugger” used was “anergistic”. Maybe someone should check this out.

anergistic is a spu emulator, good luck debugging vsh.self with that…

So is there a debugger available that can debug vsh.self (or .elf) or just the one you made yourself?

self made.