VOLTCRAFT DOV series

[Olex]

I managed to hack the firmware, gained root access, and got full access to the file system.
Currently examining the firmware; I think this can be fixed.
Will provide more details later.

Thats nice, but could you maybe dump your eMMC (and upload it here) before modifying anything?

I probably won't upload my own dump since it contains the serial number and mac address of my device.
I think you guys will be able to do it yourself using the instructions I wrote for obtaining root.

[Aldo22]

Thanks, that's great! 

I'm not very familiar with Android hacking.
Let's see if I can make it work (probably not today).

What you will need:
 - an android terminal app installed on the device

Would this Terminal Emulator APK work?
https://f-droid.org/de/packages/com.termoneplus/

[Olex]

Thanks, that's great! 

I'm not very familiar with Android hacking.
Let's see if I can make it work (probably not today).

What you will need:
 - an android terminal app installed on the device

Would this Terminal Emulator APK work?
https://f-droid.org/de/packages/com.termoneplus/

Yeah, that's the one I use.

[Martin72]

- an android terminal app installed on the device

Installation is being blocked.
I have to say, though, I don't know anything about that at all.

[Aldo22]

Yeah, that's the one I use.

So far, so good. That's all I can do today.
I guess I can ignore the linker warning?

Code: [Select]

melinux:~> adb devices -l
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
25110xyz               device usb:2-3 product:aosp_DS01 model:device device:DS01 transport_id:1

[Aldo22]

- an android terminal app installed on the device

Installation is being blocked.
I have to say, though, I don't know anything about that at all.

Olex described it here:
https://www.eevblog.com/forum/testgear/voltcraft-dov-series/msg6282254/#msg6282254

[Olex]

Yeah, that's the one I use.

So far, so good. That's all I can do today.
I guess I can ignore the linker warning?

If everything works, then there's nothing to worry about. 

[Martin72]

Enter the password and voila:

I've arrived now—so what happens next...

[Martin72]

So, it's worked out so far—what's next...

[Olex]

Let me add a little intrigue 
I managed to find where the model type is changed.
I reflashed my DOV704 into an Owon ADS824A, and it even came with some extra features.
Unfortunately, this didn't fix the ripple/pulsation issue.
I also don't have a signal generator yet to test the high frequencies, but at first glance, everything is working well.

Full details tomorrow; I'm completely wiped out today 

[Martin72]

Let me add a little intrigue

Thank you...

[Aldo22]

Could someone who knows their way around this provide instructions on the best way to back up the device and, if necessary, restore it?
I’ve already skimmed through a few things, but I’m not sure what’s correct.
Apparently, you can do something like this:

Open ADB Shell: Connect your phone and open a command prompt, then run: adb shell

Gain Superuser Access: Type su and grant root permissions on your screen.

Pull Partition: Run the dd command to copy a partition.
For example, to back up your boot partition to internal storage:
dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot_backup.img

Copy to PC: Retrieve the image from your phone's internal storage using adb pull:
adb pull /sdcard/boot_backup.img C:/Your/Computer/Path


Is this how to restore it?
1) Boot into bootloader
2) Start recovery from bootloader
3) Use adb push to copy a ROM to the /sdcard
4) Flash it

I'm unsure. I don't want to do anything malicious, just be able to restore the system in case of a problem.
Can anyone shed some light on this?
Thank you!

[Olex]

So, let's continue.

Model change

A bit of theory
If you unpack the firmware update file, you will find, among other things, a file named ota_misc.json with the following content:

Code: [Select]

JSON
{
    "int_models": [
        { "int_model": "ADS802A", "version":"V1.0.1.0.17" },
        { "int_model": "ADS804A", "version":"V1.0.1.0.17" },
        { "int_model": "ADS812A", "version":"V1.0.1.0.17" },
        { "int_model": "ADS814A", "version":"V1.0.1.0.17" },
        { "int_model": "ADS822A", "version":"V1.0.1.0.17" },
        { "int_model": "ADS824A", "version":"V1.0.1.0.17" },
        { "int_model": "CEI914",  "version":"V1.0.1.0.17" },
        { "int_model": "CEI924",  "version":"V1.0.1.0.17" },
        { "int_model": "ADS912A", "version":"V1.0.1.0.17" },
        { "int_model": "ADS914A", "version":"V1.0.1.0.17" },
        { "int_model": "ADS922A", "version":"V1.0.1.0.17" },
        { "int_model": "ADS924A", "version":"V1.0.1.0.17" }
    ]
}
These are the models that this firmware can be installed on.

