Cehbra

iTrader: (1)

Inspired by Firechicken86 and many others I’m currently preparing on swapping a digital dash into my 1991 TBI Firebird. I know, it is not going to be a piece of cake, as there is no harness that matches. So naturally I will have to cut and splice wires myself. But I like the challenge, so I’m going to do it that way. I will post my progress on the swap in a different thread in the near future.

Edit: Here it is, for interested people: https://www.thirdgen.org/forums/inte...dash-swap.html

That said, those who remember my build thread

http://www.thirdgen.org/forums/membe...-memories.html

know that I am very picky about details and I would not even try to do a swap before I could resolve that one big issue: even though digital dashes often are well kept, they usually carry high mileage on the odometer. My car currently has around 25 K miles. There is simply no way I would put in an odometer with five times that amount. I’ve been hunting around the web for answers on how to change the 86-88 GTA/Trans Am digital dash odometer reading with no luck whatsoever.

So... I thought I might as well give it a try myself.

Cehbra

iTrader: (1)

I have read - and also heard people say - it was easy to manipulate the digital dash odometer. Without telling how, that is.

Sounds totally easy

But hacking the odometer wasn’t easy at all.

Cehbra

iTrader: (1)

Yes, I did it. It took me a while, but I cracked the code in the end.

It took me several weeks of sweat, frustration and number crunching to decrypt the algorithm. On the other hand, as I can see clearly now, Pontiac engineers invented an elegant and beautiful method to securely store the odometer value in the EEPROM. In contrast to the simple hex inverter table that was implemented in the Lexus ES300 or the Ford method of merely converting miles to binary, PMD engineers made it *much* harder to break the code. I think that’s why it hasn’t been cracked in the last 30 years.

Cehbra

iTrader: (1)

Just to show you what I mean, here is the mileage on the original chip that came with the odometer. It reads 164365 miles.




Now that I know the algorithm I can freely change the reading to whatever I want. Here would be an ultra low mile Trans Am:

Cehbra

iTrader: (1)

For the moment, I’m not going to disclose the algorithm here, as I have several concerns. Once these are resolved, I will gladly reveal how it works - if anyone is interested in the first place.

These are my concerns:

While tampering with an odometer is not an illegal procedure in most countries, selling a car with a false odometer reading is a fraudulent action. I truly believe that third generation F-bodies are the most amazing cars ever built and they deserve honesty. The only two cases I imagine are legal are A) repair a broken odometer and B) correcting the odometer reading to match the real mileage of the car. So once the code is publicly known, someone might use that information for illegal purposes, who knows?

My second concern is about copyright and reverse engineering.

Pontiac is gone. But surely, GM holds the copyright on all things Pontiac. So I’m not sure if there are legal implications by disclosing a secret code that a company invented and apparently wanted to protect. And I definitely don’t want to face a penalty or whatever by revealing company secrets to the public.

Or am I worrying too much? What do you guys think? Any advice?

Cehbra

iTrader: (1)

No one interested in this topic?

In that case I'll just carry on with my digital dash project, I guess. Gonna post the progress in my build thread.

OrangeBird

iTrader: (1)

I think it's very nice and resourceful & all , , , But , ,I don't have a digital dash .

So all I can say is ..... Good Job !

John in RI

iTrader: (167)

I wonder if the same algorithm was used for the Berlinetta cluster ? The Berlinetta odometer chip is very similar - but a bit smaller - than the Firebird Digital Dash Chip.

Pretty cool trick !!!

Cehbra

iTrader: (1)

Thanks guys!



I didn't want to brag about it, I just hoped for an opinion about posting the algorithm here. Anyone think that would be a good idea? Or will I get busted?

Cehbra

iTrader: (1)

Do you know what chip was used? If it's an NCR52801 I could give it a shot if someone sent me one for testing...

thtanner

iTrader: (1)

Im interested in all digital dash modifications. Nicely done.

OrangeBird

iTrader: (1)

