PCM Hammer Release 014
Re: PCM Hammer Release 014
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 ...
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 ...
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: PCM Hammer Release 014
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.
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,
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);
}
Thanks again,
Re: PCM Hammer Release 014
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
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
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
Re: PCM Hammer Release 014
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
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
- antus
- Site Admin
- Posts: 8253
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: PCM Hammer Release 014
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?
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: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Re: PCM Hammer Release 014
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?
Anyway, I am game to try if anyone wants to compile stuff for testing. I can fix it if I kill it
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.
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;
}
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.
Re: PCM Hammer Release 014
Thanks Antus.
It appears you found the lost document, where did you find it?
Thanks
In-Tech,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.
It appears you found the lost document, where did you find it?
Thanks
Intelligence is in the details!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
It is easier not to learn bad habits, then it is to break them!
If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
- antus
- Site Admin
- Posts: 8253
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: PCM Hammer Release 014
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.
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: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Re: PCM Hammer Release 014
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
mod edit: removed the long quote of a previous post
mod edit: removed the long quote of a previous post
Re: PCM Hammer Release 014
^^^^^^^^^^ just noticed you typed that.antus wrote: So I think DoSimpleValidation needs to be able to ignore the priority byte, or check for a couple of type priority bytes.
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?