Writing 3458a Calibration RAM

[martinr33]

It would be nice  to be able to write the 3458a cal RAM. However, the 3458a is designed to make this hard, to protect the calram against things like power failures and brownouts.

This is my preliminary writeup on the protection circuit. Any thoughts invited and welcome!

The safety circuit, once activated, enables RAM write after about 256us. RAM write remains enabled for about 16ms. It cannot be retriggered, you have to go through the delay cycle.
There is a signal CALWE that indicates that the RAM write is enabled.

So the write process is:

 - trigger safety circuit through port write (not sure if there is a port write in HP BASIC, but I don't think so)
 - wait until CALWE goes true (CALWE read or 256us)
 - write to CALRAM until CALWE goes false (after about 16ms)


Possible approaches:
         - see if there is a way to do port writes in 3458a BASIC
         - write some 68k code that can trigger a port write
                - then load from BASIC
                - or do a block write from other memory
                - or create a routine that lets us tweak parameters.


Longer notes:
The meter writes bit 7 high to its SRAM control port. (U800, 74HCT273)This write triggers an 8-bit counter that is clocked at 500kHz. (U135 A+B, 74HCT393)When the top bit sets (after 128 cycles, so 256us) the circuit:       
        - Opens the write gate, which runs for 14 bits = 8192 counts, 16.4ms (U131 74HCT4020)       
        - Sets a bit indicating that the CALRAM will accept writes
When the write gate is enabled, you have about 16 ms to write to the calram (8192/500kHz).

If you jump the middle pin of JM132 (remove the jumper) to pin 10 of U908C, write enable is connected directly to the CALRAM chip and bypasses the memory protection circuitry.  So from there, it should be possible to write a BASIC routine that can write the CALRAM.
This approach might be useful for debug. 



 

[MiDi]

Just some notes - MWRITE is keyword:

There is no way to write back via MWRITE, as the CAL RAM is HW and SW protected.
PHK from the time-nuts claims to have an assembler program which can do, but he did not publish.

IIRC it is neccesary to inject machine code and then execute that to overcome several security functions.
Some insight is given in: Security, Reliability and Backdoors from Sergei Skorobogatov p. 9ff - Analyzing and attacking 3458A

Remember: Bypassing security functions might be a criminal offense (depending on local law) and with the 3458A currently in production, Keysight might initiate law enforcement.

[alm]

Remember: Bypassing security functions might be a criminal offense (depending on local law) and with the 3458A currently in production, Keysight might initiate law enforcement.

Yes, bypassing effective security measures meant to protect against copying could be a criminal offense. Is this considered copy protection? Or bypassing security measures to gain access to some device that you are not authorized to use, so don't go hacking into a 3458A standing in some random lab

As for Keysight pressing charges, that's extremely unlikely, I'd say. Clearly no one cares what you do to your personal 3458A: it does not have remote monitoring. I guess if you publish details it is a very remote possibility, but given that Keysight is not losing any money on this, it's unlikely. How many orders are semiconductor companies going to cancel because some individual posted instructions on bypassing the calibration memory protection on Hackaday, which with the old digital board you can do with any EEPROM programmer? It's also not like these instructions allows you to enable options that would otherwise be paid, like a more stable voltage reference . I haven't heard of any individual being prosecuted for publishing instructions on unlocking options on current Keysight scopes. I'm pretty sure Keysight is aware of this happening, and doesn't care unless you start selling the scopes with unlocked options commercially. The worst I remember is R&S throwing a tantrum about some information about unlocking options on this forum, and asking Dave kindly to remove said information, and him saying no.

[martinr33]

Good points - we need to respect Keysight's IP and product rights in a still-shipping product that has a very long expected life in potentially safety and business critical applications. So even though this is not an information security mechanism but a mechanism to protect cal ram data against power transients and user code errors, we have to be respectful of it.

For example, exploiting an approach that can change the cal ram data inside a sealed unit could render the seals meaningless, and that is a bad thing.

That said, there's a limited legitimate interest in being able to rewrite cal data into a replacement board.  A hardware jumper will work for the earlier baords, and maybe the later ones. Such an approach preserves the integrity of sealed instruments.

[alm]

From a cursory reading, it appears to me that you need to unlock the calibration using the security code (if configured) before you can write to the CALRAM. Is that also the case using this method? Because if so, I don't see any security issue, because using the same code, you can also complete a calibration without breaking the seals. Changing the calibration RAM is not any worse than calibrating it to a source that's 1% off, or doing zero cal with a 0.1 Ohm resistor between all terminals.

What Microsoft blogger Raymond Chen describes as "being on the other side of this airtight hatchway". If you are already past the airtight hatchway, then saying you've found a way to access the space beyond the airtight hatchway is not a security breach. Because you could just have walked over there.

[martinr33]

But you would have to have the calibration unlock code for the meter, which would imply authorization. However, given the age of the meter, I would expect the unlock code to be in plaintext in the calibration RAM. Which means thet you might be able to read it with a bit of code.

(And in 1990, we barely had networking and Windows was what you needed to run Word and Excel, if you were not a Lotus or Wordperfect user. Viruses came on floppy disks.)

[bsdphk]

Just at footnote here:

There are functions in the firmware you can call from a downloaded vector to do the correct song and dance.

If you change any values, as opposed to a bulk write of the entire CALRAM, there are checksums which must be updated.

[bsdphk]

The calibration code is not necessary to execute code on the 3458A, so no, that's not a barrier.

[alm]

I'm not sure how much this overlaps with existing documentation, but this paper has a bunch of high-level details about the 3458A firmware, including a discussion of the calibration process and its security: https://ieeexplore.ieee.org/document/10875. A full text PDF is available if you search

[martinr33]

Alm - that's a great paper! Has some nice detail on the 3458a overall. I'll have to look at it and the circuit in some more detail and update my understanding of it. I don't quite see how the timing matches the paper, but the INT7 piece makes sense.

And on that - the cal routine does trigger an interrupt, which must hold control of the system until the memory cycle is complete. The cycle is long enough that it could disrupt other measurement functions, but one would not expect the unit to be calibrated in a measurement cycle.

However, it does make getting control of the circuit trickier, as we also have to redirect the interrupt.

bsdphk - thanks for the hints, I appreciate them.

[maxwell3e10]

I am wondering if there is a way to set the calibration constants by controlling the results of the calibration measurements instead of writing to RAM. For example, when calibrating DC gain it measures a 10V input. If one can substitute another number for the result of that measurement, then one could set the calibration constant to any value by doing some arithmetics.