# yi-hack-Allwinner-v2: replacing the firmware on an Allwinner-based Yi camera

> yi-hack-Allwinner-v2 is a modified firmware for the Allwinner-based Yi Camera platform, delivered as a set of files dropped onto a FAT32 SD card, and it adds RTSP and ONVIF servers, MQTT events, an SSH server, PTZ control and the ability to disable the vendor's cloud features. It is MIT licensed, the newest release is 0.3.7 from 2026-09-26, and it supports a fixed list of camera models and firmware versions.

**roleoroleo/yi-hack-Allwinner-v2** — Custom firmware for Yi 1080p camera based on Allwinner platform

- Repository: https://github.com/roleoroleo/yi-hack-Allwinner-v2
- Stars: 1,151 · Forks: 147
- Language: Shell
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/roleoroleo-yi-hack-allwinner-v2

## v2 is a different family, not an upgrade

yi-hack-Allwinner-v2 is a modification of the firmware for the Allwinner-based Yi Camera platform, and the first thing the documentation explains is what the name means.

Allwinner-v2 is not an upgrade for Allwinner, it is a version dedicated to a different family. Same CPU, but a different flash layout.

That is a crucial distinction for anyone who has used the earlier project. The v1 and v2 firmware images are not interchangeable, because the flash layout is what determines where the bootloader and the firmware partitions live, and a v1 image on a v2 camera will not do what the user expects. The project maintains a family of related projects, and the feature set here is described as replicated from yi-hack-MStar and similar to yi-hack-v4, so the naming reflects a family of hardware targets rather than a version history.

The repository structure reflects the same division. There is a `sdhack/` directory, which is presumably the SD card boot payload, a `sysroot/` directory for the target root filesystem, an `unbrick/` directory, `src/` for the build, `scripts/` for the build and packaging automation, and a `VERSION` file at the root. The primary language of the repository is recorded as Shell, which is consistent with a project whose build is a set of scripts assembling a firmware image.

The top-level listing also includes a `.devcontainer/` directory, so the build can run in a container, and a `LICENSE` file with the project under MIT.

## The install is a FAT32 SD card, and the camera does the rest

The installation procedure is unusually simple, and that is the main reason this kind of firmware hack is approachable.

The first step is to make a backup, because it is not easy to brick the camera but it can happen, and the documentation links a wiki page on dumping the backup firmware to the SD card. The hack procedure will also create a backup for you.

Then the card. Format an SD card as FAT32, and the recommendation is to format it in the camera using the camera's native format function. If the card is already formatted, remove all the files. Download the latest release from the releases page, extract the archive to the root of the card, and the card should end up with this structure:

```
|-- Factory/
|-- yi-hack/
|-- lower_half_init.sh
```

The optional step is wifi credentials: rename `Factory/configure_wifi.cfg.ori` to `Factory/configure_wifi.cfg` and edit it with your username and password. That is a nice touch, because it means the camera can join the network on first boot without any interaction.

Then insert the card and reboot the camera, wait a minute for it to update, and check the hack by opening the web interface at the camera's IP address. The last instruction is the one people skip: do not remove the microSD card, and yes, this hack requires a dedicated microSD card.

That last point has a practical consequence. The card is not just an installer, it stays in the camera and is used for the swap file, and the performance notes recommend enabling it. So the card has to be a decent one, and it has to be a card you are willing to leave in the device permanently.

There is also an online update procedure, through the Maintenance web page where you check for a new release and click Upgrade Firmware, and a manual update procedure documented on the wiki.

## What the firmware adds, and the three RTSP streams

The feature list is the reason people do this, and it is a list of standard IP camera features that the stock firmware does not expose.

The RTSP server allows an RTSP stream of the video, high and or low resolution, and audio. The three URLs are `rtsp://IP-CAM/ch0_0.h264` for high resolution, `rtsp://IP-CAM/ch0_1.h264` for low resolution, and `rtsp://IP-CAM/ch0_2.h264` for audio only.