My Friend , as far as stepping on any "Intellectual Property" rights , since you aren't selling anything , and such matters as copyright and patent involve you not being able to make money from what they own without their permission (In other words , them getting a percentage of the sales for the use of their property) , I can't see how they could sue you for "financial damages" since there would be none . Were this a modern and relevant technology I could see the worry about tampering with the security of the numbers , but how many of these cars are still out there with a digital dash and happen to be in the ownership of someone smart enough to know how to do this in the first place ? It's not like there would be thousands of super low mileage digital dash third gens suddenly popping up to cause anyone to take notice . Lastly , since each and every parameter of the ECM's data stream has been thoroughly picked apart , modified , and published , with no legal penalties even though such tampering if done wrong could affect the all important emissions stuff , I'd bet no stormtroopers bust your door in the minute you post it .

But if per chance they do , be sure to post a selfie with them , so we all know where ya went

Theratt1

I don't see any issues legally arising for you if you do release it since it's pretty archaic technology. I mean modern dash clusters are literally a computer and as far as I'm aware some of that stuff has been released. But I'm no lawyer. Seeing as basically everything else has been picked apart and modified on these old proms I don't see an issue except some idiot in his/her garage illegally modifying cluster so people can sell "low miles" t/as and all that.

Cehbra

iTrader: (1)

fair enough!

You got me reassured on that. Especially since stormtroopers are known to always miss their targets

Cehbra

iTrader: (1)

It's going to be a heck of a long post, but I'll get to the point some time in the future

Cehbra

iTrader: (1)

Let me start the write-up by introducing my preparation work.

Ford made a digital dash cluster in the 80’s and I found two patents (4803646 and 4710888) on their technology, which reveal interesting insights into the engineer’s way of thinking. I assumed that Pontiac went in the same direction, as technology of that time didn’t allow for so many other ways of doing it - although I could not obtain information on the GM/Pontiac method.

Cehbra

iTrader: (1)

In a nutshell, what Ford proposed is as follows:

• Save the odometer data to a non volatile memory device, in their case an NC7033 336 bit (21x16) word alterable, MNMOS EAROM
• Bit cell locations of fixed size and position are arranged in a repeatable sequential loop to increase storage time
• Distance values are written to the memory in 32 bit chunks = 2 DWORDS
• Parity is 2x3 bits of the 32 bits
• Distance increments are written to the memory at periodic accumulations of 10 miles and also when the vehicle ignition is switched from on to off
• When the vehicle is turned on, all the storage locations are read in a loop. Each read value is assessed whether it has correct parity information. At least two values must have correct parity AND must have a difference of less than 25 miles. The highest of all the values with correct parity is copied to the RAM and is the basis for further incrementing and displaying.
• Values with incorrect parity are ignored. If all the values have incorrect parity, an error message is displayed
• Writing a new increment is done in a loop, too, so as to overwrite the oldest value.

Again, this is the Ford patent. As it turns out, there are some important differences in the Pontiac method, but basically a lot of the above is true for the GTA digital dash as well.

Cehbra

iTrader: (1)

As I don’t have a digital dash in my car (yet) I needed a bench testing setup. I bought a naked 87 digital dash odometer board with an intact LCD off ebay. The seller claimed it was defective - but as it turns out it’s actually working.

When looking at the board from above, with the connector to the right, here is the pinout:

H: to F from speedometer, +12 V, hot in run
G: pin 15 (from big digidash conn), to H from speedometer, VSS input LT GRN/BLK wire
F: pin 16, +12 V, hot in run
E: pin 19, display dim input, did not use this one
D: not used
C: pin 21, +12 V, hot at all times
B: not used
A: pin 24, GND, to fuse G118

So to get this little computer working all I had to do is connect 12 V to C, F and H and connect GND to A.
To simulate driving a valid VSS signal would need to go to G. That’s all.

Cehbra

iTrader: (1)

Kids need to go to bed, I'll post more later...

Cehbra

iTrader: (1)

Cehbra

iTrader: (1)

There are two chips on that board:

• HD44790: Hitachi 4-Bit CMOS automotive microcomputer chip with ROM, RAM, LCD driver and a lot more
• NCR52801: EEPROM 256 Bit (16x16)

As I insinuated, the odometer board itself is a fully working car computer, not just a dumb extension board. Obviously the NCR52801 is what we are looking for, as an EEPROM was the only suitable way to permanently store this kind of data in the 1980s. I have attached the datasheet.

Cehbra

iTrader: (1)

