Unauthenticated RCE on a RIGOL oscilloscope | Hacker News Reader

Unauthenticated RCE on a RIGOL oscilloscope

tortel.li

237 pointsjandeboevrie136 comments

Most test equipments, ancient or recent, are not expecting their programming interfaces, let it be an analog voltage, GPIB, RS232, USB or LAN, exposed to the public internet and it would be a extremely stupid thing to do so. The maker of them assume that if one is able to operate them, one should know where they should plug the cables in.

These equipments are simply assuming that anyone can access the interface is not hostile. This is a pretty good assumption in most lab settings that I know, unless the operator is so ignorant. This assumption certainly have made my life much easier in the lab, of course, where every LXI test equipments are connected to a isolated LAN. I would say a lot more f*k in the lab if I have to authenticate myself before sending a SCPI command. I'm happy that most test equipment makers do agree with me.

For example, modern Rohde&Schwartz gears running Windows or Linux (FSV, FSW, FSVA, FSUP, SMA, SMC, ZNL, etc.) have VNC or Windows RDP enabled by default, and have a weak default password shared among the series. Keysight ones too (E5071C, DSOX3000T, maybe not on by default but with a supported way). A hostile user can even screw up a LAN connected, damn simple VxWorks based multimeter like Agilent 34410A badly by sending the calibration commands at the wrong time or some backdoor commands (DIAG:xxxx, haven't tried but looks possible).

Slightly off topic, some Chinese test equipment makers are making hackability as a feature, look at Siglent or Rigol scopes. They can (and they are competent enough to) lock down the system with secure boot like some Tektronix ones. However they don't, so that people with less budget can buy a cheaper model and hack for the bandwidth.

Then maybe RIGOL should not make assumptions and not release a device with near-trivially insecure firmware.

People don't buy Rigol because they want a secure device, they just want a low cost oscilloscope.

People don't buy a fridge because they want a secure device either, that doesn't mean the manufacturer doesn't have a legal duty of care when releasing software with security vulnerabilities.

My issue with these "they don't need to worry about security" issues is that this issue is at its core still an obvious bug. If your password generator puts a ; in your password your attempt to set it will break.

I went through a similar argument with an intranet product that "didn't need to worry about SQL because it's on a trusted network" crashed when Bob O'Reilly tried to make an account.

Then it simply should not have a password. If everyone who can access it is benign by definition, simply remove the access control.

Having a password implies that it provides some meaningful security. A bad lock is worse than no lock, because it will lead people to put the instrument in inappropriate places.

Having a password makes it less likely that the script that your co-worker got in their email and ran behind your firewall will destroy your stuff as a side effect of scanning your network for things it can destroy.

I agree to some extent, that's why no one put a password to the telnet based LXI SCPI command interface.

But a weak password maybe useful sometimes, to prevent your coworker accidentally connect to the wrong equipment and mess up one's experiment.

Here it's never meant to deter a hostile coworker, in that case one reports to one's superior rather than rely on the password which is always stickered to the scope itself (in my lab).

As most have already written here, this is no suprise. These devices are made to do one job. The whole IoT thing is just cause it something that was hyped. They did try to lock down the scope _a little_. E.g. they removed the incoming RX resistor so you couldn't use the console. They disabled SSH etc. But the scope is very hackable, both in terms of the mentioned unlock ability, but also in terms of accessling Linux. The fact that this is about a RCE, is 'troublesome' but also 'meh'.

I'm mostly disappointment that the author didn't do any research. While I get the cool-factor of trying to hack the firmware from scratch, a simple search would have found the author the EEVblog [0] for starters. But i admit, it is 104 pages atm. And the biggest dissapointment, an obviously shameless plug, is that this 'reversing' of the firmware, was done more then 5 years ago [1] where I wrote scripts to extract the whole firmware automatically.

There's even rumor that the entire source code has leaked onto the internet already.

I would expect some research would have made this 'discovery' less of an 'omg there's an RCE!'

[0]: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso... [1]: https://gitlab.com/riglol/rigolee/firmware/

Hey! Congrats on the reverse engineering work and all the time you put in your research. As you and many other people have already said, RIGOL scopes are not exactly a security fortress, so this exploit I've found isn't impressive at all.

After finding the vuln, I checked online if someone else had already found the vuln, and I admit I have come across the EEVblog, but I didn't find the exact vuln I found (I also must admit I didn't read all the posts there).

