changing the rigol DS1052E to DS1102E using USB , the dummy guide

[torch]

My son is still working on it in his spare time. Originally he thought it was running Linux, but now he thinks they have written some sort of custom operating system based on some Linux libraries. He's figured out what part of the code handles the check when the USB stick is plugged in, but hasn't cracked the header encryption just yet.

[scrat]

My son is still working on it in his spare time. Originally he thought it was running Linux, but now he thinks they have written some sort of custom operating system based on some Linux libraries. He's figured out what part of the code handles the check when the USB stick is plugged in, but hasn't cracked the header encryption just yet.

Very interesting! Keep us updated, please... Sharing would be really useful, even just to know broadly how reverse engineering of such a software can be done. I know most of us are not experts (me first), and mabe won't understand too much, but even just an outline...

[delwinbest]

My son is still working on it in his spare time. Originally he thought it was running Linux, but now he thinks they have written some sort of custom operating system based on some Linux libraries. He's figured out what part of the code handles the check when the USB stick is plugged in, but hasn't cracked the header encryption just yet.

Good to know! Why did he originally think it was Embedded Linux?

Best of luck to him!

\d

[torch]

He recognized some of the code.

[torch]

A question for those of you with the latest firmware (00.02.05.02.00):

What happens if you plug a memory stick with an older firmware file (DS1000Update.RGL) in to the usb port? Do you get any sort of message about firmware? Or does it completely ignore the file?

[Vandel]

 Thought I would sign on here and let you guys know some more details on what I've been trying to do and where I'm having some problems.

Originally I thought it was running a flavour of cuLinux for the blackfin 5xx series processors, only to find that when I started doing some comparisons with code from the toolchain and also the kernel I realized I couldn't actually locate entry for the kernel or code that would have suggested it was running something else.  Since cuLinux uses a bFLT which should be easily identifed in the .RGL files.  I could still be wrong, as I'm still dissecting the hexadecimal mess that these files are made up of.  VisualDSP from Analog Devices uses a .DXE format and I'm struggling going through the .LDR bootloader format that they claim is required by the on-chip boot-rom interpreter, if it's in fact using that method... I believe the first 805686 bytes of the 2.05.01.02 firmware are the loader... directly followed by the first of 2 ELF headers easily found using an ASCII search.  I feel a bit silly as I missed them completely forgetting to tick the 'search ascii' while I was going through the hex file.  Uggghhh...

A bit earlier in the thread Bushing I guess was doing a bunch of the initial chipdumping when he wrote...

"There's no room for a hash, so you could do whatever you want to the file.   Unfortunately, this means that there's no sort of bootloader which could recover corrupted firmware, so your options would be to desolder the NOR flash holding the firmware and reprogram it using a chip programmer, or try to get the 13-pin JTAG-looking connector working."

He then followed up a bit later with...

"I was just plain wrong about the bootloader.  There are at least two, one of which has me mystified"

The internal boot ROM on the blackfin has an interesting tiny boot kernel that can either be directly bypassed or triggered during a chip reset or on power up to load processing code straight from an external memory device.  This is what allows .LDR wrapping and direct code interpretation that from what I understand bypasses and overwrites itself on the uART, or something along those lines allowing for a true no-boot mode... Interesting trick. From what I've been able to identify this firmware is using a wrapped .LDR module suggesting it does have a boot loader. Keep in mind this is heavy speculation still, but from what I've gathered so far from studying this, this is my most current speculation.  If anyone has any other insights, feel free to chime in.  I could use some help with this.

From what I get the DSP compilation and linking, basically ELF based during compilation when the toolchain apparently converts it to the native .DXE format, which in turn becomes a .LDR file? If I have the order right? I could be a bit confused on the process.  This has been a total crash course and it's making my head spin.  Anways, since cuLinux for microcontrollers has issues with the kernel compiling and what not under DSP, ADI does some absolute custom compilation and linking routines that are unique to their DSP development environment and for the Blackfin 533 processors... granted the limited ways this can be compiled and linked there's only so many choices out there.  Since I've been completely unable to identify anything that ressembles the GNU toolchain this leaves the VisualDSP environment or attaining one of the bootimage loader files that accomponies the DSP environment from ADI for comparison.  I'll admit, I have no idea how to use the DSP coding environment with the SDK that ADI provides, but someone out there might have more experience with this than me.  Regardless, what's more important is my focus on the comparison changes between the DSP USB/Pictbridge module they've imbeded as the plugin to do the USB stick reading and the interface with the PC, where it goes, and what it calls and the order.

