Flashhack - New LT1 flash tool

[steveo]

nomakewan if you want to have some totally useless fun, you should do some mode 4 brute force testing on the CCM.
device F1
command 04
now try random stuff in the payload... 02, or 00cc... or 0000C0
see if any of the bytes manage to get a response with your dashboard or whatever
maybe we'll stumble upon something that blinks a light or displays something
again totally useless but fun to try

[NomakeWan]

I'm not sure about just randomly throwing code at it, but you're correct that it should be able to do that. I have confidence in that since Vertronix's manual for the Tech 1A includes Mode 04 commands for the CCM.

Tech 1A Body Commands: http://www.zr1netregistry.com/Portal...01988-2004.pdf
Tech 1A Chassis Commands: http://www.zr1netregistry.com/Portal...6-2004view.pdf

I might give it a whirl just for shits and giggles anyway, though I imagine accidentally triggering the horn relay on might get exciting.

[steveo]

none of those look too dangerous. i wonder if 0xFFFFFFFFF turns them all on at once. if you could find the horn enable bit we could definitely have some fun with that one. keep in mind with a mode 4 command, everywhere i've seen them, sending a few zeros as the payload usually cancels the whole thing (and so does cycling the key obviously)

[JimCT_9C1]

Just a quick update -

Flashing to F-body had no issues using b0.5.4 at 16ms, 3ms, and 1ms latency.
Performed full writes to both sides. No echo-related bugs have reappeared in any of the reads or writes using b0.5.4.
Still have to test on B-body.

Downloaded b0.5.5, but haven't done any testing yet.

Steveo, sorry to hear that the 8051 is done for - LT1s seem to be in good shape though.
And excited to see you're looking at the 96+ LT1 pcms!

Jim

[steveo]

thanks for testing!

i'm very confident that the flash tool for the lt1 isn't just the best lt1 flash tool but probably one of the best flash tools period as far as recovery goes. that recovery patch kur4o came up with is barely even necessary, since ECM power failure during a flash is pretty hard to induce, but is icing on the cake.

right now we are at bricked ecm count zero and i think we'll stay that way, i don't see how it'll brick an ECM unless some total moron unplugs ECM power during an erase or after a failure occurs.

0.5.4+ was tested in a loop for 24 hours solid and had zero errors

one thing that's come up is the rare $EEB mask, due to differences in the comms code, the e-side recovery patch doesn't work (and i dont care because its so rare) but flashhack's logic does catch the problem and refuse to install the patch rather than screwing something up. you have to go disable the patch for the e-side. flashing still works and recovery still works if ecm power is maintained (and the t-side recovers fully) so i'll leave that as-is.

edit: i will put this connection code in eehack's next release (which will also hide or remove the flash tool in eehack itself, directing people to use this much safer one)

[NomakeWan]

none of those look too dangerous. i wonder if 0xFFFFFFFFF turns them all on at once. if you could find the horn enable bit we could definitely have some fun with that one. keep in mind with a mode 4 command, everywhere i've seen them, sending a few zeros as the payload usually cancels the whole thing (and so does cycling the key obviously)

LOL

