Great to see so much progress, well done to you both!
Trust, encouragement, reward, loyalty... satisfaction. That's what I'm... you know. Trust people and they'll be true to you. Treat them greatly, and they will show themselves to be great.
Trust, encouragement, reward, loyalty... satisfaction. That's what I'm... you know. Trust people and they'll be true to you. Treat them greatly, and they will show themselves to be great.
Scene developer MAGiC333X has dropped by today at our Crunching forums, to share with us his latest tool, one that can quickly Brute-Force your KLic's key, which makes it easier to get certain games running on your Jailbreakable v3.55 CFW Sony PS3 console.
README.txt:
Code:
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 @ 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.
got a little video tutorial on what im supposed to type in to use this?
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%)
@catalinnc
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.
@aldostools
Output is now being flushed (for progress updates).
@catalinnc
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.
i don't understand the yellow part...can you post an example?
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.
Reply With Quote
Originally Posted by aldostools
