[Viral Doom]

Originally Posted by Vallachia Well you really need to read the whole thread if you want to learn anything. But i'll throw you a bone. You can do it in a few ways, use EbootMOD.exe or use a hex editor for example. I prefer the hex editor method since you don't have to worry about EbootMOD.exe crashing when it calls makeself. Ok so get a hex editor such as hex workshop. Open the eboot.elf you got from decrypting the eboot.bin. Search for 3300000036000 and replace with 3300000034000 (just change 36 to 34). Now encrypt the eboot.elf using key-revision 01. All done!

do NOT forget to mod param.sfo by hexa, you need to chance the value "3.60" to "3.41" or "3.55"

or use this pkg fix:

http://rghost.net/39691008

I did it a few days ago for a friend

[Vallachia]

Originally Posted by mrWodoo Can't find this pattern '3300000036000', search method: ANSI... hhd hex editor neo decrypted to .ELF ofc.

Hex not ASCII. Seriously, just use Viral Doom's pkg if you don't know what you are doing..

[haz367]

hi, if not using EBOOTMOD to fix param_sys into 34(3.41) or 35(3.55)
use this gsarc commad in ur batch and put it before "scetool re-encrypt" command

gsar.exe  -x18 -s:x24:x13:xbc:xc5:xf6:x00:x33:x00:x00:x00:x36 -r:x24:x13:xbc:xc5:xf6:x00:x33:x00:x00:x00:x35 EBOOT.ELF fixed.elf

also edit the PARAM.SFO into the key-rev used (3.41/355)
error should be gone

manual search/edit for this in the decrypted EBOOT.ELF = (search for hex 24 13 BC C5 F6 with HxD) then change 00 33 00 00 00 36 to [b]00 33 00 00 00 34 or 00 33 00 00 00 35

credits to Asure and company for all the help
then re-encrypt with scetool

[christos]

hey guys is posible for someone to find the key for k-linc from patch.self for this BLES01377?
from my pc it takes to much time and in the end can't find it. thnx in advance

[Vallachia]

Well the real question is has anyone had any luck re-encrypting an .self with lower keys using Scetool? I mean actually building a .self that works.

All my efforts have resulted in the wrong/incomplete SCE metadata header being created. I am guessing that Scetool cannot currently do self/sprx metadata properly.

So if this is true (anyone?) then the rage k-license key won't help you for now sorry.

I also should say thanks so much to Asure and Longhornx (and others) who have contributed to this thread. So thanks to you all and hope the .self/.sprx thing is cracked soon!

[oakhead69]

Originally Posted by christos hey guys is posible for someone to find the key for k-linc from patch.self for this BLES01377? from my pc it takes to much time and in the end can't find it. thnx in advance

offset 0x1978b20 into boot.elf for Rage (BLES01377)

you find the klicense key:
58a4badb96035258c54dde01f210cbdd

[clayboy]

Did anyone figure out the issues with the system still asking for 3.60 update after being patched with the recent pkg files that were released...

[Asure]

Originally Posted by clayboy Did anyone figure out the issues with the system still asking for 3.60 update after being patched with the recent pkg files that were released...

The required version is stored by vsh when you install a package (update).
So when you build the pkg with the update, you must edit the sfo to say 3.55 or 3.41. Then, when you install that package, all will be fine.

There are many broken eboots (param not fixed) and broken packages out there that do not have the param or sfo fixed. I prefer to make my own fixes & pkgs for private use.

[christos]

Originally Posted by oakhead69 offset 0x1978b20 into boot.elf for Rage (BLES01377) you find the klicense key: 58a4badb96035258c54dde01f210cbdd

thnx
how many hours it took you to find the key? i have core 2 duo oced to 4.3ghz
and run for 2 hours but nothing and i stopped it.

[baargle]

Originally Posted by christos thnx how many hours it took you to find the key? i have core 2 duo oced to 4.3ghz and run for 2 hours but nothing and i stopped it.

Has virtually nothing to do with CPU power, the batch file is just a very dirty way of getting the correct key, a properly made application would find it in a couple of seconds. The limiting factor is the msdos prompt shell, it's not designed for this and won't be using the power of your cpu, no matter how fast or slow it is.

No disrespect to Asure, nobody else has done anything about this except him and in due course someone will code something that is optimized to extract the key, which isn't even hidden. It's in an easily locatable place and that place is possible to be worked out in an application and algorithm used to find it instantly or in seconds.