I still don't have a PCM set up on my desk yet, but there's a mock PCM in the app that returns fake data that gets displayed in the UI.

You can pick the 'mock port' and 'mock device' and it pretends to ask the PCM for the VIN and OS info. I think all of the basic plumbing is in place now. I pushed up an update to the app on Monday, and I'm pretty happy with the design at this point. Happy to commit my changes to github so you can have examples of read/write for the VPW protocol? Also added in basic coding to read VIN from LS1 ECU under the vehicle class where I saw the query VIN function. I did a quick throw together last night and chucked in some J2534 coding under the J2534port class to find the installed devices and connect on up. Just downloaded and went over whats there so far, and the base framework is looking pretty tidy! Has anyone figured out the seed/key algorithm yet? Hopefully we'll have open-source software around the same time people like Thaniel get the hardware stuff figured out. If anyone has anything to contribute to such an effort, please let me know. My hope is to extract GM's reflashing kernel from a recorded session, open it up in IDA, figure out how it works, write a new one in C, as post that on Github as well. NSFW wrote:I've been working on some utilities to help with reverse engineering: The open source LPXExpresso project is not too hard to get building (requires some mods to the project to build and checksum a firmware bin) and the code is modular and high quality so It wouldnt be too much work to do. There is also the option of a complete re-write of the guts of the firmware. The NXP main IC has enough ram, so the platform would be capable of at least 1K packets, probably more.

The 180 char was just bumping buffer sizes up, Ive made no attempt to organize ram better. Ideally we'd want to implement a raw mode where you send a non-standard AT command and it starts talking something more like the AVT protocol, so that you dont need to reserve 3 bytes of ram for every byte of data, but the app is designed around elm protocol. The 4x is just a hack to the timings, so the packet size applys to both. You can get an idea whats needed from this post viewtopic.php?f=31&t=4632&start=20#p83464 I would expect on the USB version its the same but with USB on the port your talking about. Ive only played with the original development board and its ttl serial on the end.

Openport cable chevy