A ChamSys MagicQ MQ50 is a box full of buttons and faders, a DMX interface, and an embedded Linux computer that runs the GUI under X11.
My lighting tech says to me: "The thing that's annoying about this is that I have to set the clock every time I reboot it. It's not running ntp."
So, who can get me root on this thing? It's running ssh, but the password is not "root / admin" or "admin / admin" and that's when I stopped guessing. (Greets to Joey.)
nmap says:
22/tcp open ssh Dropbear sshd 2016.74 (protocol 2.0)
445/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
4914/tcp open bones?
Service Info: Host: MQ50-0951; OS: Linux; CPE: cpe:/o:linux:linux_kernel
John could be your friend.
https://en.wikipedia.org/wiki/John_the_ripper
Don't think he said he had any password files pulled out to try to crack. (And there's some newer/shinier/better-accelerated tools for doing so than John these days iirc)
how on earth has it not got a battery-backed RTC in there? Maybe it has but the battery has failed?
That is a good guess. If it keeps configuration in flash it will remember that so it won't fall apart, but the RTC needs some power to keep it running.
Quick search indicates the default user/pass might be magicq/magicq (https://secure.chamsys.co.uk/help/documentation/magicq/system-management.html). If that fails you could always try aut a Samba RCE vulnerability. Depends how out of date it is. Eg: https://gist.github.com/0xsha/0859033e1777490576923a27fbcd23ac
There's 2 default passwords listed in the user manual
root/dbps and magicq/magical
I'd try those and then call me an idiot
Goddamn autocorrect. magicq/magicq
I have a direct contact with Chamsys engineering, let me know if you don't get in with the suggested credentials.
Thank you! I have tried these via ssh with no success:
Also if your friend has an answer for the time thing, I no longer care to root it....
Ok, so there's a coin cell battery inside that needs to be replaced for the clock to retain the time.
Apparently that's not the problem. The time drifts significantly, so it really is "why the hell isn't this thing running ntp".
Turns out those guys at Chamsys are no fun at all. Here's the response:
'Users have no access or should be attempting to accessing the underlying OS in the console. there are no user configurable settings and that login and access is not something we will make public. '
Oh nooooo I might void my warranty oh noooooooo
Apparently this is to prevent chinese knockoffs of their IP. This has happened with other console manufacturers and everyone is locking down the guts to prevent copycats.
As the needlessly-inconvenienced paying customer, I should care about their capitalist lock-in rationale for treating me this way why, exactly?
Is it possible to physically remove the boot drive and plug it into something else? If so it would be pretty trivial to mount the drive from an unencumbered Linux machine and then make whatever modifications to the filesystem you want. Probably easier to work with too.
Those things usually have soldered-on flash memory, an actual connector would cost money.
Alternatively, open up the unit, find the serial console connector, connect rs232/ttl adapter to it. From there you can usually stop the execution at the bootloader menu, take control, dump the SSD for Jacktheripper etc.
Or find the JTAG connector, and dump the flash chip from there, then john the ripper etc.
Joey says Metasploit is how he point and click penetrates and ravages delicate public and private computer systems.
According to the Dropbear release notes all the juicy remotely exploitable code execution vulnerabilities were fixed in 2016.74 so I'm not sure there's much to be gained through SSH.
Looking at the ChamSys Github repository (https://github.com/ChamSys/kernel-mq5070) it looks like they have NTP support in the kernel. Maybe they have hardcoded a dead NTP server? If might be worth looking at a packet trace from it to UDP port 123. If it is sending a request, NAT it to your own NTP server.
I presume their support email has been useless for questions like this?
Hey folks, next time someone talks about "Right To Repair" legislation, you think about this thread! It's not just tractors and phone screens.
See? The Invisible Hand of the Market is functioning properly!
The firmware update images are encrypted, so they're fairly serious about not getting in. The CPU module appears to contain a Samsung eMMC, which is trivial to drop off the board and dump, somewhat harder to re-mount afterwards. In theory the RK3288 contains a hardware security engine that allows keys to be stored on the SoC and flash encrypted with that - I can't find any evidence in their bootloader source code that that's supported, but that's not a guarantee. There's also three test pads right next to each other that plausibly look like serial, but again no guarantee there, although the kernel device tree does declare a debug UART (it may be present but only broken out on the edge connector the module plugs into, or it may be present somewhere else on the compute board assembly). Sorry, that's kind of a lot of maybes, but they've put at least a minimal amount of effort into making it annoying to get at their code and without more invasive investigation there's no way to know how far they've pushed that.
It looks like the CPU module on its own is available for about 500 Euros, so you wouldn't technically need to risk a $6000 device, but I'm guessing that unless you're solidly on team "Fuck these guys" that's still too much to justify making a clock work properly?
Yeah, that's entirely too much effort.
It's kind of baffling that they went to so much trouble for this, given that you can download their exact same controller software for macOS, Linux or Windows, so it's not like all this hardening of the device is preventing reverse engineering or anything. It's a goddamned box of switches. It's pretty well protected by virtue of being a physical object.