wor-flasher puts Windows 10 and 11 on a Raspberry Pi SD card from Linux

Why writing Windows to an SD card needs its own tool

Installing Windows on Raspberry Pi is not the same exercise as installing Windows on a PC, because the hardware is not the same and the images are not distributed the way PC images are. The project's own framing is a timeline of difficulty: in 2020 it was described as flat out impossible, in 2021 it required following a complicated tutorial, and now the script makes it a piece of cake. That framing is a bit of a sales pitch, but the underlying problem is real. Windows on ARM for the Pi has no general purpose installer image, so the operating system has to be assembled from the component packages Microsoft publishes for Windows updates. The tool does that assembly. It targets the Raspberry Pi 4 and 400 and the earlier Pi 2 rev 1.2, Pi 3 and CM3, and the supported host is any Debian based Linux on either ARM or x86, though it has only been tested to run correctly on Raspberry Pi OS. The audience is therefore a Linux user, often one with an x86 laptop, who wants to put Windows onto a Pi SD card without a second Windows machine.

Legality rests on packages fetched from Microsoft servers

The project is emphatic that the tool is legal, and the mechanism behind that claim is specific rather than rhetorical. All proprietary Windows components are downloaded straight from Microsoft's update servers using uupdump. No Windows image is bundled in the repository, so there is nothing in the tool that could be an unlicensed copy. The project points to a Raspberry Pi Forums debate in which Raspberry Pi employees confirm that the Windows on Raspberry approach is legal, and notes that the resulting OS is unlicenced in the same way a regular Windows ISO is, meaning it can be activated with an activation key or by logging in with a pre-licensed Microsoft account. That distinction between an unlicensed but legitimate image and a licensed one is the one to hold on to. It also means the tool cannot rescue you from licensing: it produces an installable Windows, and activation remains a separate step you supply.

Two entry points, one script that does the real work

The repository contains two scripts and a short set of supporting files. Downloading it is a plain clone:

git clone https://github.com/Botspot/wor-flasher

That creates a directory named wor-flasher, and you need no manual dependency step, because running the script installs the packages it needs: yad, aria2, cabextract, wimtools, chntpw, genisoimage, exfat-fuse, exfat-utils and wget. The graphical path launches install-wor-gui.sh, which presents dialogs and then runs install-wor.sh in a terminal window, and the terminal path runs install-wor.sh directly with a set of numbered prompts:

~/wor-flasher/install-wor.sh

The documentation is explicit about the division of labour: the gui script is just a front end that launches dialog windows and finally runs install-wor.sh in a terminal, while install-wor.sh is what actually does the flashing. That matters for automation, since the script is also designed to be called from inside larger bash scripts, and for auditing, since one script carries the real behaviour. The repository layout is minimal: install-wor.sh, install-wor-gui.sh, a README, some images and a config_txt_tips file, with no package manifest and no build step. The terminal walkthrough in the documentation shows the prompts you will meet: a Windows version choice of Windows 11, Windows 10 or Custom, a language, a Raspberry Pi model, a device from a list of available devices, and an installation mode.

Choosing a target device correctly is the one step that destroys data

The device selection step has size rules that decide what you can build, and reading them before plugging anything in is the difference between a recovery disk and a wiped drive. A storage device larger than 25GB is capable of installing Windows to itself, meaning the resulting drive boots Windows. A device smaller than 25GB but larger than 7GB can only install Windows on other drives greater than 16GB, which is the recovery or reset disk case. A device smaller than 7GB is too small to be usable. The walkthrough shows the same idea in the terminal output, with an installation drive option of minimum 25GB and a recovery drive option of minimum 7GB. The script then prints the configuration it will use, including the download directory, run mode, the Raspberry Pi model number, the device path, the UUID of the target, and the Windows language, before it formats the device, generates partitions and generates filesystems. The author also states plainly that Botspot cannot be held responsible for data loss, which is a fair warning given the script formats whatever device you point it at.

What the flashing step actually downloads and builds

The terminal output ends with a summary of the work: the script generates a Windows image legally, downloads all necessary drivers, the BIOS, the bootloader and a modified kernel, and once finished it ejects the drive. The download step is the slow part, since it pulls individual files from Microsoft and compresses them, and the documentation notes that the first run can take a long time. The mitigation is caching: subsequent runs can skip the lengthy image generating step if the ISO file already exists. So the practical sequence is a first long run and then faster repeats. The default download location shown in the walkthrough is a directory called wor-flasher-files under the home directory of the user running it. The tool also has an environment variable interface for automation and customization, which is the route to use if you are wrapping the flashing step in your own script rather than clicking through dialogs.

The Raspberry Pi hardware limits are documented rather than solved

Several constraints are stated plainly and they are the real reasons to think twice. WiFi does not currently work, because the necessary drivers simply do not exist yet, with a linked driver status page for the current position. On a Raspberry Pi 4 the available RAM is limited to 3GB, and the project links a documented workaround that is not the default. Raspberry Pi 5 support has arrived and it runs fast, but there are no drivers for it, so SD card boot seems more reliable and internet access needs a USB to Ethernet adapter. Separately, the tool cannot debloat the OS: performance is about the same either way, but extra preinstalled apps have to be removed by hand if you want them gone. This is the practical difference between running Windows on ARM and running it on a PC, and the hardware list in the walkthrough only covers the Pi 4 and 400 as the current generation option.

Maintenance and licensing are the weak points of this repository

The project asks for a maintainer in large letters at the top of the project documentation. The reason given is direct: the author does not use wor-flasher personally and does not have the time to maintain it, and anyone who can read and understand the script is invited to ask for write privileges. Everyone is encouraged to use the BVM project going forward. That recommendation from the author is worth taking seriously if your plan involves a device you intend to keep running, because it tells you where the author's attention is going. The last push to the repository was on 2026-06-16 and the repository is not archived, so the code is present and readable, but there are no GitHub releases to pin to, which means you are tracking a branch. The licence field is empty as well, and there is no licence file among the top level entries, so if you need to redistribute the script or its output in a commercial context, there is no stated permission to rely on. On the positive side, the dependencies are named and they are all standard Debian packages.

Editorial conclusion

Use wor-flasher if you already have a Linux machine and a spare SD card and you need Windows on ARM without following a long manual tutorial, especially for a Pi 4 or Pi 5 where the drivers are the sticking point. Do not start a new long lived deployment on it: the author states they do not use it personally and are asking for a maintainer, the last push was on 2026-06-16, the repository declares no licence, and the WiFi gap is documented as unsolved. Before you run it, read install-wor.sh end to end, back up anything on the target device, and decide whether the BVM project suits you better for anything you intend to maintain.

Frequently asked questions

Official sources

1. Botspot/wor-flasher on GitHub
2. Issues
3. README