Trust & safety

This page exists because the app triggers a few things worth explaining honestly: an “Unknown publisher” warning from Windows, and a couple of small extra helper programs (ooz.exe, texconv.exe) sitting alongside the main program. Here’s exactly what’s going on with all of it, and what the app actually does on your machine.

  1. Why Windows warns about it
  2. What the app actually touches on your PC
  3. The VFS model cache
  4. Encrypted aircraft
  5. Does it phone home?
  6. What is ooz.exe?
  7. What is texconv.exe?
  8. About the source code

Why Windows warns about it

The toolkit isn’t code-signed, so Windows SmartScreen will flag it as coming from an “Unknown publisher” the first time you run it. That’s not a statement about what the app does, it’s purely about the certificate.

Code-signing certificates that actually clear SmartScreen (EV certificates) cost real money every year and are aimed at commercial software. This is a free hobby project built and maintained by one person, so it isn’t signed. That’s the whole story, there’s no functional difference between a signed and unsigned build of the same code.

If you’d rather verify the download yourself before running it, every release has a published SHA-256 hash (see Verifying a download below). Check it against what you downloaded and you know you have exactly the file that was published, byte for byte.

What the app actually touches on your PC

  • Your installed aircraft: read-only. The toolkit reads a base aircraft’s files to find its textures and registration data; it never writes into a base aircraft’s own folders.
  • Your project folder: the only place it writes: your chosen workspace (loose PNG artwork + project file) and your chosen output/deployment folder.

  • The official MSFS SDK tools already on your machine: compiling a livery hands your artwork to Microsoft’s own fspackagetool.exe (installed with the SDK via the sim’s Dev Mode) and the community MSFSLayoutGenerator tool. The toolkit doesn’t do its own custom compiling: it drives the same official tools you’d otherwise run by hand, and that briefly opens and closes Microsoft Flight Simulator itself, the same way those tools always have.

  • The app’s own data folder (%LOCALAPPDATA%\MsfsLiveryToolkit): its settings, session logs and the VFS model cache described below.
  • Your sticker library folder, if you use Texture painting: by default Documents\MSFS Livery Toolkit\Stickers, or wherever you set it in Settings. The app writes there only when you add, move, rename or delete images in the library, and only inside that folder. Your painted layers are kept in your project’s own workspace folder, with the rest of your artwork.

Nothing outside those five areas.

The VFS model cache

Stock and marketplace aircraft are read through the simulator’s Virtual File System (VFS), which is only there while the simulator is running. So that you can still see these aircraft in 3D with the simulator closed, the app can keep a cache of the 3D models it has already shown. It asks before turning this on, and you can change your answer in Settings at any time.

  • It holds the app’s own processed models, not the aircraft’s files. What is stored is the geometry the app built for its own 3D view, in the app’s own format. No textures, and no copy of any file from the aircraft. No simulator or other tool can load it.
  • Protected aircraft are never cached. Nothing from an aircraft the simulator protects is ever written to it.
  • Where it lives: %LOCALAPPDATA%\MsfsLiveryToolkit\ModelCache by default. You can move it and set a size limit in Settings; the least recently used aircraft are dropped first when it is full.
  • Mesh livery data is the one exception to asking first: to build a mesh livery for a stock or marketplace aircraft with the simulator closed, the app always keeps the few details of the aircraft’s model that the build needs, in %LOCALAPPDATA%\MsfsLiveryToolkit\MeshBaseData, even with the cache turned off. It is only kept for aircraft you have opened a mesh livery for, and the same rules apply: the app’s own format, never a file from the aircraft, never a protected aircraft.
  • How to clear it: Clear cache… in the VFS model cache section of Settings deletes both. Deleting the folders by hand is also safe.

Encrypted aircraft

Some aircraft are partly protected by the simulator (often called encrypted aircraft): their configuration files and highest-detail 3D models can’t be read. The Livery Toolkit never decrypts, bypasses or reverse engineers protected files. It reads only the files the simulator itself leaves readable, such as textures and livery and texture configuration files, the same files any livery artist works from. That is why some features, like 3D previews and UV maps, aren’t available for these aircraft.

