Whens the last time any of us have used Blizzards map editor?

Lol.

I'd say about 6 years ago.

...well I didn't really expect it to be that much of a debate.
Considering how small the SC1 communtiy has become, I figured it would be a simple yes/no question..

Boy, could I be more wrong.
Anyhow, I won't post it so publicly then.



....on a sidenote, I'd like to say that as far as I know, SMC and various protectors like Special Protector crash out MAC users, so I advise everyone to use TinyMap2 for protection instead.
That's already hard as heck to unprotect.

Post has been edited 2 time(s), last time on Dec 12 2012, 9:31 am by Zhuinden.

Haha, Chirus shared this gem with me.

See what Sixen would think of this whole affair.

I'm surprised, and not at the same time.

SMC 2.80 can do TM2 easily. In fact there was a point release specifically with support for TM2.

Incidentally a few days ago, late at night (US time) some random new user typed "map protect" into the shoutbox, followed by an apology because they thought it was a forum search box. Evidently we have people here turning up looking for protectors.

A lot of Sixen's comments in that thread seem pretty arrogant towards the respect of other map makers if you ask me. Here's one that made me lol a little...


How can someone be for unlocking maps to learn from them, but want to find a way to have a true unlockable protection so that someone can't open the map to learn from it?

The obvious and ideal answer is that there would exist a way to lock the map in such a way that it can only be used as learning material, not as a subject of map theft.

Oh, okay. It was a while ago when I last time tried to unprotect a TinyMap2-protected map, and I guess I didn't have SMC back then.
It was hard to phase together using numerous different programs, but it worked in the end.

Anyhow, TinyMap2 cannot be unprotected by UU2, so it's all fair.

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.

Seemingly related to #6, SC has some validation checks that editors do not which is often times used for protection ... an improperly sized section will not be read by StarCraft, but an editor that encounters it will surely break. I remember certain protectors doing things related to that ... there would be sections named like a true sections, but would be huge (or tiny) and filled with garbage data.

While all of this is technically interesting, it is actually pretty irrelevant.

A protected map is one which the author says is protected. The author may also choose to apply protection mechanisms of various means (as you've outlined) in an attempt to enforce that protection.

The presence or absence of any particular technique isn't what determines if a map is protected or not.

It's relevant to people who create programs for StarCraft and wish to post them on SEN, as their programs could be classed as unprotectors if they in any way circumvent what is considered to be protection (and therefore fall under the issue of hosting unprotectors that is being discussed).


It must be included in a definition of protection in the context of this discussion, otherwise we can't call programs unprotectors (or judge whether they include map unprotecting), that is, we could say "they just change the map from something to something else, they don't change the authors intentions".

Post has been edited 3 time(s), last time on Mar 11 2015, 1:11 am by jjf28.