PCM Hammer Release 014

They go by many names, P01, P59, VPW, '0411 etc . Circa 1999 to 2006. All VPW OBD2 PCMs.
User avatar
Posts: 730
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Sun Jul 12, 2020 3:40 pm

Dissembling the kernel is unnecessary, unless your goal is to feed the brain ...

I think NSFW did create a Wiki page on the PcmHacks GitHub page, you might try looking there, I don't remember seeing a quick tutorial to build PcmHammer.

I'd be happy to create test builds if you're willing to try them??
Just a matter of downloading a zip file, unzipping it, running PcmHammer on the target, then PM'ing me the debug log.

I'm hoping we get a good sunny day this week or next so I can take the car out and get me one, that is if my favorite local yard has one for a reasonable price.
But it's thunder boomer season and she don't get her shoes wet ...
Temporary is a permanent problem!

Posts: 250
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: PCM Hammer Release 014

Postby In-Tech » Sun Jul 12, 2020 7:29 pm

Hi Gampy,
Yes, I'd like to have you create some test builds. First would be to accept the 78 response in place of the 73.

I downloaded all the source I could find off of NSFW's github. I am not good at C but am gradually learning. However, I never could find anything where it dissects that string and rejects it based on the reply we are getting after sending the kernel.
Ignoring message: UnexpectedResponse 6C F0 10 76 00 78
Actually the code I found about it appeared to accept it based on the 76 reply and if it saw a 7F it would print more bytes than the two following the 76.
Code: Select all
void SendWriteSuccess(unsigned char code)
{
   // Send response
   MessageBuffer[0] = 0x6D;
   MessageBuffer[1] = 0xF0;
   MessageBuffer[2] = 0x10;
   MessageBuffer[3] = 0x76;
   MessageBuffer[4] = code;

   WriteMessage(MessageBuffer, 5, Complete);
}

void SendWriteFail(unsigned char callerError, unsigned char flashError)
{
   MessageBuffer[0] = 0x6D;
   MessageBuffer[1] = 0xF0;
   MessageBuffer[2] = 0x10;
   MessageBuffer[3] = 0x7F;
   MessageBuffer[4] = 0x36;
   MessageBuffer[5] = callerError;
   MessageBuffer[6] = flashError;
   WriteMessage(MessageBuffer, 7, Complete);
}


On a side note about these pcm's, they are expensive around here, usually over $250 USD at a junkyard. 2 out of the 3 my bud loaned me to read, appear to be tuner locked.

Thanks again,

User avatar
Posts: 730
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Mon Jul 13, 2020 3:08 am

That code is from the kernel, wrong place to be looking!

You want to be looking in the PcmHammer C# code (\Apps\PcmLibrary), not the kernel C code (\Kernels).

I don't have it in front of me at the moment, but I think you want to be looking in either Vehicle.Kernel.cs or CKernelWriter.cs, it's likely not obvious though.

I'll look into it this afternoon/tonight, heading out on the lake with the kids and grand kids ...

Please don't be offended by this, but if you don't know Git (not GitHub, two different things) and haven't cloned the GitHub repository local you're crawling down the wrong hole and it'll just stink!
I am willing to help ya Git going as best I can. (A kick in the Git go (as I call it) (puns intentional))

-Enjoy
Temporary is a permanent problem!

Posts: 250
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: PCM Hammer Release 014

Postby In-Tech » Mon Jul 13, 2020 12:42 pm

Hello Gampy,
Thanks, I'll continue to study what I've downloaded. I'll work on assembling/compiling as time allows. If it's simple for you to try the response code edit I am willing.

I hope you had a great time at the lake today :)

Site Admin
User avatar
Posts: 6350
Joined: Sat Feb 28, 2009 8:34 pm

Re: PCM Hammer Release 014

Postby antus » Mon Jul 13, 2020 2:53 pm

The control logic for the kernel upload is here: https://github.com/LegacyNsfw/PcmHacks/ ... el.cs#L343

The filter on the responses is a bit magic because of the OO design of the app, but there are two ways to verify the data. One verifies the whole response, and one verifies a partial, that function is TryVerifyInitialBytes. Its designed exactly for this, where can know from the 76 or the 76 00 that all is well, and the 78 or 73 means something which we dont know, and dont care about. So to change the call from one to the other and ignore the last byte would probably fix this without breaking any other pcm types. https://github.com/LegacyNsfw/PcmHacks/ ... ty.cs#L126

The code to change is probably in Apps/PcmLibrary/Messages somewhere. I think this is it: https://github.com/LegacyNsfw/PcmHacks/ ... ite.cs#L89

Edit: I think i've found it. This code here uses a copy of the priority byte in its validation. It does only verify up to the 76, but because its a priority 6D packet we land in the unexpected response clause. https://github.com/LegacyNsfw/PcmHacks/ ... ity.cs#L95

