Originally Posted by flatz
It's very slow because you need to calculate a HMAC hash of the entire file for each byte sequence with the size of 16 bytes so you advance a file offset by 1 byte each time.
The data generally is aligned to 4 and in less cases it is aligned to 1. An optimization that you could consider to implement in future releases is to test first the "offsets" aligned to 4, then repeat the loop for offsets aligned to 2 (and not aligned to 4), and loop again for the odd offsets. Also a start-stop range for offsets would be nice.
Some additional tips:
1-Before bruteforce the savedata folder, always list the protected entries using: pfdtool -l <path>
2-I have noticed that if only PARAM.SFO is listed, the pfdtool does not find the key using that file (maybe the key is not needed)
3-As the HMAC hash of the entire file is calculated for each "key" being tested, it is highly suggested to always use the smallest file.
For instance, in Medal of Honor USR-DATA is 200kb but HED-DATA is only 4 bytes. So using HED-DATA let you find the key in few minutes, while using USR-DATA file could take hours.
4-In many games the key is usually found in the ELF of the EBOOT.BIN, but ocassionally the key can be found in a self (eg. MOHAGame-PS3Final.self, scimitar_final.self, etc.)
~ Dreams and dedication are a powerful combination.
... multiMAN is a perfect demonstration.