With some research I learned that the 52801 was manufactured by NCR (National Cash Register). This company was located in Dayton, OH, and was a major player in the early days of computers participating in encryption technology, and even earlier with its mechanical cash register machines. It since has gone through multiple changes, and from what I can tell, the memory group became Symbios, which eventually was purchased by Hyundai and likely disbanded.

There are a few sites that still sell new old stock 52801 chips, but usually there is a minimal order amount of 250 $. Prices for a single chip vary between 50 to over 100 $. So there is a considerable investment for just a handful of NOS NCR52801 chips. Of course I would need at least one additional chip to start working, as I didn’t want to break the original in case something went haywire…

Hacking is not a low-cost business apparently.

Cehbra

iTrader: (1)

Here are a few things I found - and a few assumptions I made on that circuit: I believe it is actually an improved version of the MCM2801 by Motorola. That 16x16 Bit EEPROM used a power supply of 5 V for reading and needed a whopping 25 V for programming/erasing. I guess that great voltage demand was the reason for NCR to create a 2801 clone, which got an integrated high voltage generator. So it used only 5 V for programming. Not surprisingly NCR called it 5-2801...

Still there is a major problem: until recently there were simply no EEPROM readers/programmers out there that were compatible with that stone age old chip. But there is a one man company - dasarodesigns.com - which makes a programmer for the MCM2801. So I called Matt and we exchanged E-Mails and I sent him a chip for testing purposes. Finally he got it tested and it’s working! So now there officially is a device that can read and write NCR52801 EEPROMs.

If someone wants to program an NCR52801, go get a 2801Prog from his website.

Cehbra

iTrader: (1)

The NCR52801 has a fully TTL compatible serial I/O. TS (non volatile data storage time) is considered 10 years. It has an unlimited read cycle number and 10'000 erase/write cycles per cell.

What does that mean? When a certain age and number of writes is reached, the memory will begin wearing out, no longer retaining the stored values. According to the datasheet, increasing the number of erase/write cycles beyond 10'000 will degrade TS logarithmically.
Because of concerns of the limited TS for a vehicle application, Ford had engineering try to make the odometer as robust as possible. This is done by not continually writing the data to the same location, but rather rotate among several locations.
As I found, Pontiac actually did exactly the same.

Cehbra

iTrader: (1)

Let’s consider some math: If Pontiac did something similar as Ford then they would use the 256 bits in chunks of 8 double words with 32 bits each. Let’s call that a storage location. So a storage location will be written to sequentially every 8th cycle, thus increasing the life of the chip to 80'000 write cycles. If we assume that the computer will write the odometer value to the chip every 10 miles that would mean a total of 800’0000 miles a car can be driven before the odometer will likely wear out.
However, as Ford intended, with each power down of the engine, the data is stored as well. If the vehicle is used daily, 10 rides a week is not uncommon, resulting in 20 power downs each week and about 1000 per year. So in the 30 years since 1986 we could well have lost 3 of 8 storage locations. If the car has been driven 200'000 miles we would have used up a total 5 of 8 and there would be left only 3 of 8 storage locations. That means, we might begin to see more and more digital dash odometers fail in the next few years simply due to the fact, that the EEPROM reaches the max. number of write cycles.

That’s not even considering that we are dealing with a 30 year old chip here!

Cehbra

iTrader: (1)

Well it is not so dramatic in the end…

Here is a little secret I found early in the process: Pontiac apparently doesn’t do the same thing as Ford did concerning writing to the EEPROM. When “driving” resp. adding miles to the odometer – and if I switch off the unit afterwards the way I believe it was intended (cut power to F and H, but keep C hot), the miles are preserved on the display - but not written to the EEPROM! The only write action I could observe was an automatic write every 10.0 miles.

But things get even more interesting: when I not only switched off the power from “hot in run” but completely disconnected the power, the odometer reading fell back to the last 5.0 miles if the last digit’s reading was 9.9 or below and it went up to the next 5.0 miles, if the last digits read 1.0 or more. Example: fictive odometer reading 428.3 miles. Now I remove the power and reconnect. The odometer now reads 425.0 miles. If I “drive” until it reads 430.1 miles, after power loss the odometer reads 435.0 miles.

