I quickly wrote up some code to properly read the boot_history.dat file (for analyzing)
I will be writing code so that people can easily rewrite the file (also will be writing code to handle game.dat and patch.dat)
|
|
|
|
Would you like to get all the new info from
PSX-Scene in your email each day?
Want to learn more about the team keeping you up to date with the latest scene news?
Read about them now! Check out our Developer bios, too! | ||
|
|
I quickly wrote up some code to properly read the boot_history.dat file (for analyzing)
I will be writing code so that people can easily rewrite the file (also will be writing code to handle game.dat and patch.dat)
I've got the whole format for the three log files, and am writing up some utilities for this, in straight C. I'll be releasing the source as part of my release.
patch.dat is the most complicated, but it's all pretty straight forward. If anything is going to give away hacked systems, it will be patch.dat, since people have games with modified EBOOTs, and patch.dat reports the game's version and sdk version. Sony will zero in on discrepancies with that.

I see good potential with this. Instead of trashing those files or putting random games in (and I'm sure somewhere else it would state you never installed those games so how could you have played them?).
Someone could make a reader that looks for list of things to remove (like names for popular homebrew) and simply remove them from the list without messing with the real games played.
or the lv2 code that keygens off of memory allocations and uses it in streams to PSN and game server SDK. Which is known to be in at least 3 different places so far. This isn't even including checks hidden in stuff in arc files on game discs that have to be hooked or patched.
The structure is really easy, just need a few to compare to. It's easy to read and write using structures, since thats how sony writes them.
| « Previous Thread | Next Thread » |