{"id":664,"date":"2025-12-23T16:00:46","date_gmt":"2025-12-23T15:00:46","guid":{"rendered":"https:\/\/www.hardwaresecurity.it\/?p=664"},"modified":"2025-12-23T16:01:56","modified_gmt":"2025-12-23T15:01:56","slug":"snhack-attack-how-hackers-could-turn-your-smart-pet-feeder-into-an-all-you-can-eat-buffet","status":"publish","type":"post","link":"https:\/\/www.hardwaresecurity.it\/?p=664","title":{"rendered":"SNHACK Attack: How Hackers Could Turn Your Smart Pet Feeder into an All-You-Can-Eat Buffet"},"content":{"rendered":"\n
\"0<\/figure>\n\n\n\n

Recently a Smart Pet Feeder landed in my home. Out of curiosity, I have decided to check how secure this IoT device is and also extended this \u201cresearch\u201d to another brand and model. So far, I have checked the following ones that were purchased on Amazon and got some interesting results…<\/p>\n\n\n\n

\"AMAZON<\/figure>\n\n\n\n

The DUT (Devices Under Test)<\/strong><\/p>\n\n\n\n

As you can see from the images above the DUTs are the so-called BALIMO LENA and the PETLIBRO remotely-controlled IoT Pet Feeders. Both have an embedded camera, speaker and microphone. <\/p>\n\n\n\n

Looking closely at the PETLIBRO packaging we can already notice the presence of a FCC ID.<\/p>\n\n\n\n

\"3<\/figure>\n\n\n\n

Looking at the FCC database we can clearly see its internal PCB: https:\/\/fcc.report\/FCC-ID\/2A3DE-PLAF203<\/a> and therefore we can already see what SoC is installed (i.e. a classic Anyka used in many IoT Cameras) and potential pins for UART and JTAG!<\/p>\n\n\n\n

\"4<\/figure>\n\n\n\n

The Mobile Apps<\/strong><\/p>\n\n\n\n

Both DUTs do rely on mobile apps for controlling them remotely: BALIMO relies on the official TUYA App called SmartLife (which has remained out of my scope for now), meanwhile the PETLIBRO relies in its PETLIBRO and PETLIBRO LITE apps.<\/p>\n\n\n\n

Since my investigation was more focused on the hardware side\u2026 I did not spend any time looking at the APKs nor the cloud APIs (which usually are still an interested target to check. Just saying \ud83d\ude09 ). However, out of curiosity I did ran a quick scan with MobSF and here you can see the results\u2026 Overall no big red flags\u2026<\/p>\n\n\n\n

\"5<\/figure>\n\n\n\n
\"6<\/figure>\n\n\n\n

Hardware Teardown<\/strong><\/p>\n\n\n\n

Now that I got some ideas of what to expect from the hardware side\u2026 I have started the teardown of the DUTs.  <\/p>\n\n\n\n

Both devices mount an Anyka SoC (System on Chip). To be precise a AK3918EN080 which is a known SoC usually installed on consumer IoT Cameras. On Github there are plenty of repositories were fellow hackers played with it.<\/p>\n\n\n\n

\"7<\/figure>\n\n\n\n
\"8<\/figure>\n\n\n\n

The Bad, The Good & The Ugly<\/strong><\/p>\n\n\n\n

Now the questions are two:<\/p>\n\n\n\n

1) Where the firmware is stored? (we will see later on is in the SPI Flash)<\/p>\n\n\n\n

2) Is there an UART interface enabled?<\/p>\n\n\n\n

Looking at the images above we can clearly see the presence of interesting pins, marked with the usual UART values (i.e. RT, TX, GNS, in the case of PETLIBRO).<\/p>\n\n\n\n

The next step was to grab the #BRUSCHETTABOARD (https:\/\/github.com\/whid-injector\/BRUSCHETTA-board<\/a>) & #PIZZABITE (https:\/\/github.com\/whid-injector\/PIZZAbite<\/a>) and check if there is the UART console enabled.<\/p>\n\n\n\n

\"10<\/figure>\n\n\n\n
\"9<\/figure>\n\n\n\n

To my un-surprise\u2026 in both DUTs I was able to get the usual UART console running at the standard 115200 bps. However, I was welcomed by a restricted console asking to login with user\/pass. At this point I could have used multiple approaches to get into\u2026 but I preferred for the faster one\u2026 dump the SPI > Extract Firmware > steal the root\u2019s shadow hash > crack it with hashcat > profit. (I followed this approach also because the device has Telnet open on port 23\/TCP open by default.)<\/p>\n\n\n\n

\"0ce213bc<\/figure>\n\n\n\n

At this point, I just needed to use again #BRUSCHETTABOARD with Flashrom to dump the SPI flash memory and use binwalk to check\/extract it. The images below are self-explanatory.<\/p>\n\n\n\n

In the case of BALIMO, I opted to use the SOP8 clip and dump the firmware directly from the PCB. Instead for the PETLIBRO I decided to physically remove the SPI and read it with #BRUSCHETTABOARD and a SOP8-to-DIP8 Socket.<\/p>\n\n\n\n

In both cases, I was successfully able to dump their firmware and extract the contents with Binwalk. As usual, for this kind of consumer IoT devices, I was presented with a classic squasfs\/jffs filesystems structure that were easily parsed\/extracted by Binwalk. So far so good.<\/p>\n\n\n\n

\"13<\/figure>\n\n\n\n

Automated Firmware Analysis<\/strong><\/p>\n\n\n\n