The ONVIF server supports stream, snapshot, ptz, presets, events and WS-Discovery, and the description is that it provides standardized interfaces for IP cameras. That is the single most useful thing in the list for anyone who already runs Home Assistant, Frigate, or a video recording system, because ONVIF is the interoperability standard and the stock Yi app is a closed protocol.

The snapshot service allows a JPEG with a web request, either `http://IP-CAM/cgi-bin/snapshot.sh?res=low&watermark=yes` to select resolution and whether to watermark, or the same URL with no parameters for the default high resolution without a watermark.

Then the parts that make the device behave like a normal IP camera. There is an SSH server using dropbear and a Telnet server using busybox, an FTP server, and FTP push to export MP4 video to an FTP server. Authentication is supported for HTTP, RTSP and ONVIF. There is a web configuration interface, a web page for managing motion detect events and videos, a web page for viewing recorded video, and PTZ support and PTZ presets through a web page if the camera supports it. Configuration can be loaded, saved and reset.

Two features are about removing the vendor rather than adding to the camera. The possibility to disable all the cloud features is there, and Proxychains-ng is included, disabled by default, described as useful if the camera is region locked.

The list also includes settings that the official app exposes, copied over into the web interface: camera on and off, video saving mode, detection sensitivity, motion detections, baby crying detection, status LED, IR LED and rotate.

## MQTT events, timelapse and the performance ceiling

The MQTT integration is the feature that pushes this beyond a media server, and it comes with three separate pieces.

MQTT events covers motion detection and baby crying detection through the MQTT protocol, so the camera can push events to your home automation system instead of you polling it. MQTT configuration lets you set the broker details, and TLS support for MQTT means the broker connection can be encrypted.

The timelapse feature is listed separately, and swap file on the SD is listed as its own item.

Then the performance section, which is where the honesty is. The performance of the camera is not so good, on CPU, RAM and so on, and low RAM is the bigger problem. If you enable all the services you may have some problems, and the example given is that enabling snapshots may cause frequent reboots. The instruction is therefore to enable the swap file even if this will waste the SD.

That is a real constraint on the feature set, and it is the kind of thing that only shows up after you have enabled everything. The device is a small embedded system with a camera and a network stack, and turning on an RTSP server, an ONVIF server, MQTT with TLS, SSH, FTP, a web interface and snapshot encoding at the same time is a lot of processes in a few hundred megabytes of RAM. The swap file recommendation is the mitigation, and the cost of it is SD card wear.

The optional utilities are in a separate repository, yi-hack-utils, and the documentation notes that some of them support experimental features like text to speech.

## Support is a table of serial prefixes, firmware versions and file prefixes

The supported cameras table is the most important document for anyone deciding whether this applies to them, and it has four columns that all matter.

The camera model, the SN prefix, the firmware version, and the file prefix. The Yi 1080p Home appears in several rows with different SN prefixes, so the serial number prefix distinguishes between units that share a model name. The firmware column lists specific versions such as 9.0.19, 12.1.19, 9.0.36, 12.0.37, 12.1.37, 9.0.35 and 12.0.35. The file prefix column, `y21ga`, `y211ga`, `y291ga`, `h30ga`, `r30gb`, `h52ga`, `h51ga`, `h60ga`, `r40ga`, `y29ga`, `r35gb`, is the prefix of the file on the camera that identifies the hardware variant.

Three rows carry a remark that says beta version, with a link to an issue, and those are the Yi 1080p Dome with the `*FUS` serial prefix and the Yi Dome Guard with the `YRS` prefix. The `*` in `*FUS` is doing real work: it means any prefix ending in FUS.

So the check for a given camera is three-way. If your serial number prefix is not in the table, it is not supported. If the firmware version is not in the table, the flash layout may differ and the hack will not apply. And the file prefix on the card has to match the one in the table, which is why the release archive contains a directory structure that must be laid out correctly on the card.

