Greg Price

6 min read

My Secondhand Photo Frame That Came With a Botnet

A cheap Android photo frame I bought through Amazon Resale arrived as a working member of a botnet. A previous owner had returned it. It still had root access open to any Wi-Fi network it joined, and a dozen pieces of malware were running on it. The malware was built into the system partition, where a factory reset doesn’t reach. I caught it only because I plugged the frame into my laptop before ever putting it on my network.

Why I was poking at a photo frame

You may have seen people using AI assistants to strip the junk out of their smart devices lately. A popular one is swapping a smart TV’s stock launcher for a simpler one that doesn’t serve ads, doesn’t track what you watch, and runs much faster on the same hardware.

I’m not hacking my TVs yet. Instead, I’m experimenting with Wi-Fi photo frames, which are essentially cheap Android tablets in a frame. My goal is to turn them into always-on dashboards for the house.

Claude, Anthropic’s AI assistant, did most of the real work. It walked me through each step, wrote the commands I ran, read and interpreted the output, researched the malware, and wrote this up. My part was mostly plugging in cables, tapping through menus, and pasting commands.

The first frame, a 10-inch Euphro WF133, went smoothly:

  1. I plugged it into my Mac over USB and turned on Android’s USB debugging through a hidden menu.
  2. I removed the vendor’s photo app and updaters.
  3. I installed a small kiosk app that shows a dashboard served from a computer on my home network.
  4. I moved the frame to its own isolated network segment. It can reach only the dashboard server and a time server, never the internet.

The second frame, a model P200 from a different vendor sold under the Vphoto app, is where things got weird.

Wide open from the factory

The P200 was insecure before anyone touched it. It has the same hardware as the first frame: a Rockchip RK3126 with 1 GB of RAM, running Android 6.0.1 from 2015. The vendor’s software is very different:

  • Root access over Wi-Fi with no password. The vendor’s own boot files open Android’s debugging port (TCP 5555) as root. Anyone on the same network can take full control without a prompt.
  • A debug build. It’s signed with Android’s public test keys, has root (su) preinstalled, and runs with SELinux enforcement off.
  • Security patch level: July 2016. Its built-in web engine dates from 2015.
  • A vendor app that downloads and runs code. A preinstalled system app, WanApp, runs a “dex loader” service, a common pattern for pulling down extra code after sale. The frame also ships Adups, an over-the-air updater with a history of privacy problems.

None of that is malware yet. It’s an unlocked front door, and the next section is what walked through it.

The odd things we found

The frame looked normal on screen, but underneath it was running a small malware ecosystem. Everything below came from read-only checks over USB; nothing on the frame was changed.

Apps pretending to be part of Android. Eight extra apps were installed, several with names chosen to look like system parts:

  • com.android.logcatd poses as Android’s logging service. Palo Alto Unit 42 lists this exact package name as an indicator of Kimwolf, a 2025–26 Android botnet that sells infected devices as residential proxies and uses them for DDoS attacks.
  • com.android.door had made itself the Device Owner, Android’s highest admin level, normally reserved for corporate device management. That stops anyone from uninstalling it.
  • com.android.shop, com.wellbeing.keystore, com.rainbow.xk4 and two “app lock” apps fill out the set. The oldest three claim Android’s own SystemUI as their installer, a forged label.
  • One app is literally named com.meowmeow.f***botnets. It looks like a “killer” that one malware crew installs to push rival malware off a device.

Malware baked into the system partition. This is the part a factory reset can’t fix:

  • About a dozen unexplained programs in /system/bin: lol, lol1, lol2, lolxdhaha, ppr, testbin, testbin2, stevenferguson, and hidden files .w and .netd_helper. A Kimwolf-linked domain uses the same “lolxd” naming.
  • The boot-animation program had been hijacked. It runs in the background disguised as netd_service, a near-copy of the name of Android’s real network service.
  • Folders matching the fake apps, /system/app/Door and /system/app/Shop, were added to the system partition, the usual way to make apps come back after a reset.
  • SuperSU’s root daemon was running alongside all of it.
  • A running process holds a private channel named @n****boxv5 (a slur, redacted). Unit 42 describes Kimwolf v7 using @n[redacted]boxv7 for the same purpose. This looks like an earlier version.

A timeline, read from install dates. The frame’s clock reset to 2021 when it lost power, but Android keeps the original install times:

Date What was installed
Apr 1, 2026 The “botnet killer” app
Mar 21–27, 2026 com.android.shop, logcatd (Kimwolf), wellbeing.keystore, plus a .russki folder in temp storage
Mar 10, 2026 com.android.door, which then took Device Owner
Sep 11–15, 2025 The first three apps (rainbow.xk4 and two “app lock” apps)
Oct 30, 2024 Factory image: Vphoto app, Adups updater, su

The frame had remembered two Wi-Fi networks, likely the factory’s and the previous owner’s. Neither was mine.

How it likely happened

My best reconstruction, based on the evidence above and published research on Kimwolf:

  1. The vendor shipped the frame with root debugging open on Wi-Fi.
  2. The previous owner put it on their home network. Kimwolf spreads by scanning for exactly this open port, often from another infected device on the same network, such as a cheap TV box.
  3. Once one dropper was in, it pulled in more over several months, and rival malware showed up to fight over the device.
  4. The owner returned the frame, and it was resold through Amazon Resale without being wiped. Even a wipe wouldn’t have removed the system-level pieces.

While it was on that network, it was likely relaying strangers’ traffic through the owner’s internet connection and taking part in DDoS attacks. Nothing on the screen would have shown it.

What to take from this

Treat any cheap Android-based gadget as an untrusted computer, not an appliance. That includes photo frames, TV boxes, projectors and kids’ tablets.

  • Be wary of returned or open-box smart devices. Retailers don’t check firmware. You inherit whatever the last owner’s network did to it.
  • A factory reset is not a clean slate when the vendor ships a rooted build. Malware with root writes itself into the system partition, which a reset never touches.
  • Put IoT gear on its own network. Use a guest network or VLAN that can’t reach your laptops, NAS or work devices. Block internet access for anything that doesn’t need it.
  • Check before you connect. If a device has a USB debugging port, adb devices and a list of installed packages takes five minutes. Unfamiliar packages named com.android.*, or anything set as Device Owner, are red flags.
  • Assume cheap means unpatched. This frame was sold with a 2016 security patch and a 2015 browser engine. It will never get updates.

As for the P200, I’m either returning it or rebuilding its system image from scratch using the clean first frame as a reference. Either way, it never touches my main network.

Sources

← all notes