here's one hf
Going to try to find this weekend to set up my VM on a lan! I will try to make a good quality video of this nasty risk. I would recommend we remove the save feature from multiplayer! We said too much in public I know a few people who are not trust worthy who can pull this off. It might not auto execute but still we should remove save because it will drop the exe in their war2 map sav folder.....
Cool, just remember your old mate Lamby when they start handing out briefcases full of cash
... and yeah if you can just make an exe appear on someones puter - can you imagine back when there was 50K players on bnet every day? You would have had hundreds of people randomly clicking ok it... Hey! now I think about it, I should make one with a .PUD file icon
that would be really tricky.... give it some interesting name that stands out so people want to look at it. hehe.. then OMG they will see my HELLO WORLD MESSAGE! AAARRRRGGHHHH!!
Anyway... such silliness aside, for custom mods if you write a mod editor that produces a custom section, I can write a mod app that will impliment them.
Just have it produce a file like this
4 BYTES "MODS"
DWORD size of mods (file size-8)
DWORD NumberOfMods
then a list of mods like this:
DWORD memory offset
BYTE number of bytes
N*BYTE data to write at offset
obviously it will be restricted from writing to executable sections otherwise this could be use to inject malicious code - so that won't be happening
I understand about 80 percent of that code. Is that how asm is setup? What does Number of Mods means a variable? Or is it like a sub name? How does the data look that I want to write in hex??? Sorry me and many people here have 0 knowledge in such low level programming.
Well it's kinda pseudocode.
its just a description of how I suggest the file (which would end up as a PUD section) be laid out.
A "DWORD" or double-word is a 4 byte number
A BYTE is a byte
so for example if you make and app that allows you to change spell MP costs and some other stuff... the app would have to know the EXE offsets that correspond to each spell or whatever, and what the appropriate format is to write the values, so the user changes some stuff and saves their work, then the app has decided it needs to do this:
(
just makin stuff up for example)
it needs to write a
0xFF byte at offset
0x444555 and these:
0x01, 0x02, 0x03, 0xAB, 0xBA at offset
0x432100and
0xC0, 0xDE at offset
0x439991then if you were using the file format I suggested you would create a file and wite this to it:
"MODS" ... the signature, which ends up as 0x4D, 0x4F, 0x44, 0x53
... not that u really need to know that - just write the 'M' 'O' 'D' 'S', it all ends up the same.
next is a DWORD (4 bytes) for the size of the data (this combination of a 4CC and a Section size is for the PUD format)
so we dont know the data size yet - you could pre-calculate it, but in this situation it's much easier to just write the data, see how big it is then go back and fill in the size at the end.
so...
"MODS"
(skip 4 bytes)
then DWORD number of mods,
which in ths case is 3, so it would end up
03:00:00:00
then we write the 3 mods, each one is like this:
DWORD memory offset
BYTE number of bytes
N*BYTE data to write at offset
so the first one is:
55:45:44:00
01
FF
the second one is
00:21:43:00
05
01:02:03:AB:BA
and the last one is
91:99:43:00
02
C0:DE
so at this stage we have:
4D:4F:44:53:00:00:00:00:
03:00:00:00:55:45:44:00:
FF:00:21:43:00:01:02:03:
AB:BA:91:99:43:00:C0:DE:
and we can see that the file is 32 bytes long.
Those 4 zeros at the end of the first line there is where we need to write our DWORD size value.
But we just want the length of the data, not the the "MODS" and the size DWORD itself - they are 4 bytes each so we subtract 8 from the total size (32-8=24) so now we just need to write a DWORD 24 (0x00000018) there
so seek to file offset 4 then write 18:00:00:00 and we're done:
4D:4F:44:53:18:00:00:00:
03:00:00:00:55:45:44:00:
FF:00:21:43:00:01:02:03:
AB:BA:91:99:43:00:C0:DE:
In a hex editor it might look something like this
4D:4F:44:53:18:00:00:00:03:00|MODS↑.....
00:00:55:45:44:00:FF:00:21:43|..UED. .!C
00:01:02:03:AB:BA:91:99:43:00|....½║æÖC.
C0:DE: |└▐
of course the actual values would depend on what offsets you can track down in the exe, and what you wanted to change them to. All the normall PUD stuff is there, but you can just set them in the .PUD anyway.
Swagier had some interesting ideas a while back like:
edit spells(for example change that orge got heal not lust)
mission objective
edit upgarde( u can change dmg +2 -> +4)
changing side train knights as orc
the mission objective I have no clue about, but this sort of stuff should be do-able.
Then the app at the other end would be locating the WC2 process, monitoring its status and waiting for you to enter a game, then when a game starts it would check the PUD for a "MODS" section and if it finds one, write the changes to the WC2 process, and back up the previous values to be restred after the game.
I would also want to include some kind of safeguard so that players couldnt shut down the app half way through a game then leave mods in place for other games on normal maps. In most cases this would probably just cause desync/drop but no doubt if there is some sneaky little exploit some gremlin will find it... so I would want to prevent this, probably by diverting part of the WC2 program flow through the app so if its terminated unexpectedly then WC2 would crash... or if you just shut it down normally it would remove it's hook and exit gracefully.
Probably this project would be an excellent candidate for dll injection.