Minor Flashhack Bug

[NomakeWan]

Heya steveo,

While chasing down an issue on my '95 today I noticed a rather odd bug with Flashhack. It could just be me doing something dumb, but I figure I'll share and see what's going on.

So I was noticing that flashhack wasn't doing the fingerprint thing correctly anymore. When I would write it would always write the full memory space. I also noticed that in EEHack, I wasn't getting a read on my VIN or CAL ID. So I tried flashing a known-good tune, then reading the exact same tune back immediately afterward. Oddly, they did not match. The VIN and CAL ID memory locations were wiped to FF, and a random memory location at $1000 was set to 00.

I've attached both BINs to this post. 'write' is the one I tried to write to the car, and 'read' is the one I read from the car after writing.

In Flashhack's settings I had enabled:

Only write side(s) that have changed, Write E-SIDE, Write T-SIDE, Install recovery ROM on E-Side, Install Recovery ROM on T-Side, Verify patching regions against reference., Do not write 0xFF regions, Set unused regions to 0xFF, Read onboard EEPROM, Handle E-Side comms patch, Get vehicle fingerprint.

I assume 'Set unused regions to 0xFF' is probably at fault here, but if so, it shouldn't be nuking VIN and CAL ID. Plus I'm not sure what that $1000 set to 00 is all about.

[steveo]

newer versions of flashhack will, by default, update those values from your bin as part of the flash procedure (so they always match the values stored with your bin, which is what most users would expect, but was never happening before).

if for some reason your bin has been wiped at that area it will not touch it. it requires at least the seed/key (which is stored there) to be sane.

see "EE_WRITE_ONBOARD_EEPROM" and "EE_PROTECT_EEPROM" and "EE_PATCH_EEPROM_UNLOCK"

it's very new code so if it's glitching out on you go ahead and disable those things

i will look into why it failed for you but can you confirm how those options are set

[NomakeWan]

newer versions of flashhack will, by default, update those values from your bin as part of the flash procedure (so they always match the values stored with your bin, which is what most users would expect, but was never happening before).

if for some reason your bin has been wiped at that area it will not touch it. it requires at least the seed/key (which is stored there) to be sane.

see "EE_WRITE_ONBOARD_EEPROM" and "EE_PROTECT_EEPROM" and "EE_PATCH_EEPROM_UNLOCK"

it's very new code so if it's glitching out on you go ahead and disable those things

i will look into why it failed for you but can you confirm how those options are set
I don't see any of those options. This is flashhack 1.2 from your website. Am I missing something?

[steveo]

huh i thought i uploaded the new version

well if you are running 1.2 it shouldn't touch the onboard eeprom as it doesn't even have the code to do that

[NomakeWan]

There was a point where you had shared a 1.3, and I believe I did use it once, but you then said you found a bug with it and took it down and warned me not to flash with it. I had already done so. Maybe that's the root cause here?

I just always assumed that was why 1.2 was the only version you made available to the public. If you have a 'fixed' 1.3 then yeah, would love to test it out to see if that resolves the issue.

[NomakeWan]

Just gonna ping back. It sounds like you've got a newer version that never got released, so I'd love to give it a shot. Especially if it could potentially fix the issue with my '95 EEPROM from the old buggy copy of 1.3. :thumbsup:

[steveo]

it'll totally rewrite your on-chip eeprom (where the vin and other stuff is) if you want it to but it'd be nice to know what the hell happened too

[NomakeWan]

If it helps, here is the copy of the source for 1.3 I had laying around. What likely happened here was I was testing it out, flashed my 95 with it, you found a bug somewhere and warned me not to use 1.3 to flash, and I shrugged and moved on since I already had, not noticing the corrupted EEPROM areas until now.

That's my theory, anyway.

[steveo]

oh yeah if you were testing unreleased versions it totally could have wiped it
when i am near my laptop ill upload the latest source for you
you should be able to restore the eeprom data from any bin you had read previously
it needs testing anyway

[NomakeWan]

Thanks a bunch! Much appreciated. Always willing to test out new stuff. :thumbsup:

[steveo]

see attached source

there are a few options related to the new features just read them carefully

this version will write your new VIN and calibration id from the bin by default. of course you can turn that off if you don't want it.

