Hacking the Rigol DHO800/900 Scope

[ebastler]

Don't ask me how I knew to watch out for that... 

[Randy222]

3) I provided the decompiled APK, tons of .java source files to edit if you like

As I understand from reading on the Internet, compiling .java files after decompilation is a very bad idea. You need to modify and compile SMALI files.

The decompiles SMALI files are in the zips I posted back a few pages. APKTOOL decompiles of all 3 or the Rigol APK's (web scope launcher). Edit the SMALI files all day if you like.

Here's what the .com.rigol.scope MainActivity looks like. attached as .smail.txt

However, I am not sure you need to edit SMALI files. The process is to code in Java, compile it, convert to dex using Android dx tool, dex --> smali using baksmali tool

Read these links
https://stackoverflow.com/questions/29051781/convert-java-file-to-smali-file#29052019
https://payatu.com/blog/an-introduction-to-smali/

[AndyBig]

The decompiles SMALI files are in the zips I posted back a few pages. APKTOOL decompiles of all 3 or the Rigol APK's (web scope launcher). Edit the SMALI files all day if you like.

Here's what the .com.rigol.scope MainActivity looks like. attached as .smail.txt

Yes, thank you, I saw your message with a link to a decompiled application, but to be honest, I’m not yet sure that I’m ready to dive even into Java, not to mention SMALI The last time I dealt with Java was about 12 years ago )

However, I am not sure you need to edit SMALI files. The process is to code in Java, compile it, convert to dex using Android dx tool, dex --> smali using baksmali tool

Read these links
https://stackoverflow.com/questions/29051781/convert-java-file-to-smali-file#29052019
https://payatu.com/blog/an-introduction-to-smali/

I have seen many reports that the Java code obtained during the decompilation process has inaccuracies and obvious errors. For example, a function may contain a return statement first and then the function code itself. I'm afraid that it will be almost impossible to find and fix all such jambs. At the same time, SMALI has code that matches the application exactly. In addition, I have come across mentions that when compiling from Java, some kind of fiddling is necessary with the external dependencies to be plugged in, or rather with their versions. But here I'm not sure, because... I haven't studied this issue in depth. In fact, the first reason is already quite enough to be very skeptical about assembling from decompiled Java sources

[S2084]

So guys the chips are installed, I filmed the whole process

https://youtu.be/tC4oR421hfM

https://youtu.be/HyH9DJBt6K0

Did anything work out? Is there any result? Look forward to.

Unfortunately, I have to admit that no changes have occurred.  memory depth remained the same.  I even went back to firmware 1.00.19, and then updated to the latest, but it did not give any result.  It looks like these two memory chips are not used by the system.  But in any case, when Rigil decides to use them, I already have them installed....

[ebastler]

Unfortunately, I have to admit that no changes have occurred.  memory depth remained the same.  I even went back to firmware 1.00.19, and then updated to the latest, but it did not give any result.  It looks like these two memory chips are not used by the system.  But in any case, when Rigil decides to use them, I already have them installed....

Did gabiz_ro's question regarding the choice of memory chips ever get answered? From what I see in teardown photos and datasheets, he seems right about a potential mismatch:

@S2084
From what I found after a quick search
DHO924 use GDP2BFLM-CA  DDR3(L)  4Gb
but you use
H5TQ2G63FFR-PBC DDR3 2Gb

[Fungus]

It looks like these two memory chips are not used by the system.

 

[Randy222]

So guys the chips are installed, I filmed the whole process

https://youtu.be/tC4oR421hfM

https://youtu.be/HyH9DJBt6K0

Did anything work out? Is there any result? Look forward to.

Unfortunately, I have to admit that no changes have occurred.  memory depth remained the same.  I even went back to firmware 1.00.19, and then updated to the latest, but it did not give any result.  It looks like these two memory chips are not used by the system.  But in any case, when Rigil decides to use them, I already have them installed....

Step #1 might have been to probe the lands of the empty mem positions using another tool while the scope was running, to at least ascertain if there's any activity there.
If #1 proves to be active, then perhaps as mentioned, specific mem chips are needed?

Not sure if you can do it, maybe remove the installed chips and solder in sockets instead, this way you can perhaps just pop-in and pop-out chips at-will.

[Randy222]

The decompiles SMALI files are in the zips I posted back a few pages. APKTOOL decompiles of all 3 or the Rigol APK's (web scope launcher). Edit the SMALI files all day if you like.

Here's what the .com.rigol.scope MainActivity looks like. attached as .smail.txt

