Quote from Heinermann
Typically the address range for the Starcraft module is 0x00401000 - 0x006DD694.
This gives us a hard limit, we cannot read or write past 0x006DD694.
Everything about a preplaced unit starts in its chk entry, things like its coordinates and hitpoints, can be disregarded, as they can be set freely without real cause for concern, and are pretty much irrelevant in the extended units arena. What matters to us is the player (1 byte) and unitID (2 bytes).
The player will determine color information and other limited amounts of information. Colors do not appear to be constant from computer-to-computer, and thus players should not be considered reliable for anything but player 1-12, more research on this is needed.
The unitID causes starcraft to read from units.dat to determine most other aspects of the unit. units.dat is statically loaded into memory, immediately being followed by orders.dat, sprites.dat and images.dat, a small map of how they are loaded, each one immediately after the other, is shown below, with the help of EUDDB.
Code
0x65FC18 - Units.dat
0x664A40 - Orders.dat + 3 bytes padding
0x665AC0 - Spites.dat + 3 bytes padding
0x666778 - Images.dat
0x66FBE4 - UNKNOWN (unsafe)
0x664A40 - Orders.dat + 3 bytes padding
0x665AC0 - Spites.dat + 3 bytes padding
0x666778 - Images.dat
0x66FBE4 - UNKNOWN (unsafe)
Starcraft loads a unit's properties using something to this effect:
Code
...
unsigned int unitTypeHitPoints[228] = { ... }
unsigned char unitTypeElevationLevel[228] = { ... }
...
unit.hitPoints = unitTypeHitPoints[unitID]
...
unsigned int unitTypeHitPoints[228] = { ... }
unsigned char unitTypeElevationLevel[228] = { ... }
...
unit.hitPoints = unitTypeHitPoints[unitID]
...
Such that if your unitID is higher than 227, it will read entries that comes after, in the case of 228, you would be using the first four bytes of ElevationLevel, whose values we know.
Thus we can predict what the properties of many extended units, and therefore we can predict whether a given unit will almost certainly crash, or is worth testing. This will require:
1) A range of units that can be predicted
2) A copy of starcraft memory in the units.dat -> images.dat range (simple enough to grab)
3) A knowledge of what ranges of a given units.dat entry will cause a crash
1) Lets assume that 0x66FBE4 and anything after it change randomly, until we know otherwise, and let us assume that AdvancedFlags (long[228], starts at 0x664080) cannot be certain values (again, until we know otherwise), this would effectively limit us to unitID's less than 11993, anything above that could potentially change on a whim, and are not worth using (at least until we determine more memory at 0x66FBE4+ is static).
2) Grabbing, will post a file when I have it.
3) Here we branch off into crazy amounts of reference work, for each units.dat entry, the relatively safe values need to be determined, this will require branching into alot of other places in memory (for example: flingy.dat) and will not be an easy task, i'll be color coding the results here, feel free to help with anything you know or your own tests.
Blue - Safe (thoroughly tested and is safe for all values)
Green - Probably Safe (prediction, has not been tested)
Yellow - Unknown Saftey
Orange - Probably not safe (prediction, has not been tested)
Red - Unsafe for given range
Units.dat
TODO: sfxdata.dat
TODO: Orders.dat
TODO: Upgrades.dat
TODO: Flingy.dat (and potentially its sub dat files)
TheNitesWhoSay - Clan Aura - github
Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.
Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.