[KDSBest]

Originally Posted by MAGiC333X It is a release build, but it's a great tip though! When i first tried a release version, i was pretty amazed by the difference. Speed about doubled Btw, new version does a little over 1 million on my system 2. I know about the overhead, but you still get a nice >99% performance increase per core. 3. I tried turning that option off, but couldn't get the errors to go away. Even tried making new solution, turning the option off in the wizard and then adding the source files, but it didn't work for me. Using '#pragma once' looks cleaner, indeed. But when i was writing this, i was more concerned with getting rid of the errors The warnings are caused by using 64bit values read from the self file as parameters for functions that accept only 32bit values, here: malloc(), fseek() and fread(). This limits the maximum size of the header to about 2gb, so it shouldn't give any problems. But thanks for your input! Just noticed it could really use a couple of sanity checks there

Normaly I say sanity checks are awesome, but if you go for performance you check nothing and hope for the best :P

[MAGiC333X]

Originally Posted by KDSBest Normaly I say sanity checks are awesome, but if you go for performance you check nothing and hope for the best :P

Haha, lol

But in this case sanity checks are welcome though, as they won't be part of the brute-force process and thus won't slow things down.

[KDSBest]

Originally Posted by MAGiC333X Haha, lol But in this case sanity checks are welcome though, as they won't be part of the brute-force process and thus won't slow things down.

Catching all Exceptions can cause trouble too. If a client calls you and has trouble and you can't remote debugged you are doomed. Not every bug is worth flying over .

[MAGiC333X]

Originally Posted by KDSBest Catching all Exceptions can cause trouble too. If a client calls you and has trouble and you can't remote debugged you are doomed. Not every bug is worth flying over .

True. But IMO it really depends on the impact the exception might have.
If you know at some point during execution, for certain that the program is not going to function properly, then i think it is best to just fail fast. In situations where you know it might not function properly, i'd say just continue and maybe display warning.

[jjkkyu]

hi, MAGiC333X

I'm trying to use your tool 1.31 to get klic from EBOOT.
But it always return me a same klic, and this is not the real klic from EBOOT.

[*] Reading input self file 'EBOOT.BIN'
[*] Reading input self file OK.
[*] Validating self file
[*] Validating self file OK.
[*] Reading input keydata file 'EBOOT.elf'
[*] Reading input keydata file OK.
[*] Reading input ps3keys file 'keys'
[*] Reading input ps3keys file OK.
[*] NPDRM key: F9EDD0301F770FABBA8863D9897F0FEA6551B09431F61312654E28F43533EA6B
[*] NPDRM IV: A551CCB4A42C37A734A2B4F9657D5540
[*] Using KLicenceDecryptKey: F2FBCA7A75B04EDC1390638CCDFDD1EE
[*] Trying known keys from ps3keys file.
[*] Key found: 72F990788F9CFF745725F08E4C128387

Done.

I think I should use some other KLicenceDecryptKey to try?
How should I do? And what KLicenceDecryptKey should I use?

--------------------------------------------------------

edit:
Finally find out by myself, Lucky.