Editing DLLs/exe

[Llama8 11]

Does anyone know how (since IIRC it's possible) one goes about the following:

1)I know there are tools out there that can be used to find what a process is doing (eg, what functions it's calling from DLLs) when it does it (eg, you hover over a CA & the tooltip comes up, what function is called/run & where's it getting the data from, etc), what are they & where can you get them from?

2)Does anyone know how to go about using said tools?

 

I ask because (here & here) it seems that quite a lot of the behaviour of both the GUI & CAs is determined by stuff that's hardcoded (eg, spellClass) & if we could change these, then we'd be able to do more interesting things.

[chattius 2,666]

The guys from former wininternals moved over to microsoft. They found the sony rootkit and did some tools to explore process activities. They still maintain most of their old freeware, but now at the technet site of microsoft.

 

http://technet.microsoft.com/en-us/sysinternals/bb795533

 

Process explorer, Process monitor, ...

 

 

I think this is closest what you will get by freeware. Commercial decompiler and debuggers are priced in the thousands.

[Llama8 11]

Thanks mate. I had a quick look via google & decompilers (even just a home license) weren't exactly cheap...

 

So presumably Process Explorer/Monitor would be able to tell me where in what DLL Sacred 2's being told what data to grab for tooltips & how a CA should behave based on the spellclass.

[Dragon Brother 620]

If that doesnt work, or if it only tells you what .dll file is being called you can try loading the .dll in either boomerang decompiler (free, open source) which in a quick test had some luck getting somewhere although you had to check the option to not decode child procedures otherwise it would only decode and then upon decompiling crash, which I assume was due to it trying to decompile what wasn't there, or there is IDA Pro who offer an older version of their software for free. Alot more options in that one, perhaps reading a manual may be a good idea...

[Llama8 11]

Ahh yes, I forgot that Sacred 2 won't run if you're using Process Monitor....

 

Edit, or you can just start Sacred 2 first, then Process Monitor.

 

Edit 2: Unfortunately there's no access of the DLL's in the Sacred 2 folder while either mousing over a CA (for the tooltip) or using a CA, which means that anything in them is loaded either on startup or when you load a character (Spells.txt is loaded when you load a save). The vast majority of what's going on during play is accessing gfx & sound files (which is understandable) & TCP communications (ie server/host stuff with S2gs.exe). The only dll accesses were to Windows\system32\d3d files (either d3d8.dll, d3d9.dll or dinput8.dll).

 

Edit 3: And the copy protection kicks in when you exit to the main menu (I wouldn't be surprised if the DRM kicks in on save file load as well).

 

Edit 4: Interestingly, when you access the load screen, Sacred 2 attempts to open up save files 0-99. *shrugs*

 

And yes, the DRM spits the dummy out on save file load... *sigh*

[Llama8 11]

I'd be interested to know how you got somethng "interesting" from the boomerang decompiler DB, I'm not really seeing much other than a page or two of code (& not much interesting either).

[dimitrius154 616]

The main problem with Sacred 2 is that's it's still not abandonware.

 

While capturing offsets to functions of interest(from various sources they all should be in either sacred2.exe, or s2logic.dll) can be performed utilising, say, Cheat Engine's debugger(it actually seems to work better than IDA's, imagine that) can be performed in due time, editing files would, imho, lead to frequent crashes, because of Securom protection. It can be removed, but then questions of legal matter arise.

[Llama8 11]

Tediting files would, imho, lead to frequent crashes, because of Securom protection.

Yeah, I hadn't thought of that TBH...

[Dragon Brother 620]

I'd be interested to know how you got somethng "interesting" from the boomerang decompiler DB, I'm not really seeing much other than a page or two of code (& not much interesting either).

 

I probably only got the same as you, it was more that I got something readable out of it in the end that I found it somewhat useful than that I got anything that looked like it could give clues.

 

Tediting files would, imho, lead to frequent crashes, because of Securom protection.

Yeah, I hadn't thought of that TBH...

 

Sigh...copy protection... ;(

 

Edit: I would just like to add, that by opening these .exe's/.dlls in either IDA or boomerang has buggered up my install and Im going to have to reinstall everything. Totally forgot to back everything up

[Pesmontis 168]

From my (programmer's) point of view, there's these approaches:

- using a powerful debugger to listen to DLL calls;

- using DLL injection to report DLL calls (additional programming required);

- trying to mimic Sacred 2 DLL calls (additional programming required + a lot of trial & error);

- using a DirectX listener / grabber, but not only for DX Draw calls;

- decompilation.

 

Additional programming or decompilation should be really heavy I think.

 

Then there's also the WoW approach for network sessions:

Simply try to capture game command packets and eventually alter binary data in them..