Hacking the Agilent 4263B LCR Meter!

[free_electron]

correct.

i can tell you exactly what fields need modifying in the eeprom. i got it written down. just need ot find the damn notebook.

[Hugoneus]

correct.
i can tell you exactly what fields need modifying in the eeprom. i got it written down. just need ot find the damn notebook.

That would be even better!

[vaualbus]

So but for the hack you need to send some gpib command or just to repropgram the nvram?
There have to be a way to enable the option using either the gpib or some internal debug port. Of course than we should know the commands to do that.

[TiN]

attached the rom and eeprom images
fw 1.02 and 1.06 are in there as well as eeprom images of a machine without options, one with option 001 and one with both 001 and 002.
you figure it out
i also uploaded an eeprom image for a 4263A with option oo1

Thank you a lot. 

I played a little with WinHEX, made a template for easier modification, based on mine EEPROM dump and free_electron's

4263B, no option:



another one, no option (this one is corrupted, just a header in there, which is enough):



4263B, option 001:



4263B, option 001 + option 002:



4263A, option 001.



A have some extra data, lookling like presets or profiles, as it's repetitive pieces of data with own checksums.

And WinHEX template files:

TPL-file for 4263A and for 4263B.
Works fine with registered WinHEX 15.6

* Seem like something important stored in 7 bytes at offset 0x23. This block always there with optioned devices, but blank FF's in stock. Maybe some serial number to option tie?
* And second byte on block at offset 0x1F00 is 0x11 on optioned devices, but 0x12 on stock.

Rest seem to be irrelevant.

Also added Firmware changelog history, easily googlable from Agilent.

[TiN]

 

Now erasing firmware ROM, to programm 1.06

Thanks Vincent!

EDIT: Firmware updated to 1.06, all works fine.



I'll post details tomorrow, as it's already 1:12am here.

[amiq]

i have both A and B machines. my A has a dead adc. i have the Asahi-Kasei chip , just need to find time installing the damn thing.

I'll be interested to hear if that fixes your unit.  I acquired a supposedly working A unit which displayed the ADC Error message.  I swapped out the ADC but that didn't fix it.  I've still to get this unit working, but it looks like a fault in the CPU/ADC interface rather than the ADC.   

[vaualbus]

Hey have you successfully enabled the options?

[merox]

What kind of program was stored on that floppy? Was it coded in HP Basic? I'd love to have a look at the program, even if it is SECUREd...

[free_electron]

What kind of program was stored on that floppy? Was it coded in HP Basic? I'd love to have a look at the program, even if it is SECUREd...

no it's a compiled binary for hp-ux. it asks serial number of the machine and the key provided by agilent. it then does something and sends a packet over gpib. the machine verifies the packet and if matched it sets the appropriate flag in eeprom

so part of the lock is in the program , part in the machine. the 'key' is serial number + a unique magic number related to the serial number. agilent knows the formula to generate a matching magic number for your serial.

the program ran only on 9000/300 series computers.

[merox]

no it's a compiled binary for hp-ux

Damn, i guess simple (SECUREd) HP Basic would have been just too easy.

[Hugoneus]

no it's a compiled binary for hp-ux

Damn, i guess simple (SECUREd) HP Basic would have been just too easy.

I just gave up on my serial number and copied the important section over to the EEPROM. That did the trick. Thank for everyone's contribution. I kept the original EEPROM data so I can revert back.

[engiadina]

I recently scored a 4263B labeled Agilent with no Options.

When looking into the EEPROM contents I found some difference to the shown contents here. This data block named "unknown block 1" seems to be some sort of key, as it is blank (containig FF) in those devices having no options activated. All other instruments have some date in there.

My EEPROM actually had some data in that space but no options installed. So I just edited the ASCII-Strings from 000 to 001 and 002 and tested again ... voila. Option 001 and 002 are activated. Maybe the more recent models had some universal keys set there.

I am posting the contents of my EEPROM here, maybe someone can test if that key activates the options without sacrifying the serial number.