The release history shows the project is still being worked on, with 0.3.6 from 2026-05-16, 0.3.6-2b904a0 from 2026-08-03 and 0.3.7 from 2026-09-26, and the last push on 2026-09-26.

## The integrations, and the two things that can go wrong

The project lists Home Assistant integration and Frigate integration as their own sections in the table of contents, which is the clearest signal of the audience. This is firmware for people who have already decided to run their own camera stack rather than the vendor's app, and the two integrations named are the most common self-hosted options.

The first thing that can go wrong is bricking, and the project addresses it head-on with a dedicated unbrick directory in the repository and a wiki page for the backup procedure, plus a note that the hack procedure creates a backup for you. Recovering a camera with a custom firmware is much easier when you have the original image.

The second is the flash layout mismatch, and that is what the v1 versus v2 explanation in the readme is defending against. The same CPU does not mean the same layout, and a wrong family image is the failure mode that produces a camera that does nothing.

There is a disclaimer section in the table of contents, which for a firmware modification project is a sensible thing to have, and a donation section.

The building your own firmware section is also in the table of contents, alongside a `sysroot/` directory and a `scripts/` directory, so the build is reproducible from the repository rather than being a black box that produces a binary release. That is the part of this project that is most reusable: a team that wanted to do the same thing for a different Yi model would start from the build scripts and the sysroot rather than from a finished image, and the project structure is set up for exactly that.

## Conclusion

The firmware fits an owner of a supported Yi camera who wants local control, standard IP camera interfaces instead of a vendor app, and the option to turn off cloud features. It does not fit an unsupported model, since the supported list is explicit and includes serial number prefixes, firmware versions and file prefixes, and the Dome variants are still marked beta. Before you flash it, make the backup the documentation asks for, because the project says the camera can be bricked, and check the performance notes, since low RAM is called out as the bigger problem and enabling all the services can cause frequent reboots.

## FAQ

### How do I install yi-hack-Allwinner-v2 on a Yi camera?

Format an SD card as FAT32, preferably using the camera's own format function, extract the latest release archive to the root of the card so it contains `Factory/`, `yi-hack/` and `lower_half_init.sh`, optionally rename and edit `Factory/configure_wifi.cfg.ori` for wifi credentials, then insert the card and reboot the camera. The card must stay in the camera afterwards.

### Which Yi cameras does yi-hack-Allwinner-v2 support?

The project lists each supported model with its serial number prefix, firmware version and file prefix, covering Yi 1080p Home, Outdoor 1080p, 1080p Dome, Dome Guard, Dome Camera U, Dome U Pro 2K, Home Y4 and others. The Dome variants with the `*FUS` and `YRS` serial prefixes are marked beta.

### What does the Allwinner v2 firmware add to a Yi camera?

An RTSP server with high, low and audio-only streams, an ONVIF server with stream, snapshot, ptz, presets, events and WS-Discovery, a snapshot service over HTTP, MQTT events for motion and baby crying detection with TLS, SSH, Telnet, FTP and FTP push, PTZ control through a web page, and the ability to disable all cloud features.

### Is the difference between yi-hack v1 and v2 an upgrade?

No. Allwinner-v2 is not an upgrade for Allwinner, it is a version dedicated to a different family, with the same CPU but a different flash layout, so the firmware images are not interchangeable between the two families.

## Sources

- [Issues](https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues)
- [License: MIT](https://github.com/roleoroleo/yi-hack-Allwinner-v2/blob/master/LICENSE)
- [README](https://github.com/roleoroleo/yi-hack-Allwinner-v2/blob/master/README.md)
- [Releases](https://github.com/roleoroleo/yi-hack-Allwinner-v2/releases)
- [roleoroleo/yi-hack-Allwinner-v2 on GitHub](https://github.com/roleoroleo/yi-hack-Allwinner-v2)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/roleoroleo-yi-hack-allwinner-v2