Hacking the Rigol DHO800/900 Scope

[Mechatrommer]

bode plot ready

But it lacks hardware support, right? This needs signal generator, which the DHO800 don't have, if I understand correctly.

yes you are right, but i suspect support is coming, or at least diy is possible. this guy gave hope, but he's probably just a clueless lunatic idiot coming from nowhere (rebels are built on hope )... ymmv.

[AndyBig]

Today I spent a lot of time trying to assemble decompiled sources of Sparrow in Android Studio. Although I read a lot of reviews on the Internet that it was almost impossible to build a working application from decompiled Java source codes, there was still a little hope. However, no, life is cruel and there was no surprise. You will have to dig into the Java assembler as before to make any changes to the application logic

[Mechatrommer]

how about trying to understand how to build a java (or any machine code such as exe) compiler and decompiler inside out? along the way you know the format and how OS make entry to the executables allocate RAM etc etc... i think if you guru enough in this, you should be able to insert additional machine codes with correct offset, and correction too on all existing call offsets? this is what i really loved to do on exe but never got the chance and time, i'm just enjoying developing my own app.. and i feel i'm getting older, not enough time too many responsibilities and hobbies. ymmv.

[ebastler]

how about trying to understand how to build a java (or any machine code such as exe) decompiler inside out?

Now we are getting into real "hacking" territory.
How about trying to understand how to build a scope inside out? 

[Mechatrommer]

Now we are getting into real "hacking" territory.
How about trying to understand how to build a scope inside out? 

the scope of discussion is SW... you dont have to know the HW in order to change the SW... vice versa. and imho its not hacking, its just a proper route when one wants to become compiler designer (human to machine OS specific conversion) or at least you need to understand its machine code and how they are arranged in certain format in apk or exe or linux/mac format whatever... human made it, so another human (we?) should be able to understand it.. it just a matter of willing to spend time. ymmv.

[norbert.kiszka]

Now we are getting into real "hacking" territory.
How about trying to understand how to build a scope inside out? 

ADC is capable to make 2 Gsa/s. Dont know how is with FPGA, but we should try to do at least 1.5.

[AndyBig]

how about trying to understand how to build a java (or any machine code such as exe) compiler and decompiler inside out? along the way you know the format and how OS make entry to the executables allocate RAM etc etc... i think if you guru enough in this, you should be able to insert additional machine codes with correct offset, and correction too on all existing call offsets? this is what i really loved to do on exe but never got the chance and time, i'm just enjoying developing my own app.. and i feel i'm getting older, not enough time too many responsibilities and hobbies. ymmv.

I'm far from a guru in Android and Java, I'm just learning everything related to them
There is no need to work with “machine codes” (Java opcodes); after decompilation, higher level sources are available - approximately at the level of assembler for a PC. I have already started changing them and it is producing results. But this method is very slow and inconvenient

ADC is capable to make 2 Gsa/s. Dont know how is with FPGA, but we should try to do at least 1.5.

Nothing related to the operation of the FPGA will be changed by me or anyone else. Well, unless someone takes and writes from scratch the complete firmware for an FPGA oscilloscope, but to be honest, I won’t even understand what to call him - a genius or a madman )

[Mechatrommer]

I found how to remove an LA I don’t need from the bottom panel and, after digging deeper into the code, I figured out how to enable the date and time display

achievement like this is already great, if its only involves flipping a constant bit/byte without changing code size/structure/logic. but even greater if it involved adding more codes into the compiled apk.. it might not be easy, you probably need access to android/java documentation on how to assemble into a machine/OS readable format, by paying professional fee... i dont know this android SDK/assembler stuffs.. maybe you need to investigate rat/grey/black/illegit route, just an idea so ymmv.

But this method is very slow and inconvenient

the problem is when new FW update is released, are you patient enough to redo all the hardwork again? maybe building an automating app can help significantly? just an idea ymmv. cheers.

[norbert.kiszka]

madman

Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.

[shapirus]

But this method is very slow and inconvenient

the problem is when new FW update is released, are you patient enough to redo all the hardwork again? maybe building an automating app can help significantly? just an idea ymmv. cheers.

