yi-hack-Allwinner: replacing the cloud firmware on an Allwinner Yi camera

What the project does, and where it came from

yi-hack-Allwinner is a modification of the firmware for the Allwinner-based Yi Camera platform, and the readme is plain about the intent: it replaces the vendor software on a camera the owner already has.

The features it adds are described as replicated from the yi-hack-MStar project and similar to the yi-hack-v4 project, which tells you the lineage. This is the third generation of a family of efforts to take a consumer camera whose original firmware ties it to a cloud service and give it local interfaces, and each project targets a different chip platform. The MStar project is a sibling by the same author, and yi-hack-v4 and yi-hack-v5 are maintained elsewhere.

The camera itself is a Yi 1080p or a related model, and the topic list names camera, custom, firmware, hack, rtsp and yi. The primary language is recorded as Shell, which fits a project that is mostly packaging, scripts and configuration around a vendor system rather than a fresh operating system.

The licence is MIT, the default branch is master, and the recent releases are 0.4.1 from 2026-09-27, 0.4.0 from 2025-10-27 and 0.3.9 from 2024-04-11, with the last push to the repository on 2026-09-27.

The repository tree explains what kind of project this is. There is a src/ directory, a scripts/ directory, an assets/ directory, a sdhack/ directory, an unbrick/ directory and a sysroot/ directory, plus a .gitmodules file, which means parts of the toolchain are pulled in as submodules, and a VERSION file that carries the release number separately from the source.

The unbrick/ directory is worth noting on its own. It implies the project includes a recovery path for a camera whose firmware has gone wrong, which is a meaningful thing for a project whose installation procedure involves replacing the vendor firmware on a device with no keyboard.

Installing: the card, the file prefix and the wait

The installation procedure is written for somebody with the camera in their hand, and it has a specific order.

The first step is a backup. The documentation says it is not easy to brick the camera but it can happen, and asks you to make a backup copy, pointing at a wiki page for dumping your backup firmware from the SD card. It also notes that the hack procedure will create a backup for you, which is a useful safety net but not a reason to skip the manual step.

There is a condition on the first two steps. If you want to use the original Yi app, you should install it and complete the pairing process before installing the hack. Otherwise, check step 4. That is the detail most people would miss, because the pairing is what the vendor cloud uses to identify the camera, and skipping it when you intend to keep using the app means the camera has to be paired again later.

After that: check whether your camera is in the supported section and note the file prefix, format an SD card as FAT32, which the documentation recommends doing with the camera's own native format function, and if the card is already formatted, remove all the files from it. Download the latest release from the releases page based on the file prefix. Extract the contents of the archive to the root of the SD card, so the card looks like this:

|-- Factory/
|-- newhome/
|-- home_xxx.stage

Then optionally, if you want to set WiFi credentials, rename Factory/configure_wifi.cfg.ori to Factory/configure_wifi.cfg and edit the file with your username and password. Insert the SD card and reboot the camera.

The update then takes a while, and the documentation is honest about it. The camera reboots a couple of times as it is rooted and the new firmware is applied, it can take up to an hour to update, and once the light is solid blue for at least a minute it is complete. The solid blue light for a minute is a specific and useful completion signal, because a camera that looks finished because it stopped blinking is not the same thing.

After that, check the hack by opening the web interface at http://IP-CAM, where IP-CAM is the address your router assigned, and if there is a problem, the FAQ is linked.

The two update paths afterwards are the online one, through the Motion Events and Maintenance web pages, and a manual one documented in the wiki of a separate v2 repository. The online procedure has a warning that is easy to skim past: if you do not delete the mp4 files, the upgrade procedure will take a long time, which is a statement about how the firmware stores and moves video.

The feature set, and the parts that matter for automation

The feature list is long and it is worth sorting by what it lets you build rather than by what it is.

The RTSP server allows a RTSP stream of the video, at high and/or low resolution, and of the audio, and it gives three URLs:

