TH2830 vs TH2832

[nctnico]

What do you think about simply overwriting the contents of the chips with the ones from a 2832 ?

I think the device ID is in the external FRAM. I think the firmware consists of 3 parts: the LPC1788 firmware, some kind of look-up table that goes into the flash and the FPGA image.
In other words: you will not be overwriting the device ID with overwriting the contents of the chips. I'm quite sure the firmware update process already takes care of that. We need to call in forum member tv84 to take a look.

[tv84]

We need to call in forum member tv84 to take a look.

He has... 

What is that makes these devices so special?

Just loading with a totally random address, we can see plenty of code (ARM little endian). Don't know what you're trying to accomplish but Nico's inference to read the FRAM (if it has one) seems the best way.

Edit: Added a picture (code graph) that show the different models involved... looks like there are lots of them.

[KungFuJosh]

It looks like the firmware image has 3 chunks and these are seperated by a header containing a text string 'B9FZI'

That only appears in the 2830 firmware. Did you find something similar in the 2832?

[KungFuJosh]

We need to call in forum member tv84 to take a look.

He has... 

What is that makes these devices so special?

Just loading with a totally random address, we can see plenty of code (ARM little endian). Don't know what you're trying to accomplish but Nico's inference to read the FRAM (if it has one) seems the best way.

Edit: Added a picture (code graph) that show the different models involved... looks like there are lots of them.

😇

I dunno, they're well made I guess? 😉

The goal is to get the features being blocked by the firmware; primarily an increase in frequency range, and a DC bias voltage function.

It is funny how many models are mentioned. Even in the plain text many are listed:
TH2830N TH2832X ST2832X TH2830L TH2832  ST2832  SM6024  eWK6302BQ   TH7832  9216B   JDI1022 TH7832A AMM3046 LCR2200 LN2020  TH2831  ST2831  M2831B  XTD4510 DHK6200 TX6200  AMM3044 TH2830  ST2830  SM6023  DHK6100 JCX860  TX6100  TH7830  TH2816D OCT1010 TH2830HY LCR2100


The TECPEL LCR-2100 looks like another 2830 clone, currently $700 on Amazon.

[nctnico]

It looks like the firmware image has 3 chunks and these are seperated by a header containing a text string 'B9FZI'

That only appears in the 2830 firmware. Did you find something similar in the 2832?

I see it in all firmware files... I = letter I, not number!

BTW: I see the LPC1788 also has an internal EEPROM that may also hold information about the model.

[KungFuJosh]

It looks like the firmware image has 3 chunks and these are seperated by a header containing a text string 'B9FZI'

That only appears in the 2830 firmware. Did you find something similar in the 2832?

I see it in all firmware files... I = letter I, not number!

BTW: I see the LPC1788 also has an internal EEPROM that may also hold information about the model.

Oops, my bad. WinMerge is goofy on the search function sometimes (even thought it was really a PEBKAC error). 😉

[nctnico]

We need to call in forum member tv84 to take a look.

He has... 

What is that makes these devices so special?

These are nice LCR meters for a reasonable price.

Judging from your call-graph, it seems there is a value stored somewhere that says which model it is and after that some kind of text comparison is made. It would be nice to figure out where this is stored and maybe how the model type is set.

[Martin72]

Silly question,
Which program is used to generate this information from the previously posted hex file ?
I would also like to have a look at it.

[coromonadalix]

Ida dissasembler  or  ghidra ...

some free, some cost a fortune  loll

https://mohamad-wael.medium.com/best-microsoft-windows-disassemblers-and-decompilers-6fdfbf9990de

[KungFuJosh]

Judging from your call-graph, it seems there is a value stored somewhere that says which model it is and after that some kind of text comparison is made.

That seems likely, but it's interesting that there's nothing that blocks use of the same level firmware from different branding. My TH2830 is currently running the ST2830 firmware. It appears they only care about the 2830 part.

[nctnico]

It looks like the model information is a model ID number (which may be used at other locations in the firmware as well to determine the abilities of the hardware) AND a text with the model number. Your experiment to load different firmware likely failed due to the model ID number being wrong.

[KungFuJosh]

It looks like the model information is a model ID number (which may be used at other locations in the firmware as well to determine the abilities of the hardware) AND a text with the model number. Your experiment to load different firmware likely failed due to the model ID number being wrong.