git.

[AndyBig]

achievement like this is already great, if its only involves flipping a constant bit/byte without changing code size/structure/logic. but even greater if it involved adding more codes into the compiled apk.. it might not be easy, you probably need access to android/java documentation on how to assemble into a machine/OS readable format, by paying professional fee... i dont know this android SDK/assembler stuffs.. maybe you need to investigate rat/grey/black/illegit route, just an idea so ymmv.

The decompiled source codes of DALVIK allow you to add/remove/change anything you like. These are not machine codes in an executable file, where you need to take care not to break the structure of the file, where it is impossible to insert something, or replace it with something larger. No, here are the source codes in a programming language, just a very low-level one
Here is an example of a piece of such source code:

Code: [Select]

# virtual methods
.method public draw(Landroid/graphics/Canvas;)V
    .locals 16
    move-object/from16 v0, p0
    .line 85
    iget-object v1, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
    iget v1, v1, Landroid/graphics/Rect;->right:I
    iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
    iget v2, v2, Landroid/graphics/Rect;->right:I
    iget v3, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mTopWidth:I
   
# changed
#    const/16 v3, 120
#    sub-int/2addr v2, v3
#    sub-int/2addr v1, v2

    .line 87
    iget v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->currentState:I
    if-eqz v2, :cond_1
    const/4 v3, 0x1
    if-eq v2, v3, :cond_0
    goto/16 :goto_0
    .line 92
    :cond_0
    iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
    iget v2, v2, Landroid/graphics/Rect;->left:I
    int-to-float v5, v2
    const/4 v6, 0x0
    int-to-float v7, v1
    iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
    iget v2, v2, Landroid/graphics/Rect;->bottom:I
    int-to-float v8, v2
    iget v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mRadius:I
    add-int/lit8 v4, v2, 0x1
    int-to-float v9, v4
#    const/high16 v9, 0x3f000000    # 0.5f
    add-int/2addr v2, v3
    int-to-float v10, v2
#    const/high16 v10, 0x3f000000    # 0.5f
    iget-object v11, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->selectedPaint:Landroid/graphics/Paint;
    move-object/from16 v4, p1
    invoke-virtual/range {v4 .. v11}, Landroid/graphics/Canvas;->drawRoundRect(FFFFFFLandroid/graphics/Paint;)V
    .line 96
    iget-object v2, v0, Lcom/rigol/scope/views/resultItem/ResultItemDrawable;->mBounds:Landroid/graphics/Rect;
    iget v2, v2, Landroid/graphics/Rect;->left:I
You can change it as you like, when you reassemble it, it will be compiled into the correct “executable” Java file with all the changes made.

the problem is when new FW update is released, are you patient enough to redo all the hardwork again? maybe building an automating app can help significantly? just an idea ymmv. cheers.

Well, I try to mark all changes with a comment so that later they can be easily found in all files. In addition, I think that during updates a very small part of the code will be affected, so you can simply copy the files with your changes.
In general, just for fun, you should try to decompile versions 00.01.01 and 00.01.02 and compare the resulting sources

Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.

I assure you that changing the binary firmware of such an FPGA is several orders of magnitude more difficult than any port of the Linux kernel Perhaps this can be compared to completely rewriting the entire kernel from scratch. Moreover, initially without having any source codes for this kernel, only a compiled kernel and a disassembler

[AndyBig]

Any chance you can get the info boxes for CH1..4 to display the probe divider setting? Only possible if the information is available to the display routine, I guess.

Something like that, right? )

[ebastler]

 

[gf]

The decompiled source codes of DALVIK allow you to add/remove/change anything you like. These are not machine codes in an executable file, where you need to take care not to break the structure of the file, where it is impossible to insert something, or replace it with something larger. No, here are the source codes in a programming language, just a very low-level one
Here is an example of a piece of such source code:

Is there no decompiler for Android which generates Java source code instead of bytecode assembly?
For plain .class and .jar files, there seem to exist a couple of decompilers.

[Mechatrommer]

Here is an example of a piece of such source code:

Code: [Select]

...
You can change it as you like, when you reassemble it, it will be compiled into the correct “executable” Java file with all the changes made.

those codes look somehow readable and editable.. so then why your statement above is contradicting with your statement below?

Although I read a lot of reviews on the Internet that it was almost impossible to build a working application from decompiled Java source codes, there was still a little hope. However, no, life is cruel and there was no surprise. You will have to dig into the Java assembler as before to make any changes to the application logic

Something like that, right? )

great job! rigol should hire you

[norbert.kiszka]

Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.

I assure you that changing the binary firmware of such an FPGA is several orders of magnitude more difficult than any port of the Linux kernel Perhaps this can be compared to completely rewriting the entire kernel from scratch. Moreover, initially without having any source codes for this kernel, only a compiled kernel and a disassembler

I did already an email to Rigol for source codes just for kernel and U-boot used on this scope - currently they didnt reply. Maybe they do tomorrow?

[Veteran68]

Is there no decompiler for Android which generates Java source code instead of bytecode assembly?
For plain .class and .jar files, there seem to exist a couple of decompilers.

The fact that decompilers exist doesn't mean rebuilding decompiled code produces the same build as the original code.

While it's been a few years since I did hardcore Java development, the typical decompiler like jad almost never produces source that can be cleanly compiled back to an identical binary/bytecode representation of the original build. Often it won't even build at all, especially with a complex project. It's more for reverse engineering and analysis purposes, being able to better understand what the code is doing, than it is for producing pristine source to make changes to and rebuild. Even if you could rebuild it successfully, you could never trust it to behave exactly the same way in every detail.

It is possible to include your Java source in your JAR/WAR/EAR file, and in the early days of Java you'd sometimes run into this, which was a pleasant surprise. For our internal Java apps we would sometimes do this just as emergency backup of the source before we were more disciplined about source control. If you had the executable Java, then you also had the source that built it. Obviously not something a commercial Java application would want to do (unless maybe it was open source). It also bloats the Java archive considerably for larger code bases.

[AndyBig]

Is there no decompiler for Android which generates Java source code instead of bytecode assembly?
For plain .class and .jar files, there seem to exist a couple of decompilers.

Yes, there is, but the decompilation process is imperfect; there are many errors and strange designs that need to be corrected in order to be able to compile a working application from these sources. When the application is small, with a couple of dozen source code files, this is not so scary. But when the application is huge, consisting of several thousand source code files, then fixing all the decompiler errors becomes unrealistic.
Decompiled Java sources can be used for information in order to better understand what is happening in the corresponding files with DALVIK. That's all.

those codes look somehow readable and editable.. so then why your statement above is contradicting with your statement below?

No contradictions. Although these source codes are quite readable and allow any editing, working with them is still much more difficult and labor-intensive than with high-level source codes like Java or C.

great job! rigol should hire you

It’s too early to rejoice, for now this is just a static inscription, in no way dependent on the actual setting of the probe divider But I seem to already see a fundamental possibility of linking the selected divider setting to it. But I'll have to tinker with this.

[AndyBig]

I did already an email to Rigol for source codes just for kernel and U-boot used on this scope - currently they didnt reply. Maybe they do tomorrow?

It's very interesting how this will end. I will be waiting for the result of your request

[Randy222]

Currently Im porting Linux kernel to regular Debian on this scope. Rigol added some of their Linux modules.

I assure you that changing the binary firmware of such an FPGA is several orders of magnitude more difficult than any port of the Linux kernel Perhaps this can be compared to completely rewriting the entire kernel from scratch. Moreover, initially without having any source codes for this kernel, only a compiled kernel and a disassembler

I did already an email to Rigol for source codes just for kernel and U-boot used on this scope - currently they didnt reply. Maybe they do tomorrow?

It would be somewhat neat if Rigol would split the SW for the device. Close up the actual functional parts like FPGA and the like, but make the UI side more opensource. We appear to just want to change UI stuff. There's some functionla stuff whre Rigol has issues, like FFT, and from the hack-1000 thread we got a util form a user that fixes FFT flat-top issue.