one caveat is if you want FULL eeprom write (there is a protected region by default) you need to do a reflash once before that region is unprotected (need to let flashhack alter the config register part of the bin)

[steveo]

i should mention that the code this thing uses is a port of my routine for reprogramming the CCM (which also stores stuff in the on-chip eeprom)

it has a variable run time length depending on how much you are actually changing, and does bit level comparison to avoid unnecessary erasing.

i'm pretty happy with how well it worked for my own test suite it but it is totally possible it has insane bugs that i haven't anticipated. i have a bit of experience modifying existing 6811 assembly code but this is something i wrote from the ground up which is why i don't really want everyone using it until it's proven it works.


TO RUN THE PROGRAM:
7E $program_routine_address [BLK_SIZE] [OFFSET_16] [DATA...]

; ALDL_REPLY(START)

18 CE F4 9D ; LDY 0xF49D
C6 01 ; LDAB 0x01
ce ff b0 ; LDX loc_FFB0
ad 00 ; JSR,x+00
39 ; RTS

; ALDL_REPLY(END)

; PROGRAM_BLOCK(START)

; INPUT MUST GO AT 61C3 OR MUST REALIGN ALL 61E VALUES.
; INPUT: [BLK_SIZE] [OFFSET_16] [DATA....]

CE 61C6 ; LDX address of data
F6 61C3 ; LDAB block size
5A ; DECB block size--
2B EB ; BMI if b<0 goto ALDL_REPLY (operation finsihed)
F7 61C3 ; STAB block size
3A ; ABX - add blk size to address of data
A6 00 ; LDAA,x - A = data at address of data
FE 61C4 ; LDX write offset
3A ; ABX - add blk size to write offset
8D 02 ; BSR PROGRAM_BYTE
20 E9 ; BRA PROGRAM_BLOCK (loop)

; PROGRAM_BLOCK(END)

; SUBROUTINE PROGRAM_BYTE(START) - A=VALUE X=ADDRESS

; CONFIGURE:
C6 03 ; LDAB 03
37 ; PSHB - push max retry count onto stack

; RETRY LIMIT:
33 ; PULB - pull retry counter
5A ; DEC B (B--) - decrement counter
37 ; PSHB - push retry counter
27 06 ; BEQ COMPLETE

; VERIFY:
A1 00 ; CMPA,X - compare target value with existing value
27 02 ; BEQ COMPLETE - if value is already correct.
20 02 ; BRA ERASE - if value not yet programmed

; COMPLETE:
33 ; PULB - remove retry counter from stack
39 ; RTS

; DIFF:
; SEE IF ANY BITS ARE ACTUALLY GOING TO BE SET HIGH.
; IF NOT, WE DO NOT HAVE TO ERASE (AVOID 10MS DELAY)
36 ; PSHA
43 ; COMA - NOT A
A4 00 ; ANDA - AND A WITH MEMORY AT X
32 ; PULA
26 04 ; BNE SKIP FF (SKIP ERASE)

; ERASE:
C6 16 ; LDAB 0x16 - program mode ELAT/BYTE/ERASE
8D 0A ; BSR EEPROM_PROG - call program subroutine

; SKIP 0xFF:
; IF WE ARE JUST "PROGRAMMING" AN FF, WE DO NOT NEED TO DO ANYTHING
; AFTER ERASE (AVOID 10MS DELAY)
81 FF ; CMPA 0xFF - see if A = 0xFF
27 04 ; BEQ VERIFY - skip programming if FF

; PROGRAM:
C6 02 ; LDAB 0x02 - program mode ELAT
8D 02 ; BSR EEPROM_PROG - call program subroutine

20 DE ; BRA RETRY LIMIT (VERIFY AGAIN)

; PROGRAM_BYTE(END)

; SUBROUTINE EEPROM_PROG(START) - ACCUMULATOR B = PROGRAMMING MODE.

; LATCH AND SET BYTE
F7 103B ; STAB 0x103B - set eeprom control register from B
A7 00 ; STAA,x - store A (value) at X (location) (write byte)

; SET EPGM (PROGRAM VOLTAGE)
CA 01 ; ORA 0x01 - set EPGM (bit 1) in B
F7 103B ; STAB 0x103B - set eeprom control register from B