This is an elegant way of preserving the EEPROM by only writing to the chip every 10 miles, with the disadvantage of less accuracy in case of power loss. This also explains that orange wire, which is not present in the analog cluster. That wire goes to the digital dash on connector C2 / pin 21 and is hot at all times. In the 88 Firebird service manual it is labeled “memory input”. The odometer CPU (HD44790) needs constant power to hold the precise value in its volatile RAM. So only a coarse mileage is stored in the EEPROM as a backup in case of power failure.

Cehbra

iTrader: (1)

So if anyone with a working digital dash in the car wants to verify if I’m right, here’s my suggestion on how to test:

• Switch to miles (not km)
• Write down the odometer reading of your car (if the last digits read 5.0 then you should drive a mile or two first)
• Engine be shut down, now disconnect the battery for a few seconds and reconnect
• Check the odometer reading. It should be different, with the last digits being 5.0

Am I correct?

Cehbra

iTrader: (1)

So for all you hackers out there: here comes your challenge.

Remember the first picture above? The EEPROM I got with the odometer board read 164365.0 miles. And this is the memory dump from that chip:

BAF0986FCAF0D053CAF03837CAF0802BAAF048CFBAF080B3BAF0E897BAF0308B

The NCR52801 is organized as 16x16 bit words. Matt’s programmer uses big-endian format, so when data is read from the device the most significant byte in each word comes first.

Any takers?

More to follow in the coming days...

muswp1

That's very interesting. Fortunately with my IT background I understood what you were saying. It's interesting to see how Ford and GM were thinking in terms of programming the chips.

OrangeBird

iTrader: (1)

Being a Vacuum Tube technologist I haven't the vaguest clue of what he's talking about , but I'm damn proud of him for having done it ! Such a mission takes both brains and determination , and it's nice to see what a smart & determined person can come up with when they set their mind to it .

Here's some of the tech I'm most familiar with ....

Chet

This is great info, I've always been curious about how the DigiDash works.

Theratt1

That's pretty interesting how they set that up. Only write cycles every 10 miles and rotates writing addresses to improve life of storage. I'm no software engineer or hardware engineer but I know how to get in trouble with this kind of stuff. Definitely will look forward to more of this.

Cehbra

iTrader: (1)

Thanks a lot! Makes me feel a lot better! Cool technology, by the way. I always wondered about those tubes, but never got to understand them.

And thanks for all the other comments, guys!

Cehbra

iTrader: (1)

OK, next part

There are 4 requirements PMD engineers had to consider in the design process of the odometer storage system.

1. Storage: keep the mileage number (obviously)
2. Data integrity: some kind of error detection to evaulate whether the stored number is authentic. Nothing's more annoying than an odometer that suddenly shows a totally screwed up reading
3. Protection: safety measurements against hacking (especially TGO members). We don't want to make it too easy to manipulate the numbers, do we?
4. Chip specific protocol: as already mentioned, the NCR 52801 has some write cycle limits, so in this case an intelligent and economical write algorithm makes sense

Cehbra

iTrader: (1)

Now when we look at the hex readout, there seems to be some kind of pattern:

BAF0986FCAF0D053CAF03837CAF0802BAAF048CFBAF080B3BAF0E897BAF0308B

BAF or CAF seem to repeat in regular cycles. We can break the line after every eighth digit, so it will show something like this:

BAF0986F
CAF0D053
CAF03837
CAF0802B
AAF048CF
BAF080B3
BAF0E897
BAF0308B

Not much fantasy involved to see that apparently there are 8 storage locations, meaning 256/8 = 32 bits (2 DWORDS) per storage location. Each storage location probably holds one mileage plus its data integrity information. As there are 8 similar values we can safely assume from the already acquired knowledge, that they are each 10 miles apart.

Cehbra

iTrader: (1)

So the highest of these 8 values would represent 164365 miles. Unfortunately we cannot tell which one is the highest, as the values surely are scrambled and are not accessible to simple sorting. So how to reveal which number corresponds to which distance?

Simple. We need to drive a few miles and observe the change in the memory dump. But how do we drive without a digital dash car? I chose to build a VSS simulator which gives square waves like the original VSS buffer. I found an interesting site on the web: www.lukeskaff.com. As far as I found out Luke is or was a TGO member himself and owns a thirdgen Camaro. So the VSS simulator is all copyright by Luke Skaff. I built it to his plans.

Cehbra

iTrader: (1)

Now I got the bench test setup complete and I could start “driving”.