In the app, these aircraft carry a padlock on their VFS tag and are described as protected by the simulator, and any feature that would need a protected file is greyed out with a padlock beside it rather than attempted. Supported aircraft lists exactly what works for them.

Does it phone home?

Only to check for updates. Once a day, when the app starts, it reads the public list of releases from the toolkit’s GitHub page, the same list anyone sees at github.com/theflaknine/MSFS-Livery-Toolkit/releases, to tell you when a newer version is out. That request carries nothing about you, your computer or your projects: no account, no ID, no app version, no usage data. GitHub sees the request come from your internet address, as it would for any web page. To turn it off, go to Settings and clear Check for updates when the app starts; the app then makes no network requests at all, unless you select Check for updates yourself.

One other request: when you open What’s new or the Donate window, the app reads the donation figures shown on this site’s home page from the site itself (support.json), so the card in the app matches the home page. That request carries nothing about you either, and it is not covered by the startup switch, because it only happens when you open one of those yourself.

One more, and only when you ask for it: Add from URL… in the Texture Paint sticker library downloads the one image at the link you type, in a single request (a Wikimedia file page link is turned into the address of the file itself). Nothing about you is sent, only the request for that address and the app’s name, and the image is saved into your sticker library. The app makes no other request when you paint.

Nothing else in the app uses the network. Every place that looks like a “link” (the Help button, Donate, the SDK download link, the download buttons in What’s new) is the app asking Windows to open your normal web browser to a page, exactly like clicking a link in a text editor. The app never uploads anything, and collects no telemetry or usage data of any kind.

What is ooz.exe?

Most base-aircraft textures decode with a fully in-app, built-in image decoder and no extra program involved. A minority of newer MSFS aircraft compress their textures with a format the built-in decoder can’t unpack on its own. For that specific case, the app calls a small, separate, open-source helper program: ooz (licensed GPL-3).

A few things worth knowing about it:

  • It’s a genuinely separate program, launched as its own process the same way the app launches the official MSFS SDK tools, it is never linked into or combined with the app’s own code.
  • It only ever touches local files you already have, the base aircraft texture you asked to extract, and the PNG it writes out. No network access, no other purpose.
  • Its complete source code ships inside every release, alongside the license, so you don’t have to trust a compiled binary blindly; you (or anyone) can read exactly what it does, or rebuild it yourself from that source and compare.
  • It’s used narrowly, only when you explicitly choose “Extract from aircraft” on a texture that needs it. Every other feature in the app never touches it.

What is texconv.exe?

MSFS 2020 liveries can optionally be compiled without the MSFS 2020 SDK or simulator installed at all, using a small texture encoder instead of the usual official SDK tool. When that’s turned on in Settings (off by default, or automatic if you don’t have the 2020 SDK installed), the app calls texconv: Microsoft’s own DirectXTex texture converter, MIT licensed, run as a separate process. Same arm’s-length pattern as ooz.exe above.

A few things worth knowing about it:

  • It’s Microsoft’s own official texture-conversion tool, part of the DirectXTex project, used unmodified.
  • It’s off by default. The app compiles through the real MSFS SDK/simulator unless you explicitly turn this on, or the 2020 SDK isn’t installed, in which case it’s the only option since there’s nothing else to compile with.
  • It only ever touches your project’s own texture files: the source artwork you’re compiling and the DDS files it writes out. No network access.
  • A few small Microsoft Visual C++ runtime files ship alongside it so it runs standalone. These are standard, widely distributed system components, not anything specific to this app.

About the source code

The application’s source isn’t public, this is still a small, early hobby project, not something ready for outside contributions yet. What is public and welcomes scrutiny: this documentation, the issue tracker, and every third-party component the app bundles (listed in the in-app About panel, with full license texts in THIRD-PARTY-NOTICES.txt inside every release package). If something here doesn’t add up or you’d like more detail on a specific behavior, please open an issue and I’ll be happy to answer.

This site uses Just the Docs, a documentation theme for Jekyll.