Yes, thank you, I saw your message with a link to a decompiled application, but to be honest, I’m not yet sure that I’m ready to dive even into Java, not to mention SMALI The last time I dealt with Java was about 12 years ago )

However, I am not sure you need to edit SMALI files. The process is to code in Java, compile it, convert to dex using Android dx tool, dex --> smali using baksmali tool

Read these links
https://stackoverflow.com/questions/29051781/convert-java-file-to-smali-file#29052019
https://payatu.com/blog/an-introduction-to-smali/

I have seen many reports that the Java code obtained during the decompilation process has inaccuracies and obvious errors. For example, a function may contain a return statement first and then the function code itself. I'm afraid that it will be almost impossible to find and fix all such jambs. At the same time, SMALI has code that matches the application exactly. In addition, I have come across mentions that when compiling from Java, some kind of fiddling is necessary with the external dependencies to be plugged in, or rather with their versions. But here I'm not sure, because... I haven't studied this issue in depth. In fact, the first reason is already quite enough to be very skeptical about assembling from decompiled Java sources

I believe we have good methodology to undo APK's, edit them, pack them back up, less the signing issue.

Have a read:
https://medium.com/@sandeepcirusanagunla/decompile-and-recompile-an-android-apk-using-apktool-3d84c2055a82

[S2084]

Unfortunately, I have to admit that no changes have occurred.  memory depth remained the same.  I even went back to firmware 1.00.19, and then updated to the latest, but it did not give any result.  It looks like these two memory chips are not used by the system.  But in any case, when Rigil decides to use them, I already have them installed....

Did gabiz_ro's question regarding the choice of memory chips ever get answered? From what I see in teardown photos and datasheets, he seems right about a potential mismatch:

@S2084
From what I found after a quick search
DHO924 use GDP2BFLM-CA  DDR3(L)  4Gb
but you use
H5TQ2G63FFR-PBC DDR3 2Gb

In order not to look for answers, you can install those chips yourself that you consider necessary

[S2084]

So guys the chips are installed, I filmed the whole process

https://youtu.be/tC4oR421hfM

https://youtu.be/HyH9DJBt6K0

Did anything work out? Is there any result? Look forward to.

Unfortunately, I have to admit that no changes have occurred.  memory depth remained the same.  I even went back to firmware 1.00.19, and then updated to the latest, but it did not give any result.  It looks like these two memory chips are not used by the system.  But in any case, when Rigil decides to use them, I already have them installed....

Step #1 might have been to probe the lands of the empty mem positions using another tool while the scope was running, to at least ascertain if there's any activity there.
If #1 proves to be active, then perhaps as mentioned, specific mem chips are needed?

Not sure if you can do it, maybe remove the installed chips and solder in sockets instead, this way you can perhaps just pop-in and pop-out chips at-will.

Are you at least somewhat competent to give such advice?

[ebastler]

In order not to look for answers, you can install those chips yourself that you consider necessary

Not sure whether it was meant that way, but your comment comes across as disparaging. Which would be unwarranted, since my question was sincere:

If indeed you populated 2 GB DRAM chips instead of 4 GB, that would obviously be an explanation why they did not work. Since you seem to know what you are doing, I assume you had a good reason to choose those chips. Hence I would hope that you can share that reason. Thanks!

[Aleksandr]

Fine! Job is done! And there is a result! Since the absence of a result is also a result! Then let competent people tell you whether such RAM is suitable? mt41k256m16tw-093

[Aleksandr]

And I would still try to upload a full dump from the DHO900 oscilloscope into a 25 series flash drive that is connected to the FPGA! There is some certainty in this too!

[ebastler]

Since the absence of a result is also a result!

I disagree. A negative result -- i.e. the definite conclusion that even suitable RAM does not get used -- would be a result. But the absence of a result provides very limited information.

Having said that, I think it is entirely possible that the RAM is unused (at this time). I have speculated earlier that Rigol had originally designed it in to store the digital data, providing extra capacity and extra bandwidth for these. But ran into problems, maybe routing congestions in the FPGA, and decided to share the main RAM between analog and digital data, as a fallback solution. Which would explain the somewhat embarrassing reduction of the analog sampling rate when the digital channels are used.   

[Randy222]

Step #1 might have been to probe the lands of the empty mem positions using another tool while the scope was running, to at least ascertain if there's any activity there.
If #1 proves to be active, then perhaps as mentioned, specific mem chips are needed?

Not sure if you can do it, maybe remove the installed chips and solder in sockets instead, this way you can perhaps just pop-in and pop-out chips at-will.

