KLicense Brute-force Tool By MAGiC333X for PS3 is Now Available

[PS3 News]

Following up on the PS3 BruteForce / SCETool Decrypter builds by aldostools and http://aldostools.org/temp/klics.txt, this weekend PlayStation 3 homebrew developer MAGiC333X has released a KLicense Brute-force Tool for PlayStation 3 users complete with source code and updates below.

Download: KLicense Brute-force Tool v1.0 for PS3 / KLicense Brute-force Tool v1.1 for PS3 / KLicense Brute-force Tool v1.2 for PS3 / KLicense Brute-force Tool v1.3.1 for PS3 / http://www.dll-files.com/dllindex/dll-files.shtml?msvcr100 (Required)

To quote: I've created a new, ultra-fast tool for your KLicence brute-forcing needs! Compiled for Windows. Source code is included. Happy brute-forcing!

I've just released version 1.1 of my tool. Download link in first post.

Changes:

Version 1.1 (October 7, 2012):

• Keys stored as hex-strings in keydata file will now be found
• Added option to select search mode (see USAGE for directions)
• Flushing output of progress updates to allow for better integration
• Performance increase (~40%)

I've implemented the hex-string search function. And I made sure all cases are covered, except for one: When searching for hex-strings there is one case where the key will not be found. It occurs when the KLicence hex-string is preceeded by an odd number of hex digits. I haven't covered this case, because I don't think this will ever occur. If you (or someone else) think this can occur, please tell me, because it's very easy to implement at this point.

Output is now being flushed (for progress updates). I will give you a example. EBOOT.ELF from BLES00330 contains string: "-drmKey=1fbadf00d726101632a11da1cafeacac", if this string was instead: "-drmKeyf1fbadf00d726101632a11da1cafeacac" there is an odd number of hex digits (1x 'f' here) preceeding the key, causing the key not to be found.

Version 1.2 (October 7, 2012):

• Removed restriction on hex-string search mode
• (BugFix) Found hex-string is now displayed, instead of data at address

Version 1.3 (October 10, 2012)

• Added support for UTF-16/UTF-32 encoded hex-strings
• Added search-range option

Btw, decided not to add separate options for UTF-16/UTF-32 as it has just a very minor impact on performance (like 1%). Also a note on using the search-range option (from README.txt): When using option search-range to process part of a file, please keep in mind that the last key tried is at offset: end position - 16 (size of KLicence).

Version 1.3.1 (October 10, 2012)

Sorry about the search-range bug, I was in a bit of a hurry and completely forgot to test if the option worked... Almost did work though What it did was it always tried to process fileSize amount of bytes starting at the given offset, instead of (end - start) amount of bytes. Had to change just one line to get it working. Anyways, everything should be working now in version 1.3.1

-MAGiC333X

From the ReadMe File: KLicence Brute-force Tool v1.0 (2012/10/06)
Copyright (C) MAGiC333X

[RELEASE NOTES]

Initial release of the KLicence Brute-force Tool. Version 1.0, built on October 6, 2012 using Microsoft Visual C++ 2010 Express.

Use this program with caution. I will not be held responsible for any damage caused by (the use of) this program or it's source code.

Source code is included as a donation to other developers.

Files included in this release:

• Compiled program (Win32): 'klicencebruteforce.exe'.
• Example ps3keys file: 'keys'.
• This README file: 'README.txt'.
• Source code: 'klicencebruteforce-src-1.0.rar'.
• GPL v3 for used libraries: 'gpl-3.0.txt'.

Special thanks to:

• Asure (PS3Hax) - for the first steps in this subject and gaining my interrest.
• PS3DevWiki - for the information on SELF files and NPDRM decryption algorithm.
• naehrwert - if SCETool source code was available, i wouldn't have made this.

[DESCRIPTION]

This program will try to decrypt the metadata info of a SELF file that's been encrypted using a developer KLicence, by trying all the possible keys in the user-specified input keydata file. If the input keydata file contains the key to decrypt the metadata info, then the key will be found. When a working key is found, it will be written to the console.

It is VERY fast! On my Core2Quad Q6600 at 3.2 GHz it does ~770.000 keys/second, utilizing only a single thread/core. Moreover, it scales perfectly when running multiple instances concurrently. So, if you have a quad-core processor and you split your input keydata file into four equally sized parts and run four instances of this program, each using one part of the input keydata file, it will give you a nice x4 speedup!