rtsp://IP-CAM/ch0_0.h264             (high res)
rtsp://IP-CAM/ch0_1.h264             (low res)
rtsp://IP-CAM/ch0_2.h264             (only audio)

The ONVIF server, with support for stream, snapshot, ptz, presets, events and WS-Discovery, is described as providing standardized interfaces for IP cameras. That is the most valuable single line in the list for most people, because ONVIF is what a home automation platform, a network recorder or a video management system already speaks. A camera that speaks ONVIF is a camera that works with software written for cameras rather than one that needs a bespoke integration.

The snapshot service allows you to get a jpg with a web request, with a query string that selects the resolution and whether there is a watermark, and a default of high resolution without a watermark.

MQTT is there twice, once for events and once for configuration. The event side covers motion detection and baby crying detection through the MQTT protocol, which is the feature that turns the camera into a sensor rather than a camera.

Then the infrastructure that makes the rest practical. There is a web server with a web configuration interface, an SSH server using dropbear, a Telnet server using busybox, an FTP server, and FTP push, which exports mp4 video to an FTP server. Authentication applies to the HTTP, RTSP and ONVIF servers, which matters because a device that roots itself and offers three network services with no authentication is a liability on a home network.

Proxychains-ng is included but disabled by default, with the note that it is useful if the camera is region locked. That is a small feature with a large meaning: the camera's video services normally depend on a regional cloud, and this lets the traffic be routed so that they work.

And there is the possibility to disable all the cloud features, which is the point of the whole exercise.

The list also covers the settings the original app could change, copied into the web interface, including camera on and off, video saving mode, detection sensitivity, motion detections, baby crying detection, the status led, the ir led and rotate. There is management of motion detect events and videos through a web page, viewing of recorded video through a web page, PTZ support and PTZ presets through a web page if the camera supports it, swap file on the SD card, online firmware upgrade, and load, save and reset of the configuration.

The supported camera table, and the two warnings around it

The table of supported cameras is the most important page in the readme, and it is short.

The documentation says the project currently supports only the following cameras:

| Camera | Firmware | File prefix | Remarks |
| --- | --- | --- | --- |
| **Yi 1080p Home 9FUS** | 8.2.0* | y20ga | - |
| **Yi 1080p Home BFUS** | 12.2.0* | y20ga | - |
| **Kami Baby LFUS** | 1.3.0* | y501gc | beta version |

The full table in the documentation covers the Yi 1080p Home 9FUS, BFUS, SFUS and BFCN models at firmware 8.2.0 and 12.2.0 with the y20ga prefix, the 9FUS and IFUS at 8.3.0 with the y25ga prefix, the Yi Dome X BFUS at 8.1.0 with the y30qa prefix, and the Kami Baby LFUS at 1.3.0 with the y501gc prefix, which is the one marked as a beta version.

Three details in that table do the work. The camera model matters, because several models share a firmware version and a prefix and differ in nothing else that matters to the flasher. The firmware version matters, because the same model on a different firmware may not be listed at all. And the file prefix is the practical part, because it is what tells you which archive to download from the releases page.

The asterisk next to the firmware versions is unexplained in the visible text, and it is the kind of detail that a reader should ask about rather than guess at.

Then there are two warnings, set in bold, and they are the reason to read the table carefully before downloading anything. Do not try to use a firmware on an unlisted model. Do not try to force the firmware loading by renaming the files.

That second one is the one to dwell on. It is tempting, when the model is not listed, to assume that the prefix is a naming convention and that renaming the archive to match will work, and the documentation says explicitly that it will not. The table is a compatibility statement, not a lookup table for file names.

The way to check your own camera is given separately and it is simple. Check the serial number, first four letters, and the firmware version, and if both numbers appear in the same row in the table, your camera is supported. If not, the documentation points at the other projects related to Yi cameras: yi-hack-v4 and its predecessors, yi-hack-v5, and yi-hack-MStar.

Performance, and what the hardware can actually carry

There is a performance section, and it is short and blunt.

