VF2 BCM: Temporarily enable feature per key cycle

[Gnome]

I'm in the process of learning how to interact with various features and modules on my car over UDS. I'm also working through the BCM firmware as practice for other modules.
In this scenario I have a manual transmission. I would like to know, if I can track down the memory address of enable Tap up / Tap down paddle shifters on the BCM (assuming it is just a Boolean); can I just send a UDS write to address to enable them? This seems too simple and shouldn't work. But will it?

[antus]

usually there is a security challenge needed and then a reflash process of some kind, so not impossible, but more than just a simple UDS write commend. You'll probably need an entire read/write process like a PCM reflash tool would.

[Gnome]

Hmmm... as I'm just getting my feet wet, I was hoping to delay a full flash until I had a better grasp on how to test in vehicle. I really don't want to brick a control module and writing to RAM just seemed so convenient.

So, @antus you're saying that reflashing is just more straightforward (and better documented)? So I would enable the feature as a firmware and flash the calibration file?

I would like to avoid crafting my own resident routine that would execute in RAM to modify a single memory address in ROM as that seems more in-depth with creating checksums along the way that all match.

[antus]

No I am not saying its straight forward or better documented. Just that is what you are going to be up against. These things do not just let you write to RAM with no security, and even if they did the bit you need to change is probably in flash direct, not copied to ram. You would be best to do some research and see if you can find how other people have read them - can it be done with software? Are they putting a clip over the chip and reading it direct? Then get another BCM and experiment to find a way to read it. Then read yours once you know what you're doing and then try to clone yours on to the spare. Once you have that you then have a spare, and way to write it with minimal risk. Then try and flash it with factory tools, monitor how it does it and/or read back a changed bin from the flash, and compare to yours. Then you need to figure out checksums and you'll need to set that feature flag in an official way to figure out what flag it is then document it for others.

[Tazzi]

I have quite a bit of experience in this field.

To properly understand what you are doing requires creating a kernel to actually dump the entire BCM.

From here you can disassemble and begin mapping the routines to find where all calibrations are being used.

Mapping out the IO pins of the processor to see where they go to on the BCM to then understand what certain functions and areas might be doing, then understand how calibrations in those areas affect usage of those.

Another method is comparing calibrations between various vehicles to spot what certain items are, mapping them in the disassembly and following through to see what other values may do around that region.

It’s a bit of a process. But gets easier the more you do it.

[Gnome]

Hello @Tazzi, I've been lurking for a while on this forum and have tried to pick up as much as possible before posting. I wrote a slow UDS program that uses service $23 to download a range of addresses and self heals. With this method I was able to aquire 0x00000000 - 0x001FFFFF and then loaded that into Ghidra and added a memory map to include the RAM and set the global registers from information at 0x8260. Currently I'm unsure if I have all the runtime code and or eeprom data.

I do not have access to SPS to any GM tooling.

If you want to DM me any useful addresses I'll be sure to check then this weekened

[Tre-Cool]

well since Tazzi sells a service that allows programming of said modules. it's probably not in his interest to share too much of his hard works for free.

[Gnome]

Still just poking around on Saturdays. Had a few wins.
1. Was able to get CVN and Checksum generation working. Seems that different calibrations headers calculate the CVNs differently.... so it goes.
2. Mapped the following DIDs:

Code: Select all

DID	Menu path						Values
$23	Power Door Locks → Delay Door Lock			Off=0, On=1
$24	Power Door Locks → Auto Door Unlock			Off=0, Driver Door=1, All Doors=2
$25	Lighting → Exit Lighting				Off=0, 30 Seconds=1, 1 Minute=2, 2 Minutes=3
$26	Lighting → Vehicle Locator Lights			Off=0, On=1
$28	Remote Lock/Unlock/Start → Remote Left in Veh. Reminder	Off=0, On=1
$29	Remote Lock/Unlock/Start → Passive Door Lock		Off=0, On=1, On with Horn Chirp=2
$2D	Remote Lock/Unlock/Start → Remote Door Unlock		Driver Door=0, All Doors=1
$2E	Power Door Locks → Open Door Anti Lock Out		Off=0, On=1
$32	Remote Lock/Unlock/Start → Passive Door Unlock		Driver Door Only=0, All Doors=1
$34	Remote Lock/Unlock/Start → Remote Unlock Feedback	Off=0, Flash Lights=1
$35	Remote Lock/Unlock/Start → Remote Lock Feedback		Lights Only=0, Lights and Horn=1, Horn Only=2, Off=3

That leaves 10 possible other DIDs that are user configurations... and may have nothing to do with what I'm looking for, but seems like low hanging fruit. Looks like I'll have to borrow another Sedan to see if a different RPO allows for those to change. I still haven't tried to write to the BCM.

[Knackersjewels]

If you get somewhere with this, I'd love to disable dtcs in standalone setups that only use the bcm for shifter/reverse output