Since I had access to the firmware, but not much interest in a full bug-hunt I quickly ran EMBA and Bugprove to get a grasp of the security of these two DUTs\u2026 and the results were not a surprise\u2026 usual IoT consumer devices where security is not the first (and not even a second) priority\u2026 This is the overall results from the scan of PETLIBRO firmware with Bugprove:<\/p>\n\n\n\n

\"14<\/figure>\n\n\n\n

This is the overall results from the scan of BALIMO firmware with Bugprove:<\/p>\n\n\n\n

\"15<\/figure>\n\n\n\n

One interesting feature of Bugprove is the 0day detection\/hunting feature\u2026 which actually found some interesting findings automatically (that should be manually checked, time permitting).<\/p>\n\n\n\n

\"16<\/figure>\n\n\n\n
\"17<\/figure>\n\n\n\n

Firmware Analysis<\/strong><\/p>\n\n\n\n

With the extracted firmware at my disposal, I was able to look for some low hanging fruits. Here a quick self-explanatory overview.<\/p>\n\n\n\n

\"18<\/figure>\n\n\n\n
\"19<\/figure>\n\n\n\n

As you see there are plenty of stored credentials, Tuya cloud token, Wifi settings, etc\u2026 but what I was looking for primarly was the root\u2019s shadow hash: root:kRVZynxtm9Jac:0:0:99999:7:::<\/p>\n\n\n\n

Here, I noticed immediately an interesting thing\u2026 BOTH targets (i..e supposedly being from TWO different vendors, using different mobile apps and having a different main PCB\u2026 share the same root hash!<\/p>\n\n\n\n

With that hash in my hands, I quickly fired hashcat and left it running all night\u2026 the day after I was welcomed by a lovely result. The root password: AK2040jk<\/strong><\/p>\n\n\n\n

\"20<\/figure>\n\n\n\n

Now with this important piece of information we can check with Nmap if Telnet is open (i.e. which was also confirmed being enabled with the command \u201ctelnetd &\u201d contained in the fw\u2019s file \/etc\/init.d\/rcS).<\/p>\n\n\n\n

\"21<\/figure>\n\n\n\n

At this stage of my investigation, it was proved that both DUTs can be reached from LAN and access as root through telnet. A legit question at this point would be\u2026 What about Internet? Well, we will see later on this article that Shodan can help us figure this out.<\/p>\n\n\n\n

At this point is clear that both vendors and products could be easily hacked remotely and become part of a IoT botnet in pure Mirai style. But again, this was not the goal for the moment. <\/p>\n\n\n\n

The SNHACK ATTACK explained<\/strong><\/p>\n\n\n\n

Now that we have two ways to interact with the DUTs (i.e. both UART and telnet) we can start playing around with the live console. My goal, at this point, was to figure out a way to trigger remotely the feeder servo motor in order to overfeed the victims\u2019 pet (i.e. reason why I called this article SNHACK ATTACK).<\/p>\n\n\n\n

The initial approach was to hunt for some GPIOs that at-rest are set to a 0 value and when the user triggers the feed routine it will change to value of 1 and thus enable the servo motor.<\/p>\n\n\n\n

\"22<\/figure>\n\n\n\n

During the investigation I also started checking the main ELFs involved (i.e. ak_tuya_ipc, feedwatchdog, etc.) with Ghidra and IDA but I ended up wasting too much time and eventually focused on another strategy: checking for logs or debug information.<\/p>\n\n\n\n

I first started deploying a cross-compiled version of tcpdump on the DUT and then tried to dump some packets while triggering the feeding function through the mobile app.<\/p>\n\n\n\n

\"23<\/figure>\n\n\n\n
\"24<\/figure>\n\n\n\n
\"25<\/figure>\n\n\n\n

As you see the network dump was not very useful, lot of encrypted traffic encapsulated into UDP stream and lot of TLS traffic, both going to the Tuya Cloud infrastructure. As I already mentioned, I intentionally avoided dealing with Tuya cloud and APIs because only this topic would take days and days of checks and I am a lazy and busy hacker nowadays, so I will leave to some of you the pleasure of playing with this.<\/p>\n\n\n\n

\"26<\/figure>\n\n\n\n

While looking around dmesg logs, uboot logs and the debug information printed on screen through UART while triggering the feeding function\u2026 I noticed the following debug data:<\/p>\n\n\n\n

\"27<\/figure>\n\n\n\n

It seems that the servo motor is NOT controlled through GPIOs but through a serial connection (note: at this point I could also have checked the PCB to understand if there was involved an external driver connected through serial connection on the SoC\u2026 but at the end I didn\u2019t need to). <\/p>\n\n\n\n

At this point, the challenge was to understand what was the device name related with this serial connection\u2026 cross-checking the list in \/dev\/ together with the U-boot logs\u2026 I quickly realized that two serial ports exist: \/dev\/ttySAK0 (i.e. our UART serial console) and \/dev\/ttySAK1. <\/p>\n\n\n\n

The next step was to replay those packets to that serial connection and hope!<\/p>\n\n\n\n

#Magic command for triggering 1 time the BALIMO feeder servo motor<\/p>\n\n\n\n

echo -en “\\xff\\xff\\x01\\x01\\x00” > \/dev\/ttySAK1 <\/p>\n\n\n\n

#Magic command for triggering 1 time the PETLIBRO feeder servo motor<\/p>\n\n\n\n

echo -en “\\x55\\xaa\\x03\\x01\\x00\\x01\\x01\\x05” > \/dev\/ttySAK1  <\/p>\n\n\n\n

This was enough for a PoC. However, if I will have time, I will reverse engineer the serial protocol to forge the correct packet to trigger an max feeding action. For now, I am ok with this. For the overfeeding attack I just need to sending the same packet in loop and I reach the same goal.<\/p>\n\n\n\n

\n