The documentation says the performance of the camera is not so good, citing the CPU and RAM, and that low RAM is the bigger problem. If you enable all the services you may have some problems. For example, enabling snapshots may cause frequent reboots. And the conclusion is to enable swap file even if this will waste the SD card.

That is an unusually candid statement from a firmware project, and it changes how the feature list should be read. The list is not a set of features you switch on; it is a set of services competing for a small amount of memory, and the ordering of what you enable matters.

The swap file on the SD card is the mitigation, and it is listed as a feature of the firmware rather than left to the reader. A swap file on a removable card is an unusual thing to enable by default recommendation, and it is a consequence of the RAM being the binding constraint. The cost is stated plainly, that it will waste the SD card, which matters because the card is also where the video goes.

The two services named as problematic are snapshots and, implicitly, the ones that are not named. The RTSP server is the feature most people will want, and the ONVIF server sits on top of it, and the web interface for recorded video and the FTP push are both more memory than they look. A user who enables everything and then wonders why the camera reboots is going to find the answer in this section rather than in a bug report.

The other place the hardware shows through is the Home Assistant integration. The table of contents lists a Home Assistant integration section, which tells you the project aims to be usable from a mainstream automation platform rather than only from a script, and the MQTT events are the other route in.

Where the custom firmware is the wrong tool

The first limit is the support list, and it is a hard boundary rather than a soft one. A dozen model and firmware combinations are supported, and the documentation says twice not to force it. A camera from a different year, on a different chip, is not addressed by this project, and the pointer to the sibling projects for other platforms is the answer rather than a workaround.

The second is that this is firmware for somebody else's hardware, on somebody else's update path, and the update mechanism is itself part of the firmware. The online firmware upgrade feature, the manual upgrade procedure and the separate wiki for the manual route are all signs of a project that has had to handle the case where the upgrade does not go well, which is the normal case for a device with a small amount of memory and a card-based root filesystem.

The third is the risk of the procedure itself. The camera has to be rooted, the firmware is replaced from an SD card, and the documentation's own warnings about bricking, about taking an hour, about the camera rebooting several times in the middle, are a fair description of the experience. This is not a firmware flash from a menu; it is an operation on a device with no display and no keyboard, where the only feedback is a light.

The fourth is the upstream dependency. The firmware is a modification of the vendor's, and the vendor's servers are part of the design, since the original app has to be paired first and the cloud features have to be disabled rather than removed. A vendor that ends support for its cloud, or changes the API the camera depends on, can break this firmware in a way the maintainer cannot fully control.

And the fifth is the licence surface, which is more layered than a single MIT file. The firmware itself is MIT licensed, and the project pulls in components through a .gitmodules file, and the camera's own hardware carries the vendor's firmware and drivers. A project that ships a modified operating system for other people's devices is in a different legal position from a project that ships a library, and a team deploying this inside a product would want to look at what is included rather than at the root licence.

Editorial conclusion

yi-hack-Allwinner is worth installing if you own one of the listed Yi cameras and want local control of it, because the firmware removes the cloud dependency and gives you RTSP and ONVIF, which are the two interfaces that every home automation system already speaks, and because the MQTT event feed and the web interface for recorded video turn the camera into something you can script rather than an appliance you configure through a phone app. It is the wrong tool if your camera is not on the list. Before you flash anything, check three things: whether your exact model and firmware version appear in the supported table, because the documentation is emphatic that you should not try to use a firmware on an unlisted model and not to try to force the loading by renaming files, and the file prefix in the table is what tells you which archive to download; that you make a backup first, since the documentation says it is not easy to brick the camera but it can happen, and it points at a procedure for dumping your backup firmware from the SD card; and that you understand the hardware limits, because the project states plainly that the camera's performance is not good and that low RAM is the bigger problem, and it warns that enabling all the services may cause problems and that enabling snapshots may cause frequent reboots, so the swap file on the SD card should be turned on even at the cost of card space.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. roleoroleo/yi-hack-Allwinner on GitHub