Passing Parameters

c++ / delphi package - dll injection and api hooking
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Passing Parameters

Post by madshi »

> I believe a mailslot is the simplest route without issues

But there *IS* an issue with mailslots, don't you see? Waiting for a reply from another process in DllMain is very very very bad.
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Passing Parameters

Post by iconic »

I understand waiting is "potentially" dangerous inside DLLMain, of course. I'm not suggesting that it's the safest option, just the easiest. MMF would be better here as you mentioned but again it suffers issues already mentioned. The OP didn't exactly describe the context he'd be working in so it's hard to advise which method to choose and why. On a side note, doesn't MCH use a sleep loop inside DLLMain when a DLL is to be uninjected with your SAFE_UNHOOKING flag (assuming APIs are hooked and still in use)? Isn't that forcing a potentially dangerous wait inside DLLMain, too?

--Iconic
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Passing Parameters

Post by madshi »

Just had a problem with you saying that using mailslots is "without issues", which is not true inside of DllMain.

madCodeHook indeed has a loop which waits when unhooking using SAFE_UNHOOKING (which is the default option). However, uninjection unhooks all APIs completely before even trying to unload the hook dll. So the wait loop always runs outside of DllMain. madCodeHook does not ever wait in DllMain.
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Passing Parameters

Post by iconic »

DLLMain is a sensitive area indeed and you're right with the "no issues" comment I made.
When a mailslot is created it functions as a server and can use the creation flag "mailslot_wait_forever" so a "client" can post a message to it and the OS backs this message up (storing it indefinitely), therefore no polling is needed nor "waiting" inside the DLL, it just needs to do one read of a message, the message(s) remained stored for as long as the OS backs this up until the server chooses to read it. So, the DLL is never really "waiting" on abc.exe process. I understand where you are coming from and again we're way off topic. If the OP needs a write once before injection and the DLL picks up on this that's a great solution in MMF, given admin rights it's no issue and a "good" solution as you've mentioned, which is the context of doing system-wide stuff with your package since it assumes these rights are already present.

My entire argument is that I do not assume these things such as admin rights or special privileges for the sake of simple IPC (which I understand you mostly assume it's granted), it's the only reason I suggested an alternate route. Have you ever used a mailslot? Create once and post any messages you want from any process or DLL, one reader and multiple writers (broadcasting), each one is read in queue and pulled from it, all of this requires zero usermode intervention of the queue since the OS does all the work for you.

--Iconic
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Passing Parameters

Post by madshi »

Sounds good. Didn't know the "mailslot_wait_forever" flag. The term "broadcast" is usually used for one writer and multiple readers, though.
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Passing Parameters

Post by iconic »

Yup. They can be fancy for just about anything but of course nothing is perfect.
A mailslot is a mechanism for one-way interprocess communications (IPC). Applications can store messages in a mailslot. The owner of the mailslot can retrieve messages that are stored there.
...
Mailslots, on the other hand, are a simple way for a process to broadcast messages to multiple processes.

https://msdn.microsoft.com/en-us/librar ... 85%29.aspx
It assumes one server/reader and multiple writers/clients, only one reader can exist per mailslot server (for protection against squatting aka unauthorized reading of the channel's data)

--Iconic
dcsoft
Posts: 380
Joined: Sat Dec 11, 2004 2:11 am
Location: San Francisco Bay Area, CA USA
Contact:

Re: Passing Parameters

Post by dcsoft »

It's too bad mailslots don't support the reader sending back a response to the caller; as it is, Madshi's MCH IPC could be implemented using mailslots, were it not for the "answer" that is supported.

Named pipes do support the "answer". Do they have any problems, compared to mailslots?
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Passing Parameters

Post by iconic »

Hey DCSoft,

I hate to continue this discussion because I should perhaps create a new thread entitled "IPC solutions and considersations" =) I don't want to disrespect the OP and get too off topic. But, to quickly answer you I feel that both pipes and mailslots have advantages and disadvantages and I agree that it's too bad mailslots don't support an "answer" out of the box =( In my IPC solution I have built this in and I have to say it works phenomenally. I actually modeled my IPC after MCH's IPC and MCH too has amazing IPC functionality, as you said. It's why we've both been on Madshi's forum for over a decade, great package and support :D

--Iconic
Post Reply