I wrote a little software for analyzing the memory dump every 10 miles and make a diff. Not going into details. Here are some distance values:

164425: EAF07192
164435: EAF0CA76
164445: EAF0126A
164455: EAF07A4E
164465: FAF0C132

From the Ford patent I furthermore assumed, that we need two correct values with a difference of 10.0 miles for the odometer to accept it as valid.

I did a quick test and programmed a chip with this reading:

EAF07192EAF0CA76000000000000000000000000000000000000000000000000

Guess what? It correctly showed 164435 miles. Further testing reassured me that indeed two correct values with a difference of 10.0 miles is sufficient for a correct readout. It is also the minimal requirement.

So we got requirement #4 out of the way. Still 3 to go.

Cehbra

iTrader: (1)

By the way: When there is wrong information in the chip, the error message displayed is a flashing 999999.9.

Also according to the service manual, this error indicates a faulty chip hardware or software. So by using a newly programmed chip we should be able to repair such an odometer.

Cehbra

iTrader: (1)

Now that we got that straight let’s move to analyzing the miles:

164425: EAF07192 => 1110 1010 1111 0000 0111 0001 1001 0010
164435: EAF0CA76 => 1110 1010 1111 0000 1100 1010 0111 0110
164445: EAF0126A => 1110 1010 1111 0000 0001 0010 0110 1010
164455: EAF07A4E => 1110 1010 1111 0000 0111 1010 0100 1110
164465: FAF0C132 => 1111 1010 1111 0000 1100 0001 0011 0010

These are the numbers converted to binary, the way they are actually stored in the chip. For sake of simplicity let’s call a 4 bit chunk a “nibble”.

Cehbra

iTrader: (1)

Whatever method I tried converting the mileage - say for example 164425 – to binary did not yield any bit pattern that could be matched to a pattern above. Meaning: the mile reading must somehow be encrypted before converting to binary. I’m not going into the details on the stats I did. Here is what I believe the engineers did – at least that worked for me:

• Subtract 5 => 164420
• Multiply by 100 => 16442000
• Convert to binary (32 bit) => 00000000111110101110001010010000
• Group the number into nibbles => 0000 0000 1111 1010 1110 0010 1001 0000
• Scramble as follows (to match colors) =>

"calculated" row: 8 nibbles as calculated with the formula above
"reading" row: 8 nibbles as actually read from the chip, see post 39, row with 164425 miles

Cehbra

iTrader: (1)

As you can see, there are some things not completely under control (yet):

• Nibble 0 that we calculated is not used and can be discarded.
• Nibble 7 that we calculated seems not to be used, either (hmmm…).
• Nibbles 4 and 5 from the readout have no counterpart in the calculated row.

So what about nibbles 4 and 5? Well, what else than data integrity checking can they be? So this must be that ominous parity information.

Interestingly, nibble 7 will not stay 0000. It will be 1000 in the next storage location: check out 164435 => 164430 => 16443000 => 0000 0000 1111 1010 1110 0110 0111 1000 (see that last nibble?). If you discard nibble 7 and convert back you will not end up with 164435 but with 164434.92.

If we continue down the line nibble 7 will be 0000 with the next higher mile reading of 164445 again, i.e. nibble 7 is alternating between 0000 and 1000 with every write cycle

So what about that one nibble? Is it stored somewhere else? Or are we wrong after all?

Requirement #1 and #3 on their way. #2 still untackled.


While I let you twist your mind, I’ll go get some sleep… I hope you have some fun reading!

Cehbra

iTrader: (1)

OK, last part.

Let’s first address that calculated nibble 7, so we can get requirement #1 checked. Where is it hiding???

From now on I will call it nibble X, as we will be dealing with the second row from the table above, and there nibble X doesn’t have a place - yet. There are two positions really where Pontiac engineers could hide another number, and that is nibble 4 and 5 only. Would they really mix parity bits with part of the stored value itself?

Cehbra

iTrader: (1)

Let’s have a closer look at nib4, 5 and X: (x-axis shows miles 164425 to 164675)



nibX (red line) alternates between 0 and 8 (0000 and 1000) as we already know. But clearly there is a consistently parallel jump in nib5 (purple line), whereas nib4 (green line) shows a different pattern.

So do we have that sucker or what? As it seems, those badass PMD engineers crammed one part of the mileage (nibble X) into half of the parity bits (nibble 5), by XOR. Savage!!!

