Hello everyone! I am pleased to finally introduce myself, Crowbarmaster (Crowbar is fine) aka Tad here. I am here to dive deep into the Uno project, and Hammer in general. I bring years of self-taught C#/.NET skills, and I can't speak for myself, but have shown that I can understand and overcome most any challenge.
Right off the bat, I'll start off that I've had some small conversations with Antus and NSFW. I have come out with a few odd goals for this project:
Come up with a way to select a PCM type and attempt to brute-force flash the unit. This will have the conditions of making sure that at the very least, the file lines up with the selected hardware. I would believe there should be a second dialog after the wait-timeout that gives a strict warning that an incorrect select might end some hardware.
I also hear that it would be good to have some sort of remote API to top the locally hardcoded ECU data, fetching likely JSON information about OSIDs to hardware types, as well as upload them after coming across an unknown. Well, I truly believe you'll love the following idea I had already started working on in my demo project before all of this. I had a terrible time walking through PcmInfo.cs... I started breaking that down in a serializable way.
Firstly, Create a base class for OS information:
Create a base class for basic ECU setup and OSID info:
Filter out unique data on a per ECU basis; Setup information on OSIDs:
Finally, call an ECU with something like this:
I had this working with my P01, and it makes it so those OSInfo's can be passed around with JSON pretty easily. We could store those on a server, fetch them on load, then save them for offline use. It will make adding a new ECU a breeze too. Happy to hear your thoughts, and I can easily map the rest of that file out in due time!
In the meantime, I have pushed a PR to merge all current changes to the develop branch. I'll look into what all is needed to add some switching in the read/write windows. I actually had that setup in my sample:
That's the read window, but same concept. We can even opt to block risky actions initially with an "Advanced features" checkbox in options, with yet another warning about how this unlocks "dangerous" concepts.
I have more, but it's late. I look forward to hearing some insight!
PCM Hammer - The Uno UI, Improvements, and priorities
-
crowbarmaster
- Posts: 34
- Joined: Tue Mar 10, 2026 10:26 pm
- cars: 1998 Camaro SS LS1/T56 - RIP
2003 Blazer Xtreme - LM7 swap/Factory NV3500 - The project
2012 Civic LX - DD
PCM Hammer - The Uno UI, Improvements, and priorities
You do not have the required permissions to view the files attached to this post.
-
crowbarmaster
- Posts: 34
- Joined: Tue Mar 10, 2026 10:26 pm
- cars: 1998 Camaro SS LS1/T56 - RIP
2003 Blazer Xtreme - LM7 swap/Factory NV3500 - The project
2012 Civic LX - DD
Re: PCM Hammer - The Uno UI, Improvements, and priorities
Hello folks! I want to place this little teaser here. I have a functional variant of the UNO app running on Android (API 36). It has a few rough edges to smooth out yet and currently only supports OBDX and OBDLink devices connected via Bluetooth. I need more information on devices to support and people to test them - feel free to chime in!
What's changed so far:
* Added a new BluetoothPort class that implements the IPort interface. Complimentary SerialBluetoothDiscovery provides the means of polling paired devices. This port class has been fine tuned to act like a standard serial port, so very little change was needed to implement this. I will figure out how to make use of this in Windows in due time so we can prefer native BT access over virtual COMs.
* Uno can now detect Recovery and live kernel states as part of the polling loop. I have some work to go as I realized I have yet to check source/dest in the packets I receive, but I have both my OBDLink and the OBDX relying on the the broadcast message the PCM issues in recovery mode. Found out my Radio appears to be requesting programming
* In both the WinForms and Uno versions, selection of a Serial device type will soon no longer be necessary. I have come up with an assortment of tests for different devices that has so far proven to quickly select the correct type. Just for clarification, this is only partial automation. Users will still need to know what port their device exists on. It might be possible to scan each port with a timeout, but there are likely too many variables to make that work for everyone.
All in all, I have read and write well under the belt here, the comms have been rock-solid, and it works with very little issue!
Active reading! Starts off around 25, ends at about 30Kb/s After performing the read, my radio went silent on it's request and I can see the polling loop working "EC F0 80 A2 01" Oops. Actually makes sense though, the radio in this truck is an OEM, but I suspect from a different platform. Might be why this happened. This becomes an excellent test later though!
What's changed so far:
* Added a new BluetoothPort class that implements the IPort interface. Complimentary SerialBluetoothDiscovery provides the means of polling paired devices. This port class has been fine tuned to act like a standard serial port, so very little change was needed to implement this. I will figure out how to make use of this in Windows in due time so we can prefer native BT access over virtual COMs.
* Uno can now detect Recovery and live kernel states as part of the polling loop. I have some work to go as I realized I have yet to check source/dest in the packets I receive, but I have both my OBDLink and the OBDX relying on the the broadcast message the PCM issues in recovery mode. Found out my Radio appears to be requesting programming
* In both the WinForms and Uno versions, selection of a Serial device type will soon no longer be necessary. I have come up with an assortment of tests for different devices that has so far proven to quickly select the correct type. Just for clarification, this is only partial automation. Users will still need to know what port their device exists on. It might be possible to scan each port with a timeout, but there are likely too many variables to make that work for everyone.
All in all, I have read and write well under the belt here, the comms have been rock-solid, and it works with very little issue!
Active reading! Starts off around 25, ends at about 30Kb/s After performing the read, my radio went silent on it's request and I can see the polling loop working "EC F0 80 A2 01" Oops. Actually makes sense though, the radio in this truck is an OEM, but I suspect from a different platform. Might be why this happened. This becomes an excellent test later though!
You do not have the required permissions to view the files attached to this post.
-
antus
- Site Admin
- Posts: 10096
- Joined: Sat Feb 28, 2009 10:34 am
- cars: TX Gemini 2L Twincam 8psi
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Subaru WRX 2007
Re: PCM Hammer - The Uno UI, Improvements, and priorities
Sorry a bit late on this thread. Great progress, and looks good! I do like the pcminfo class changes. That is one giant switch statement that got out of control. It works, it is searchable, but it compiles to a behemoth switch statement that is probably half the size of the app (or more).
Part of the reasoning to do it that way was so that people would have to tell us if they have an undefined OSID and we can record it properly. Being able to add it manually could take us developers out of the loop and fragment the ecosystem out there. Having said that I had some time over easter and have gone ahead and implemented the reader interface. I have been trying to get to the point of being able to do an official pcmhammer 2 release, and I think it is really really close. I have the app doing what it needs to, and am just testing and re-testing existing flash targets. You might want to rebase your work on antus/p11 or wait a little longer for it to land in develop. I'll post up a request for testing when its ready.
As always i've fixed and change a bunch of tiny things that I noticed were not perfect in the background so you'll want to pick up those changes as well. Things like continuing to look for an unlock response after an unlock failure, where as now it realises an official unlock failure is terminal and gives up. It doesn't change the outcome but it just gets rid of some more messyness in the logs.
Is this idea this Uno UI is going to be used on windows and android? Or is it used when you are using a phone target? Is the original code used, or have you cut things out? I would be keen to merge this in to the official tool if the code is still all there and the UI still looks good in windows. I think it'd be OK if at runtime the device picker could identify the machine had no available serial ports and hid the serial devices from the picker. On the other hand, even on Android if it could look for RW /dev/tty* devices and allow you to pick them, that would also be cool. Most people would not use it but it would mean Linux compatibility and might work on android desktops / laptops / vms.
Here is an example of the windows UI as it is now, on the antus/p11 branch. It does not try each type, that would be quite heavy as you cant tell in advance what is going to happen when the kernel is uploaded. If the security is accepted or its in recovery mode the pcm will load and execute the file, and that could cause half working things (though typically would be a crash on fail). Generally thinking, I suspect the same kernel would be used from factory for each security algo so maybe this would work in that if the key is stock and it succeeds to unlock then it can assume which kernel to use based on that but it would be quite messy and Im not sure we should try to auto-write each supported type one by one. I think fully auto or user selection covers both angles, people should be able to pick the pcm type from its appearance and service number and some googling if they know they have a supported PCM but the app does not have the OSID in its database.
Part of the reasoning to do it that way was so that people would have to tell us if they have an undefined OSID and we can record it properly. Being able to add it manually could take us developers out of the loop and fragment the ecosystem out there. Having said that I had some time over easter and have gone ahead and implemented the reader interface. I have been trying to get to the point of being able to do an official pcmhammer 2 release, and I think it is really really close. I have the app doing what it needs to, and am just testing and re-testing existing flash targets. You might want to rebase your work on antus/p11 or wait a little longer for it to land in develop. I'll post up a request for testing when its ready.
As always i've fixed and change a bunch of tiny things that I noticed were not perfect in the background so you'll want to pick up those changes as well. Things like continuing to look for an unlock response after an unlock failure, where as now it realises an official unlock failure is terminal and gives up. It doesn't change the outcome but it just gets rid of some more messyness in the logs.
Is this idea this Uno UI is going to be used on windows and android? Or is it used when you are using a phone target? Is the original code used, or have you cut things out? I would be keen to merge this in to the official tool if the code is still all there and the UI still looks good in windows. I think it'd be OK if at runtime the device picker could identify the machine had no available serial ports and hid the serial devices from the picker. On the other hand, even on Android if it could look for RW /dev/tty* devices and allow you to pick them, that would also be cool. Most people would not use it but it would mean Linux compatibility and might work on android desktops / laptops / vms.
Here is an example of the windows UI as it is now, on the antus/p11 branch. It does not try each type, that would be quite heavy as you cant tell in advance what is going to happen when the kernel is uploaded. If the security is accepted or its in recovery mode the pcm will load and execute the file, and that could cause half working things (though typically would be a crash on fail). Generally thinking, I suspect the same kernel would be used from factory for each security algo so maybe this would work in that if the key is stock and it succeeds to unlock then it can assume which kernel to use based on that but it would be quite messy and Im not sure we should try to auto-write each supported type one by one. I think fully auto or user selection covers both angles, people should be able to pick the pcm type from its appearance and service number and some googling if they know they have a supported PCM but the app does not have the OSID in its database.
You do not have the required permissions to view the files attached to this post.
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
-
crowbarmaster
- Posts: 34
- Joined: Tue Mar 10, 2026 10:26 pm
- cars: 1998 Camaro SS LS1/T56 - RIP
2003 Blazer Xtreme - LM7 swap/Factory NV3500 - The project
2012 Civic LX - DD
Re: PCM Hammer - The Uno UI, Improvements, and priorities
Awesome, I'll get to that refactoring that class soon enough!
As of now, the UNO project builds to both Windows and Android, and works well on both! There is no reason to stop there, as I should be able to target Apple and Linux products. Linux will be last, because I'm not entirely sure that every build is going to support GUI. I'm thinking that could maybe filter down into a CLI at the very least. The Linux crowd is pretty well used to doing things CLI.
One of my next projects will be making a WiFi driver so the OBDX can be used on iOS (well, and others too) since that does not support classic BT. Do you believe it worthwhile to implement BLE? It's said to be quite slow, and I worry about that causing issues. The idea here is to make one recognized app across all platforms. I definitely have planned to work USB into android as well, but that will be last as Id like to focus on supporting other platforms first. Bluetooth has shown itself to be pretty reliable for this purpose.
Generally, the majority of the shared library is fairly untouched or added to. It's been a continuous goal to go back and verify that the original WinForms version continues to function. I am not entirely sure if this new app will be backwards compatible for older machines, so it could be useful to keep that up to date. If everything pans out and this becomes the app to use, we could eventually label that as legacy.
I am in love with the concept here, a single shared window for all of this will give the user a better experience. I'll think of a good way to work that into the UNO variant, shouldn't be too crazy! Type selection is huge - we exist in an environment where the unknown is always present, might as well cater to that. That said, it's definitely not an automated process in my eyes. I'd say we put an advanced user flag that will lock those at first, only being an option on a failed query for OSID. Advanced users can check that box and have access to those right away. We should also give loads of warning, since we have no idea the level of uncertainty that could result from a mismatch.
I'll make a new branch soon off of the merger, and apply my changes to it in preparation for a testable branch!
As of now, the UNO project builds to both Windows and Android, and works well on both! There is no reason to stop there, as I should be able to target Apple and Linux products. Linux will be last, because I'm not entirely sure that every build is going to support GUI. I'm thinking that could maybe filter down into a CLI at the very least. The Linux crowd is pretty well used to doing things CLI.
One of my next projects will be making a WiFi driver so the OBDX can be used on iOS (well, and others too) since that does not support classic BT. Do you believe it worthwhile to implement BLE? It's said to be quite slow, and I worry about that causing issues. The idea here is to make one recognized app across all platforms. I definitely have planned to work USB into android as well, but that will be last as Id like to focus on supporting other platforms first. Bluetooth has shown itself to be pretty reliable for this purpose.
Generally, the majority of the shared library is fairly untouched or added to. It's been a continuous goal to go back and verify that the original WinForms version continues to function. I am not entirely sure if this new app will be backwards compatible for older machines, so it could be useful to keep that up to date. If everything pans out and this becomes the app to use, we could eventually label that as legacy.
I am in love with the concept here, a single shared window for all of this will give the user a better experience. I'll think of a good way to work that into the UNO variant, shouldn't be too crazy! Type selection is huge - we exist in an environment where the unknown is always present, might as well cater to that. That said, it's definitely not an automated process in my eyes. I'd say we put an advanced user flag that will lock those at first, only being an option on a failed query for OSID. Advanced users can check that box and have access to those right away. We should also give loads of warning, since we have no idea the level of uncertainty that could result from a mismatch.
I'll make a new branch soon off of the merger, and apply my changes to it in preparation for a testable branch!
-
NSFW
- Posts: 802
- Joined: Fri Feb 02, 2018 5:13 am
Re: PCM Hammer - The Uno UI, Improvements, and priorities
I merged develop into the net8-uno-ui branch last night, and the combination is now in the net8-uno-ui-develop branch.
If there are no objections, I'd like to merge that back into develop, so that we can all merge contributions into develop branch going forward.
The only caveat is that this change upgrades the .Net version, and I'm pretty sure we won't be able to support Win7 anymore. IMO it's not worth the trouble to try to maintain Win7 compatibility though. That takes extra effort, and I'd prefer to just focus new capabilities instead.
If there are no objections, I'd like to merge that back into develop, so that we can all merge contributions into develop branch going forward.
The only caveat is that this change upgrades the .Net version, and I'm pretty sure we won't be able to support Win7 anymore. IMO it's not worth the trouble to try to maintain Win7 compatibility though. That takes extra effort, and I'd prefer to just focus new capabilities instead.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
-
NSFW
- Posts: 802
- Joined: Fri Feb 02, 2018 5:13 am
Re: PCM Hammer - The Uno UI, Improvements, and priorities
This PR will merge net8-uno-ui-develop into develop: https://github.com/PcmHammer/PcmHammer/pull/37
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
-
crowbarmaster
- Posts: 34
- Joined: Tue Mar 10, 2026 10:26 pm
- cars: 1998 Camaro SS LS1/T56 - RIP
2003 Blazer Xtreme - LM7 swap/Factory NV3500 - The project
2012 Civic LX - DD
Re: PCM Hammer - The Uno UI, Improvements, and priorities
Sounds good to me!
I checked, and Net4.8 is shipped in Windows 7 SP1 and I believe I saw Windows XP SP3. That should continue to function without a hitch for those platforms as a legacy application. You guys have done a good job splitting things up to a point where changes that affect devices and PCMs will keep the legacy WinForms shell working strong. If anyone needs to use a legacy windows, they will have to target the legacy app.
On the android side of things, I'll dig out some older devices and see how things work. I have piles of different generations of android devices, and can deploy some images on a few for more testing. I'll figure out what a good minimum is there.
I checked, and Net4.8 is shipped in Windows 7 SP1 and I believe I saw Windows XP SP3. That should continue to function without a hitch for those platforms as a legacy application. You guys have done a good job splitting things up to a point where changes that affect devices and PCMs will keep the legacy WinForms shell working strong. If anyone needs to use a legacy windows, they will have to target the legacy app.
On the android side of things, I'll dig out some older devices and see how things work. I have piles of different generations of android devices, and can deploy some images on a few for more testing. I'll figure out what a good minimum is there.
-
antus
- Site Admin
- Posts: 10096
- Joined: Sat Feb 28, 2009 10:34 am
- cars: TX Gemini 2L Twincam 8psi
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Subaru WRX 2007
Re: PCM Hammer - The Uno UI, Improvements, and priorities
These days win 7 is long dead and even 10 is eol without esu.. I run 10 with esu in my shed still, so based purely on that Im happy to drop 7, but I think keeping 10 working for longer is worth it.
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
-
crowbarmaster
- Posts: 34
- Joined: Tue Mar 10, 2026 10:26 pm
- cars: 1998 Camaro SS LS1/T56 - RIP
2003 Blazer Xtreme - LM7 swap/Factory NV3500 - The project
2012 Civic LX - DD
Re: PCM Hammer - The Uno UI, Improvements, and priorities
I still run 10 on my desktop... I know I'll need to move on someday but to be honest, I don't want to yet. This is certainly a nit-pick but the one very useful feature I didn't know I'd miss in Windows 10 was the recents list produced from a right-clicked icon on the taskbar. I used that way more than I thought
The UNO project currently targets Windows 10 19041 as a minimum. That should keep people using the '21 LTSC in the loop and beyond. I'll eventually install that on a machine for testing and to verify what all goes into running from a clean install too.
Edit: After looking at the state of the LTSC releases, it would seem that 1809 will be around for a couple more years yet. 2021 is only a 5 year channel, so it's pretty much expired. Perhaps I'll see if it's possible to drive the minimum down a bit more.
The UNO project currently targets Windows 10 19041 as a minimum. That should keep people using the '21 LTSC in the loop and beyond. I'll eventually install that on a machine for testing and to verify what all goes into running from a clean install too.
Edit: After looking at the state of the LTSC releases, it would seem that 1809 will be around for a couple more years yet. 2021 is only a 5 year channel, so it's pretty much expired. Perhaps I'll see if it's possible to drive the minimum down a bit more.
-
NSFW
- Posts: 802
- Joined: Fri Feb 02, 2018 5:13 am
Re: PCM Hammer - The Uno UI, Improvements, and priorities
Cool, I'm glad we're all on the same page. And glad to hear there's a chance the WinForms stuff might still work on Win7, in case anyone out there is keeping an old laptop alive just for tuning.
I'll merge that PR into develop after work today.
I'll merge that PR into develop after work today.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!