Budget Stream Deck Clone Is Ripe For Hacking

The original Stream Deck was a purpose-built device to make it easier to manage a live video stream on the fly. Since its release, many other similar products have hit the market. Among them is the Ulanzi D200 U-Studio, which is proving popular with hackers for good reason.

[Rodrigo Laneth] has been digging into the D200, and found out it’s running Linux 5.10.160 on a quad-core Rockchip RK3308HS chip. Notably, he determined the kernel appears to be from Android, but that Ulanzi removed the Android userspace and “slapped Buildroot on top,” in his own words. Interesting, if not that unusual. What is key, however, is that the device has a fully open adb root shell, as noted by [lucasteske], which inspired [Rodrigo]’s investigation. This pretty much allows full access to the device, so you can make it do whatever weird thing your heart desires.

As you might expect, people are already making the D200 do fun stuff. [lucasteske] got it running DOOM in short order. Meanwhile, [Rodrigo] has it playing out Bad Apple!! at 30 FPS, with code and a deeper explanation available on GitHub.

It’s rare these days that manufacturers leave root open on any commercial device. You normally need to pull a few tricks to get that kind of access.

13 thoughts on “Budget Stream Deck Clone Is Ripe For Hacking

  1. At the driver-level I wonder whether it treats each button as a separate LCD screen, or one large one? I.E. does doom just “work” spread across all the button screens or did they have to coalesce the output?

    It makes me realize I could DIY a cheap stream deck by taking a 7″ touchscreen and putting it inside a 3d printed case with cut-outs for the “buttons”.

    1. Yes, it appears to be exactly as you’re thinking.

      I haven’t disassembled mine to physically confirm it’s a single LCD screen but it does appear as a single 720×1280 framebuffer. The buttons themselves appear as a matrix-keypad device:

      root@rk3308hs-buildroot:/# evtest
      No device specified, trying to scan all of /dev/input/event*
      Available devices:
      /dev/input/event0: matrix-keypad
      Select the device event number [0-0]: 0
      Input driver version is 1.0.1
      Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
      Input device name: “matrix-keypad”
      Supported events:
      Event type 0 (EV_SYN)
      Event type 1 (EV_KEY)
      Event code 7 (KEY_6)
      Event code 8 (KEY_7)
      Event code 9 (KEY_8)
      Event code 10 (KEY_9)
      Event code 11 (KEY_0)
      Event code 12 (KEY_MINUS)
      Event code 13 (KEY_EQUAL)
      Event code 14 (KEY_BACKSPACE)
      Event code 15 (KEY_TAB)
      Event code 29 (KEY_LEFTCTRL)
      Event code 30 (KEY_A)
      Event code 31 (KEY_S)
      Event code 33 (KEY_F)
      Event code 34 (KEY_G)
      Event type 4 (EV_MSC)
      Event code 4 (MSC_SCAN)
      Key repeat handling:
      Repeat type 20 (EV_REP)
      Repeat code 0 (REP_DELAY)
      Value 400
      Repeat code 1 (REP_PERIOD)
      Value 80

    1. I haven’t disassembled mine to physically confirm it’s a single LCD screen but it does appear as a single 720×1280 framebuffer. The buttons themselves appear as a matrix-keypad device:

      root@rk3308hs-buildroot:/# evtest
      No device specified, trying to scan all of /dev/input/event*
      Available devices:
      /dev/input/event0: matrix-keypad
      Select the device event number [0-0]: 0
      Input driver version is 1.0.1
      Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
      Input device name: “matrix-keypad”
      Supported events:
      Event type 0 (EV_SYN)
      Event type 1 (EV_KEY)
      Event code 7 (KEY_6)
      Event code 8 (KEY_7)
      Event code 9 (KEY_8)
      Event code 10 (KEY_9)
      Event code 11 (KEY_0)
      Event code 12 (KEY_MINUS)
      Event code 13 (KEY_EQUAL)
      Event code 14 (KEY_BACKSPACE)
      Event code 15 (KEY_TAB)
      Event code 29 (KEY_LEFTCTRL)
      Event code 30 (KEY_A)
      Event code 31 (KEY_S)
      Event code 33 (KEY_F)
      Event code 34 (KEY_G)
      Event type 4 (EV_MSC)
      Event code 4 (MSC_SCAN)
      Key repeat handling:
      Repeat type 20 (EV_REP)
      Repeat code 0 (REP_DELAY)
      Value 400
      Repeat code 1 (REP_PERIOD)
      Value 80

      1. Not so sure… If you see the DOOM image, you can see that it isn’t “cut” between keys; instead, parts of it, like the face or the biceps, are literally “bellow the key separator”, so it looks like it’s just a big screen with transparent keys over it. Which, BTW, makes more sense if you want a cheap product (only one screen controller, the screen probably is cheaper due to economy of scale…)

  2. just a short note for context — I’m actually the original discoverer of the Ulanzi Studio Deck vulnerabilities mentioned here. My original disclosure and proof-of-concept were posted a few weeks ago on Reddit:

    https://www.reddit.com/r/hardwarehacking/comments/1nyxatq/reported_2_security_issues_to_ulanzi_3_days_ago/

    The case is still open with ULANZI’s internal team, and I’ve been trying to handle this responsibly under a coordinated disclosure process (90-day window).

    While I’m glad to see more people interested in researching the device, publishing uncoordinated details about open security issues is not a good way to handle vulnerability research. It can put users at unnecessary risk before the vendor has a chance to fix things.

    A small credit or reference to my original work would have been very much appreciated — we should all try to support proper disclosure ethics instead of taking credit for someone else’s findings.

    For reference, here’s also my post in ULANZI’s official forum:

    https://bbs.ulanzistudio.com/forum.php?mod=viewthread&tid=96&extra=page%3D1

    Einstein2150 (Raik Schneider)

    1. Hey! I’m Lucas (the one that did what mentioned in the article). I’m sorry but I actually never saw your reddit post about it. I just bought the device for using in my livestreams and tried to figure out a way to use on Linux (since their SW is only Windows). I did dump the flash, found a UART port that has root access as well just to after all of that discover there was an ADB running as well.

      It was really a independent work where the only thing I saw in the internet was the reverse engineering someone did for the Home Assistant, not the actual info of the ADB.

      I also dont consider that an actual vulnerability, but a feature. Users can customize whatever they want, even the Secure Boot wasnt fused so you can do your own secure firmware for that, which is why I published what I found. I think Ulanzi wont treat that as a security vuln as well.

Leave a Reply to JaqlFrostCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.