Civ3Conquests.exe API hook mystery during game setup phase...
Skybuck Flying
The Civ3Conquests.exe process is injected with an "InjectableDLL.dll" which
overwrites 4 function addressess in the import table for wsock32.dll:
send,
sendto
recv,
recvfrom
The address are replaced with the addressess for:
injected_send,
injected_sendto
injected_recv,
injected_recvfrom
Which call the original addressess and then spy on the results.
This works while being in the "lobby".
However once a game has been launched it does not seem to work anymore.
The tasklist shows a new process: "dpnsvr.exe".
Which is probably related to DirectX/DirectPlay ?
However this service/server does not seem to use any winsock module/dll for
communication ???
Maybe civilization 3 conquests uses an anti-api-hooking technique during the
game ?
Or maybe it uses some low level communication library which circumvents
winsock ?
Can somebody shed some light on this ?
Bye,
Skybuck.
Jamie
DLL in it..
give it up, stop hacking..
--
"I'm never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5
Skybuck Flying
"Jamie" <jamie_ka1lpa_not_v...@charter.net> wrote in message
news:u0rWh.27$o07...@newsfe12.lga...
I already checked the second process by injecting a dll into it.
The second process does not use a winsock dll.
Bye,
Skybuck.
Skybuck Flying
IDA Pro is able to intercept all functions instances/versions/modules.
Apperently there are two modules at work:
Winsock 1 and Winsock 2.
However Winsock 2 is not listed in the import table ?
Does that mean dynamically loaded libraries are not listed in the import
table ?
That could make sense....
But then how does that work ? Hmmm.
Me need to do some more research on LoadLibrary and DLL's loaded at runtime
;)
P.S.: With IDA Pro it took like 3 minutes to track down the problem... nice
=D
Bye,
Skybuck.
J French
<sp...@hotmail.com> wrote:
>I used IDA Pro to add a breakpoint for each function in the function list.
>
>IDA Pro is able to intercept all functions instances/versions/modules.
>
>Apperently there are two modules at work:
>
>Winsock 1 and Winsock 2.
>
>However Winsock 2 is not listed in the import table ?
>Does that mean dynamically loaded libraries are not listed in the import
>table ?
Spot on
>That could make sense....
>
>But then how does that work ? Hmmm.
>Me need to do some more research on LoadLibrary and DLL's loaded at runtime
You certainly do, there is no magic in them.
Skybuck Flying
"J French" <ere...@nowhere.uk> wrote in message
news:462b1a91...@news.btopenworld.com...
You happen to know how to intercept api's which are part of libraries loaded
at runtime ? ;)
Bye,
Skybuck.
Jamie
Winsock 1 simply calls the Winsock2 DLL functions. the 2 version is the
main work horse.
J French
<sp...@hotmail.com> wrote:
<snip>
>
>You happen to know how to intercept api's which are part of libraries loaded
>at runtime ? ;)
Sort of yes an no
- if you know the parameters simply replace them with an apparently
identical DLL
Skybuck Flying
> Skybuck Flying wrote:
>> I used IDA Pro to add a breakpoint for each function in the function
>> list.
>>
>> IDA Pro is able to intercept all functions instances/versions/modules.
>>
>> Apperently there are two modules at work:
>>
>> Winsock 1 and Winsock 2.
>>
>> However Winsock 2 is not listed in the import table ?
>>
>> Does that mean dynamically loaded libraries are not listed in the import
>> table ?
>>
>> That could make sense....
>>
>> But then how does that work ? Hmmm.
>>
>> Me need to do some more research on LoadLibrary and DLL's loaded at
>> runtime ;)
>>
>> P.S.: With IDA Pro it took like 3 minutes to track down the problem...
>> nice =D
>>
>> Bye,
>> Skybuck.
>>
>>
> it's what you call using inferior tools.
> Winsock 1 simply calls the Winsock2 DLL functions. the 2 version is the
> main work horse.
Nonsense, if that was true then it would have worked.
The winsock 2 api's get called seperately, that's why some part is not
working.
At least that's what I believe now ;) :P*
Bye,
Skybuck.
Skybuck Flying
I'll take that as a no :)
Bye,
Skybuck =D
Jamie
That goes to show how much you think you really know.
Just live with it, it's above you.
J French
<sp...@hotmail.com> wrote:
>
>"J French" <ere...@nowhere.uk> wrote in message
>news:462b7fbc...@news.btopenworld.com...
>> On Sun, 22 Apr 2007 16:44:15 +0200, "Skybuck Flying"
>> <sp...@hotmail.com> wrote:
>>
>> <snip>
>>>You happen to know how to intercept api's which are part of libraries
>>>loaded
>>>at runtime ? ;)
>> Sort of yes an no
>> - if you know the parameters simply replace them with an apparently
>> identical DLL
>I'll take that as a no :)
Look at it like this, a DLL is loaded into memory by LoadLibrary
- it is then asked for pure memory addresses using either a number or
a name using GetProcAddress
After that the caller makes calls to Absolute Addresses within the DLL
- there is no intermediary layer, it is just like making calls to
addresses within the EXE
If somebody wanted to be crafty, they could set up one Call to return
the addresses of procedures that are not 'Exported'.
However one could replace a known DLL with another that exports all
contained calls, or maybe even slips itself into the GetProcAddress
area, it could then simply JMP into the real DLL
Skybuck Flying
What do you mean with replacing a known dll ?
I only need to intercept 4 calls probably.
Bye,
Skybuck.
Skybuck Flying
Lol, think about it Jamie.
You said:
winsock 1 calls, call the winsock 2 calls.
I intercept the winsock 1 calls which call the real winsock 1 calls, which
would according to you ultimately call winsock2 calls.
So I am correct when I say it would have worked, but it does not which
indicates a different problem, namelijk winsock 2 calls are called directly
and not via winsock 1 calls or anything like that.
Bye,
Skybuck.
J French
<sp...@hotmail.com> wrote:
<snip>
>What do you mean with replacing a known dll ?
Gawd's sake
>I only need to intercept 4 calls probably.
Rename the DLL
Write another DLL to replace it
Intercept and pass on the calls
Skybuck Flying
I tried that in the past, replacing winsock dll, it didn't work...
Not sure why it didn't work... I think there were callbacks and other
"internal" stuff that called winsock functions as well.
So for some reason simply replacing the winsock dll didn't work ;)
Bye,
Skybuck.