[pag]

correct.

i can tell you exactly what fields need modifying in the eeprom. i got it written down. just need ot find the damn notebook.

I picked up an A model missing option 1.  The serial number is not far from the example A EEPROM dump and I made up an EEPROM with the example's serial number, the 7 special bytes, and checked the 11/12 near the end (mine was already 11).

Unfortunately this hasn't had any effect and still no option 1.

Did I miss something?

Peter

[nfmax]

Recently I picked up a late-model (Agilent branded) 4263B in immaculate condition, but with no options. This unit had the EEPROM byte at 0x1f01 already set to 0x11, but the bytes between 0x0021 and 0x0029 were all 0x00. I found I could enable option 002 by setting the byte at 0x002c to 0x32 ('2'). However, setting the byte at 0x0020 to 0x31 ('1') did not enable option 001 (though it didn't give any errors). Both these bytes were originally 0x00.

I can now select 20kHz test frequency, but the unit is out of calibration at that frequency (spot on on all the others, as far as I can tell). The date in the EEPROM is 15th July 2005; the date of last calibration was 4th February 2011.

[Miek]

I did a bit of reverse engineering on the un-swapped firmware posted above and found out what the Unknown Block 1 is for the 4263B.
It is a sort of key/hash based on the serial number, it actually starts at 0x22, and if it's not set correctly then the instrument won't recognise option 001 being enabled.

Here's the function doing the checking:


and here's a python implementation of the "hash" function:

Code: [Select]

$ cat 4263b_hash.py
#!/usr/bin/env python
import sys

if len(sys.argv) < 2:
print(f"Usage: {sys.argv[0]} <serial_number>")
sys.exit(1)

sn = bytes(sys.argv[1], "ascii")
yhp = b"YHP Kobe-Instrument-Division HP4263A.   "

result = [0] * 8

for i, c in enumerate(sn):
u1 = (c * i) % 0x28
for j in range(len(result)):
u2 = (u1 % 0x28)
result[j] += yhp[u2]
u1 += 1

result = " ".join(hex((x % 0x5f) + 0x20) for x in result)
print(f"Hash: {result}")

$ ./4362b_hash.py MY40103309
Hash: 0x6f 0x42 0x29 0x74 0x5f 0x3f 0x6a 0x4c

$ ./4362b_hash.py MY40102817
Hash: 0x4c 0x52 0x24 0x37 0x24 0x40 0x61 0x62


[tv84]

Miek,

Nice work! 

What about the GPIB command syntax, for those devices that don't have the key already in, did you find anything?

[Miek]

Miek,

Nice work! 

What about the GPIB command syntax, for those devices that don't have the key already in, did you find anything?

Thanks!

Unfortunately, I couldn't see any dedicated command like there was in the E4916A.

However, there are some commands to peek/poke at memory directly. Under "TEST:MEMory" there's "ADDRess", "LONG", "REAL", "REGister", and "WORD".
"TEST:MEM:ADDR" seems to set the address for a subsequent long/real/word read or write, and the address auto-increments after the read/write. REGister seems to be some special case that I'm not sure about yet.

The EEPROM space is mapped starting at 0x1e0000, but the low bit is unused so you have to shift any real EEPROM address left by one. So, the hash block appears at 0x1e0044 for example (not 0x1e0022).
In theory, running the following would read out the hash block (I don't think the scpi parser takes hex):

Code: [Select]

:TEST:MEM:ADDR 1966148
:TEST:MEM:LONG?
:TEST:MEM:LONG?
If there's someone who's up for experimenting a bit and is set up to backup/restore their unit, we could probably figure out how to set the options and write the hash all over GPIB.

[gamalot]

Miek,

Nice work! 

What about the GPIB command syntax, for those devices that don't have the key already in, did you find anything?

Thanks!

Unfortunately, I couldn't see any dedicated command like there was in the E4916A.

However, there are some commands to peek/poke at memory directly. Under "TEST:MEMory" there's "ADDRess", "LONG", "REAL", "REGister", and "WORD".
"TEST:MEM:ADDR" seems to set the address for a subsequent long/real/word read or write, and the address auto-increments after the read/write. REGister seems to be some special case that I'm not sure about yet.

The EEPROM space is mapped starting at 0x1e0000, but the low bit is unused so you have to shift any real EEPROM address left by one. So, the hash block appears at 0x1e0044 for example (not 0x1e0022).
In theory, running the following would read out the hash block (I don't think the scpi parser takes hex):

Code: [Select]

:TEST:MEM:ADDR 1966148
:TEST:MEM:LONG?
:TEST:MEM:LONG?
If there's someone who's up for experimenting a bit and is set up to backup/restore their unit, we could probably figure out how to set the options and write the hash all over GPIB.

it's me again! 

Unfortunately I don't have a 4263A/B, but I have a 4338B. I can confirm that the SCPI commands you found can indeed read the contents of the EEPROM, and the results they return are the same as what I read with the programmer.

My 4338B thread/

[nfmax]

I have a 4263B, s/n MY40103486  . As I related above, I was able to activate option 002 by writing the appropriate bytes into the EEPROM, which I removed for the job. I have a full dump I took at the time while the EEPROM was in the programmer, although the instrument has been recalibrated since. So, I proceed with caution...

Using the proposed :TEST:MEM: commands, I am able to dump the EEPROM as described, and the contents mostly match what I see in the dump file, except that the original (factory calibration?) date '15/Jul/2005' at offset 0x12 is now changed to '07/Jan/2019', which is the date on the certificate of calibration I got back from Keysight.

I think I need to write a short script to dump the entire EEPROM, including the calibration data, before going any further. It may be a little while before I can do this, though.

I would expect that if :TEST:MEM:LONG? reads a longword at the current address, :TEST:MEM:LONG 123456 would be the command to write a longword. Is anyone in a position to confirm this?

[gamalot]

I have a 4263B, s/n MY40103486  . As I related above, I was able to activate option 002 by writing the appropriate bytes into the EEPROM, which I removed for the job. I have a full dump I took at the time while the EEPROM was in the programmer, although the instrument has been recalibrated since. So, I proceed with caution...

Using the proposed :TEST:MEM: commands, I am able to dump the EEPROM as described, and the contents mostly match what I see in the dump file, except that the original (factory calibration?) date '15/Jul/2005' at offset 0x12 is now changed to '07/Jan/2019', which is the date on the certificate of calibration I got back from Keysight.

I think I need to write a short script to dump the entire EEPROM, including the calibration data, before going any further. It may be a little while before I can do this, though.

I would expect that if :TEST:MEM:LONG? reads a longword at the current address, :TEST:MEM:LONG 123456 would be the command to write a longword. Is anyone in a position to confirm this?

It's works on my 4338B, both reading and writing.

[nfmax]

SUCCESS!!!

I used @Miek's Python script to generate the hash for my instrument's serial number:

Code: [Select]

(base) byrd:test max$ ./4263B_hash.py MY40103486
Hash: 0x21 0x44 0x56 0x41 0x28 0x56 0x73 0x67
I then programmed 4 longwords, starting at offset 0x020. This is actual address 0x1e0040 because of the last address bit fiddle described. In decimal, this is 1966144.

The three longwords are made up of:

Code: [Select]

0:  0x31   0x00  hash0  hash1
1: hash2  hash3  hash4  hash5
2: hash6  hash7   0x30   0x30

The first byte in word 0 is the ASCII '1' character that enables the option, the second byte is what I originally read from the EEPROM. The last two bytes in word 2 are the leading zeros in the code for option 2, which I enabled back in 2018.

The actual commands I sent, using Interactive IO from the Keysight IO library suite, were:

Code: [Select]

:TEST:MEM:ADDR 1966144
:TEST:MEM:LONG 822092100
:TEST:MEM:LONG 1447110742
:TEST:MEM:LONG 1936142384

I read the same addresses back, using the commands:

Code: [Select]

:TEST:MEM:ADDR 1966144
:TEST:MEM:LONG?
:TEST:MEM:LONG?
:TEST:MEM:LONG?
and verified the contents had changed as expected. I took a deep breath and power-cycled the instrument - and option 001 was there! The extra measurements appear on the menus as expected. Not having a transformer test fixture, I am not able to verify their function yet.

I have a copy of the original installation note for end-user installation of this option. Importantly, this does NOT say that the unit needs to be recalibrated after enabling the option (it does for option 002, though obviously only at the 20kHz setting. In my case, only the lowest capacitance ranges were out of spec before adjustment. Looking elsewhere in the dump file, I can see there are 'new' calibration factors, which look like doubles, in many places. For example, at offset 0x3f0, 0x3f80000000000000 has become 0x3f800019bc0c8cc3.)

I think @Miek qualifies for the hacker's Golden Pizza award for this - well done!

[RolandK]

You don't need the special adapter.

The connection scheme is described in the AN1305-3 Effective Transformer LF Coil Testing 5967-5377. Figure 2 is wrong, L2 should be connected to the low side of Lpot/Lcur, too.

The not so simple procedure is described in the user manual in Chapter 3 at the end. The Adapter shorts Lcur and Lpot, what you should do without it, too.

The only other thing the adapter does is to swap the high side of L1 and L2 with a switch between Hcur and Hpot.

Just checked the function with a 12V transfomer. It calculated to be 16V, which seems plausible, as without load the voltage is higher.


Did anybody get the 20 kHz range calibrated without the hp software?

[metebalci]

Something tiny to add. All the EEPROM images I looked (on the repo linked here etc.), the address 0x30 contains:

Code: [Select]

2E 30 30 00 FF FF FF FF
My 4263B  (no options, 1.06) contains:

Code: [Select]

2E 30 30 00 00 FF FF FF
There is a 00 instead of FF at 0x34. I was thinking maybe I messed up something but then I realized @engiadina 's firmware posted in this thread is the same.

[Hugoneus]

Amazing information. I changed the name of the thread so others can find it easier.

[TERRA Operative]

I just bought one of these instruments, and with a bit of help I added to the code posted above by @Miek to provide an output that can be directly cut and paste into the GPIB comms software as detailed by @nfmax.

I'll try it when my unit arrives and report back.

What would be cool is to use PyVISA to automatically communicate with the instrument, grab the serial number (and back up the existing memory contents), then with a click of the button, generate the unlock values and write them back.
Might be a good excuse for me to finally learn a bit of Python..... 

Code: [Select]


import sys

serial = sys.stdin.readline().strip()

if not serial:
    print(f"Usage: {sys.argv[0]} <serial_number>")
    sys.exit(1)

sn = bytes(serial, "ascii")
yhp = b"YHP Kobe-Instrument-Division HP4263A.   "

result = [0] * 8

for i, c in enumerate(sn):
    u1 = (c * i) % 0x28
    for j in range(len(result)):
        u2 = (u1 % 0x28)
        result[j] += yhp[u2]
        u1 += 1

result = [(x % 0x5f) + 0x20 for x in result]

# Insert fixed values
result.insert(0, 0x31)  # 1st byte
result.insert(1, 0x00)  # 2nd byte
result.append(0x30)  # Last 2 bytes
result.append(0x30)

# Convert each group of 4 bytes to a long unsigned integer
long_integers = [
    (result[0] << 24) + (result[1] << 16) + (result[2] << 8) + result[3],
    (result[4] << 24) + (result[5] << 16) + (result[6] << 8) + result[7],
    (result[8] << 24) + (result[9] << 16) + (result[10] << 8) + result[11],
]

print (':TEST:MEM:ADDR 1966144')

for i, value in enumerate(long_integers):
    print(':TEST:MEM:LONG 'f"{value}")