If we can figure out what the reference model ID numbers are for both devices, maybe we can modify the firmware to allow the 2832 fw on the 2830?

[tv84]

It looks like the model information is a model ID number (which may be used at other locations in the firmware as well to determine the abilities of the hardware) AND a text with the model number. Your experiment to load different firmware likely failed due to the model ID number being wrong.

You may be correct although from what I conclude from the "call-graph" it seems the decision flag is the model name. But, to be honest, I didn't think much about it.

And, it seems that there are plenty of model names that end up in the same few "real" models.

If the thing has a FRAM, please dump the FRAM.

[nctnico]

It looks like the model information is a model ID number (which may be used at other locations in the firmware as well to determine the abilities of the hardware) AND a text with the model number. Your experiment to load different firmware likely failed due to the model ID number being wrong.

You may be correct although from what I conclude from the "call-graph" it seems the decision flag is the model name. But, to be honest, I didn't think much about it.

Not really. The 2nd check is just for the right model name. At the top of the graph the decision goes into 3 columns for the 3 different base models (2830, 2831 and 2832). After that decision, there is a text comparison as a 2nd check.

[tv84]

After that decision, there is a text comparison as a 2nd check.

You're right. So, it's something like this:

Model_byte (in hex):
Ax - TH2830 / ST2830 / SM6023 / DHK6100 / JCX860 / TX6100 / TH7830 / TH2816D / OCT1010 / TH2830HY
Bx - TH2831 / ST2831 / M2831B / XTD4510 / DHK6200 / TX6200 / AMM3044
Cx - TH2832 / ST2832 / SM6024 / eWK6302BQ / TH7832 / 9216B / JDI1022 / TH7832A / AMM3046
Dx - TH2830L
Ex - TH2832X / ST2832X
Fx - TH2830N

If these combinations don't match, the FW will show "Wrong Firmware!" msg.

So now you can do some FRAM/EEPROM analysis...

[KungFuJosh]

After that decision, there is a text comparison as a 2nd check.

You're right. So, it's something like this:

Model_byte (in hex):
Ax - TH2830 / ST2830 / SM6023 / DHK6100 / JCX860 / TX6100 / TH7830 / TH2816D / OCT1010 / TH2830HY
Bx - TH2831 / ST2831 / M2831B / XTD4510 / DHK6200 / TX6200 / AMM3044
Cx - TH2832 / ST2832 / SM6024 / eWK6302BQ / TH7832 / 9216B / JDI1022 / TH7832A / AMM3046
Dx - TH2830L
Ex - TH2832X / ST2832X
Fx - TH2830N

If these combinations don't match, the FW will show "Wrong Firmware!" msg.

So now you can do some FRAM/EEPROM analysis...

That sounds like it's a simple function in the firmware to halt loading if the combination doesn't match. Is that correct? Can we defeat that in the firmware? For example: firmware says 2832, but right now the model byte says Ax, so it says wrong firmware. Can we change the definition of Ax to match 2832?

[tv84]

That sounds like it's a simple function in the firmware to halt loading if the combination doesn't match. Is that correct? Can we defeat that in the firmware? For example: firmware says 2832, but right now the model byte says Ax, so it says wrong firmware. Can we change the definition of Ax to match 2832?