Some more testing confirmed that to be correct. So we get requirement #1 checked. And thereby we know how all the nibbles are scrambled and thus we get requirement #3 checked as well.

Cehbra

iTrader: (1)

Now only #2 remains. How is data integrity calculated?

First I needed to clean nibble 5 from nibble X. After I did that, I ran a few brute force attacks over each nibble, in all different combinations possible, either with a MODULO or a parity (XOR) test, with no luck at all. Turns out, it’s all done quite differently.

I won’t go too much into detail, here is the end result, on how the error detection nibbles are calculated:

1. Cross add all the mileage nibbles (pos 0, 1, 2, 3, 6, 7 and X) to form the first checksum (cs1)
2. divide that first checksum by 5
3. here’s the translation table to calculate the second checksum (cs2) from the first:

The second checksum (cs2) equals the cross total from nibble 4 and 5 (nibble 5 cleaned from nibble X that is).

Cehbra

iTrader: (1)

Last problem: How do we get nibble 4 and nibble 5 if we only have the sum of the two? I simply couldn’t find an answer. Until I gave up and decided to try the simplest of all approaches: random. Guess what, any combination works,

So if cs2 is - let’s say - 12, nib4 and nib5 can be 11+1, 10+2, 9+3 or whatever… I confirmed that when I started over and “drove” from scratch. Indeed I got slightly different readings. Gee, Pontiac! I imagine how them PMD engineers laughed their a**es off when they designed the algorithm. They surely knew how to fool people…

As a last note, I only confirmed this to be true if nibble 5 is either 1, 2, 3 or 4, I haven’t checked other numbers. I could imagine it to work with 5, 6 or more as well.

So to calculate nibble 4 we would randomly define nibble 5 to be something between 1 and 4, then take cs2 and subtract nibble 5. The result is nibble 4. If nibble 4 is negative, just add 16 and there you go. Of course, you should not forget to XOR nibble X into nibble 5 as the last step.

Requirement #2: checked.

Cehbra

iTrader: (1)

So here is the summary:

To encode a mileage do as described above. That should leave you with a 32 bit number, thus 8 Hex digits per mileage. Construct a second one, which is 10 miles less. Concatenate (smaller first). Fill the remaining 6 locations with 8 zeroes each, or even better, six times with the larger mileage.

So to code 80815 miles, using the above algorithm, you would calculate for example: 4B706A6E. Then calculate a number that is 10 miles less, for example: 4B70118A

Now set them behind each other, preferably the smaller one in the first place:

4B70118A4B706A6E000000000000000000000000000000000000000000000000

or even better:

4B70118A4B706A6E4B706A6E4B706A6E4B706A6E4B706A6E4B706A6E4B706A6E

Run that 256 bit number through the programmer onto an NCR52801 and you’re good to go.

Cehbra

iTrader: (1)

This is still work in progress. For example I haven’t figured out how to set the odometer to read 0.0 miles, as I wasn’t so much interested in that mileage reading – there is no T/A with 0 miles anyway.

Very low readings don’t give a 5 as the last digit, but a 0, don’t know why, yet. So 10 miles is the lowest for the moment. There may be more quirks, but for the moment it basically works.

Phew, long post. Thanks for hanging on. I hope you enjoyed it.

Time to comment or complain or ask questions.

Cehbra

iTrader: (1)

Well, that’s it! Now I’ll be moving on to getting the digital dash and some other interior stuff ready to go in the car! Excited, holidays may come!!!

One more thing: I had bought myself a handful of NOS NCR52801 chips for testing purposes, that I don’t need anymore. So if someone is interested I will gladly get rid of them one by one. To (barely) cover my expenses US$ 60 per programmed chip incl. shipping and handling should be a fair price. If someone has a chip and needs it programmed you can send it in as well. If interested, shoot me a pm.

Theratt1

That's sort of an odd way to encrypt. But back in the 80s things were different. It had to be simple and work. Thank you sir for sharing this odd and interesting information.

Cehbra

iTrader: (1)

You're welcome!

I think Pontiac engineers did a great job! Given the limited possibilities of that time they invented a challenging encryption while maintaining a robust and enduring way of storing distance over a long period. Compared to other car makers it's quite an elegant solution.