PCMHammer P04

[Gampy]

Good point, it's getting an OsID though, that's all it should need for a read though, isn't it ??

-Enjoy

[antus]

It'll resolve to being a P01/P59 in the default case, and attempt to use that security algo, and that kernel. If the whole block is 00, then the key will be 0000, and it'll think its unlocked after it reads the seed, when it is not. Last time I recovered a key 0000 PCM, I had to modify PCMHammer to skip the seed 0000 is already unlocked logic and actually send the key. Then I could send 0000 as a custom key. Its possible the key will be FFFF too. PCMHammer will need to send the P04 kernel, not the P01/P59 kernel. Really this is where we need the program prompt that lets you pick a few options manually including something like "send key even if PCM is unlocked", "custom key 0000 (we have this one)" and PCM Type manually set to P04. Two of those 3 dont exist yet, though. If we could see the bin we could confirm the PCM is in the state I think it is. If there are P04 bins with an empty ID segment getting around commonly from other tools, then we probably need to add another safety check for that.

[Gampy]

It's getting the OsID, it's recognizing it's a P04 ...

[08:19:21:513] TX: 6C 10 F0 3C 0A
[08:19:21:525] RX: 6C F0 10 7C 0A 00 C0 2D 5F
[08:19:21:525] OS ID: 12594527
[08:19:21:527] Hardware Type: P04

-Enjoy

[antus]

Oh yeah, just not calibration id or hardware id.

Well if the security is unchanged, it'll probably write. If seed and key are FFFF then it'll unlock with a manual key of FFFF, but if seed and key are 0000 and 0000 then PCMHammer wont do it, as it wont send the key once it sees a seed of 0000. If this is the case a build with the check that seed is 0000 that returns on match with "pcm is already unlocked" needs to be removed. From memory there are 2 places that both do that.

[Gampy]

I believe the way I did the User defined key logic is, it's priority, therefore all one needs to do is define the user defined key as 0000 and it'll work!

I know I questioned your mod to it, but I never looked into it, had more important things on my mind at that time.

A bit brain numb ATM ... I'd have to go look.

-Enjoy

[antus]

Yeah I couldnt make sense of the flow when I needed to do it. This is why we need to revisit the logic in the app and move the logic more cleanly in to the libs. I found it via testing, and I needed to patch 2 places. But I never pushed it back because it was a one off (supposedly, but here we are). We might need to patch a seed and key of 0000 in to a param block on a p01 or a p59 to test the logic again.

This looks like one https://github.com/LegacyNsfw/PcmHacks/ ... le.cs#L320

I am not 100% sure about the second, if it was real or not. Maybe I patched something else I didn't need to for this exact scenario, before hitting that one.

[Gampy]

All I got to say is have fun with it because it's getting near impossible for me to think my way out of a paper bag!

I'm turning into a slobbery drooling twitching heroin junkie ...

I've got the 'Morphine Tremors' so bad that sometimes my outer mouse gets knocked across the room and I gotta ring the ol'lady to come get it for me, or I drag n' drop things to unknown places ...

Having a super tough time in code, I guess it's time to take up needlepoint or something along that line!

Just babbling, no sympathy!

-Enjoy

[zack4200]

yeah here's the bin I wrote to it. I thought it was one I read out from a different p04 with either PCM Hammer or LS Droid but its possible it was one I grabbed from somewhere on the internet.

[Gampy]

Yea, I recognize this file, it is blank from 4000 to 8000 ... No parameter segments.

Bad file ...

-Enjoy

[antus]

Well, its all FF so try a manual key of FFFF and if you get seed of FFFF it'll probably work and you can clone your original bin back on to it.

Also the P04 write worked perfectly, just it was a bad file written. So I'd call this a successful test, and yet another thing people could do with bad files that we need to add another guard against to stop it happening.