I can but can you flash it without a programmer? (and hope that it doesn't verify any checksum while running...)

Edit: Attached is the FW with A0 and C0 bytes swapped, as requested. Have no idea if that will work. In logic terms I would say that you should be already running this precise patched version in order to accept a... patched version.

Edit2: The file was wrong! A correct one is in a following msg.

[nctnico]

I'm pretty sure that it will end up as 'Wrong firmware'. You'd need to change the text that is being tested as well. If all the tests for the right model name fail, the graph goes into 'Wrong firmware'.
 
What puzzles me is why the firmware doesn't run on Josh' ST2830 while it is supposed to support that model. This seems to suggest that the model name might be derived from the firmware file that is being loaded. Maybe, just maybe changing the firmware filename to ST2832 already makes the file work as the model ID and model name now match. But I doubt the features of the ST2832 are enabled. I don't see any signs of the model ID being used to set a flag for the functionality in the call graph that TV84 has posted.

[KungFuJosh]

That sounds like it's a simple function in the firmware to halt loading if the combination doesn't match. Is that correct? Can we defeat that in the firmware? For example: firmware says 2832, but right now the model byte says Ax, so it says wrong firmware. Can we change the definition of Ax to match 2832?

I can but can you flash it without a programmer? (and hope that it doesn't verify any checksum while running...)

Edit: Attached is the FW with A0 and C0 bytes swapped, as requested. Have no idea if that will work. In logic terms I would say that you should be already running this precise patched version in order to accept a... patched version.

Unfortunately no, that didn't work. It didn't get past 5%, so it seems it fails some kind of precheck.

Renaming ST2832 to ST2830 will allow it to fully flash the stock firmware, it's when you try to run the meter that it fails after that.

Edit: Attached is two screenshots comparing the beginning of the stock fw files, and the modified one. There's something missing with the modified version.

[KungFuJosh]

I'm pretty sure that it will end up as 'Wrong firmware'. You'd need to change the text that is being tested as well. If all the tests for the right model name fail, the graph goes into 'Wrong firmware'.
 
What puzzles me is why the firmware doesn't run on Josh' ST2830 while it is supposed to support that model. This seems to suggest that the model name might be derived from the firmware file that is being loaded. Maybe, just maybe changing the firmware filename to ST2832 already makes the file work as the model ID and model name now match. But I doubt the features of the ST2832 are enabled. I don't see any signs of the model ID being used to set a flag for the functionality in the call graph that TV84 has posted.

The firmware files aren't the same though. For whatever reason, the 2830 fw file is actually 2k larger than the 2832. I think (am guessing) the fw itself contains what we need for those functions to work. They don't need to flag for individual functions if the fw won't let you get past startup.

My hardware model is the TH2830, currently being run as an ST2830.

[KungFuJosh]

Attached is the FW with A0 and C0 bytes swapped, as requested.

Are those swapped in the hex file, or did you decompile / recompile?

On a quick search A0 (41 30) appears in both hex files exactly 12 times. C0 (43 30) appears in 2830 two times, and in 2832 seven times.

[tv84]

Attached is the FW with A0 and C0 bytes swapped, as requested.

Are those swapped in the hex file, or did you decompile / recompile?

On a quick search A0 (41 30) appears in both hex files exactly 12 times. C0 (43 30) appears in 2830 two times, and in 2832 seven times.

Do a binary comparison between the files and you'll understand what I did. I just swapped the ones involved in that call-graph shown. Just as a proof-of-concept with no deep analysis behind.

[KungFuJosh]

Do a binary comparison between the files and you'll understand what I did. I just swapped the ones involved in that call-graph shown. Just as a proof-of-concept with no deep analysis behind.

I did a binary comparison in a hex editor (WinMerge), and the files are significantly different. Attached is a partial comparison of the patched fw and the stock fw (left side is stock, right side is patched).

Am I supposed to compare them a different way?

[tv84]

Sorry, Josh.   

I messed up big!    That's what results when doing things in a hurry.

This is the correct patched file (with A0 and C0 swapped). Try this one.

Edit: This file had incorrect checksums. See my following messages where I share this file with correct checksums.

[KungFuJosh]

Sorry, Josh.   

I messed up big!    That's what results when doing things in a hurry.

This is the correct patched file (with A0 and C0 swapped). Try this one.

No worries my friend, I always appreciate your help!

However, are you sure that's the right file? It appears to be identical to the ST2832 stock file? I mapped the location of those references, and they are still the same:

2830 A0 (41 30) Appears:
000010
005ba0
010590
03b570
03b5f0
04e6c0
0525a0
0579c0
0ecd20
187850
1a3640
1bdba0

2830 C0 (43 30) Appears:
082170
19b270

2832 A0 (41 30) Appears:
000010
0058e0
00fb00
03af50
03afc0
04dc00
056b80
0779f0
0ec4f0
187030
1a2e10
1bd370

2832 C0 (43 30) Appears:
003fc0
0058f0
0075c0
007700
081940
175c70
19aa40

Edit: okay, something is different, the update failed instead of finishing and saying wrong firmware. The A0s were all the same, I'll check the C0s. Edit again: C0 also at the same lines. I didn't see anything different otherwise, so I don't know why it failed. 🤷