A few Nooberish Questions...
-
- Posts: 2
- Joined: Thu Jul 01, 2004 10:01 am
A few Nooberish Questions...
Here we go...
What kind of code can be injected via "remote"?
Say...if i wanted to open a socket...connect...send a string through...then close it again...can it be done in the "injected function" or do i have to open the socket in the main function...then send the data via a pointer in the "remote" function...
Confusing, confusing, confusing
What kind of code can be injected via "remote"?
Say...if i wanted to open a socket...connect...send a string through...then close it again...can it be done in the "injected function" or do i have to open the socket in the main function...then send the data via a pointer in the "remote" function...
Confusing, confusing, confusing
Re: A few Nooberish Questions...
Your problem is sending data trought a Socket witch is openned by another process?Milk-in-a-Can wrote:Here we go...
What kind of code can be injected via "remote"?
Say...if i wanted to open a socket...connect...send a string through...then close it again...can it be done in the "injected function" or do i have to open the socket in the main function...then send the data via a pointer in the "remote" function...
Confusing, confusing, confusing
If yes you could use DuplicateHandle passing the Socket ID as the TargetHandle, then you could use SEND normaly to send a string. All this can be donne by your applicationg without the need of injecting code.
I've not that much knowledge about winSock functions. So listen to nildo there.
Generally: You can remote execute *any* code, as long as you follow the rules. The most important ones are: No usage of global variables/constants (that includes global string constants!). No calls to any functions/APIs except exported APIs which are available in the target process.
If the code you want/need to execute inside of another process is too complex, I'd suggest putting it into a dll and to inject the dll into the target process. Not so nice, but much easier to realize.
Generally: You can remote execute *any* code, as long as you follow the rules. The most important ones are: No usage of global variables/constants (that includes global string constants!). No calls to any functions/APIs except exported APIs which are available in the target process.
If the code you want/need to execute inside of another process is too complex, I'd suggest putting it into a dll and to inject the dll into the target process. Not so nice, but much easier to realize.
-
- Posts: 2
- Joined: Thu Jul 01, 2004 10:01 am
Re: A few Nooberish Questions...
Thank you for both your time, and your quick replys.
You have cleared some very important "perspective issues" i had.
Oh...one more thing. The injected code...has it some kind of...maximum size?
You have cleared some very important "perspective issues" i had.
Oh...one more thing. The injected code...has it some kind of...maximum size?
Check out HookAPI(..., SYSTEM_WIDE_9x). It's exactly what you're describing!why don't you do a Code Hook Library using the your Remote execute method?
AFAIK, those programs are using drivers, which are incorporated into the exe and temporarily extracted to the harddisk.how can Regmon and Filemon from InternalSys can hook APIs without using DLLs?
Well, I didn't really examine it, but it must be this way. Earlier versions of RegMon and FileMon shipped with driver files (even with full sources some years ago). Now the driver files are gone, but the functionality is the same. So I'm quite sure that the drivers are just stored inside of the exe (and get temporarily extracted). madCodeHook does it the same way. The dll injection into newly created process in the NT family is done by a little kernel mode driver.nildo wrote:Ohhh, this I did not know!
Ohh I understand!madshi wrote:Well, I didn't really examine it, but it must be this way. Earlier versions of RegMon and FileMon shipped with driver files (even with full sources some years ago). Now the driver files are gone, but the functionality is the same. So I'm quite sure that the drivers are just stored inside of the exe (and get temporarily extracted). madCodeHook does it the same way. The dll injection into newly created process in the NT family is done by a little kernel mode driver.nildo wrote:Ohhh, this I did not know!
What method do you use for merging and unmarging this little kernel mode driver from and into your pack?
I've written a special tool which converts the driver file into a big static Delphi style hex array constant. This I can copy&paste into my Delphi code. Then when the driver is needed, the Delphi code writes it to a temporare file, installs the driver and deletes the file again (after the driver was installed, it can immediately be deleted again!). This way the driver file is as good as invisible to anyone. I've not done this to hide anything (of course), but only to make things easier to distribute and to also make uninstallation easier. The driver is automatically gone with the next reboot.
Anh! Cool!
So your utility is something like this anh?
May I use this technic with my programs too? I like this!!
So your utility is something like this anh?
Code: Select all
var
fsArquivo: TFileStream;
OutStr: string;
nAux: Byte;
begin
fsArquivo := TFileStream.Create( leArquivo.Text, fmOpenRead );
try
OutStr := 'var NomeArray : array [0..' + IntToStr( fsArquivo.Size - 1 ) + '] of byte = ' + #13#10 + '(' + #13#10;
while fsArquivo.Position <> fsArquivo.Size do
begin
fsArquivo.read( nAux, 1 );
OutStr := OutStr + '$' + IntToHex( nAux, 2 ) + ', ';
if fsArquivo.Position mod 16 = 0 then
OutStr := OutStr + #13#10;
end;
OutStr := OutStr + ');';
finally
fsArquivo.Free;
Memo1.Clear;
Memo1.Lines.Add( OutStr )
end;
end;