As a side note, I am working on adding a color box to the Channel widget, in the color box you can enter RGB value to change the color of the channel. I thought about color picker wheel too. My work has been slow comared to others here, I just too busy with other priorities.

color wheel

Code: [Select]

    BufferedImage createWheelBuffer(int radius) {
        final int diameter = radius * 2;
        final double radius2 = radius * radius;
        float hue, sat;
        final double PI2 = 2 * Math.PI;
        double dist2;
        int rgb;
        BufferedImage buffer = new BufferedImage(diameter, diameter, BufferedImage.TYPE_INT_ARGB);
        for (int x = 0; x < diameter; x++) {
            for (int y = 0; y < diameter; y++) {
                dist2 = distance2(x, y, radius, radius);
                // if the point is not inside the circle we go to the next point
                if (dist2 > radius2) continue;
                hue = (float) (Math.atan2(y - radius, x - radius) / PI2);
                sat = (float) Math.sqrt((float) dist2) / (float) radius;
                rgb = Color.HSBtoRGB(hue, sat, 1);
                buffer.setRGB(x, y, rgb);
            }
        }
        return buffer;
    }

    int distance2(int x1, int y1, int x2, int y2) {
        int a = x2 - x1;
        int b = y2 - y1;
        return a * a + b * b;
    }

And in the paintComponent event:

    protected void paintComponent(Graphics gr) {
        super.paintComponent(gr);
        Graphics2D g = (Graphics2D) gr;
        BufferedImage buffer = createWheelBuffer(radius);
        g.drawImage(buffer, x, y, this);
    }

     

[Fungus]

ADC is capable to make 2 Gsa/s. Dont know how is with FPGA, but we should try to do at least 1.5.

That would be a good hack.

There's been speculation that the bottleneck is the FPGA but we don't know that for sure.

It all depends on what generates the clock. It might be fixed by hardware though.

[Fungus]

Yes, there is, but the decompilation process is imperfect; there are many errors and strange designs that need to be corrected in order to be able to compile a working application from these sources. When the application is small, with a couple of dozen source code files, this is not so scary. But when the application is huge, consisting of several thousand source code files, then fixing all the decompiler errors becomes unrealistic.
Decompiled Java sources can be used for information in order to better understand what is happening in the corresponding files with DALVIK. That's all.

Is is possible to just decompile individual classes? Surely that would make it much more manageable.

The majority of the code in these is C++ though. From the poking around I did it seemed like Java is only used for UI, everything else is in a huge .so file (12Mb IIRC).

[AndyBig]

As a side note, I am working on adding a color box to the Channel widget, in the color box you can enter RGB value to change the color of the channel. I thought about color picker wheel too. My work has been slow comared to others here, I just too busy with other priorities.

Have you already found in the source code how to set the color of the channel trace?

[Randy222]

As a side note, I am working on adding a color box to the Channel widget, in the color box you can enter RGB value to change the color of the channel. I thought about color picker wheel too. My work has been slow comared to others here, I just too busy with other priorities.

Have you already found in the source code how to set the color of the channel trace?

I posted the color wheel code (that just creates the color wheel, would still need picker and variable set), but implementing a box in the CH widget where you enter RGB value is much easier.
I need to hunt down the widget code, insert box and a [0-9][a-f][ok] keypad, then it updates the channel color variable.

[Randy222]

Yes, there is, but the decompilation process is imperfect; there are many errors and strange designs that need to be corrected in order to be able to compile a working application from these sources. When the application is small, with a couple of dozen source code files, this is not so scary. But when the application is huge, consisting of several thousand source code files, then fixing all the decompiler errors becomes unrealistic.
Decompiled Java sources can be used for information in order to better understand what is happening in the corresponding files with DALVIK. That's all.

Is is possible to just decompile individual classes? Surely that would make it much more manageable.

The majority of the code in these is C++ though. From the poking around I did it seemed like Java is only used for UI, everything else is in a huge .so file (12Mb IIRC).

Sparrow is almost all java smali. Most of the math related functions are in that auklet.so file.
apktool decompiles all of it.