As for the suggestions from ToBeFrank and my initial ideas of writing an emulator, or doing some sort of decompilation of the firmware this is a full fledged processor with  a complete 16 and 32 bit instruction set.  GDB apparently has a simluation environment under cuLinux that is capable of emulating most of the chipset, but it's buggy, and still doens't have a full set of the instruction implemented.  So...I hate to admit this, but my experience with this sort of thing without low level access to trace and breakpoint step through process with a real-time decompiler is grim.  Since I don't have a way to do this with the processor it leaves me painstakingly looking at this for changes betwen the Toolchain DSP code and the code that's in the .RGL files.

I was hoping to at least be optomistic about identifying the FILE/IO sections but even that isn't going well.  I've been systemically using a programming guide and the byte code variations attempting to write a custom decompiler of certain ranges of code that I think may contain the serial number checker.  The largest problem I'm having is addressing how memory is being mapped and what the DPS code is doing once it recognizes there's a .RGL file on a USB stick. If I could figure out how memory addresses are being stored, and looked at, this would be a whole lot easier.

Past that... a new file that shows up in the mangled header

AUTO_KEY_Lock&Unlock.RGL has also peaked my interest...

As well as the small block of 48 characters that preceeds it...

0012de53h: 73 68 91 ED 7C 3F B5 3F 1B 2F DD 24 06 81 B5 3F ; sh‘í|?µ?./Ý$.µ?
0012de63h: 0A DA E4 F0 49 27 42 3F F7 8F 85 E8 10 38 42 3F ; .ÚäðI'B?÷…è.8B?
0012de73h: 2D 43 1C EB E2 36 3A 3F 61 32 55 30 2A A9 43 3F ; -C.ëâ6:?a2U0*©C?

