Last working version of TortoiseSVN 1.9.7 for Windows 7.
Download TortoiseSVN-1.9.7.27907-x64-svn-1.9.7.msi (TortoiseSVN)
TortoiseSVN is a Subversion (SVN) client, implemented as a windows shell extension. Which means it's available right where you need it: in the Windows file explorer.
NTFS Alternate Data Streams (ADS) Dumper
ADSDump.exe is forensic tool that dumps all ADS stream for a file. Common streams are Mark‑of‑the‑Web (MoTW) set when you download a file, and the SmartScreen stream.
BTW, Windows SmartScreen (officially called Microsoft Defender SmartScreen) is a cloud-based anti-phishing and anti-malware component included in Windows operating systems.
ADSDump.exe critically identifies suspicious stream names and abnormally long streams for a file. It is used to check if you have possible malware stuffed into a stream. It dumps the stream in text (if it can), with option to force binary and hex format dumps.
Usage: ADSDump.exe [/b] [/h] "<filepath>" Optional Switches: /b Print binary output /h Print hex (0x--) output
If you need business license, email me. Contact as validated today, .
Free for personal use. Businesses require a license. Read the EULA.txt in the zip file.
Download ADSDump.7z
c:>ADSDump testads.txt Stream ::$DATA [Skipping default stream named '' (blank). This blank points to the file contents itself]. Note: Stream format is ':{streamname}:$DATA'. The ':$DATA' represents the raw data contents of this stream. Stream :calc.exe:$DATA Path testads.txt:calc.exe Size 918528 raw bytes Suspicious Indicators: - This is a user-created or unknown common ADS Stream Name - Found on a file type that rarely has legitimate streams - Stream is unusually large (918528 bytes) - Stream appears to contain binary data - Magic header detected: Possible PE executable (MZ header) ...
Find Files with Streams
C:>dir /r Volume in drive C is Win1TSSD Directory of C: 03/23/2026 12:53 AM 7 testads.txt 918,528 testads.txt:calc.exe:$DATA 10 testads.txt:SmartScreen:$DATA 25 testads.txt:Zone.Identifier:$DATA 1 File(s) 7 bytes 0 Dir(s) 182,644,506,624 bytes free
Brief, what is Alternate Data Streams (ADS)
ADS streams, or Alternate Data Streams, are a feature of the NTFS file system that allows files to contain multiple streams of data, enabling the storage of additional information without altering the primary file content. When Windows NT 3.1 was being designed (early 1990s), Microsoft wanted NT to interoperate with Macintosh HFS.
Once the feature existed, Microsoft realized ADS was a powerful general-purpose mechanism to store metadata.
Windows uses ADS for:
Understanding Alternate Data Streams (ADS)
Definition: Alternate Data Streams (ADS) are a file attribute unique to the NTFS file system used by Windows. They allow a single file to have multiple data streams, meaning that in addition to the primary data stream (the main content of the file), there can be additional, non-primary streams associated with that file.
A stream is denoted with : in the following format ':{streamname}:$DATA'.
The ':$DATA' represents the raw data contents of this stream.
The primary data stream is the standard content of a file, has no stream name, and visible to users in Windows Explorer. For example, SOFITUKKER-PickUpThePhone.mp3::$DATA
In contrast, alternate data streams are named streams that are not visible in standard file views, making them useful for storing metadata or other information discreetly. You can open them in Notepad.
Examples are:
SOFITUKKER-PickUpThePhone.mp3::$DATA
SOFITUKKER-PickUpThePhone.mp3:alt.txt:$DATA
SOFITUKKER-PickUpThePhone.mp3:SmartScreen:$DATA
SOFITUKKER-PickUpThePhone.mp3:Zone.Identifier:$DATA
When you download a file from the interwebs, every modern browser (Edge, Chrome, Firefox, etc.) marks the file with a stream called the Mark‑of‑the‑Web (MoTW).
It matters because MoTW tells Windows and apps like Office that a file came from the internet, so extra security checks should apply. This helps protect everyday users from accidentally opening malicious documents that could otherwise run dangerous code without warning.
These values come directly from Windows’ URL Security Zones model.
| ZoneID | Meaning | Typical Source | Security Behavior |
|---|---|---|---|
| 0 | My Computer Zone | Local disk, trusted local paths | Fully trusted, no warnings |
| 1 | Local Intranet Zone | Corporate LAN, internal sites | Medium trust, fewer prompts |
| 2 | Trusted Sites Zone | Sites user/admin marked as trusted | High trust, minimal restrictions |
| 3 | Internet Zone | Files downloaded from the Internet | Triggers MOTW warnings, SmartScreen, blocking |
| 4 | Restricted Sites Zone | Sites explicitly marked restricted | Most restrictive, scripts blocked |
Windows treats the file as local and trusted
No warnings
No Protected View
No SmartScreen prompts
This is why MOTW is such a central mechanism in Windows security.
The Mechanics of the "SmartScreen Stream"
In the NTFS file system, files downloaded from the internet are tagged with a "Zone Identifier."
| Component | Description |
| ZoneId=3 | This is the default "Internet" zone tag that triggers the SmartScreen check. |
| AppZoneId=4 | Often added to signify the file originated from a restricted or untrusted web source. |
| Unblock Attribute | When you click "Run anyway," Windows essentially "unblocks" the file by removing the requirement for a reputation check. |
What Code Signing Actually DoesCode signing is a broad, platform‑agnostic idea:
Uses a digital certificate (X.509)
Signs a cryptographic hash of the file
Proves:
Publisher identity
File integrity (no tampering)
A Windows PE signature absolutely is tied to a cryptographic hash of the file’s contents. When a file is signed:
Windows computes a hash of the file excluding only the signature block itself.
That hash is what the certificate signs.
Any modification to the code section, data section, resources, or most metadata changes the hash → signature becomes invalid.
This is why even editing something as trivial as a comment field in some file types can break the signature.
Authenticode is Microsoft’s specific implementation of code signing for Windows PE files. It defines:
Everything except the WIN_CERTIFICATE block
PE headers, sections, resources, etc.
Stored inside the PE file’s WIN_CERTIFICATE structure
Or in a catalog file for MSI/driver packages
Uses WinVerifyTrust / Wintrust.dll
Chains the certificate to a trusted root
Ensures the file has not changed since signing
EXE, DLL, SYS (drivers), OCX
MSI installers
Catalog-signed packages
SmartScreen reputation
Windows Defender trust decisions
Authenticode is Windows‑specific and follows Microsoft’s rules.
1. Windows SmartScreen ReputationThis is the big one.
The scary blue “Windows protected your PC” SmartScreen warning Once your certificate builds reputation, SmartScreen stops treating your EXE as an unknown threat.
A newly signed EXE still shows SmartScreen warnings at first.
As more users run it without incident, Microsoft’s cloud reputation system improves.
Eventually, SmartScreen shows no warning at all.
It does not bypass antivirus scanning.
It does not guarantee trust if the binary behaves maliciously.
2. “Unknown Publisher” Pop‑upsUnsigned EXEs show:
Publisher: Unknown
Signed EXEs show:
Publisher: Your Company Name
The “Unknown Publisher” label in:
Windows UAC prompts
File Properties → Digital Signatures
Installer dialogs
Some enterprise endpoint tools
This alone dramatically reduces user suspicion.
What Code Signing Does for Chrome/EdgeChrome doesn’t have its own SmartScreen, but it relies on Windows’ SmartScreen for downloaded EXEs.
Chrome’s “This file isn’t commonly downloaded” warning is less likely to appear.
Chrome is less likely to flag the file as “potentially dangerous.”
Chrome hands the file to Windows SmartScreen, which behaves better with a signed binary.
Chrome will still warn if:
The file is extremely new
The file is rare
The file is signed but reputation is zero
The file is detected by antivirus engines
Signing helps, but reputation still has to build.
What Happens When a Signed EXE’s Certificate Expires
1. Already‑signed EXEs continue to runIf the EXE was timestamped at signing time (which almost all proper signing tools do), Windows checks:
Was the certificate valid at the time of signing
Is the timestamp authority trusted
If yes, the signature is still considered valid, even after expiration.
The EXE still shows Publisher: Your Company Name
The signature still verifies
SmartScreen reputation is preserved
This is why timestamping is essential.
2. If the EXE was not timestampedThis is where things go downhill.
Windows treats the signature as invalid because the certificate is now expired.
Signature shows as invalid
Windows UAC shows Unknown Publisher
SmartScreen treats it like an unsigned file
Chrome may warn that the file is “not commonly downloaded”
AV heuristics may become more aggressive
In other words, it behaves almost exactly like an unsigned EXE.
How Windows Behaves with an Expired Certificate
Signature still valid
Publisher name still shown
SmartScreen reputation preserved
No scary warnings
Enterprise policies still trust it
Signature invalid
“Unknown Publisher”
SmartScreen warning returns
Reputation lost
Users get the big blue “Windows protected your PC” screen
How Edge/Chrome BehavesChrome relies on Windows SmartScreen for downloaded EXEs.
Chrome treats it like a valid signed file
Fewer warnings
Better trust score
Chrome treats it like an unsigned file
“This file isn’t commonly downloaded” becomes more likely
SmartScreen may block it outright
What Expiration Does Not DoAn expired certificate does not:
Break the EXE
Prevent it from running
Remove the signature from existing files
Cause antivirus to automatically flag it
The only real impact is trust and reputation, not functionality.
The Key Rule to RememberIf you don’t, expiration resets you to “Unknown Publisher.”**
Timestamping is the difference between a smooth user experience and a flood of support tickets.
A Windows EXE signed with Azure Trusted Signing will continue to run after the 3–4‑day certificate expires, as long as the signature was valid at the time of signing and the timestamp is valid. Windows does not block expired signatures — it only blocks signatures that were never valid or have been revoked.
What effect does recent Windows 11 Update to change certificate validation have? 1. Affected Update: KB5050021Multiple reports show that KB5050021 introduced a change in how Windows validates certificate chains. After installing it, Windows began treating some certificates as explicitly revoked, even though the developers insist they were not.
Example: The popular tool Everything (Voidtools) stopped launching because Windows claimed its certificate—signed Jan 1, 2025—was revoked.
Rolling back the update restored functionality.
This strongly suggests the update tightened or altered the certificate trust logic rather than the certificates actually being revoked by DigiCert.
2. Why Windows Would Do ThisWindows 11 has been steadily increasing enforcement around digital signatures for security reasons:
Windows 11’s UAC blocks elevation for executables signed with revoked or untrusted certificates. If an update changes the trust store or revocation list, UAC will immediately start blocking affected apps.
Microsoft has been preparing for major certificate expirations (e.g., Secure Boot certificates expiring in 2026). This has led to more aggressive validation and cleanup of older or misconfigured certificate chains.
Windows 11 refuses to load drivers or executables if:
The certificate is expired
The certificate is revoked
The certificate chain is incomplete or mismatched
When an update modifies the trusted root store or revocation lists, legitimate software can get caught in the crossfire.
3. Why It Looked Like “Revoked Signature Updates”The key issue is not that Microsoft intentionally revoked developer certificates. Instead, the update caused Windows to treat certain certificates as revoked because:
The DigiCert Trusted Root G4 chain was broken or reinterpreted
Revocation lists (CRLs/OCSP) were updated or misapplied
Windows tightened chain validation logic
Some intermediate certificates were removed or replaced
This created a false‑positive revocation scenario.
4. How Users Confirmed the IssuePeople who restored a disk image before KB5050021 found everything worked normally. After reinstalling the update, the certificate errors returned.
This strongly indicates the update—not the certificates—was the trigger.
5. What You Can Do (Safely)Here are the practical, non‑risky steps:
A. Check if the affected software has released a new buildDevelopers often re‑sign their binaries with a different certificate chain.
B. Temporarily uninstall KB5050021If the issue is blocking critical tools, rolling back the update restores functionality.
C. Wait for Microsoft to patch the trust storeThese certificate‑chain regressions are usually corrected in the next cumulative update.
D. Avoid disabling signature enforcementWhile possible, it’s not recommended for system security.
If you want, I can walk you through diagnosing a specific executable or certificate chain on your system—just tell me the file or the error code you’re seeing.
For Driver & Executable Signature Enforcement in Win11, will custom exes which are signed by Azure Trusted Signing and lasts 3-4 days, will it not run after 5 days ?Here’s the clear, practical answer you need — and the part most people misunderstand:
A Windows EXE signed with Azure Trusted Signing will continue to run after the 3–4‑day certificate expires, as long as the signature was valid at the time of signing and the timestamp is valid. Windows does not block expired signatures — it only blocks signatures that were never valid or have been revoked.
Let’s break this down precisely.
Will your Azure‑signed EXE stop running after 4 days?Azure Trusted Signing uses short‑lived signing certificates (typically 3–4 days), but this does not limit how long the signed executable can run.
What matters is:
The EXE must be timestamped at signing time.When you sign with Azure Trusted Signing, the signing process automatically includes a trusted timestamp.
Windows checks the timestamp, not the certificate’s current validity.If the certificate was valid at the moment of signing, Windows treats the signature as valid forever — even after the certificate expires.
The EXE only fails if the certificate is revoked, not if it expires.Expiration ≠ revocation. Revocation is rare and only happens if Microsoft/DigiCert explicitly pulls the certificate (e.g., malware abuse cases).
Why Azure uses short‑lived certificatesAzure Trusted Signing intentionally issues short‑lived certificates (3–4 days) to reduce the risk of certificate theft. This is normal and expected. Developers do not need to rebuild binaries every few days.
Important: What would break your EXE?Your EXE will only fail to run if:
1. You sign without a timestampThen Windows requires the certificate to still be valid. After 4 days, the signature becomes invalid.
2. The certificate is explicitly revokedThis is extremely rare but can happen if a certificate is abused for malware. Microsoft has revoked short‑lived certificates in such cases.
3. A Windows update breaks trust chain validationThis has happened recently with certain DigiCert chains, causing false “revoked” errors.
Practical example for your caseYou sign your EXE on March 16 with Azure Trusted Signing.
Certificate expires on March 20
Timestamp says: “Signed on March 16 with a valid certificate”
Windows sees the timestamp and accepts the signature forever
Your EXE continues to run in April, May, 2027, etc.
No rebuild needed.