This program is built for speed, not compatibility. This means that there is a great chance that some SELF files won't be processed correctly. If this is the case, try processing it with option '--minimize-validation' enabled. If it still doesn't work, use option '--npdrm' together with '--metadata-info'. This will result in the SELF file not being used or validated (the argument is still mandatory though). This way you can force the program into brute-forcing the metadata info of any SELF file.

Input ps3keys file must use format as used by SCETool. A sample ps3keys file is provided: 'keys'. The program will try all keys in the ps3keys file with name prefix 'NP_' as possible KLicence keys before starting the brute-force attack. This has the advantage that previously found keys can be added to the keys file. For an example, see the included keys file: it has the InfinityWardKey added to it as 'NP_infinitywardkey'. Also, you can use comments in the keys file by starting a line with '#' (just like an INI file).

Input keydata file is a binary file. This is the file that is used for the brute-force attack. If the KLicence key is in this file, it will be found.

For more help on how to use this program, see the USAGE section below.

[CHANGELOG]

Version 1.0 (October 6, 2012)

- Initial release

[SOURCE CODE NOTES]

Source will build using Microsoft Visual C++ 2010 Express.

I've tried to keep the code portable, so making it compile on Linux shouldn't cause too many problems. This is untested, however.

There is some room for improvement:

• Thorough testing for bugs/flaws.
• Don't read input keydata file fully to memory.
• Make brute forcing multi-threaded (it will scale perfectly!).
• Use another (faster) AES library to improve performance.
• Refactor: make coding style consistent.

Libraries used:

• aes.h/aes.c - AES library from PolarSSL, GPL v2+.
• common.h - Endianness swapping library by Youness Alaoui (KaKaRoTo), GPL v3.
• Code may contain some parts from euss's ps3tools/fail0verlow tools, any licence that came with these 'borrowed' source parts remain in effect.
• A copy of the GPL v3 licence is included.

My source code is not protected by any licence, feel free to use it any way you want. If improvements are made to the source code, I would be very pleased if those improvements are made public.

[USAGE]

klicencebruteforce.exe [options] <self-file> <keydata-file> <ps3keys-file>

Options                     Parameters       Decription
-n, --npdrm                 <key32> <iv>     Overrides NPDRM key and IV used
                                             for decryption. Using this option
                                             in conjunction with '-m', causes
                                             skipping of even more self parts.

-k, --klicdeckey            <key16>          Overrides KLicenceDecryptKey used
                                             for decryption. This key will be
                                             used instead of 'NP_klic_key' from
                                             the ps3keys file. If used in
                                             conjunction with '-npdrm', then
                                             ps3keys file won't be used.

-m, --metadata-info         <data64>         Decrypt specified metadata info.
                                             If this option is used together
                                             with '-npdrm', then self file will
                                             not be used.

-i, --progress-interval     <millis>         Sets the progress update interval
                                             (default=1000).

-p, --disable-progress                       Disables periodic progress updates

-x, --minimize-validation                    Minimizes validation. Parts of the
                                             self file that are not necessary
                                             for brute-forcing are skipped and
                                             most validity checks are disabled.

Parameters                  Values           Decryption
file                        filename         If filename contains spaces use
                                             quotes. Example: "file name.xyz".
millis                      decimal          Duration in milliseconds.
key16                       16 bytes hex     16 bytes key, hex notation.
key32                       32 bytes hex     32 bytes key, hex notation.
iv                          16 bytes hex     16 bytes IV, hex notation.
data64                      64 bytes hex     64 bytes data, hex notation.

More PlayStation 3 News...

[PS3 News]

Following up on the PS3 KLicense Brute-force Tool release, this weekend PlayStation 3 scene developer Flat_z has made available a PS3 Disc Key Dumper, Klicensee Dumper and corresponding Data Dumper with details outlined below.

Download: PS3 Disc Key Dumper / PS3 Data Dumper 0 / PS3 Klicensee Dumper / PS3 Data Dumper

From Twitter:

Disc key dumper http://mir.cr/1YDDSN6T http://mir.cr/0R8C1JVN
Klicensee dumper http://mir.cr/AKODIFIA http://mir.cr/1BAUGCKJ

The klicensee_dumper should speed up the gathering of http://aldostools.org/temp/klics.txt. One of dumpers is an alternative to klicensee bruteforcer which released before because some klicensee keys cannot be bruteforced. Klicensee is used to resign/decrypt/encrypt self/sprx/edat.