But wait, don't we have a Voltcraft?
Yes and no.
In the oscilloscope's web interface, under the SCPI query section, the default command is

Code: [Select]

*IDN?It outputs: "VOLTCRAFT,voltcraft-model,serial_number,firmware_version"
However, there is another command:

Code: [Select]

*ODN?This one outputs something else: "VOLTCRAFT,owon-model,serial_number,firmware_version",
and this model must match one of the int_models in ota_misc.json.

*IDN? outputs the ext_models variable - this is the OEM model and can essentially be anything.
*ODN? outputs the int_models variable - these is the actual Owon models (I honestly don't know what the CEI914 and CEI924 models are, perhaps some future versions).

The device configuration itself is determined by an encoded file located inside the oscilloscope at - /oem/BootTxt.bin
This file contains the model, manufacturer, serial number, MAC address, and a few other parameters.

⚠️ CRITICAL: > First and foremost, make a backup of this file just in case!

Code: [Select]

DS01:/ # cp /oem/BootTxt.bin /oem/BootTxt.bin.backup.origIt also makes sense to save a backup of the entire /oem folder to some external storage device.

How to Change the Model

What you will need - python3 installed on your computer.

Download the /oem/BootTxt.bin file from the oscilloscope to your computer.
Place it in the same folder as the following script:

Code: [Select]

#!/usr/bin/env python3
#
# Change of Voltcraft DOV oscilloscope model.
#

key = b"llpowon"

def decode(enc):
    return bytearray((b + key[i % len(key)]) & 0xff for i, b in enumerate(enc))

def encode(plain):
    return bytes((b - key[i % len(key)]) & 0xff for i, b in enumerate(plain))

def put_field(buf, off, s, n=20):
    buf[off:off+n] = s.encode("utf-8")[:n].ljust(n, b"\x00")

enc = open("BootTxt.bin", "rb").read()
plain = decode(enc)

# Changing model
put_field(plain, 0x3C, "ADS824A")  # int_model
put_field(plain, 0x50, "ADS824A")   # ext_model
put_field(plain, 0x64, "OWON")
# put_field(plain, 0x64, "VOLTCRAFT")


func_base = 0x78

# Enabling flags
# uncomment/comment required items
plain[func_base + 0] = 1  # Support14Bit
plain[func_base + 4] = 1  # InstallAPK
plain[func_base + 5] = 1  # Adb
# plain[func_base + 6] = 1  # GenOn
# plain[func_base + 7] = 1  # WaveformClone
# plain[func_base + 8] = 1  # FRA
# plain[func_base + 9] = 1  # SweepAndBurst
# plain[func_base + 10] = 1 # LA

open("BootTxt.modified.dec.bin", "wb").write(plain)
open("BootTxt.modified.bin", "wb").write(encode(plain))

Run the script:

Code: [Select]

$ python3 DOV_change.py
As a result, you will get a file named BootTxt.modified.bin in the same directory.
Upload this file back to the oscilloscope under the name BootTxt.bin.
I copied it from a USB flash drive, but you can also use ADB.

Let's check the mount name of the flash drive:

Code: [Select]

DS01:/ # ls /mnt/media_rw/
1BFA-0317
Copy the file:

Code: [Select]

DS01:/ # cp /mnt/media_rw/1BFA-0317/BootTxt.modified.bin /oem/BootTxt.bin
Set the correct owner for the file:

Code: [Select]

DS01:/ # chown system:system /oem/BootTxt.bin
After doing this, you can restart the Oscilloscope application to see the changes.
If everything looks good, reboot the device.

Script Description (What Can Be Changed):
put_field(plain, 0x3C, "ADS824A")  - int_model: The Owon model. It must correspond to one of the models listed in ota_misc.json.

put_field(plain, 0x50, "ADS824A") - ext_model: Theoretically, any model name can be specified here; it only affects how the model is displayed.

plain[func_base + 0] = 1 - Support14Bit: I'm not entirely sure about the 14-bit part, but with this flag enabled, the signal display layout changed when I selected Acquire -> Mode -> High Res.

plain[func_base + 4] = 1 - InstallAPK: Activates the visibility of the "Security" section in the Android Settings. This is where you can explicitly enable the installation of third-party apps.

plain[func_base + 5] = 1 - Adb: Permanently activates ADB and the visibility of the "Developer options" section in the Android settings.

plain[func_base + 6] = 1 - GenOn: Activates the built-in waveform generator (not soldered on the board in my case).

plain[func_base + 7] = 1 - WaveformClone: Activates additional generator features and signal cloning from the oscilloscope input to the generator output. This feature requires the built-in generator hardware (GenOn).

plain[func_base + 8] = 1 - FRA: Activates the FRA (Frequency, Gain, and Phase) analyzer - an option that becomes available in the oscilloscope's menu. Theoretically, it requires the built-in generator, but I suspect it might work with an external one as well.

plain[func_base + 9] = 1 - SweepAndBurst: This feature requires the built-in generator hardware (GenOn).

plain[func_base + 10] = 1 - LA: Activates the Logic Analyzer (not soldered on the board in my case).

I tried changing the int_models on my device (DOV704) to ADS804A, ADS814A, ADS824A, ADS914A, and ADS924A.
They all boot up, but ADS914A and ADS924A do not function properly - the channels glitch out and the counters display incorrect information.

Currently, I have the options enabled exactly as shown in the script above.

[Martin72]

That sounds great, even though I don't even understand half of it...

[Olex]

That sounds great, even though I don't even understand half of it...

You can send me your BootTxt.bin file, and I will regenerate it for you with the new parameters.

[Martin72]

I couldn't get the Python thing to work(though I did manage the steps leading up to it), but Olex helped me out—thanks a lot for that.
Now my scope is a “DOV2004,” with FRA (which you can access but, naturally, can't use) and, as it turns out, a “working” Hi-Rise mode (14-bit).

[Martin72]

And here's the proof that the scope is now a “true” 200 MHz model:
The frequency counter is linked to the scope's official bandwidth and previously didn't go beyond 80 MHz.
That's now a thing of the past...

[Olex]

I couldn't get the Python thing to work(though I did manage the steps leading up to it), but Olex helped me out—thanks a lot for that.
Now my scope is a “DOV2004,” with FRA (which you can access but, naturally, can't use) and, as it turns out, a “working” Hi-Rise mode (14-bit).

By the way, the FRA is actually trying to work.
There is a good chance that if you connect an external generator as shown in the diagram, it might actually produce some results.

[Martin72]

That should work, but the scope also needs to be able to control the (external) generator.

[Aldo22]

@Martin72
Congratulations!
Is there any difference in the bandwidth, other than the fact that it can now measure higher frequencies?

What does the 14-bit mode do?

I've created the BootTxt.bin file for the ADS822A, but I haven't uploaded it yet.

[Martin72]

Hi Aldo,

Is there any difference in the bandwidth, other than the fact that it can now measure higher frequencies?

I don't think so, but I'd have to “check” again.

What does the 14-bit mode do?

Ideally, it should be more finely resolved(Just as I had originally imagined).
When I enabled “Hires” earlier, the "beam" got thinner, but I need to check that again properly.

[Martin72]

So...
Well, nothing has changed with Hi-Res; it's still (to me) worthless.
The image shows a signal from the Siglent STB3 demo board, which is specifically designed for Eres' demonstration purposes.
But there's no change in the noise.
Bandwidth:
Today I measured it using my RF generator instead of the function generator I used before.
The bandwidth is approximately 177 MHz.
This suggests a filter with a steeper slope, because if you use 0.45 as a rule-of-thumb factor (as I did before), you get over 225 MHz based on the measured rise time.
The “old factor” of 0.35 is more appropriate in this case. (0.35/177Mhz)

@Olex:
My Webcontrol isn't working properly anymore...
I can view everything, but I can no longer control the scope via the panel.

[Olex]

My Webcontrol isn't working properly anymore...
I can view everything, but I can no longer control the scope via the panel.

That's strange, I didn't notice any issues like that during my testing.
Did you try the latest BootTxt.bin file that I sent you?

[Olex]

A little bit of news.

I found a way to access the device's hidden engineering menu, which includes various calibrations and other low-level configurations.
However, the menu is completely in Chinese, so I have to sit there with a translator just to make sense of anything. 

I also managed to locate the fan control registers.
I was able to enable automatic regulation and control its speed, but this is still in the testing phase.
There is a clear bug in the firmware related to fan control, and I'm not sure I'll be able to fix it since it seems to be at the FPGA level.
However, I have an idea on how to bypass it, I'll probably have to write an auxiliary utility for Android.

[Martin72]

Did you try the latest BootTxt.bin file that I sent you?

Not yet...