BSP Fingerprinting Explained: Watermarks for GMod Maps
A BSP fingerprint is a hidden marker inside the map file. It does not prevent copying, but it makes a leaked copy traceable to its origin.
A BSP fingerprint is a hidden, technical marker inside a map file that allows a specific copy to be recognised later. It does not stop anyone from copying the file. It is meant to allow a copy that shows up somewhere to be matched to an origin, ideally to one specific purchase.
Fingerprint, watermark, hash: the differences
The three terms are often mixed up but mean different things.
| Term | What it is | Strength | Weakness |
|---|---|---|---|
| Hash, such as SHA-256 | Checksum over the whole file | proves that two files are exactly identical | changes with even the smallest modification |
| Visible watermark | Logo or lettering in the map | can deter, everyone sees it | can be found and removed |
| Hidden fingerprint | Marker in the data structures of the file | stays inconspicuous and is designed for recognition | does not prevent a copy |
A hash answers the question of whether a file is unchanged. A fingerprint answers the question of which delivery a file descends from, even if it no longer matches the original exactly.
How a fingerprint works inside a map
A BSP consists of many data sections called lumps: geometry, entities, material assignments, embedded files. Those structures contain degrees of freedom that do not matter to the engine: the map looks the same and plays the same although the file is built differently in detail. A fingerprint uses such freedom to carry an identifier.
Two properties make a method dependable:
- Several independent signals. If the evidence relies on different parts of the file, it does not hinge on a single marker. If one signal is damaged, the others can still contribute to the assessment.
- A record outside the file. On its own, the identifier in the map is meaningless. Only a server-side record links it to a protection run or a purchase. That is why no name and no email address has to be in the file.
It makes sense not to publish where exactly a fingerprint sits or how it is encoded. Those details would add no trust, but they would make targeted removal easier.
Proof of origin and buyer-specific copies
A fingerprint can be used on two levels.
Proof of origin: the marked file can be matched to a protection run and therefore to the account that had it protected. That can help when someone presents a map as their own work.
Buyer-specific copies: every delivery receives its own fingerprint. Two buyers of the same map then own technically different files that are indistinguishable in the game. The sequence in a real case:
- A buyer downloads their individually marked copy.
- Later the map shows up somewhere it should not be.
- The author obtains the file and has it checked.
- If the fingerprint can still be read, the check matches the file to the original delivery.
- Any action is decided on that basis.
What a fingerprint does
- Attribution instead of suspicion. The assumption that some buyer passed the map on becomes a concrete technical finding about which delivery the file comes from.
- Deterrence. People who know their copy is marked may think twice before sharing it.
- A basis for action. A verifiable finding supports a block or a takedown request better than a gut feeling.
- Clean versions. Each version of a map can be marked and documented separately.
What a fingerprint does not do
- It does not prevent copying. The file can still be duplicated.
- It does not stop the map from running on someone else's server. Binding the map to a server does that, see Server-Exclusive maps.
- It does not prevent decompiling. Obfuscation targets that, see BSP obfuscation explained.
- A complete rebuild by hand carries no fingerprint.
- Copies delivered before the fingerprint was switched on cannot be matched afterwards.
- A match shows which copy a file descends from. It does not automatically settle who distributed it, because a server or an account may have been compromised.
That last point is why a match should be reviewed rather than punished automatically.
How bspmarket.de implements the fingerprint
In BSP Protection, Fingerprint is a protection level of its own. The hidden fingerprint is spread across several map structures and linked to a server-side origin record. No plaintext contact data is stored in the BSP.
For marketplace products, Creators can additionally enable the buyer fingerprint. Every download then receives an individual fingerprint. If a copy shows up, the Creator uploads the file they found in the "Protection" area. The system reads the buyer fingerprint and matches the file to the original delivery, even if it was modified afterwards. The file is deleted after the check, and its hash is kept as evidence.
Two rules protect both sides. The Creator only sees a pseudonymous reference and the quality of the evidence, never the buyer's identity. Buyer data is visible only to the bspmarket.de team, which reviews the case and decides on any action.
On the protection guide, anyone can also compare a SHA-256 hash against the server record without logging in, to check whether a file is a genuine bspmarket.de output.
A fingerprint is one building block among several. Protect your GMod map from leaks shows how it works together with the others.
FAQ
Does the fingerprint contain personal data?
Not in plain text on bspmarket.de. The BSP holds a technical identifier, and the link to a purchase is made through server-side records.
Do players notice the fingerprint?
No. A fingerprint is not a visible watermark. The map looks and plays the same as before.
Can a fingerprint be removed?
That cannot be ruled out. Methods with several independent signals make targeted removal harder, and the exact positions stay unpublished for that reason.
Is a fingerprint enough to prove a leak?
It is a technical finding that shows which delivery a file descends from. How it should be weighed in an individual case depends on the circumstances. For a legal assessment you need qualified advice.