Bifrost: a cross-platform Samsung firmware downloader in Kotlin

What it does, and what it is a port of

Bifrost is described in the README as yet another firmware downloader for Samsung devices, but it has some special features, and the first of them is that it is cross-platform. Bifrost runs on Windows, Linux, macOS, and even Android. It is also a graphical program, with a shared UI across all supported platforms.

The functional basis is stated plainly: most of the functionality in Bifrost is based on Samloader, and the Python code has been converted to Kotlin and tweaked to take advantage of some of Kotlin's features. So this is a port with a UI, not a new protocol implementation. The upstream is a Python tool and the name of the author of that tool, nlscc, is in the link.

The stack explains the shared UI. Bifrost uses Jetpack Compose, JetBrains Compose for Desktop, and Kotlin Multiplatform to create a shared codebase for all supported platforms. The repository tree shows how that splits: common/ holds the shared code, with desktop/ for the desktop target, android/ for Android, iosApp/ for iOS, and libs/ for the vendored dependencies including the Samloader port. The Gradle build has a build.gradle.kts at the root, a settings.gradle.kts, gradle.properties and the wrapper scripts.

The primary language is Kotlin, the licence is MIT, and the default branch is master. The repository is not archived and the last push was on 2026-09-26, with releases 2.1.4 in August 2026, 2.1.3 in July and 2.1.2 in May.

The notices section is worth a line too, because it tells you where the real work came from. It thanks VanVuong41429 for contributing so many TACs, the Samsung carrier codes, and henr1kas for the download method that does not require IMEIs. That second credit is the interesting one, and it points at the part of the problem that is genuinely difficult.

CSC, the region problem, and why your firmware download fails

The FAQ in the README is where this project explains itself, and the CSC material is the heart of it.

Samsung firmware is not one file. It is regional, and the region is identified by a code called a CSC, a carrier services code, and the README explains how to read it off the device. Open the Settings app, scroll down to About phone or About tablet and tap it, tap Software information, scroll down to Service provider software version, and you will see something like "XAA/XAA,XAA/XAU/TMB" or "XAR/XAR/" on the second line. The first three letters are your current CSC, and the last three letters are the original or firmware CSC of your device. With the examples given, the first has a current CSC of XAA and a firmware CSC of TMB, and the second has a current CSC of XAR and a firmware CSC of XAR.

So a device sold in one region can carry a firmware identifier from another, and asking Samsung for the wrong combination produces an error rather than a file. The CSC picker dialog, reachable through the button that looks like a list inside the Region text field, lets you search for your country or region and see the different CSCs used, and if there are specific carriers associated with a CSC, those are shown as well.

The error handling is where the README is most candid, and it is worth reading before you file a bug. When Bifrost returns error 400 or 401 when downloading, these errors are on Samsung's end, and the advice is to try using a different region or CSC. When Bifrost returns error 403 when checking for updates, these errors are on Samsung's end too, and Samsung may no longer be serving firmware for your device or may not have started serving firmware yet, so the advice is to try a different region or CSC and check that the model number is correct. And the first FAQ entry is the one that saves you the most time: Bifrost cannot download watch firmware, because Samsung does not serve the full firmware files for watches.

The download speed FAQ is the other practical one. Samsung's servers sometimes throttle downloads to about 3MiB/s, and for older devices you may see even slower speeds, and different regions or CSCs may have faster downloads. So the region choice has a performance consequence as well as an availability one, which is not obvious before you have tried a few.

The false positive, and the two distributions

There is a README section devoted entirely to an antivirus false positive, and it is unusual enough to be worth quoting at length.

Certain antivirus programs may flag Bifrost as malware, and the README says this is, hopefully obviously, a false positive. There is a trojan horse malware family named Bifrost, which is part of the greater Bifrose family, and antivirus programs flagging Bifrost, the app, seem to be doing it solely based on this app having the same name as the malware. The malware only affects Windows systems and has limited functionality after Windows XP, with a link to the Wikipedia article for more information. The app does not contain malware, and the README points out that you can verify this by browsing through the source code or by compiling it yourself.

That last sentence is the real answer to the false positive, and it is also the strongest argument for the project being a good citizen: the source is readable, the build is reproducible, and anyone suspicious can check.

The distributions follow from that. For Windows, macOS and Linux, you can download from bifrost.zwander.dev, and for macOS and Linux you can also install using Homebrew:

brew install --cask bifrost

Alternatively, the README points at the Releases page on the SamloaderKotlin repository for binaries, which is a detail that catches people out, since the project in question is zacharee/Bifrost while the releases live in the SamplerKotlin repository.

