peterthepigeon

So now that my account is back and recovered. I'm starting a project to allow you to edit unit values as you would in RA, TS, etc. I may make a repo for the project, I haven't decided yet. Right now I'm just in the planning phase of the project, doing some UML, etc. The actual project will be coded in C++, and make use of regex, along with std::map and std::vector. For a project of this complexity, a parser is not required. Boost may be used, although maybe not as the STL provides everything I need. I plan to have a worker thread running every so often to query changes to the file and spit out any inconsistencies. In other words, you'll be able to alt tab out of the game to edit values on the fly and if it causes potential inconsistencies, they'll be discarded and the file overwritten with the last stable changes. It would be tempting to hardcode offsets and the like into the .dll itself, however, for ease of modification, simplicity sake and ease of development, I think I will simply keep it to .ini files. I plan to add a detours.ini, or something where you specify an offset, a detour type, or a modification in assembly and whether you allocate to a new RWX section or overwrite the opcodes in the .text section. I could use the heap for this, and then call VirtualProtect to mark the page RWX, however, I am not in 'love' with the idea, nor just willy nilly throwing out 4096 byte allocations. A memory manager seems most appropriate. This thread will be updated as I work on the project.

CPU Disasm Address Hex dump Command Comments 0041D1EC |. 8D4D AC LEA ECX,[EBP-54] 0041D1EF |. 8D5D A8 LEA EBX,[EBP-58] 0041D1F2 |. 8B55 B8 MOV EDX,DWORD PTR SS:[EBP-48] 0041D1F5 |. B8 C0DD5300 MOV EAX,0053DDC0 0041D1FA |. E8 A9520100 CALL 004324A8 ; [C&C95.004324A8 0041D1FF |. 8D4D B4 LEA ECX,[EBP-4C] 0041D202 |. 8D5D B0 LEA EBX,[EBP-50] 0041D205 |. 8B55 BC MOV EDX,DWORD PTR SS:[EBP-44] 0041D208 |. B8 C0DD5300 MOV EAX,0053DDC0 0041D20D |. E8 96520100 CALL 004324A8 ; [C&C95.004324A8 The lea just means pass by reference, from what I can see it takes a pointer to the map in EAX. void Compute ( void* mapptr, int unknown, short* a, short* b ) { // stuff goes here } This is what tells it where to draw the laser from and it's obviously related to cell computation or other drawing because I see this call referenced elsewhere. I haven't checked, nor do I really desire to spend too much time on it. The only question is what other input is necessary, and I'll examine that. Once you have this working it's a trivial matter to call drawline in the unit/infantry firing code to render the laser. This is the first real reverse engineering I've done in months on C&C. I'm lazy, get over it.

That's not a bad idea, commandos modified to auto capture certain structures and c4 the rest.

The fact that you could fence the computer in and it does nothing.

A lot of WinAPi and hungarian notation, eh? Typical CnC hacker... Grow up. I hacked FPS games long before I took a whack at CnC. It's easy to determine whether a patch gives an advantage or not, just have a whitelist. Ergo, what are you talking about.

My disasm engine spits out mnemonics and the works. I'm tempted to do likewise for his executable. I'd copy the original code to the new section and set a check(config parsed at startup or new map) to execute original or jump over to the patched or nopped code, then back to the regular execution. Clean, simple and efficient. As for nasm files, meh, I'd just write my own mini assembler

I was wondering about that, the way you specified "unit code" and "Obelisk code" separately... though that's the same code for the same address, just called with different vtables. Meh. I'd have to look into the exe to properly parse this. To be honest it's probably better just to patch the unit code to call drawline. That's the route I intend to go.

or in other words, 0, 2 Rearranging stupidly cause well it's fun, only works on 0 and 2 also. 2x = x^2 x = ( ( x^2 ) / 2) Alternatively you could just realize this is a quadratic form also. ax^2 + bx + C = 0 ( x^2 - 2x ) = 0 factor out the x x ( x - 2 ) = 0

I honestly would recommend duplicating the code paths and redirecting to a new section, make sure of course to properly handle relocations. I could do this myself and maybe I will when I feel like it.

The hackishness of your patched executable versus the clean pristine one to notate all your patches.

Keep in mind this is extremely hacky and I haven't worked beyond this, but it does work and on the move the laser sometimes may not draw at all.

Start by finding the call that handles the firing code. 00471197 FF92 04010000 CALL DWORD PTR DS:[EDX+104] Notice that it's a vtable. The code for structures is at: 004211CC 53 PUSH EBX However notice that if we immediately patch it, guess what? We crash at: 004211DB 8A40 54 MOV AL,BYTE PTR DS:[EAX+54] So even if we nop it out, or patch it to find the unit location in memory we still don't see the laser drawn. The answer is straight forward. 00421213 2E:FF2485 A0114200 JMP DWORD PTR CS:[EAX*4+4211A0] ; C&C95.00421265 We must zero out eax, so a simple unit or infantry check and done. No laser? Oh my. We breakpoint on where we're supposed to: Unit code 0042177E FF91 BC010000 CALL DWORD PTR DS:[ECX+1BC] ; C&C95.004B6120 Obelisk code 0042177E FF91 BC010000 CALL DWORD PTR DS:[ECX+1BC] ; C&C95.0041D058 More entry replacement. Then we crash again. 0041D06F 8B58 42 MOV EBX,DWORD PTR DS:[EAX+42] Nop or fix accordingly. 0041D0C0 8A40 54 MOV AL,BYTE PTR DS:[EAX+54] Ditto. You'll have to adjust some of the jump paths, but it should start drawing. Presto done.

CreateFile on both files ReadFile on both get offset to code section iterate until through ( *pbOldCodeSection != *pbPatchedCodesection ) notate accordingly simple

Changing macros, expanding memory foot print, that's a lot of work. Then making sure units and structures that are in the expanded regions remain inactive. Lots of work.

42 is best cause it's the answer to everything