This thread is to become a central location for all currently known information about extended preplaced units (that is, units preplaced in a map with a unit ID higher than 227 and/or a player ID higher than 11 that also exhibit some effect usable in maps), including but not limited to working examples, proposed theories, and aims to hopefully in the future provide the general formulaic processes of the buffer overflows caused by these units, as opposed to brute testing.

StarCraft does not perform bounds checking on the unit IDs and player IDs of preplaced units as it does with creating units via triggers, therefore the limit for these values are only defined by the byte count of them defined by StarCraft. 2 bytes are allocated for unit ID, making the limit 65535 ((2^8)^2-1), and 1 byte for player ID with the limit 255 ((2^8)^1-1). As StarCraft only allocates data structures large enough to contain the valid players/units, providing it with values above the limits StarCraft expects will make it write data ahead of the intended data structures, possibly in locations useful for map applications.

One of the many buffer overflows take that place is in unit scores. Referring to Farty1Billion's EUD DB, the Score Unit Total located at 0x00581ED4 will be used as an address base to calculate the address in which to increase the value by the unit score of the unit being created, using the following formula: 0x00581ED4 + 4 * player ID. This overflow is used particularly in Extended Supply.

Contrasted with EUD Actions having one easy to control buffer overflow, extended preplaced units are much more erratic and write data in many places difficult to rigorously document.

Unit Speed Acceleration
Probably the most used, the player 15 scarab, interceptor, and map revealer appear to speed units up in the game. From what I tested the scarab and interceptor speed up the units placed after it in terms of animation, movement speed, and reload speed, and the map revealer appears to just speed up the reload speed.
Units placed before them appear to be unusable.
An explanation for this effect is still unknown.

Extended Supply
The three values for supply (available, used, and max) for almost each race can be increased with extended preplaced units. Place units for the following players to increase each supply by a half of the unit score:
Zerg Available: Player 157
Zerg Used: Player 169
Zerg Max: Player 181
Terran Available: Player 193
Terran Used: Player 205
Terran Max: Player 217
Protoss Available: Player 229
Protoss Used: Player 241
Protoss Max: Player 253

Terrain Palette Modification (?)
Placing a player 20 scarab, interceptor, or map revealer radically modifies the terrain, and must be the first placed unit. Most likely it modifies a pointer to terrain palette data which would cause havoc in terms of color representation.

Discussion is encouraged.

I think we went through/tested them at least 5 times. Nothing was consistent.

There are more than just a few overflows in these cases. It's difficult to keep track of every possible overflow that can be produced, and what their effects are.
Just to name some for unit types:
Read/Write:

• Completed Unit Counts
  
• All Unit Counts
  
• Completed Unit Counts (Trigger Copy)
  
• All Unit Counts (Trigger Copy)
  

Read:

• All unit stats from units.dat that are loaded into memory. (including all overflow sprite/image/order/flingy/weapon/upgrade/sfx entries that come from it)
  
• Buttonset entries
  
• UI Layout (statdata) entries
  
• Unit name string
  
• Unit icons/wireframes
  
• AI unit strength computation
  

Keep in mind I didn't cover any of the other overflows that come from units.dat overflows (there are also overflows with flingy, sprite, images, iscript, orders, weapons, upgrades, sfx, strings, and any overflows that come from those overflow entries as well).

I didn't even list them all. Extended players have even more overflows than this (Including AI controllers, scores, resources/supply, their own counts(incl all/buildings/factories/men), colors, vision(several references here), alliance, force, race, owner, nation ID, local ID, tech/upgrade counts, and more).

A program can be written to find statistics for extended units/players but not all memory is static so results can change.

Tested what? All (65536*256=16777216) combinations?

Here is a summary of the reverse engineering I did on this:


My knowledge on RE in general is somewhat limited, but I think what would be ideal is if we could somehow record from the time the procedure starts to the time it ends each instruction that writes data to the data segment or to stack frames preceding the starting one, recording each address of the written data along with their new values. Doing this several times in an incremental fashion (Player 1 marine, player 2 marine, etc.), and comparing the results of each case with a program, we could possibly figure out several things:
1) Which written addresses are not overflowable (static addresses appearing in all cases)
2) Which address represents what value (weapon.dat pointer, etc)
3) How these overflowable addresses are calculated, by studying the instructions in the vicinity of the instruction that wrote the data there

I lack the tools both in terms of software (I use only GDB) and hardware (very slow when debugging with software breakpoints).

Tested enough to figure out that it is essentially a waste of time to actually test them all.

Over 90% of the overflows aren't read/written in the Create Unit function. So if you think you can hook there and then log all read/write instructions then you won't find anything abnormal except for the application of default unit stats (max hp, shields, etc), which is expected to overflow and can be calculated anyway.