0000000ah: 82 85 84 88 C3 7B 47 92 39 C8 7E 60             ; ‚…„ˆÃ{G’9È~`

The serial number occurs at 12c7d5, 134925, 13600f, and 1362cf as straight text

My initial thought with the 3 keys was something like Des3... but that didn't work.  Tried a few different flavours of the algorithm to no avail.  Possibly RSA, 3-128 bit keys... I haven't converted them from hex to base 10 and checked for primality yet... got some old miller-rabin algortihms, I'll run those when I get back... any other ideas?  This could also be something completey in house, as marked by the Rigol Technologies marker from 2005.  That 48 byte key showed up injected when the header started getting scrambled.  Which leaves no choice but to decompile and interpret the code.  

3 other series keys exist in the file up a bit...

0012d21bh: C7 EB CA E4 C8 EB BE C9 BD E2 CB F8 C3 DC C2 EB ; ÇëÊäÈë¾É½âËøÃÜÂë
0012d22bh: 3A 00 00 00 50 6C 65 61 73 65 20 65 6E 74 65 72 ; :...Please enter
0012d23bh: 20 74 68 65 20 6F 6C 64 20 6B 65 79 73 3A 00 00 ;  the old keys:..
0012d24bh: C7 EB CA E4 C8 EB D0 C2 BD E2 CB F8 C3 DC C2 EB ; ÇëÊäÈëнâËøÃÜÂë
0012d25bh: 3A 00 00 00 50 6C 65 61 73 65 20 65 6E 74 65 72 ; :...Please enter
0012d26bh: 20 74 68 65 20 6E 65 77 20 6B 65 79 73 3A 00 00 ;  the new keys:..
0012d27bh: C7 EB D6 D8 D0 C2 CA E4 C8 EB D0 C2 BD E2 CB F8 ; ÇëÖØÐÂÊäÈëнâËø
0012d28bh: C3 DC C2 EB 3A 00 00 00 50 6C 65 61 73 65 20 72 ; ÃÜÂë:...Please r
0012d29bh: 65 65 6E 74 65 72 20 74 68 65 20 6E 65 77 20 6B ; eenter the new k
0012d2abh: 65 79 73 3A 00 00 00 00 C7 EB CA E4 C8 EB BD E2 ; eys:....ÇëÊäÈë½â
0012d2bbh: CB F8 C3 DC C2 EB 3A 00 50 6C 65 61 73 65 20 65 ; ËøÃÜÂë:.Please e
0012d2cbh: 6E 74 65 72 20 75 6E 6C 6F 63 6B 20 6B 65 79 73 ; nter unlock keys
0012d2dbh: 3A                                              ; :

Those 3 keys exist even in the unmangled 2.04 version of the firmware... so the code likely has been there all along, it was just never activated.  Or it was mistaken oversight on their part.  Dunno...

I'm not out of ideas yet... and I'm still plugging away...

Back to the ELF headers that are in the files.. doing what I can with knowledge of the structures and their formats, the 2 elf statements, I'm pretty sure are not what I think they are.  106 should be in there somewhere identifying them as Analog Devices header... which in hex would be 6A... the first one has 6a in the neighbourhood, but the 2nd one has no 6a near it... and they just don't seem right.  So this is what puts me back to thinking they're no-boot, no kernel... though there still the issue of VDK which is a potential inhouse ADI proprietary kernel.   But I can't find traces of it either.  Doesn't mean it's not in their, I think their just some obfuscations I'm overlooking.

Be well...

Vandel
[Torch's Son]

[Mechatrommer]

@Vandel: cant you just bypass the encryption algorithm and find the branch where it will accept the new firmware or not, and crack from there? i dunno, might not be as simple as that
i was trying to take the challenge of dissambling it. but i stopped in very early of the process. attached is what i got so far from blackfin datasheet (programming manual iirc), i dont know what good it is to anybody out there. sharing anyway.

[Vandel]

cant you just bypass the encryption algorithm and find the branch where it will accept the new firmware or not, and crack from there? i dunno, might not be as simple as that

Well, if this was an x86 based app, I'd have had this ripped apart, and fully customizable by now.  But unfortunately there are a few problems with something that would otherwise be trivial.

Without point of entry,  I can't calculate memory offsets.  This is a problem for 2 things.

1.  Jump offsets can't be calculated.
2.  I have no idea what chunk of code is looking at what sections of strings.

As soon as I can get memory offsets figured out, then all the byte to byte comparisons will be more useful. 

i was trying to take the challenge of dissambling it. but i stopped in very early of the process. attached is what i got so far from blackfin datasheet (programming manual iirc), i dont know what good it is to anybody out there. sharing anyway.

Well, you basically were doing what I've been doing for the past week and a bit.  Byte Code by painstaking Byte Code... I've yet to definitely identify what they used to compile and link it.  If this is actually doing stragiht injection in the processor then entry won't be presented as the code itself is initializing volatile memory space and doing things on the fly without the need for executable header table addressing.  This processor in my understanding is fully capable of doing just that.  I don't think Rigol intended this to be this difficult, but the fact that auto_key_lock algorithm has been around for a good 6 years, I suspect they may have done more than we give them credit for.

I don't have the funds to dump out for a usb blackfin emulator to  natively run the code base on.  But since I also don't know with absolute surety how the code is getting from the flash memory to the processor, I don't know what's doing the injection.  My understanding is it needs to be controlled with a PROM, but I'm still frantically reading through white papers trying to grasp as much as I can.   There may still actually be a boot loader there that's wrapping the kernel.  This obfuscation is what's making it very difficult to calculate offsets.

Normally yeah, it would just be a jump to bypass... flip a Jump if equal... to a Jump if not equal.  I've done more than my fair share of reverses and hacks over the years.  But this is taking the cake as this a completely foreign environment for me, and there's really not that much information on something that's very likely completely proprietary.  A lot of the toolchains are just barely out of alpha and reaching Release Candiate Stage despite these processors being around for a few years.

I have a couple of focuses I'm going to keep plugging away at.

1. Identify a loader... and it's size... this will give earliest offset to code that I can then use for 2.
2. Write a quick program to scan the file with brute force range of suspected memory entries for a given string.  The file isn't that large and I'm pretty sure most of it happens within the first 1.5 megs of the file.
3. Focus on byte code breakdowns of anything that hits those addresses instead of mass decompilation of the entire firmware package, which at present is basically impossible... but still plausible doable.  I'm one to hold to slim to nil, it's still something favourable...

  I'll keep you all updated.  I have some other development issues with some other things I'm struggling with in overlap...

[Mechatrommer]

i was thinking about the bootloader myself. without the dump (or the source), it will make the dissasembly even more difficult. as you said, ad hoc brute force method. too many problems for me made me abandon ship. i hope you have enough strength to continue the journey. i wish you luck.

[RJSC]

Yet another successful conversion of a DS1052E from DealExtreme.
It came with firmware version 00.02.05.01.00, Hardware revision 58.

Thank you all for sharing!

[roleo]

Hello everyone, this is my first post.

I purchased my Rigol DS1052E on ebay.
It arrived in 8 working days and everything went ok.
HW version is 58 and FW version is 00.02.05.01.02.
I saw the AndrewK post with fw downgrade attached but I haven't read a lot of feedback on it.
Has anyone successfully used the file 2.05.01.02_to_2.02sp2.zip?

Thanks.

[jedreg]

After I choose rise and fall and it crashes, it hangs everytime I restart the unit, to get out of this loop I have to press the "AUTO" button on startup a couple times until it changes back to rise.

I have just experienced this on my own 2.05 SP1.  I found better recovery procedure however -- after the unit hungs, power off and power on again as usual; then during firmware startup hit "run/stop" immediatelly to stop acquisition before it starts first time. After that unit works fine (until started again) and you can easily change trigger mode

Anyway, hack day is comming so this will not be any longer an issue.

cheers,
andy.

[jedreg]

Another hacked rigol should be added to the list. In my case I started from 2.05 SP1 thru 2.02 SP1, hacked using safri's tool, and then back to 2.04 SP1. Everything went smooth, thanx to all great people contributing to this effort !!
cheers,
-andy.

[darrylp]

Vandel,   the ascii text relating to unlock and autolock,  are the function buttons lock out text.   and allowing  user to set the code.    its nothing to do with the encryption of the file.

[Vandel]

@darrylp: Well... I figured it might be something similar to what all cellphones are equipped with, to lock out keys, as the function had a similar name.  Just the 14 byte sequences that preceded matches the xx.xx.xx.xx.xx in length that they use for the revision indexes... I was drawing at straws...

Thanks...

From 2.04.00.03, to 2.05.01.02 they changed format for a bunch of internal files.  The internal subset of commands changed drastically.  Afor the rest of this mess... I'm jumping ship... without a way to run this with any sort of step through, I'm at a total loss... I've been unable after looking at 77 bootloader images and about 8 subsets of toolchains, I can't get anything to match.  This is beyond my capabilities at this point.  Sorry I couldn't help...

[EE_Alan]

Hi Guys

Got My DS1052E Scope from Aidetek Today Its a DS1052E

FW Version 00.02.05.02.00     ( 2.05 SP2 I think )
HW Version 58

Now waiting Anxiously for a hack...
50MHz if perfect for my work, but the extra bandwidth would be great.
As it stands its a very impressive piece of kit for the price!

Is there any way to contribute that may help the community?

Regards

[darrylp]

Hi Guys

Got My DS1052E Scope from Aidetek Today Its a DS1052E

FW Version 00.02.05.02.00     ( 2.05 SP2 I think )
HW Version 58

Now waiting Anxiously for a hack...
50MHz if perfect for my work, but the extra bandwidth would be great.
As it stands its a very impressive piece of kit for the price!

Is there any way to contribute that may help the community?

Regards

one way to help,  is to find a bug with this firmware version,   get it reported to Rigol, and hopefully they will fix it,  thus allowing users to to then do a real upgrade on it along with the 100MHz hack.

[therian]

My  HW Version 07  
It is original ds1102e
Is it a bug after update or I was lucky one getting really old scope ?  

[hacklordsniper]

Is it possible to download 2.5 SP2 somwhere?

Edit: Found it here http://www.eevforum.com/index.php?topic=553.465 

[Mechatrommer]

minutes ago, i just upgraded my rigol upgrade utility app to include upgrade to DS1152E (still default to 1102 hack). the procedure is the same as DS1102E mod, ie change model to DS1152E and then change serial to become DS1EF***. and then i tried to find in eevblog 1052 threads the concrete method of doing this 150MHz hack, none! esp the serial number modding, which people like dimlow suggesting giving the same DS1EB**** after the model mod DS1152E. after rethinking, i cancel my intention to upload the updated app, i will hold it until i find a bright light to this. still too scared to upgrade mine to 150MHz unit, and the auto addition of EDU in model info suggesting rigol already thought of this during the design, maybe it means for educational purpose only? i dont know, but i dont feel right. so any advice is welcomed.

[gordo51]

Just thought I would chime in here to say last Sunday I hacked my newly aquired 00.02.05.01.02 scope to 100MHz. I went through the calibration process and reset to factory initial settings with no problems.  As far as I can tell the scope works fine. I used the guide provided by Polossatik, AndrewK's RGL file and Shafri's Rigupgr application. I did almost use the wrong RGL file as in 3(c)of Polossatik's procedure it mentions using the 02.05.01.02 patch but this is for scopes that are 02.05.01.01, not the 05.01.02 scopes. AndrewK's file mentioned in 3 (d) is "2.05.01.02 to 2.02 SP2". I got the following MD5 sum for Andrew's RGL file:
4445a02a71ddf670cccba00fdbeb67cf
My scope came as 00.02.05.01.02, DSP 00.00, FPGA 02.00, HardVersion 58
I am now 00.02.04.01.02, DSP 02.20, FPGA 02.00 and HardVision 58
Does anyone know if there is any real advantage to upgrading to the 04.01.03 software or higher?

I ordered my scope from Deal Excel on Feb7 and it arrived in WA in about 2 weeks. It was in a Rigol box with the end flaps cut off as others have mentioned. The packing could be a little more robust for overseas shipping but the box was in good shape so maybe they are treated well.  I am just an old fart (60) who has been puttering around in electronics for the last 20 years, ever since I discovered I could buy test equipment and parts on eBay for cheap. I have no training in electronics, just what I can pick up in books.
I have accumulated quite a few old scopes over that time and I'd say this Rigol is a really nice unit. Seems to be quite well built and looks more professional than some of the Agilent scopes in the same price range.  The only one I have which is somewhat similar is a Tek TDS 320 that I bought for $150 since only CH1 will aquire a signal. I have not had a chance to directly compare them yet.  Hope to do more real experimenting when I retire and have more time.  Thanks to everyone for working on this project and thanks to Dave for an interesting blog and for putting out the information.
cheers,
Gordon

Hi Guys

Got My DS1052E Scope from Aidetek Today Its a DS1052E

FW Version 00.02.05.02.00     ( 2.05 SP2 I think )
HW Version 58

Now waiting Anxiously for a hack...
50MHz if perfect for my work, but the extra bandwidth would be great.
As it stands its a very impressive piece of kit for the price!

Is there any way to contribute that may help the community?

Regards

[roleo]

I can confirm the same situation as gordo51.
00.02.05.01.02
DSP: 00.00
FPGA:02.00
HardVersion:58

Hack ok!

Thanks to all

[kyren]

Well, got my scope today from Saelig and... <drumroll>

FW Version 00.02.05.02.00
HW Version 58

So I guess I'm SOL until a new hack is found.  This all started as a hardware hack, right?  If there turns out to be no way to ever hack a 02.05.02.00 scope, would it still be possible to modify it in hardware?

[Fraser]

YES 

[AndrewK]

I can confirm the same situation as gordo51.
00.02.05.01.02
DSP: 00.00
FPGA:02.00
HardVersion:58

Hack ok!

Thanks to all

Great job, roleo!
Welcome!