I have a terminator X Max in my LS swapped Audi (hence the username) that I would like to send some inputs to the ECU such as when the AC button is pressed to increase idle RPM. I could do this using the normal wired inputs, I know, but I don't want to. Holley doesn't publish CAN IDs because they want you to buy their modules  , and yes hindsight being 20/20 I should have bought Maxxecu or something else but I'm too cheap to buy another ECU at this time, maybe in future.

I've seen devices such as the ones Holley makes, but also aftermarket products such as the BoostSmart IO, that can accomplish this. I found a firmware update for the 7" display and loaded it into Ghidra. Looks like the dash is using an ARM Cortex processor and can send sensor data inputs to the ECU (manual says telemetry for example) and this is done with several functions such as the ones attached I believe. I'm still pretty new to programming in general and especially disassembly but thought this was a cool find! Attached is the bin that Ghidra disassembled nicely. Still deciphering exactly how the Can ID is formatted for transmission because I know Racepak output from the Holley uses extended IDs and also trying to figure out how CanLookupTable for received messages is populated (for more projects) but I still wanted to share. I didn't have to label anything or set the base address and I don't understand how but numerous functions were named accordingly already once analysis was performed.

Thanks @d3irb!

So looks like the older firmware version has better labels and makes more sense to me. From what I can gather, the Holley CAN ID is similar to the Racepak protocol and runs at 1mbps but has a slightly different structure for the ID:

Bits 28:28 – Command Bit (=0 for broadcast i think)
Bits 27:25 – Target ID (I think 101= broadcast)
Bits 24:22 – Source ID (haven't confirmed if 010 is hefi like Racepak but pretty sure it is)
Bits 21:11 – Target Serial (used as a channel # index, index #1 is RPM)
Bits 10:0 – Source Serial Number (11 bits)

So assuming the structure above, the CAN ID for RPM with the source serial number masked out (using 0xfffff800) would be 0x14100001.

For the data:
First 4 Bytes: This would be the Value field. These bytes are combined into a 32-bit value. I haven't found any evidence of a scale or offset factor being applied.
Second 4 Bytes: This would be the Status field. Usage is TBD.

RPM = (RxMessage.Data[1] << 8 ) | RxMessage.Data[0];

Example:
If the CAN message has:

CAN_ID = 0x14100001
RxMessage.Data[3] = 0x0
RxMessage.Data[2] = 0x0
RxMessage.Data[1] = 0x09
RxMessage.Data[0] = 0xC4

---------------
uint32_t RPM = RxMessage.Data[0] |
(RxMessage.Data[1] << |
(RxMessage.Data[2] << 16) |
(RxMessage.Data[3] << 24);

Then:
RPM = 2500 RPM

My car is currently not operational or else I'd log and confirm. Anyone have a Holley CAN trace / log they can share?

Well now I don't think Target ID of 101 = broadcast. I need to log some traffic to confirm... attached is the IRQ function with comments. For broadcast data such as RPM looks like the function doesn't care what the Target ID is so long as it's not 0101 and the command bit is 0 then it will extract the data.

Pretty sure I can say broadcast messages such as RPM for sure have a 010 Source ID though,