I am sorry if I have in some way disrespected your work, but it wasn't my intention at all!

I was very confused by the date format, so here's the timeline with ISO dates:

Vulnerability found, 2022-11-08

Sent detailed PoC, 2022-11-09

RIGOL says they would have contacted me with updates from R&D, 2022-11-09

Follow-up on the vulnerability, 2023-01-25

RIGOL says they would reply in 2-3 days, 2023-01-28

Full disclosure, 2023-02-08

Does this mean they never patched this, then?

So odd to list a timeline but not enough detail to work out what happened.

Such is life with CVEs, unfortunately. While there are some great central repositories of information there is often very little in the way of consistent information on the disclosure process itself.

It's pretty clear to work out what happened from the timeline listed: RIGOL didn’t do shit.

The style the author chose to list the timeline is IMHO the most faithful, honest, and polite way of communicating it without adding wrong or legally problematic reasoning to the situation, from their perspective.

Nah, "no response received from RIGOL" if that's the case is faithful, honest and polite.

This is RIGOL we are talking about. In a year, they will release a firmware that solves the RCE but opens two more and also breaks cursors (or some other very basic thing). A year after that, they will release a second firmware that fixes the cursors but breaks the calibration and still has the two new RCEs.

In my experience this is most firmware vendors

I actually reported the same pair of bugs to them 2021-03-01, so I don't think they're interested in fixing it...

Instruments like this normally boot from a read only image, so even if you have root access to the box you can't do anything bad to it, well, nothing that won't disappear on reboot.

On my Siglent scope (an SDS2104X plus) you can easily hack it to enable telnet access. This requires physical access to the device to add a USB stick with a file on it to achieve this, but it's then very open (described here https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus...)

It was actually one of the things that attracted me to this scope, that it was to some extent hackable. Compared to other scopes like the old Tektronix ones running VxWorks it's nice to have something familiar behind the scenes.

Exactly! A curl 1-liner to get root access to the Linux shell running on my Rigol scope (an older 1074Z-S...do I even have a webserver?)

Think of all the awesome things I could do!

This security vulnerability does not make me worried, it makes me happy. Rigols have always been somewhat hackable, this is an even easier way to do it.

I think such devices anyway have anything lost in a companys LAN. Before such devices had a serial link to a PC. Now every device is in the office LAN. They can never be secure for the many years they are in service.

It has been like that since the 90s. At Stanford we had a sysadmin track down a warez site to our HP logic analyzer. Everything at Stanford in the 90s had a public IP address (at least in EE).

Probably an HP 16600/16700[1]. The control processor is basically a repackaged HP-PA workstation running a full version of HP/UX. Used X11 for remote access. The earlier 16500 had an optional, separate equivalent processor.

I have a 16702A, which includes a front panel LCD and keyboard console. It's a beast.

[1] https://www.keysight.com/us/en/product/16700A/logic-analysis...

Maybe easy fix would be some certification requirement for routers that by default ports to device are closed even from same network? Some time ago there was issue with default passwords and it got solved with default passwords unique to device.

Such devices can also be attacked in a second stage from a compromised PC or so. Such devices have nothing lost in a production LAN at all.

Nice writeup and explanation how to get firmware outside of the hardware.

Bypassing strncmp was particularly insightful.

Was I reading it wrong, or does the system actually store a clear text copy of the password instead of a hash?

It would appear to be clear text with the assumption that no one can login onto the device. I assume the manufacturer makes this assumption.

Storing a salted hash would be nice, but scopes without ntp or internal wall clocks are the norm, so not sure what to salt with. And a plain hash is pretty easy to beat right? As far as getting the hash, these are people who are using oscopes, it doesn't seem unlikely they could jtag it out without some decent safeguards in place. Worrying about physical security on an oscope seems like a bad risk management trade.

> so not sure what to salt with

Scopes have massive amounts of true random data at their disposal. :P

This isn't a nonce where you might need some kind of special timing properties.