For iOS, or to use the iOS version on macOS, the README points at a TestFlight sign-up, with the note that this version may not receive the same frequency of updates as the rest.

The project also has its own funding route, a PayPal donation link, and a crowdin.yml at the repository root, so the interface is translated through Crowdin.

Building it: Conveyor, Gradle and two target families

The build section is the most technical part of the README, and it describes a two-stage process.

The preparation is short: make sure you have the latest Android Studio Canary installed, clone the project into Android Studio and let it import. The Canary requirement is a signal, since a Compose Multiplatform project that targets desktop and mobile in one codebase pulls in bleeding-edge Kotlin and Compose plugin versions.

For desktop builds, Bifrost makes use of Conveyor to create binaries for different desktop platforms, and the README notes that Conveyor can build for Windows and Linux from any host OS, but macOS is required to build for macOS. The steps are to download and install Conveyor, open a terminal in the project root, and then run one of eight conveyor commands depending on the target. The pattern is consistent: `conveyor -Kapp.machines=<target> make <format>`, with the formats being windows-zip, debian-package, linux-tarball and unnotarized-mac-zip, and the machines being windows.amd64, windows.arm64, linux.amd64, linux.arm64, mac.amd64 and mac.arm64. The binaries end up in the output folder in the project root.

The macOS target deserves a note because the format name says what it means. The commands produce an unnotarized-mac-zip, which is fine for your own machine and not something you would hand to another user on a stock macOS, because Gatekeeper will object to an unnotarised build.

There is also a plain Gradle route for a debug binary, running the `:desktop:run` task:

./gradlew :desktop:run

For Android, the command line path is to open the Terminal view in Android Studio, enter `gradlew :android:build` on Windows or `./gradlew :android:build` on macOS and Linux, and then take the APK from `android/build/outputs/apk/debug`, where it is called android-debug.apk. A GUI path through the Gradle view is also described.

So the build system is Gradle for the code and Conveyor for the desktop distribution, and the reason for Conveyor is that a single Kotlin Multiplatform codebase has to produce a signed, packaged binary for six machine targets, which Gradle alone does not shape the way the project wanted.

Platform support, fonts on Linux, and where Bifrost stops

The compatibility table is a grid of platforms against architectures, and it is worth reading because it is precise where most projects are vague.

Windows and macOS support x86_64 and ARM64 but not x86 or ARMv7. Android supports all four architectures, which makes sense for a mobile target and means Bifrost on a phone can run on essentially any current handset. Debian-based and generic Linux support x86_64 and ARM64. iOS supports ARM64 only, which is the normal state of the world for iOS.

The x86 row being empty everywhere except Android is a real constraint. A 32-bit x86 Linux machine, which is exactly the kind of machine you might find as a cheap lab server, is not a target. That is a decision about the Compose toolchain and the native libraries it pulls in rather than about the firmware download logic, but it is still a decision the user absorbs.

The Linux note is the one that will bite a user. Make sure you have at least one of the following font families from each category installed: Noto Sans or DejaVu Sans for sans serif, Noto Serif, DejaVu Serif or Times New Roman for serif, Noto Sans Mono or DejaVu Sans Mono for monospace, and Comic Sans MS for cursive. Compose draws text with system fonts, and a machine with none of these installed will render a desktop application with missing or substituted glyphs.

The limit on the functionality itself is the watch firmware, which Samsung does not serve in full and therefore Bifrost cannot download. Beyond that, the errors that users actually hit are 400, 401 and 403 responses from Samsung, and all three are documented as server-side problems with the region as the lever.

There is one more platform-level failure worth knowing. If Bifrost opens to a blank screen on Windows, on certain GPUs Jetpack Compose and Skia has trouble rendering, and the advice is to try running the program as an administrator, and if you have switchable graphics, to try using a different GPU. That is a rendering bug in the UI toolkit rather than in the downloader, but it is the failure a user sees first, before they have done anything with the application at all.

Editorial conclusion

Adopt Bifrost if you need to reflash or repair a Samsung device and want a graphical tool that works the same on every desktop platform, rather than the Python original you would have to install and run. Do not adopt it for devices where Samsung does not publish firmware, notably watches, or if you need a signed, notarised macOS build, since the release artefact is an unnotarized zip. Verify first that your model and region combination is served by Samsung, that your CSC matches what the device reports, and that your machine meets the font requirements on Linux, because Compose needs the system fonts installed to render text.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. zacharee/Bifrost on GitHub