To give a little technical perspective:
A protected map is roughly defined as a map that staredit/popular editors are unable to open.
However protection isn't achived by encryption or adding a password or anything, it's the result of the map editors not having loading procedures as complete as StarCraft's (one could go as far to say it exists because the editors were coded poorly).
All scenario files are structured in the following, exceedingly simple way:
4 byte section title
4 byte section size
(section size) bytes of data
4 byte section title
4 byte section size
(section size) bytes of data
... more sections ...
(possibly an incomplete section).
Protection as it applies to Staredit and SCMDraft is achived in the following ways:
1.) Split sections/section stacing: sections are split by the protector such that starcraft compiles them back into the original section.
2.) Signed boundaries: sizes of sections are changed such that starcraft jumps backwards and begins reading the rest of the CHK from there, this is used for section-stacking based compression.
3.) VCOD section changes: VCOD is used to validate the contents of the map, staredit doesn't read VCOD the same as starcraft, and will not open maps that it believes to be corruped.
4.) Missing sections: a section that is typically found in StarCraft maps, but not read by StarCraft is not present.
5.) Unknown sections: a section that isn't typically found in StarCraft maps is placed in the map (this is sometimes used for meta-mapping purposes such as extended strings).
6.) Salting: a tremendous amount of crap that is added to various sections such that they exceed program's capacities to hold a section in memory or to build meta-data (not enough memory to build a new copy of a section for example).
7.) Undersized trailing section: all sections are made up of a 4-byte name a 4-byte size, and the rest of the data, if the data is shorter than the size the section may be loaded by StarCraft different than in an editor.
8.) Invalid trailing section: the trailing section header is made up of only part of the size/title (for example your section could have a 3 byte size just before the file ends, or a 1-byte title)
9.) MPQ Protection (details redacted)
In this light let us try to define protected maps in a verifiable way.
(5) should not be used, as it's quite possibly the most useful of the above (ex: being able to have comments that don't take up StarCraft string table space).
(4) should not be used as sections are often useless junk (ex: IVE2), and can be removed for compression (ex: VCOD)
Next let us posit that some mapmakers use compression for distributability purposes with no desire to make their map "closed source".
(1) and (2) definately cannot be used as these result result in huge gains (in some cases you can achive less than 20% the original map size).
(3) is (reportadly) already used by TiniMap to reduce map size and should therefore should not be trivially used in a definition of protected maps.
(7) has potentially significant compression gains
(8) has tiny compression gains
(9) at least one means of MPQ protection is easily identified and can't be used for anything except MPQ protection
What's left is (6) salting, but how can you differ between salt and legitimate sections? Data simply not used by StarCraft isn't a valid criteria as that applies to a vast range of things including disabled triggers, comments, etc. I see no valid way to check if something is salt.
So a technical definition of a protected map should come down to:
(8) || (3) || (9)
Where (3) is used only under the condition that total map size increases.
Post has been edited 1 time(s), last time on Oct 7 2019, 12:12 am by jjf28.
TheNitesWhoSay - Clan Aura -
githubReached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.