Interprocess Memory Access: always block?

so here’s the deal: intermemory access is when an app injects itself into another app right?

but this sounds a “covert” thing, if an app is legit then why hijack another app instead of doing what it needs itself? (like, why hijack a browser? why not just directly access internet, or at worst, simply launch the browser?)

which means only malware hijacks processes, so aint it better to just block intermemory access for everything by default, and if so how do I do it?

Unfortunately things are not as clear cut black and white when it comes to techniques like memory access. They are used by both normal applications and malware.

I don’t know what a blanket block on all memory access would do. How much it would break or not break.

but why on earth or elsewhere would a legit app need to hijack another app?

I can understand an app loading a dll into itself (almost all complex progs do that), but why would an app inject a dll into another app? ??? that sounds devious & underhand, as if the app is trying to hide itself or something. typical malware stuff

it’s like “if you got nothing to hide then no reason to hide”, if an app tries to hide itself then it can only be bad right?

Here’s a link that may illuminate the matter:

If you look at D+ ‘View Active Processes’ you’ll see a hierarchy of processes. Explorer is a good example, it spawns a gamut of processes. One of which is IE. Virtually anything you do in IE, e.g., context menues, will invoke Explorer functionality, or the shell32 API. Normal functioning of Windows and application demands the ability of these processes to communicate.

IF the app is doing an RPC locally, that is invoking a local procedure library, it probably invokes such function library through the system gate-keeper, i.e., Explorer, which implements runDLL32 which invokes shell32 as an exe. Comunication between the called and the caller utilizes interprocess memory access. It could be something as simple as returning to the return address pointed to by the invoked processes on the stack.

Typically IE & Explorer want interprocess communication to each other and themselves. Other apps may request memory access if they utilize COM objects such as browseUI.dll (which is probably transparently handled by Explorer). This stuff won’t happen if whatever arbitrary application has developed its own file browse dialoge. In the contemporary .NET environment developers won’t re-invent the whell, they’ll just implement the existing winAPI library.

I’d ssay a safe rule of thumb is interprocess communication should be allowed (and rule remembered as appropriate) if said alert arises from some deliberate and overt act the user did. However, if alert come up out of the blue, by unknown / unrecognized processes, and attempts access to unrelated process, that’s be the canary in the coal-mine.

k thx 8)

but Im not sure I understood all the previous parts :embarassed:

simple question, is there legitimate reasons where one app will inject a dll into another app? (like, not load a dll into itself but into an app other than itself)


and NO:

if the goal of such injection is malicious, or deleterious to the intent of the authors of the application being targeted. This per:

In a nutshell: it depends; interprocess memory access isn’t necessarily exclusive to DLL injection.

I previously mentioned RPC. That’s an acronymn for Remote Procedure Call. It can be maliciously exploited remotely, i.e., on the interwebs, or the intrawebs. In fact it’d be good secuirty prectice to secuire externally unsolicited RPC (by steallthing ports implicated for such). One could infer that ultimate security would be to disable RPC service on the host. Do that for poops and grins and you’ll find virtually notihing’ll run on your system.

In CIS the D+ resource access name ‘DNS client service’ serves a dual role, i.e. DNS client service AND RPC functionality. An app that needs DNS lookup functionality will never even be able to invoke SVCHost DNS service, i.e., UDP on port 53 to DNS servers, unless the client inherently possesses DNS service access permissions.

So before SVCHost can make the UDP port 53 address resolution an app may request, RPC probably necessary to hook the shared memory pool that SVCHost has available for that purpose. And that most likely will entail an interprocess memory access.

Try to use Process Explorer

and you will see how (and why) a perfectly legitimate program (by Microsoft) uses this feature

In fact it cannot (unfortunately) access cmdagent memory :-TD

That is part of Comodo’s self protection. Very important!

(btw prcexplorer is bugged: ‘show lower pane’ option (to show DLLs) doesnt work :frowning:
no surprise coming from Microsoft. lol

but in all these cases the process loads modules into itself right? A.exe loads X.dll into A.exe

but are there legit apps that load a module into another app?

like, A.exe loads X.dll into B.exe ?

You have to click on a process to show its associated dll’s in the pane below…



I know but it dont work! the pane is invisible even with ‘show lower pane’ checked

when I click on any process, on the status bar it says “refreshing DLLs” for a split second, but that’s it, no lower pane appears, nothing

(then again what else to expect from Microsoft “programmers” . lol)