We hash so that people can't grab your password and use it elsewhere. We add some salt to make the hash more robust to memory and precomputation attacks.

I don't think it's strncmp itself that's the problem. They fucked up and are only checking that the provided password matches a prefix of the stored password. And obviously an empty string is a matching prefix.

The (decompiled) code looks very amateurish in general. Like, who writes something like system("echo >... or system("sync"). Looks like something written by a very green engineer/intern and not reviewed by anyone else.

Sadly this looks like "industry standard" to me. I have seen many embedded Linux devices using mostly C applications and a lot of usage of the system() function with no or very poor input validation before. When you want to exploit embedded Linux devices always look for calls to system() first.

The "strncmp(saved_pwd,pass0,strlen(pass0))" looks equally bad. Probably someone did not understood the advice "always check the length first" and just did it everywhere.

Intel AMT checked the password in a similar way some time ago: https://www.tenable.com/blog/rediscovering-the-intel-amt-vul...

Many of these faults are simply the consequence of never reading the manpage of a function but making assumptions about implementation details of an imaginary version of a function with the same name.

Though, in this case, manpage doesn't exactly spell out that two strings of which one is 0 chars long results in a match.

I often remember my PHP days in horror, but mysqli_query manpage does warn you about SQL-injections now.

It does actually.

"The strncmp() function is similar, except it compares only the first (at most) n bytes of s1 and s2."

Possibly it's years of string wrangling in C that sets me up here for being biased towards the compact way in which the C manpages state what the function will do, but 'early termination' because of zero length strings for comparisions returns 0 just as sure as comparing "" and "" would. And that 0 indicates a match...

Of course an experienced developer would have thought about edge cases, but I can see a thought process like: ok, I'm comparing two strings. "" != "123" in languages with built-in string types.

I'm definitely not arguing that C shouldn't be used and everybody should be using <insert-the-currently-trendy-systems-programming-language>: just thinking out loud if improved documentation could prevent at least some of the common footguns.

Embedded Linux engineers in general are not incompetent. Many of us do care about quality of the software we write. Although you are right that there is a lot of dodgy embedded software around, that isn't a reason to accept mediocrity like this in newly written user facing APIs.

I have never seen firmware from any vendor in any industry that doesn't use these patterns. There's a lot to unpack culturally around "hardware company engineers" vs "software company engineers," but I don't think this is "amateurish" so far as it is "industry standard from another industry."

I’m sorry, but your comment came right after the comment thread about a guy printing gay porn and I thought you were making a joke and I was giggling about the firmware and hardware thing and then I realized you were making a serious point.

https://pbs.twimg.com/media/EkUjA7rVoAA6FF6?format=jpg&name=...

Also don't expose your Xerox printers to the internet (they will auto install user-hostile "upgrades")

Not just that - they can ~all be bricked remotely unless running the latest updates!!

CVE-2022-23968: https://neosmart.net/blog/xerox-vulnerability-allows-unauthe...

The timeline of this vulnerability might just be the best argument I've ever seen for full disclosure:

  2019-09-26 Reported to vendor with POC
  2020-01-14 Followed up with vendor
  2022-01-24 Publicly disclosed (still no fix over 2 years later!)
  2022-01-28 Fix released by vendor

I wonder if the same will happen with this RIGOL oscilloscope vulnerability.

I'm a bit confused about the timeline at the bottom, was the vulnerability patched?

It looks like they never replied to him for months so he just published it. This would also fit with the HN title (conclusion in the post). I think if it was patched it would be "I found a bug".

This sounds like Rigol and Siglent. Very impressive hardware for the price, questionable support and software.

Siglent seems to be moving upmarket at least. Rigol has wildly good on paper hardware but their software is suspect.

Rigol made their own ADC chip that beats most off the shelf stuff yet they have some of the jankiest software and English translation known to man.

From the timeline

> RIGOL says they would reply in 2-3 days, 1/28/23

> Full disclosure, 2/8/23

Those should be January 28 2023 and February 8 2023, which is the date of the post. It's only 13 days after the last communication from RIGOL, not months.

By the way, could at least us developers use ISO dates instead of whatever our local conventions are?

> It's only 13 days after the last communication from RIGOL, not months.

3 months of total stalling without a real reply to him. The last communication was only that they'd provide more details in a few days.

The fact that he asked again before the disclosure timeframe and they were like "uh, just give us a minute" doesn't change anything.

> By the way, could at least us developers use ISO dates instead of whatever our local conventions are?

2023-28 and 2023-39 aren't any more readable.

Usually when people say ISO8601, they mean "2023-07-12T09:20:00Z". But the actual spec, which no one reads because it costs money to access, allows dozens of other variations. (Too many IMHO.)

RFC3339 is compatible with "the good parts" of ISO8601 and it's also free.

https://www.rfc-editor.org/rfc/rfc3339

I interpret "ISO 8601" to be "lexicographically sortable in chronological order" or maybe "big endian".

I prefer to use dd/mmm/yyyy with mmm like jan/feb/mar etc that takes care of all confusion and seems to be understood the world over. This saves me from having to adopt some local convention depending on who I'm invoicing.

Problem is you can't sort in that order.

I don't think anybody reading my invoices will have trouble interpreting them, and if they need to sort then they're welcome to add their own version of the date. But at least there will be no ambiguity about when I sent the invoice.

Yeah, I agree that 13 days from the last contact was maybe a bit too fast. But they haven't replied to this day and I reported the vuln two months earlier without response!

P.S. sorry for the american time dates, I don't know what I was thinking lol.

    sprintf(&CMD_BUF,"echo admin:%s > %s",pass1,path);
    system(&CMD_BUF);

You've probably heard of useless use of cat, but this is a useless use of echo. Given that the code even opens the file in question several lines above, I'm surprised that the author didn't know about fprintf.

Lots of these tools have truly awful software engineering. Even companies that are top, premium brands have some really questionable decisions like embedding backdoor passwords in the firmware.

Never connect these things to the internet or any untrusted network. Last thing you need is a 10k instrument bricking itself.

I wonder who goes around thinking "I'm going to expose an oscilloscope to the WAN!". Something you have to do on purpose, taking lots of extra steps, because of CG-NAT. Kinda asking for it.

Many universities give everyone on their network a fully routed IP address, at least this was the case ten-ish years ago for me in Germany. Was ideal if you were developing something and showing it off to someone at the other end of the campus while being on the phone or Teamspeak - just give the other person your IP address and spin up a server at 8080, that's it.

Besides, if I were on a red team, I'd enumerate all devices on the LAN as well. Simply to look for all that old cruft someone set up years ago and never updated... that's where you get persistence. No one goes and checks 'scopes, network gear or printers for indicators of compromise in their firmware, because no one thinks of them if the admin isn't looking for outgoing Internet traffic.

> Many universities give everyone on their network a fully routed IP address, at least this was the case ten-ish years ago for me in Germany

Times have changed a lot in the past decade. No reasonable network admin would be giving public IPs to everything that connects to the network any more.

IPv4 addresses are also scarce relative to a decade ago.

Sadly, to my current understanding, my alma mater still does this. At the time it was extremely convenient - we had labs full of Solaris and Linux boxes, which could be remotely accessed from home without any issue. And I also seem to remember that basically nothing on IT's part had to be done during the Xbox 360 / Xbox Live craze, unlike my peers at other schools.

Even then, though, the downsides of consumer network security (mostly) relying on NAT were obvious. Common ports (80, 25, etc) were blocked inbound; the school's printers basically had to be on their own network, or get spammed all day.

> No reasonable network admin

You are speaking about academia. It's not mutually exclusive, but it's different then out there in the wild.

Most of the staff/admins in the universities that I've worked in have relatively modern sensibilities when it comes to this stuff. However, their constituents, particularly on the academic sides of the house ... less so. I've heard a modest firewall policy argued against on the grounds of Academic Freedom, let alone private IP addresses.

It is indeed a different environment.

There are so many devices on a campus network with nebulous ownership set up by clever but still-learning grad students and even undergrads, trying to secure the perimeter seems pointless. Someone internal will find a way to get hacked, or even themselves could be malicious (what are we going to do, background check every student?), so all the nodes on the network need to themselves be secured.

Routable IPs aren't the problem here. In fact under IPv6 you generally would give devices routable IPs. NAT is not a security mechanism.

Instead, you should put a default-deny rule on your firewall for all incoming traffic to user devices (which is generally the default setting anyway).

I can confirm that it is completely normal at German universities as of today. You can setup your own router at home if you so desire

As of a year ago, the major university I worked at still does this

Yeah IPv4 addresses are not scarce at many (some?) big universities

I talked to the security person at a German university a few years ago and suggested that they put some restrictive firewall rules in place to increase security. He agreed with me in principle, but lamented the fact that the grey beards in the university's network administrator team follow a philosophy which says that networks need (or want?) to be free.

Trust me, it's not the case. I sell electronic instruments for laboratories, and in the large majority of the cases they are simply attacched to the local network. And such network has simply internet access. I once made a blogpost to advise our customers how to create a local instruments network for higher performances and security, but I don't know how much impact it had

You are forgetting that many universities (at least in the US) are sitting on enormous allocations of address space due to being early users of the technology from DARPA.

Coupled with "NAT isn't a firewall", assigning actual IPs to your end devices isn't all that silly if you happen to have a few million to spare.

IPv4 exhaustion isn't nearly the issue for universities that it is elsewhere. Most unis grabbed a large allocation early on, before it was an issue. Many have multiple class B allocations; quite a few have As.

This is still the case I think, though admins now restrict the access for sensitive equipment. My work laptop's ethernet has a fully public ip4, for example.

In the era of IPv6 you can't assume that your device is implicitly firewalled for incoming connections. My smartphone currently has a public IPv6 address from my relative's home wifi network.

Oh I didn't realize that. How can that be identified and locked down?

IPv6 is intended to always use public addresses. If you have an ipv6 address, it's probably public. But that doesn't necessarily mean there's no firewall.

You can go to https://whatismyipaddress.com/ and get your public IP then paste it at https://ipspy.net/nmap to port scan yourself.

Your link does not report my public IPv6 address. Only my public IPv4 address.

Here is a service that will show you both your public IPv4 and your public IPv6 address.

https://whatismyipaddress.com/

Ah, thanks. I don't have an IPv6 address so I couldn't check.

Still, that's the only nmap-in-a-website I'm aware of. There are probably others.

Does the nmap scan work on IPv6? That site might actually only be IPv4...

I tried the online scan that you linked with my IPv6 address.

At the end it said

Nmap done: 0 IP addresses (0 hosts up) scanned in 2.20 seconds

Even though it claims to support IPv6

Also the site spent a whole lot of time showing progress bars and stuff.

Whereas when I run Nmap from one of my servers on the internet against my public home IPv6 address

    % nmap -6 -A -T4 2a0c:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

I get:

    Starting Nmap 7.94 ( https://nmap.org ) at 2023-07-16 17:43 CEST
    Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
    Nmap done: 1 IP address (0 hosts up) scanned in 2.23 seconds

So in conclusion yeah, that site you linked was not able to scan IPv6

I think better than that online version of Nmap is to run Nmap from another computer on another IPv6 enabled network against your own public home IPv6 address. Assuming you have additional computers like a server or a VPS, etc. Same way I did.

Another possible alternative is to use shodan.io and check what they have found in their past scans for your IP address. Seems that shodan requires creating an account now in order to use it. Not sure if it did before. I remember testing shodan.io a few years ago but don’t remember if I had to create an account then.

It might just be that your host is blocking all IPv6 probes, as nmap reports, in which case your host would already be in your desired configuration.

Also I'd be extremely surprised if Shodan had anything on your IPv6 address.

Notice the difference of their output:

Nmap done: 0 IP addresses (0 hosts up) scanned in 2.20 seconds

And mine:

Nmap done: 1 IP address (0 hosts up) scanned in 2.23 seconds

And note that 0 IP addresses scanned is exactly what you get if you run nmap with an IPv6 address as target but without the -6 flag. They probably are doing just that; running nmap without the -6 flag.

But let's try something else.

    % host google.com

    google.com has address 142.250.184.14
    google.com has IPv6 address 2a00:1450:4003:808::200e
    google.com mail is handled by 10 smtp.google.com.

    % nmap -6 -A -T4 2a00:1450:4003:808::200e

    Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-16 16:53 BST
    Nmap scan report for mad06s10-in-x0e.1e100.net (2a00:1450:4003:808::200e)
    Host is up (0.032s latency).
    Not shown: 998 filtered ports
    PORT    STATE SERVICE   VERSION
    80/tcp  open  http      gws
    [...]
    Nmap done: 1 IP address (1 host up) scanned in 76.10 seconds

And now try putting 2a00:1450:4003:808::200e into their web tool and see what they report.

At the moment their website will get 0 addresses scanned for that as well.

Nmap done: 0 IP addresses (0 hosts up) scanned in 1.58 seconds

The site is actually spinning up a VM to run the nmap so those progress bars are real. Thanks for checking. I reached out to the creator and he will update it to work with IPv6.

Agree nmap from another machine is best but that's not always an option. I'm thinking like if I am on hotel wifi or something. I might not have easy access to another box.

Shodan is a great suggestion.

I prefer https://www.whatsmyip.org/

Firewalls.

In the network path. On the device. They control what packets get allowed or denied.

But have you actually tested connecting to it from outside the network? Just because something has a public IPv6 address doesn't mean there isn't a firewall somewhere in between. It just means there's no NAT.

I wish we lived "in the era of ipv6". Unfortunately one of the biggest mobile providers in my country (and the only one available to me at reasonable speed) has no ipv6 setup. Also, they NAT their entire network.

So, to have any way to connect back to my home network I have to run a permanent vpn to a server in aws and connect to that.

Probably quite a few people who want to remote-monitor a test setup? The web interface is one of the selling points.

All the people against NAT/PAT and hyping up v6 as a way to get rid of it.

That's unrelated. Any firewall can block incoming connections without the massive performance penalty of NAT

What performance penalty does NAT entail? Even low end home routers have built-in NAT on the chip, no cpu is used for NATting.

Virtually all SOHO routers do routing on CPU.

If you're going to do SOHO routing safely/correctly, you'll need to do some sort of connection tracking. You'll need to allow packets on new and existing outbound connections, but only allow incoming packets on existing connections. SOHO routers generally won't support this in hardware, so you have to route on the CPU anyway.

NAT on IPv4 vs stateful routing on IPv6 is a wash in terms of performance.

> low end home routers have built-in NAT on the chip

Low end home routers have tiny connection tracking tables and fall back to software routing when that table overflows. IMO if you don't notice the massive drop in performance when this happens, you have very low standards/expectations for internet latency. In had to upgrade to a prosumer router just to get acceptable perf on IPv4

I'm thinking maybe they meant performance impact on peer-to-peer protocols like WebRTC, where if both sides are behind NAT, you might end up routing traffic between two local devices with a NAT gateway between them through a remote TURN server to establish connectivity.

There's no performance penalty for NAT that I'm aware of, I'd like to hear more about this. IPv6 OTOH has enough privacy busting concerns that I personally will never use it on my home systems. Trying to use only IPv4 on a smart phone though causes various connectivity issues, I've tried it. Google does own Android and wants to make sure they know as much about what we do on our phones as possible.

NAT is and always was a massive band-aid for the lack of public IPv4 addressing.

Exactly! I don't see anything on shodan. (I didn't look very hard, however.)

How are developers still screwing this up? Is it negligence or stupidity? They shouldn't be allowed to work in industry writing bad code like this.

Security vulns happen, but come on, this is the basics.

You know how much embedded dev pays? It’s shit. People that are good are usually good enough to go write some Java crud apps and make 3x as much.

Unlike the games industry there isn’t nearly as many people drawn to writing the shitware on a consumer router or cut rate oscilloscope.

I have no qualms with "acting your wage." This goes below the minimum bar in my opinion. Real engineers don't get away with fuckups with real consequences because of their salary.

> This goes below the minimum bar in my opinion.

I'm not giving you a justification, I'm telling you how it is.

> Real engineers don't get away with fuckups with real consequences because of their salary.

I mean they absolutely do.

What is a "real" engineer anyway? I am a licensed engineer (electrical) because I used to work independently as an engineering firm. I understand the various definitions.

The overwhelming majority of those with a title of electrical or computer engineer do not have any kind of professional licensure or certification - at best they may have an accredited 4 year degree.

None of these people are going to be personally liable for fuckups of any kind in their careers.

As others have mentioned, the pay and the incentives for producing quality embedded software is non existent.

Just last year I casually inspected and found an RCE in a decade old consumer product just sitting there in plain sight:

http://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-1...

It seems the device embeds a conventional ARM Linux. If I were developing embedded software for a device like that, I would have used asp.net core runtime.

It’s much easier to create secure web apps using C#, compared to cgi-bin written in C for lighthttpd web server.

As a separate issue, it’s strange the firmware pkg is not encrypted.

Why is it an issue? Is it to make sure that the right firmware is loaded? I always thought encrypted firmwares were mostly a form of lock in.

Yeah - if anything, you could sign it and/or checksums it. Encryption indeed sounds like lock-in.

Rigol is pretty famous for not really caring a single bit about security. It's helpful in one particular area, in that they sell the device in the OP for anywhere between $900 and $2900 depending on which features are enabled, except all of those features are software locked with the same attention to security as they do everything else.

The result is that you can get a hell of a lot of scope for very little money, but don't expect it to offer things like "robust security".

Awesome detective work!

That's the kind of thing that makes this site special.

Here, I have a better, simpler , all encompassing rule: do not expose anything closed source to the Internet.

No, this is not Linux zealotry, I also advocate against using Linux as a daily driver on a modern laptop.

The right tool for the right job: OpenWRT on routers, Windows + WSL on laptops.

But, you are asking, how do you use your Windows laptop like this when away from home?

Easy: GL.iNet has tiny travel routers with OpenWRT supported out of the box.

Why would you advocate against Linux on Laptops?

If it works just as well and floats my boat, why change to windows?

https://news.ycombinator.com/item?id=36678027

I agree. Life's too short for fiddling with the OS and i would have wiped PopOs from my Laptop a long time ago if it wouldn't work flawless, but it does (cheap Thinkpad L580).

Windows has it's own fun set of problems with drivers: https://www.esecurityplanet.com/threats/malicious-microsoft-...

I don't know bro, I've been installing Linux on random computers (not-preselected) for years and I don't have these problems.

FWIW I haven't had any hard tech issues with Linux across many different kinds of computers (laptops, desktops, servers, as well as some stuff never intended to run Linux at all such as Macs) and haven't had a serious hardware issue in more than 15 years. The biggest stumbling block was to get Linux installed on an early issue Macbook air just after it came out, other than that not a single glitch. Meanwhile, my family members have issues with their windows boxes every other week or so.

I'm sure there are plenty of people that never have a problem with Windows and that can't get Linux to work on their hardware but I'd be careful to generalize from personal experience.

For what is worth, last time I encountered compatibility problems wrt Linux on a laptop has been when I was using RedHat 6 or 7 on the cheapest+crappiest Asus laptop I could purchase at that time, and had to recompile kernel and gfx drivers at every update. That happened like 22 years ago, and was 100% the laptop's fault, not Linux, which also worked flawlessly on every laptop I installed later on.

> Easy: GL.iNet has tiny travel routers with OpenWRT supported out of the box.

It supports modified OpenWRT with proprietary drivers, which are closed source. Still better than completely black-box travel routers but /shrug.

From https://github.com/gl-inet/glbuilder:

> Since the driver part uses the driver code maintained by many chip manufacturers, we have no right to open it to users. We have tried to provide it to users in the form of ko, but we will always encounter many strange problems.

> I also advocate against using Linux as a daily driver on a modern laptop.

Why would you do that?

https://news.ycombinator.com/item?id=36678027

If you're as right about one as you are about the other recommendation, I might have to start exposing closed-source stuff to the internet.

https://news.ycombinator.com/item?id=36678027

I've been running Linux on all my computers for years and haven't had problems, so I'm not sure why I'd avoid it.

Why would anyone who needs to program willingly choose windows + wsl over macbooks

Reply on news.ycombinator.com