Are you at least somewhat competent to give such advice?

Yes is the answer.
But it was more a question. Would it be easier, for testing purposes, to install some type of socket?

That mem is 96-TFBGA package. 96 ball contact, Are you confident all 96 were soldered in good and clean, even with the swimming?

The results do provide some head scratching,

1) no apparent change with mem soldered in?
2) no adverse affects either?

[ebastler]

But it was more a question. Would it be easier, for testing purposes, to install some type of socket?

Last time I looked, BGA sockets cost about the same as a DHO9xx. Have you come across more affordable options?

[Randy222]

Side note for hacking.
Mem dump KLM
compile LiME, insmod it, mem dump, evaluate memory.

https://www.pwc.be/en/FY21/documents/Android_memory_forensics.pdf

[Fungus]

But it was more a question. Would it be easier, for testing purposes, to install some type of socket?

For BGA? Nope.

[Randy222]

But it was more a question. Would it be easier, for testing purposes, to install some type of socket?

For BGA? Nope.

Well, the naked lands could have been probed before trying to solder in the chip, yes?

[gabiz_ro]

In order not to look for answers, you can install those chips yourself that you consider necessary

Nice replay
I will definitely do that in near future.

on topic now
As for MT41K256M16TW-093 that was what I found available on stock, seems compatible but I'm not 100% sure, from datasheet looks like some data lines are splitted  in lower and upper.
Just for example on video cards when replace RAM chips there are some some config resistor that you need to change based on chip vendor, it may be different pinout but I don't think so.
So best approach will be to use same chips as original ones.

I don't think they are separated, data lines are shared, to check for some activity on this chips you must be doing this only on specific pins that are used only by that memory chip under test, chip select or chip enable (maybe some others too) and if there is firmware on that 25Q128 and is different from models with different RAM size then you also got nothing since FPGA will not try to use them so no activity an dedicated pins.And now we can't be sure for anything.

Some say that 25Q128 is used to store some initialization for FPGA and firmware is loaded by startup script, a little strange to use 16MB chip only for that, if my memory serve well that firmware or boot from FPGA folder is around 4MB

 

[S2084]

Step #1 might have been to probe the lands of the empty mem positions using another tool while the scope was running, to at least ascertain if there's any activity there.
If #1 proves to be active, then perhaps as mentioned, specific mem chips are needed?

Not sure if you can do it, maybe remove the installed chips and solder in sockets instead, this way you can perhaps just pop-in and pop-out chips at-will.

Are you at least somewhat competent to give such advice?

Yes is the answer.
But it was more a question. Would it be easier, for testing purposes, to install some type of socket?

That mem is 96-TFBGA package. 96 ball contact, Are you confident all 96 were soldered in good and clean, even with the swimming?

The results do provide some head scratching,

1) no apparent change with mem soldered in?
2) no adverse affects either?

Are you familiar with the concept of "surface tension of a liquid"

[ebastler]

Did gabiz_ro's question regarding the choice of memory chips ever get answered? From what I see in teardown photos and datasheets, he seems right about a potential mismatch:

In order not to look for answers, you can install those chips yourself that you consider necessary

Look, there are a few simple potential answers to my question which I can think of:

• "You are mistaken; the DRAM I used is the correct type because ..."
• "I know it's not the exact type; I chose this one as a workaround because..."
• "Oh shit."

But I can't think of an explanation why you would first come back with a snide comment, then ignore my polite request to clarify. What's wrong?

[S2084]

Please don't be angry, I'll answer you now.

[Fungus]

Well, the naked lands could have been probed before trying to solder in the chip, yes?

If you have a DHO800 with no chips blocking the pads you can probe them to look for activity at boot up.

PS: Has anybody looked in the boot log for messages to do with extra memory?
 

[Randy222]

Some say that 25Q128 is used to store some initialization for FPGA and firmware is loaded by startup script, a little strange to use 16MB chip only for that, if my memory serve well that firmware or boot from FPGA folder is around 4MB

 

FPGA boot.bin is fairly small
3.6 MB (3,631,368 bytes)

Some reasons why maybe 16MB mem chip is used:
1) more common and less expensive than older 8MB chips?
2) maybe just bought 16MB in huge bulk for various products where more mem is needed, so less cost and common chip across the product lines?
3) maybe for possible future feature releases?

As a side question, the experiment was done on 800 series. I wonder if anything changes if you change vendor.bin so the 800 thinks it's a 914 or 924?