It think its going to take a ugly hack to ignore this if one of these PCMs have been detected. Im not certain if its a real error, or a bug in the factory OS. I think it is a bug so this might be the first PCM bug we'll need a hack for.

Could it be that this PCM cant take a multi-part kernel? Has anyone observed another tool read it and seen what it does here?
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

Posts: 250
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: PCM Hammer Release 014

Postby In-Tech » Mon Jul 13, 2020 10:32 pm

Hi antus,
Thanks for the reply and the links. I struggle tracing through C code but I'm learning. I see where it OR's to compare with the 76 but get lost after that when it goes to the TryVerifyInitialBytes. I think I see where it checks packet size. I can't compile yet but for future knowledge and testing, if I was to change this from false to true, would it continue?
Code: Select all
            for (int index = 0; index < expected.Length; index++)
            {
                if (actual[index] != expected[index])
                {
                    // This is how we indicate that the response contained garbage.
                    status = ResponseStatus.UnexpectedResponse;
                    return false;
                }


Anyway, I am game to try if anyone wants to compile stuff for testing. I can fix it if I kill it :thumbup:

There's this...
-73-
BLOCK TRANSFER COMPLETE / NEXT BLOCK
This response code indicates that a block transfer operation has been completed successfully.

-78-
BLOCK TRANSFER MESSAGE CORRECTLY RECEIVED
This response code is used to indicate that the block transfer message was received correctly,
and that any parameters included in the message were valid, but the action to be performed
may not be completed yet. This response code can be used to indicate that the message was
properly received and does not need to be retransmitted, but the receiving device is not yet
ready to receive another block transfer.

User avatar
Posts: 730
Joined: Sat Dec 15, 2018 7:38 am

Re: PCM Hammer Release 014

Postby Gampy » Mon Jul 13, 2020 11:16 pm

Thanks Antus.

In-Tech wrote:-73-
BLOCK TRANSFER COMPLETE / NEXT BLOCK
This response code indicates that a block transfer operation has been completed successfully.

-78-
BLOCK TRANSFER MESSAGE CORRECTLY RECEIVED
This response code is used to indicate that the block transfer message was received correctly,
and that any parameters included in the message were valid, but the action to be performed
may not be completed yet. This response code can be used to indicate that the message was
properly received and does not need to be retransmitted, but the receiving device is not yet
ready to receive another block transfer.

In-Tech,

It appears you found the lost document, where did you find it?

Thanks
Temporary is a permanent problem!

Site Admin
User avatar
Posts: 6350
Joined: Sat Feb 28, 2009 8:34 pm

Re: PCM Hammer Release 014

Postby antus » Tue Jul 14, 2020 12:49 am

I dont think the 73/78 are the problem, look at the priority byte of the good message and the bad one... the good is priority 6D, the bad is 6C. So I think we have:

https://github.com/LegacyNsfw/PcmHacks/ ... ity.cs#L78

Line 78 - Enters DoSimpleValidation, where the first argument is the expected prioirty
Line 83 - Builds the array to compare to - 6D F0 10 76 (doesnt include 00 73 or 00 78, so theyre not checked)
Line 84 - Checks the initial bytes are 6D F0 10 76 but theyre 6C F0 10 76 so thats a fail
Line 114/115 - Checks for a Mode 7F error response
Line 120 - Returns the Unexpected response which is logged

So I think DoSimpleValidation needs to be able to ignore the priority byte, or check for a couple of type priority bytes.
Have you read the FAQ? For lots of information and links to significant threads see here: viewtopic.php?f=7&t=1396

Posts: 250
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: PCM Hammer Release 014

Postby In-Tech » Tue Jul 14, 2020 1:34 am

Yeah antus, I mentioned that in the bottom of this post. Plenty of 6C in then out but it's weird that this one is 6D in with a 6C reply :| So do we still just let it pass if the reply is the correct length or ? Allow 6C or 6D? Just thinking of an easy way to let the last half of the kernel load and see if it will run :think:

mod edit: removed the long quote of a previous post

Posts: 250
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: PCM Hammer Release 014

Postby In-Tech » Tue Jul 14, 2020 4:03 am

antus wrote:So I think DoSimpleValidation needs to be able to ignore the priority byte, or check for a couple of type priority bytes.

^^^^^^^^^^ just noticed you typed that.


I know sometime I read a little on the:
6C = 0110 1100
6D = 0110 1101
can't find it, still digging through my notes.

It does appear that all that matters on a mode 36 is the 76 reply and you already have that check structured. So, like you said, allow either. Isn't a 6C a higher priority anyway?
36-76.JPG

PreviousNext

Return to GM LS1 512Kbyte and 1Mbyte

Who is online

Users browsing this forum: No registered users and 2 guests