As for the other dumper (for a disc key), I'm writing a tool to decrypt/encrypt saves and resign them for your console if you want to use a save from another console. I will release a tool soon when it will be completed.

From the included ReadMe Files:

Disc Key Dumper

Requirements:

• 3.55 CFW (e.g. Kmeaw)
• MultiMAN or original dev_blind application and FTP client

1. Install `Data Dumper` (data_dumper.pkg) if you didn't installed it before. It is a homebrew application to dump a data from some LV2 memory to a file: /dev_hdd0/tmp/dumps.bin. A data which stored there is written by dumper loaders, e.g. by Disc Key Dumper.

2. Install `Disc Key Dumper Loader` (disc_key_dumper_loader.pkg). It stores a disc key if your game is not a PSN/SEN game.

3. Reboot a console to clear a data storage in LV2 memory.

4. Now you need to start `Disc Key Dumper Loader`, then start your game.

5. After exiting from the game you need to run `Data Dumper`, you will hear some beeps.

6. Then run any FTP client (e.g. builtin in MultiMAN) and download a dumped disc key from /dev_hdd0/tmp/dumps.bin.

Klicensee Dumper

A klicensee is specified by developer of the game. Usually it is stored in EBOOT.ELF and you can find it in a disassembler or by brute forcing a key along with a NPD header. But in some cases this key is not stored in a plaintext format and can be annoying to analyze a game's executable. That's why I had created this dumper.

Requirements:

• 3.55 CFW (e.g. Kmeaw)
• MultiMAN or original dev_blind application and FTP client

1. Install `Data Dumper` (data_dumper.pkg) if you didn't installed it before. It is a homebrew application to dump a data from some LV2 memory to a file: /dev_hdd0/tmp/dumps.bin. A data which stored there is written by dumper loaders, e.g. by Klicensee Dumper.

2. Install `Klicensee Dumper Loader` (klicensee_dumper_loader.pkg). It stores a file path to self/sprx/edat and a klicensee key if it is specified.

3. Now you need to replace original `libsysutil_np.sprx`. I use a dev_blind feature from MultiMAN, you can use any other way. Don't forget to backup original file.

4. Reboot a console to clear a data storage in LV2 memory.

5. Now you need to start `Klicensee Dumper Loader`, then start your game.

6. After exiting from the game you need to run `Data Dumper`, you will hear some beeps.

7. Then run any FTP client (e.g. builtin in MultiMAN) and download dumped klicensee keys from /dev_hdd0/tmp/dumps.bin.

8. Restore an original `libsysutil_np.sprx` using the same method as at step 3.

Data Dumper

Requirements:

• 3.55 CFW (e.g. Kmeaw)
• MultiMAN or original dev_blind application and FTP client

1. Install `Data Dumper` (data_dumper.pkg) if you didn't installed it before. It is a homebrew application to dump a data from some LV2 memory to a file: /dev_hdd0/tmp/dumps.bin

2. Every time you're want to dump a data from my applications (e.g. Klicensee Dumper) you're need to reboot a console to clear a data storage in LV2 memory.

3. Run a dumper loader, then start your game.

4. After exiting from the game you need to run `Data Dumper`, you will hear some beeps.

5. Then run any FTP client (e.g. builtin in MultiMAN) and download a dumped data from /dev_hdd0/tmp/dumps.bin.


More PlayStation 3 News...

[JOshISPoser]

uhhhhh, what? so, does this just help people get keys for the klicense tool to share?

[kotnaphaha]

thank you. you'r the man!

[kalberto]

useless tools CAN NOT decrypt 4.xx

OMG, this is old !

[niwakun]

really? if this can be executed on DEX, I cant say this is not useless anymore.

[Blade86]

Nice, thank you so much for sharing

So only DEX-MFW-3.55 (like rogeroV2) i think... Anyone knows if this needs peek&poke? probably

Perhaps Deank can change the syscalls? I mean, you are able to copy/paste files on DEX4.21OFW with MM (without peek&poke)

If someone manage it to run on DEX-OFW,... hmmmmmmm NICE

Cheers
Blade

[StanSmith]

Anyone got better links? I've opened up about 30 popups and new pages and still nowhere near downloading the files.

[Blade86]

Can't be. There are sooo many mirrors.

Which one you can't find??

[StanSmith]

ALL of them. I can't get any of the files to download. There are too many popups and pages to open.

How about someone put them on a fileserver that actually has the files instead of links to other pages with more links.