Update Security Chain

Update Security Chain

An auto-updater is the most powerful thing an app has: whatever it installs runs on your PC with your permissions. Flashback treats it that way. This page explains, step by step, what an update has to prove before Flashback installs it, and what each step protects against. For the short version, see Security.

The short version: every update needs two independent signatures, held by different keys in different places. Flashback also checks the exact hash of the whole package, pins the publisher's identity to Microsoft's root, refuses older releases, re-checks everything at the last moment, and never accepts partial "delta" patches. Neither key alone can ship code to your PC.

The chain at a glance

 flashbk.gg serves:  release-manifest  +  update package  +  publisher catalog
                          |                    |                    |
                          v                    |                    v
  1. Manifest signature   offline key signs:   |      2. Publisher signature
     (ECDSA P-256)        version, feed,       |         Microsoft Artifact Signing
                          package + installer  |         signs a catalog that binds
                          sizes and SHA-256    |         the package's name, size
                          |                    |         and SHA-256
                          v                    v                    v
              3. Package hash must match BOTH the manifest and the catalog
                                      |
              4. Publisher identity pinned, chain must end at Microsoft's
                 identity-verification root; timestamp and revocation checked
                                      |
              5. Not older than the newest release already accepted
                                      |
              6. Re-fetched and re-verified right before handoff,
                 file held so it can't change
                                      |
                                   install

1. The signed release manifest

Every release has a small manifest file listing exactly what that release is: the version, the update feed, the full update package, and the installer, each with its size and SHA-256 hash. It's signed with an ECDSA P-256 key that's kept offline, never on a web server.

Flashback carries the matching public key inside the app. If the manifest's signature doesn't verify, or a downloaded file's size or hash doesn't match what the manifest says, the update is refused.

Protects against: a compromised website, CDN or mirror serving a different file.

2. The publisher signature

Since 0.7.41, Flashback's installer and program files are signed through Microsoft Artifact Signing, Microsoft's code-signing service, which keeps the private key in Microsoft's hardware security modules. Windows shows Flashback's verified publisher when you run the installer.

Flashback adds a second, detached signature from the same publisher over a small package catalog. That catalog binds the exact update package by its filename, size and SHA-256 hash. Because it covers the whole package through one hash, a genuine signed Flashback.exe placed next to a changed DLL still fails: the package's hash no longer matches the catalog.

Flashback checks the program's own Authenticode signature against that same publisher too.

Protects against: someone who got hold of the manifest key alone. They still can't produce the publisher signature.

3. Two locks, two keys

The manifest key and the publisher identity are independent. One is an offline key; the other lives in Microsoft's signing service behind a verified identity. An update needs both, and both must point at the same package hash. That's the core of the design: compromising either one alone isn't enough to ship code to an install.

4. A pinned publisher, not just "any valid signature"

A valid Windows signature from someone isn't enough. Flashback's update check requires all of this:

• The file is signed by exactly the certificate the signed manifest names for that release.
• Windows validates the signature outright.
• The certificate carries the code-signing purpose, Microsoft's public-trust marker, and Flashback's own pinned signing-profile identity.
• The certificate chain ends at Microsoft Identity Verification Root Certificate Authority 2020, which is compiled into the app.

Microsoft's service issues short-lived certificates that renew every day, so pinning one certificate fingerprint wouldn't work. Flashback pins the signing profile's durable identity instead, which every certificate from that profile carries.

Trusted timestamps and revocation

The catalog is countersigned with an RFC 3161 timestamp from Microsoft's timestamping service. Flashback verifies the timestamp, checks that it falls inside the certificate's validity, validates the timestamping authority, then validates the certificate chain as of that time against the pinned root, with an online revocation check. That's what lets a catalog signed with a three-day certificate stay valid for as long as the release is current. The installer and program files are timestamped the same way.

5. Built in, not downloaded

The keys, the pinned identity and the rules are compiled into Flashback. The website can't change what the app trusts, and a release that requires the publisher signature can't quietly fall back to checking the manifest alone.

Changing a key or signer is done with overlap: a release first trusts both the old and new values, then a later release drops the old one. The one exception so far was the move to Microsoft Artifact Signing in 0.7.41, which installs on 0.7.40 or earlier can't follow by themselves; they're asked to run the current installer once. See Installing and Updating.

6. No downgrades

Flashback remembers the newest release manifest it has accepted and refuses an older one, even if that older one is genuinely signed. A compromised website, CDN or mirror can't push you back to an old release with a known bug.

To be honest about the limits: that record lives in your own %LOCALAPPDATA%\Flashback folder, so it protects against the network, not against malware already running on your PC as you. Such malware could already tamper with your files directly; no app-level check can stop that. If the record is ever damaged, Flashback sets it aside, logs it, and accepts the current fully verified release, so a damaged file can't block updates.

Releases only roll forward. A bad release is fixed by shipping a newer one, never by putting an older one back.

7. Whole packages only

Flashback's public updates are always full packages, never "delta" patches. The update framework can rebuild and replace its own updater from a delta before Flashback gets the chance to check the publisher signature, so a signed delta isn't a safe boundary. Full packages are checked completely before anything is applied.

8. Checked again at the last moment

• Downloads resume. An interrupted download keeps its verified partial bytes in %LOCALAPPDATA%\Flashback\Updates and picks up where it stopped, even after a restart. Only a complete file whose size and SHA-256 match is used.
• A full disk is named, not retried in a loop: you get Not enough free space on <drive> with the space needed.
• Right before handoff, Flashback re-fetches the signed manifest and catalog, re-verifies the package, and holds the file open so it can't be swapped while Flashback is still running.
• If the handoff doesn't finish, for example the old version starts again, the next check offers the signed installer instead of downloading the same package in a loop. The installer is checked against the manifest's hash and the pinned publisher before it runs.
• Afterwards, Flashback restarts minimized and shows Flashback updated to <version> in the tray.

9. When you're asked, and when you're not

• Flashback checks once when you open its window, or when you press Check for updates. It never checks while it's only in the tray.
• It never downloads without your click, and never installs without a second click (Restart and update).
• Signatures carry time limits, so a PC clock that's far off fails the check. Flashback tells you to check the date and time instead of failing silently.

What this doesn't cover

• Installers you download yourself are checked by Windows, not by Flashback's updater. Check them with Verifying Downloads.
• Malware already on your PC running as your Windows user can interfere with any app's files. The chain protects updates on their way to you.
• There's no remote kill switch. A bad release is fixed by shipping a newer one.

Related pages

Security · Verifying Downloads · Installing and Updating · Troubleshooting Updates and Install · Architecture Overview