Which multimeters use the STM32 Micro? Ive just reviewed one.

[Perrin21]

Hi, does anyone know which multimeters are using the STM32 Microcontroller?  I have recently been testing one out (a multimeter based on this micro) and wondered how common this microcontroller is in DMMs.  I have noticed there is a large hacking community for these microcontrollers and have just watched Dave's STM32 video showing how the chips can be reprogrammed.  Could this be the ultimate hackable DMM?  or am i barking up the wrong tree and its quite common? Its not what i expected to find when i tore it apart.

Review here https://youtu.be/xRkMdbNCBWo

[ogden]

Hi, does anyone know which multimeters are using the STM32 Microcontroller?  I have recently been testing one out (a multimeter based on this micro)

I don't know any, but you can tell more about the one you tested. PCB pictures will help too.

I have noticed there is a large hacking community for these microcontrollers

Any pointers to stm32 *hacking* community?

[Perrin21]

That's interesting.  I have one here.  Very cool.  That should at least make the teardown more interesting.  Will share more details very soon, I'm just working on the video now.  Could be a nice hackable meter then 1000V Cat 4 too.

[Perrin21]

here is a teaser

[ogden]

here is a teaser

Teaser? Can't you tell make and model of multimeter? Yes, indeed there is stm32 inside. So what? Most likely you can't read-out it's firmware anyway (unless you are ready to invest significant amount of money). It means no *hacking*. You have to swap chip on PCB with new one and *develop* stm32 code from grounds-up. Before that you have to reverse-engineer and analyze circuit of device to fully understand it's operation so you can write code that actually works. All that for what exactly? - To prove that you can do it? Good luck with that. I mean it.

"Improvement"of instruments is recurring topic here. Most of those who actually want to use instruments will just use them as is. Serious engineer do not want to debug device he is building with tool he can't rely-on, that needs to be debugged itself.

[Kean]

Hi, does anyone know which multimeters are using the STM32 Microcontroller?

You know that Dave's 121GW DMM uses an STM32L152 don't you?

[001]

here is a teaser

Why so pathetic? It is only EE forum

[ebastler]

here is a teaser

Yeah, man, you have uncovered the ultimate business model. Buy those secret multimeters, hack them up to 10 times better resolution and add an on-board Tetris game, then sell them for twice the price. Better make sure nobody figures out the DMM brand!

 

[coromonadalix]

Why double posting  in the microcontroller section ? 

Annoying to say the least.  thread removed

[ogden]

As we know that Dave's DMM uses this exact stm32 kind, it could be Brymen 869S? Other option would be Megger AVO835?

[coromonadalix]

Another going nowhere thread .......  unless Perrin21  show us a video of photo(s) or model name and brand,  this thread should stop here.

[gamalot]

EEVBlog 121GW 

[MosherIV]

I think the Fluke 287/289 both use an STM32F of some kind.

How hackable are they?
Firstly, someone has already mentioned that the firmware is likely to be protected, it is near impossible to read out.
Secondly, there are over 100 variants of the STM32F line of micros. Even if you know the specific micro, with all the peripheral options,  knowing what all the io pins are doing means reverse engineering the entire circuit.
Thirdly, The original source code is likely to be in high level language like C. So the amount of binary/assembly code is likley in 100s Kbytes. Then you have compiler optimisation to get your head around.

Simple answer - not very. Only the really, really, really, really determined will even try!

[gamalot]

I think the Fluke 287/289 both use an STM32F of some kind.

How hackable are they?
Firstly, someone has already mentioned that the firmware is likely to be protected, it is near impossible to read out.
Secondly, there are over 100 variants of the STM32F line of micros. Even if you know the specific micro, with all the peripheral options,  knowing what all the io pins are doing means reverse engineering the entire circuit.
Thirdly, The original source code is likely to be in high level language like C. So the amount of binary/assembly code is likley in 100s Kbytes. Then you have compiler optimisation to get your head around.

Simple answer - not very. Only the really, really, really, really determined will even try!

MCU used in Fluke 287/289 is MSP430 from TI:

https://www.eevblog.com/forum/reviews/fluke-287-dmm-teardown-and-photos/

[Mr. Scram]

Guess what I had for supper last night? I'm not going to tell you but I'll give you a hint. It came on a plate.

[ogden]

Guess what I had for supper last night?

You think we want to know but whole sensation of revelation is just your illusion

[Mr. Scram]

You think we want to know but whole sensation of revelation is just your illusion

Considering the number of revelation teaser threads lately that can't be right.

[DaJMasta]

Guess what I had for supper last night? I'm not going to tell you but I'll give you a hint. It came on a plate.

Fancy schmancy, you didn't have to eat it off some wax paper/paper bag?


I also don't understand the secrecy.  As far as I know, every STM32 is reprogrammable, so it would be hackable with commonly available tools.  Also not uncommon among meters, it's a fairly standard, fairly good, fairly cheap micro from a reputable brand name, and it makes for a good light-duty low power application processor.

[ogden]

You think we want to know but whole sensation of revelation is just your illusion

Considering the number of revelation teaser threads lately that can't be right.

Teaser of revelation does not guarantee that it will be delivered in the end. That's actually The Point.

[ogden]

As far as I know, every STM32 is reprogrammable, so it would be hackable with commonly available tools.

Incorrect. Read-out protection level-2 disables all debug interfaces leaving only bootloader as means for reprogramming. If bootloader is vendor-specific or what's worse - uses firmware encryption, you are out of luck reusing such stm32 IC especially "with commonly available tools".

[MosherIV]

As far as I know, every STM32 is reprogrammable, so it would be hackable with commonly available tools.

If by 'hackable' you mean wipe and re-program from scratch. Yes.

If you mean read out and modify single bytes to modify the existing program - 
NO.

I refer you to ogden's comment and if you manage to read out the existing code I refer you to my ealier post

Secondly, there are over 100 variants of the STM32F line of micros. Even if you know the specific micro, with all the peripheral options,  knowing what all the io pins are doing means reverse engineering the entire circuit.
Thirdly, The original source code is likely to be in high level language like C. So the amount of binary/assembly code is likley in 100s Kbytes. Then you have compiler optimisation to get your head around.

[Nornand]

Hacking a secured STM32FO

https://www.aisec.fraunhofer.de/en/FirmwareProtection.html

[ogden]

Hacking a secured STM32FO

https://www.aisec.fraunhofer.de/en/FirmwareProtection.html

To do the "hacking", in this case flash readout, protection level must be downgraded from RDP2 to RDP1 using UV EEPROM eraser on previously decapsulated chip. It can't be considered as "reprogramming with commonly available tools"

As far as I know, every STM32 is reprogrammable, so it would be hackable with commonly available tools.

If by 'hackable' you mean wipe and re-program from scratch. Yes.

No. You can't wipe nor reprogram RDP2-protected stm32.

[MosherIV]

No. You can't wipe nor reprogram RDP2-protected stm32.

I have not worked with ST parts now for more than 5 years but I thought that using SWD/JTAG to disable RDP2 would result in wiping the flash and hence allow reprogramming. My bad if I am wrong.

[ogden]

No. You can't wipe nor reprogram RDP2-protected stm32.

I have not worked with ST parts now for more than 5 years but I thought that using SWD/JTAG to disable RDP2 would result in wiping the flash and hence allow reprogramming. My bad if I am wrong.

How could you disable RDP2 with SWD/JTAG when main function of RDP2 is to disable SWD/JTAG?!