With all the paranoia about Chinese equipment with backdoors it's extraordinarily dumb to do something like that.
If they are deeply worried about hacking, well, it's not that hard ot make it much more difficult. I can even imagine that they somewhat tolerate some hacking activity in the lower end.
Most of the backdoors I have seen even in examples of the "backdoored" Chinese equipment can be described by Hanlon's razor just like in Rigol's smtp case.
Never attribute to malice that which is adequately explained by stupidity
People get paranoid because of the "Chinese" boogeyman (not to say there isn't a threat), but I've seen as equivalent stupidity from American equipment vendors, even big names like Cisco are part of it
like this,
or this,
or this,
or this (suspicious they keep leaving these backdoors eh?)
Just reinforcing the point that you can't trust any piece of networked hardware from any vendor anywhere in the world.
So is it really just an RSA encrypted packet? If it connects using SSL/TLS it could be possible to try to intercept it. Maybe they won't actually check the certificate (or it's possible to replace certificate trust settings on a firmware file).
SSL/TLS
No, they are posting it over http.
So is it really just an RSA encrypted packet? If it connects using SSL/TLS it could be possible to try to intercept it. Maybe they won't actually check the certificate (or it's possible to replace certificate trust settings on a firmware file).
The info seems to be packaged and then encrypted with the RSA pubkey. It's not a big deal since we can intercept the info buffer (in realtime) before the encryption and see what is being packaged.
It's mostly info from the /data dir. But this is from what I've seen. There could be other info exchanges that I didnt notice.
Most of the backdoors I have seen even in examples of the "backdoored" Chinese equipment can be described by Hanlon's razor just like in Rigol's smtp case.
Never attribute to malice that which is adequately explained by stupidity
I know, that's why I said "paranoia".
That said, lousy security can be a very serious problem in some environments.
People get paranoid because of the "Chinese" boogeyman (not to say there isn't a threat), but I've seen as equivalent stupidity from American equipment vendors, even big names like Cisco are part of it
Of course. Getting it right in a big company is very hard. Especially when everything was just soooo coool, dude, in happiest times!
Straightening poor practices inherited from the past is really difficult.
Just reinforcing the point that you can't trust any piece of networked hardware from any vendor period.
And indeed you are right. My commment deals with the trust problem that these new manufacturers can face. They are newcomers, they are beginning to sell somewhat mature products and nowadays people pays much more attention to this crap than 30 years ago.
Of course. Getting it right in a big company is very hard. Especially when everything was just soooo coool, dude, in happiest times! Straightening poor practices inherited from the past is really difficult.
Well, I don't see it as an issue about getting it right at a big company. It's the year 2019. A "big company" not auditing it's releases and processes at this point is committing willful negligence at this point (or if I continue my rant about Cisco, increasing outsourcing their development to a patchwork of lowest bidders/it doesn't take "a change in company practices" to learn how to grep your update packages for ssh keys before release).
The optics are just against new/smaller manufacturers like you say.
Unfortunately a lot of large corporate entities are very much in big company mentality of the left hand is not knowing what the right hand is doing.
In this case Rigol should take a very seriouy look at the cyber security dept and kick a few backsides as this is a fundamental faux par of large proportions. The possibility of looking in on any of Rigol's personal and private files even for a brief period is pretty grim, as a customer it certainly does no favors for their brand image or credibility in the market place, which is a shame.
Looking to trade up to an MSO 8000 very soon, maybe not so sure now
I didn´t see a reason to connect my scope to lan at home, at work I would be "killed" for if I connect anything else to lan as my authorized notebook.
So I don´t have problems with things who want to phoning home...they couldn´t.
Or:
Do anyone have a fire-tv stick from amazon ? Or a pc connected to lan ? Or alexa ? Or home automations ?
So why worrying about a scope….
As a FYI, if you are using a somewhat modern router, it is pretty easy to set up a rule to prohibit the scopes nic from going through the router. You can still access it on your lan, but it can no longer 'call home'.
DD-WRT (router firmware) calls this 'Access Restrictions -> Wan'.
-Stan
Or just set a fixed IP and leave the gateway out.
Does this enable all features?
Thanks.
Here's a new bspatch that should disable two callbacks to rigol. But I could only test that it stopped storing the response in /tmp/firmware.xml right now.
delfinom, what about disabling email capabilities?
sub_273B50
sub_2745AC
Here's a new bspatch that should disable two callbacks to rigol. But I could only test that it stopped storing the response in /tmp/firmware.xml right now.
delfinom, what about disabling email capabilities?
sub_273B50
sub_2745AC
May be better to just nuke the smtp client at /rigol/mail/bin/msmtp
I like how in the invocation they are turning off tls.
273B50 creates the config file for it.
2745AC sends mail using it
My analysis (FW v00.01.01.04.08):
sub_273B50 - load_mail_config_vars
/rigol/mail/etc/Muttrc
/rigol/mail/etc/msmtprc
sub_2745AC - send_mail_test
/rigol/mail/bin/msmtp
sub_274B70 - send_mail
/rigol/shell/send_mail.sh (uses /rigol/mail/bin/mutt)
It seems they use it to send system logs and/or screen snapshots of the scope. Let's assume that with our previous authorization.
To stop mails from the MSO5000:
Option 1Delete/rename files:
/rigol/mail/bin/msmtp
/rigol/mail/bin/mutt
Option 2Patch appEntry (sub_275A08):
offset 0x26DA08 - patch: 00 48 2D E9 -> 1E FF 2F E1
I just got an email from someone (who is not anonymous) that claims to have cracked the scope and is seeing performance up to 1GHz after setting the front end chip to 4GHz bandwidth.
I will have a new look at this claim in the coming days. I have a "feeling"...
Edit1: I'll start by recreating what is shown in this image. (And, yes, I believe it's a real image...) It should be pretty easy to do (although not by everyone).
These asiatic forum members are extremely volatile and that's why this line of thought has been kept buried somewhere! I'll try to dig it up in plain english...
https://www.eevblog.com/forum/testgear/rigol-mso5000-upgrade-to-500m-bandwidth/msg2316924/#msg2316924I will then need some external help to test the performance. But that should be easy for some of you guys!
Once we do this step, we step up the game...
Let's see where we'll end.
(Of course, let's hope all of this may be extendable to the 7000, 8000 series.)
PS: And, all in "feature" mode. No "patches" or "hacks".
That last thread left off with a suggestion that this was an April Fool's thing. Do we have reason to think the front end on these devices can function past 500MHz?
Maybe. Same chip like mso8000 but IT will not be interesting because of the missing 50Ohm input. 500MHz is max what can be done with passive probe.
So, as promised, here is the replication of that accomplishment. And, I will not disappear in the myst...
The tests (done by another forum member) with the new FW version still continue.
But, at first sight, it seems that the BW limit of the MSO5000 is definitely near the 500MHz mark and doesnt go further:
To be continued...
But, at first sight, it seems that the BW limit of the MSO5000 is definitely near the 500MHz mark and doesnt go further:
Maybe the lack of 50ohm input?
tv84,
That’s an excellent update, can’t wait to learn more.
Even if we don’t use all 500MHz, just not having the -3dB drop at 350MHz is a welcomed enhancement.
I agree that not having the 50 Ohm input would limit how high we can go on the hardware without modification.
Have you had a chance to check if heat on the front end increases with the update and how well the existing cooling handles it?
tv84,
That’s an excellent update, can’t wait to learn more.
Even if we don’t use all 500MHz, just not having the -3dB drop at 350MHz is a welcomed enhancement.
I agree that not having the 50 Ohm input would limit how high we can go on the hardware without modification.
Have you had a chance to check if heat on the front end increases with the update and how well the existing cooling handles it?
Its already been measured at 450-500MHz prior to modifications tv84 is currently working on:
https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/What he could unlock is possibly >500MHz or >8Gs/s, the second of which would increase power consumption.
tv84,
That’s an excellent update, can’t wait to learn more.
Even if we don’t use all 500MHz, just not having the -3dB drop at 350MHz is a welcomed enhancement.
I agree that not having the 50 Ohm input would limit how high we can go on the hardware without modification.
Have you had a chance to check if heat on the front end increases with the update and how well the existing cooling handles it?
Its already been measured at 450-500MHz prior to modifications tv84 is currently working on: https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/
What he could unlock is possibly >500MHz or >8Gs/s, the second of which would increase power consumption.
Is > 8GS/s needed at 500MHz max BW? It looks like the hard analog bw 3dB point is 500MHz, which is likely limited by the actual frontend. So with 4x oversampling that's 2GS/channel and that's enough for 500MHz I guess. But I am not an expert.
thm_w, thanks for pointing that post out.
Do you happen to know what "correction of the measuring path" means in graph 4.1 for the MSO5000? In the MSO4000, I believe they upgraded the heat sinks for the FPGA and ADC, I wonder if they perform the same hardware upgrade in the MSO5000 to get this "correction".
I ask because without this correction, it is -2.2dB at 350MHz, vs. -0.6dB with correction, that's a meaningful difference. And without this correction, the -3dB point is about 450 MHz.
But if tv84 can perform his magic, I would gladly take the extra 100MHz bandwidth
Its already been measured at 450-500MHz prior to modifications tv84 is currently working on: https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/
What he could unlock is possibly >500MHz or >8Gs/s, the second of which would increase power consumption.
Using the existing 350MHz license unlock
myself and
others have tested the MSO5074 up around 450MHz already. Is the 500MHz unlock just a display thing? Or is there some extra headroom left in these things?
I managed to goof up. I tried following the same lines of the hack in this thread, but managed to get myself in a bad situation.
I was trying as a first step to gain SSH access to my MSO5000 scope, which I did by modding the start.sh file. I appended the following code to the end of the file:
/usr/sbin/sshd
/etc/init.d/550sshd restart
However, now after applying the patched firmware to the scope, it correctly goes into the boot loading showing the RIGOL logo, however, when the progress bar reaches the end it stalls - I assume because either of the commands I added are not valid.
I've tried holding down the SINGLE button while booting, but I do not seem to get into the secret menu to be able to re-patch the firmware.
Also, even with the network cable plugged in, the network does not seem to initialise and the Rigol scope does not get assigned an IP, so SSH does not seem like an option to recover as well.
Do you guys have any ideas on how to recover from this?
I've tried holding down the SINGLE button while booting
It's not "holding". It's multiple presses.