Okay, so first off, it's actually hard to use Flashhack to interrogate the Mode 04 commands for the CCM. This is because the communication routine in Flashhack causes the digital dash to freak out anyway on successful connection, so it's hard to tell what's from the command you just sent and what's just a result of the bus going into serial data deprivation mode. Sending FFFF, from what I could tell, did cause the high beam indicator to come on (though my headlights were down, so I couldn't tell if this was just the indicator or also the lights; judging by the wiring diagram it should just be the indicator). I didn't notice any others but I'm not sure. So after finding it hard to tell the difference between the command I sent and the connection routine resetting the digital dash, I decided to send FFFFFFFF.

This was a massive mistake, as as I should have expected, it caused everything to come on all at once, including the horn relay. These all stayed on for about five seconds before the CCM reset to normal mode. I also was reminded the hard way that the CCM is on battery power, not ignition power, because turning the key off did not stop the horn from blaring.

[steveo]

i can't believe we honked your horn via the aldl port. that's some really great pre-canbus stuff.

flashhack 0.6:
- made horn honk at random during flash write. only affects corvette owners

[NomakeWan]

Definitely going to stick to 0.55, HAHAHA.

Tomorrow if I have some time during the day (somewhere other than my driveway), I'll try using EEHack to do the test so I can keep the dash up, and see if I can figure out which bit goes to which operation. Would be pretty hilarious if it really was just based on their position in the list from the service manual.

[steveo]

i'd like to know why eehack and flashhack work differently with regards to your dash, can you look into it? things should pretty much be identical from the perspective of the dash, especially with the new connection logic that doesn't disturb the bus too much

[NomakeWan]

I'll look into it. I haven't gotten my second laptop set up yet so I can't do signal analysis just yet, but I plan on being able to do that this weekend. But yes, the latest version of EEHack does not interfere with the dash (except of course for nullifying the MPG calculations), but Flashhack causes the dash to reset upon successful connection (security light comes on, digital displays SYS, then it wakes back up).

I did some more experimenting with EEHack and the CCM in a parking garage today at work. It turned out that the five seconds I was experiencing while experimenting with Flashhack was actually due to Flashhack's timeout period. So with Flashhack, if I send a command, it first connects to the bus, then sends the command, then after a certain amount of time (~5 seconds?) with no further commands, it disconnects from the bus and returns everything to normal operation. This disconnection process resets the CCM, which cancels the Mode 04 command. EEHack on the other hand connects first and stays connected until you disconnect it. As such, sending a command will cause that to continue to run until you send an opposing command (such as 00) or reset the CCM or the bus.

So, the results of my experimentation were...interesting. I haven't pinned down how to exactly get what I want out of the Mode 04 commands. But here's what I was playing with.

First, 00 does reset Mode 04, so you can turn things back off that you turned on. That's important, especially if you turn the horn relay on with EEHack. Here are the commands I was able to try out:

FF = High Beam Indicator/Relay? Again, had the headlights down, so not sure if it's just the light or if it's also the high beams themselves. You do hear a fairly loud relay click when this comes on.
00FF = Dim Speedometer. This causes the digital portion of the dash to blank out.
FF00FF = Security, Change Oil, Door Ajar, High Beam, Check Gauges, Seatbelt, Low Oil. This essentially causes every light on the dash to come on (except the turn signal indicators), as well as the Low Oil light on the DIC.
F000F0F0 = Door Ajar, High Beam, Low Oil.
00FF00FF = Dim Speedometer, Courtesy Lights On, Chime On, Horn Relay On.
00FF00F0 = Dim Speedometer, Chime On.

Interestingly, attempting to do something like "000000FF" does nothing. It seems that if the first four bits are 0, nothing happens. At least one of the first four bits must be nonzero. I only tested F, but considering the combinations of lights that came on, I'm guessing that this is actually based on number values somehow.

[steveo]

I did some more experimenting with EEHack and the CCM in a parking garage today at work. It turned out that the five seconds I was experiencing while experimenting with Flashhack was actually due to Flashhack's timeout period. So with Flashhack, if I send a command, it first connects to the bus, then sends the command, then after a certain amount of time (~5 seconds?) with no further commands, it disconnects from the bus and returns everything to normal operation. This disconnection process resets the CCM, which cancels the Mode 04 command. EEHack on the other hand connects first and stays connected until you disconnect it. As such, sending a command will cause that to continue to run until you send an opposing command (such as 00) or reset the CCM or the bus.

flashhack doesn't really have a timeout period. eehack does have a keep-alive feature that keeps twiddling the bus keep it asleep. what's happening is the CCM times out with no activity on the bus in flashhack and resuming normal traffic. i might add a keepalive thing to help with testing like this but as a flash tool it's probably not necessary, we just start our operation, and when it's done, it's done. there should be no idle time.

Interestingly, attempting to do something like "000000FF" does nothing. It seems that if the first four bits are 0, nothing happens. At least one of the first four bits must be nonzero. I only tested F, but considering the combinations of lights that came on, I'm guessing that this is actually based on number values somehow.

ah yeah that's something we've seen before. sometimes there's bits/bytes for 'enable override' then bits/bytes for 'on/off'.

this is because overriding a control system switch is actually a tri-state. it can't just be on/off, it's actually on/off/normal (i write on/off/auto in eehack)

when eehack is running, enable that advanced mode thing that shows the hex at the bottom of the screen, you'll see how some actuators require multiple bits in combination to work this kind of thing.

[kur4o]

It is usual 1 bit to enable control of the solenoid and a second bit to turn on/off.

You can try 00000101 00000202 00000404 00000808 00001010 00002020 00004040 00008080

and so on

On PWM output one bit enables it and the a second byte defines the range. I am sure there is more left on the table than you have in the list.

I tried to find the commands in the bin but I am still nowhere near to that.

[steveo]

my 8051 test bench is working again.....for now.

[NomakeWan]

You can try 00000101 00000202 00000404 00000808 00001010 00002020 00004040 00008080

and so on

None of those work. As I thought, if the first four bits are 0, then nothing works. So nothing that starts with 0000 will get you any response.

That said, here are the results of today's testing. I still wasn't able to really pin down individual commands, nor how exactly individual things were queried. But looking at it, there does appear to be a firm numerical component rather than just "[device][state]" like "1F". So I'm going with my original theory that the actual output value in decimal form is relevant to the command(s) performed, rather than individual bits representing which command is done and on/off.

1F (Relay under steering wheel clicks)
2F (High Beam Indicator On dim)
3F (Same as 2F)
4F (Nothing?)
5F (Same as 1F; Click that interferes with radio; Radio Dim?)
6F (Same as 2F)
7F (Same as 1F)
8F (Nothing?)

001F (Speedo Dim)
002F (Same as 001F)
003F (Same as 001F)
004F (Same as 001F)...

F0F01F00 (Same as 2F)
F0F02F00 (relay clicks, high beam light brighter, radio interference)
F0F03F00 (high beam bright)
F0F04F00 (hi beam dim, click, low oil)
F0F05F00 (hi beam dim, low oil)
F0F06F00 (same as F0F04F00)

F0F0F01F (hi beam bright, door ajar, low oil)
F0F0F02F (door ajar, hi beam bright, low oil, slow chime)
F0F0F03F (same as F0F0F02F)
F0F0F04F (door ajar, hi beam bright, low oil, fast chime)
F0F0F05F (same as F0F0F04F)
F0F0F06F (door ajar, hi beam bright, low oil, faster chime) (faster chime = both chimes??)

FFF0F0F0 (same as F0F0F06F!?)
FFF1F0F0 (same as above but with speedo dim)
FFF1F1F0 (same as above but with Change Oil)
FFFFFFF0 (same as above but with seatbelt)

0F0F1F11 (security, change oil, seatbelt)
0F0F1F12 (same as above, with speedo dim and horn)
0F0F1112 (same as above??)

Oh, and I popped the headlights up, and confirmed that the high beam light is just the indicator, not the actual high beams.

[steveo]

i did some research and found the most efficient way to keep the ALDL bus alive is to send a valid message to a nonexistant device.

conventionally, we would 'silence the master device' over and over, since the device wont wake back up if there's ALDL traffic.

one problem with that is the device may be gone, or be unable to reply as it's running a kernel incapable of that. so we have to wait for that reply, because if it comes while we're sending a message, it'll be corrupted, forcing a reasonably long delay between keepalives and requests.

i tried just sending zeros for a keepalive, but it *seems* like it needs to be a valid message which passes checksum verification, and is obviously ignored as it's from a nonexistant device.

so if you just send a valid mode 0 request to device 0 or some other nonexistent device every few idle seconds that works