; DELAY
3C ; PSHX - save X register
CE 0D06 ; LDX 0xD06 - loop total exec time approx 10ms @ 2mhz clock (6 cycles in loop)
09 ; DEX - x--
26 FD ; BNE REL-3 IF > 0
38 ; PULX - restore X register

; RESET COP (for every 10ms delay)
C6 55 ; LDAB 0x55 ; ARM COP.
F7 103A ; STAB 0x103A (COPRST)
C6 AA ; LDAB 0xAA ; RESET COP
F7 103A ; STAB 0x103A (COPRST)

; COMPLETE
7F 103B ; CLR eeprom control register
39 ; RTS return

; EEPROM_PROG (END)

[NomakeWan]

see attached source

there are a few options related to the new features just read them carefully

this version will write your new VIN and calibration id from the bin by default. of course you can turn that off if you don't want it.

one caveat is if you want FULL eeprom write (there is a protected region by default) you need to do a reflash once before that region is unprotected (need to let flashhack alter the config register part of the bin)
So, two things. You'll have to excuse me as I've never built anything Qt before, so I'm going through this like a bull in a china shop.

First, attempting to build Flashhack throws errors in datastream_obdxpro.cpp because of the cast to (unsigned char)0x00 being ambiguous. I corrected this by adding a line as such:


unsigned char c = 0x00;
b.append(c);
This resolved the ambiguity and allowed the compiler to compile the EXE successfully.

The second issue, however, is that the source doesn't include all the other files I need to make it work. While I could copy these from 1.2 or 1.3, I see that this EXE is version 1.4. I also see that the files in the EE folder in 1.2 are not the same as the files in the EE folder in 1.3. Specifically, ONBOARD_EEPROM.BIN does not match between 1.2 and 1.3. This makes me think that 1.4 may have 1.4-specific files. If this is the case, I'd like those as well. Then I can fire this thing up and give it the ol' college try.

I've attached a screenshot of the difference between the two BIN files for your reference.

[steveo]

oh yeah you definitely need those too

[steveo]

here's the binaries

[NomakeWan]

steveo,

It appears 6811.zip is missing ONBOARD_EEPROM.BIN. While I thought this might have been intentional, Flashhack 1.4 complained about it being missing and said that as a result, it couldn't set the Vehicle ID.

However, despite this, it did successfully flash both sides, and has indeed corrected the issue with my VIN and CAL ID being corrupted. So that's a plus!

[steveo]

i think the error is in error assuming it fixed your vin and cal id without you doing it manually.

[NomakeWan]

i think the error is in error assuming it fixed your vin and cal id without you doing it manually.
Looking at your code, it appears you have shifted from doing maths on factors that exist in the BIN already in order to determine vehicle fingerprint to attempting to write a unique Vehicle ID to the 4-byte region of EEPROM stored at 0x0FFC. In this branch of code, you use ONBOARD_EEPROM.BIN as the simple program to execute on T-SIDE. However, since ONBOARD_EEPROM.BIN does not exist, this attempt fails, triggering the message:


Could not set or retrieve vehicle ID. The compare functions are not going to work well.
Looking further, the actual routine that writes the EEPROM region for VIN and CAL ID doesn't use a simple program, it calls...


bool processor_ee::program_eeprom_block(int device_id, region r, QByteArray data) {
log("PROGRAMMING" + r.to_string(),LOGLEVEL_DEBUG);

datastream_request request(device_id,COMM_EXECUTE);
request.append16(0x0300); // ram location to store the block
request.append(0x7E); // JMP
request.append16(0x1CB4); // .. to the exec point of the write program.
request.append(r.size);
request.append16(r.offset);
data.resize(r.size);
request.append(data);
request.override_timeout = (r.size * 35) + 150; // could take a bit o' extra time if writing lots of stuff.

emit region_changed(device_id,r.offset,r.size,REGION_PR OGRAMMING);
datastream_reply repl = interface->request(request);

if(repl.success == true) {
emit region_changed(device_id,r.offset,r.size,REGION_WR ITTEN);
return true;
} else {
emit region_changed(device_id,r.offset,r.size,REGION_ER ROR);
errmsg("Error programming EEPROM.");
return false;
}
}

Which works since it's not looking for ONBOARD_EEPROM.