Strange behaviour of F.E.A.R. Multiplayer [Resolved]

Help for v2
#1

Hi all.

I ain’t new to firewalls but when it comes to the component checks it can get a little uhm… complicated.

My situation:
I have the CPF 2.4.18.184 installed.
I am behind a router.
I have the game America’s Army (free ego-shooter from the US Army)
I have recently installed the free F.E.A.R. Multiplayer version (it doesnt include the singleplayer version)

Anyway, playing FEAR works fine, Using Thunderbird/Firefox works fine. In fact everything works fine except that one problem since I have FEAR installed:

Everytime I am starting America’s Army CPF pops up with the message:
(for details you can view the attached screenshot, its in german but you should be able to comprehend the facts ^.^ )
FEARMP.exe loads dinput8.dll in ArmyOps.exe with the use of GlobalHooks etc.

Now, I have send a support ticket to Sierra to check what they have to say but dont you think that this is a strange behaviour? It doesnt happen with other application or even games I am playing…
dinput8.dll seems to be a directX file. I have scanned my PC with AntiVir and Anti-Ad and whatnot, nothing to be found.

If I deny acces ArmyOps.exe cant connect to the internet at all…
Any ideas what this could be? Is F.E.A.R. checking for pirated software? But why when you start a free game? I have other games (commercial ones) where this doesn’t happen.

[attachment deleted by admin]

#2

This is caused by FEARMP.EXE (the F.E.A.R Multi player version), which is an add-on to America’s Army, loading the DirectX direct input dll into the Americas Army executable. CFP sees this sequence as (in laymans terms) application “A” has modified application “B” by injecting component “C” into “B”. This CAN be indicative of trojan behaviour - in this case, it isn’t, but it can be.

My first thoughts would be to add an application monitor rule for FEARMP.EXE but allowing all activities and excluding advanced security checks. The same rule would need to be created for the Americas Army executable.

Let us know if these work out for you. Please bear in mind that these two suggestions are just off the top of my head.

Cheers,
Ewen :slight_smile:

#3

Hi

FEARMP.exe as an Americas Army add-on? Strange… I didn’t hear about it till now.
I also have FEAR COMBAT, the free multiplayer component of the whole game (it is started by fearmp.exe) Unfortunatelly I don’t remember if I was alerted about dinput8.dll, because I installed fearcombat almost a year ago, but it is allowed in my component monitor so I think I was:).
Processlibrary about dinput8.dll: process name: “Microsoft DirectInput DLL for DirectX”, “dinput.dll is a DirectC DLL, which handles DirectInput. This gives functionality for multimedia input devices such as joysticks.” “dinput8.dll should not be disabled, required for essential applications to work properly.”
So you may allow it.
Hope it helps,
Blas

#4

@panic

Thanks for your quick response, its much appreciated ;D but I think you are confusing something here.
FEAR and Americas Army have nothing to do with each other.

F.E.A.R.
F.E.A.R. - Wikipedia.
Publisher: Vivendi
Developer: Monolith Productions
Engine: Lithtech: Jupiter EX

Americas Army

Publisher: U.S. Army
Developer: U.S. Army
Engine (the current one): v2.4-2.x (Unreal Engine 2.5)

The only connection could be direct X. I will test if this is maybe because I have played FEAR first and AAO (Americas Army) after that. Maybe FEAR keeps something in memory wich cfp is detecting?

@Blas

I dont get the alarm when I am starting FEAR itself. Only when I am starting AAO. And only with AAO so far.

EDIT:
After a reboot and starting AAO (without a prior start of F.E.A.R.) = No such message
So, would this be a clear sign that F.E.A.R. keeps active in the background even after closing?

#5

hmm…
Its strange. And if you play AA first, and than fear do you get a similar alert?
I don’t think that fearmp keeps running in the background. But if not, then how can it load components to other processes ??? Wierd indeed.
Maybe fearmp.exe used last time the dll file and when it loads to armyops.exe CFP interprets this act as if fearmp.exe has loaded into it.
To be honest I have no idea about whats going behind the scenes.
But as far as my research for dinput8.dll has got, it has nothing to do with malware activity so I think you can allow it in component monitor. When you recieve that alert next time, click on the “Ziege Bibliotheken…” button and allow it. This way in the future you wont get alerts for this component. (btw I dont speak german, just copied it from your screenshot ;))
Its maybe one of CFP’s misteries…

#6

As far as I understand this message fearmp.exe has to be active somehow, or re-enables as soon as another program requests the dll…
Or could it be that fearmp.exe stays the parent program for it even after closing?

For now I won’t allow it out of principals even if that means to reboot more often ^.^

btw: No response from Sierra yet.

#7

Little update:

Well, looks like the Vivendi/Sierra support isn’t very helpful either.
The first reply was a tutorial to enhance system-performance and after telling them to please read my support-ticket the answer was to scan my computer for viruses and spyware (wich I told them I had done already in the first place 88) ) and if that doesn’t help to contact my firewall and anti-virus provider…

At least that answer wasn’t a copy and paste :stuck_out_tongue:
Worst problem is the wording because it translates to “It’s all your fault, now ■■■■■■ off and bother somebody else”. A short sentence like “Our database doesn’t show anything that could point to a reason of that jada jada jada jada…” and all would have been at least a little better…

Ah well. Maybe I’ll get the reason some day. If any of you have any ideas where to check and ask, every hint would be much appreciated. Yes, I have googled already and yes I know its not a big thing but well, I would like to know. :wink:

Thanks for the help so far,
Lucky

#8

Lucky

Isn’t that original pop-up you posted also listed in CFPs Log (Activity tab)? You should be able to see the Library components involved in the event in the Log detail. I’m wondering if its related to global hooks into explorer.exe, where explorer.exe is the parent of all concerned.

#9

Based on what Egemen has said about these types of things, yes they can stay resident in memory long after an application closes. So if you do the one first and then the other, the 2nd one triggers an ABA alert because of the transferred DLL (or even just background communication where the DLL is “mentioned” in passing, etc). These things all revolve around how applications communicate with each other, the system, the desktop/shell, the browser, and any combination thereof. Egemen’s rule of thumb is that if both applications are known to you, it is safe to Allow (even to Allow w/Remember so you won’t see the alert again); it’s when the applications shown are not known that you need to Deny and investigate.

To test it, you can do this: On a fresh reboot, run American Army. Don’t run FEAR first. See if you get the same popup, when FEAR hasn’t even been fired up since the reboot.

LM

#10

Isnt that info already in the screenshot? Armyops.exe tries to connect to the internet, fearmp.exe tries to load dinput8.dll into armyops.exe …
Next time I’ll check if there is more info in the log.

So, this depends on the application, then? Because so far I have only noticed this with fear. I mean, does that depend on the code of the application or other software (driver, windows,…) on my end?

I see, so, when I am sure my system is clean (up-to-date virus scan, spy/malware scans and whatnot) and something like this happens, I can allow it without a background-check on the components involved? Or would this depend on the level of trust towards the applications? Well, ok, if I wouldn’t trust them they shouldn’t be on my system in the first place but, you know, sometimes the paranoia strikes me ^.^

#11
So, this depends on the application, then?
To an extent, yes (probably to a large degree). Here's something else that plays into it - Comodo's "safelist." If you are using the safelist (Security/Advanced/Miscellaneous/Do not show alerts for applications certified by Comodo) then if [u]both[/u] applications in question are on that list, you will not see these types of alerts. That is because the apps are cryptographically signed, sealed, and delivered, and are known to be safe (if the apps become suspect, you will get an alert on that, but as long as they match, you won't). Once V3 comes out, the safelist will be a "ginormous" thing, to greatly reduce such "false positive" alerts. BTW, you can contribute apps for entry, from Application Monitor; right-click an entry and select "send the file to Comodo for analysis...from there it goes through a process of analysis and evaluation, for eventual inclusion to the list.
Or would this depend on the level of trust towards the applications?
You've got a handle on it, I think. If you have a reasonable level of confidence in the cleanliness of your system, in the trustworthiness of your apps, etc, then there's not much point being too paranoid. ;) I understand it's easy to go there, though, especially with these alerts from CFP that we've never seen from a firewall before. Understanding more about why they happen and how, has helped me have a level of comfort with it. By all means, when something "odd" happens, investigate. CFP is good (very good) at alerting a user to behavior that is similar to behaviors used by malware (so as to exploit Windows weaknesses in any/every way possible); IMO, it's good to investigate anything you're not sure about.

The Help files have a pretty good explanation about each type of ABA alert; combine that with a little judicious Wikipedia research and it should paint a pretty good picture of your scenario.

LM

EDIT: To respond to your edit, yes, that is an indication that FEAR stays resident in memory after closing, at least as far as the components in question.

Edit 2: In response to your following post, yes the updates should come through the updater function, once they’re available (provided in Security/Advanced/Miscellaneous, Automatically check Comodo certified applications update is enabled).

#12

Yeah, I am doing that. I would hate for the team to run out of work ^.^ A little off-topic on that: Do you get the new signatures via the update function?

#13

I don’t think so… “Ziege Bibliotheken…” means “Show libraries…” right? If so, that indicates there are other components involved. These would also be detailed on CFPs Log entry of the event.

#14

Zeige = Show yep
But the dll listed is the dinput8.dll

#15

That is strange. I’d certainly like to see a Log version of this event.

#16

Sure thing.

Hmm, too bad you cannot attach or insert the exported html-log… lol

Well, here it is as text:

But I dont see how this shows more than the screenshot…
I hope its no big deal that it is in german, if you have any question, just ask ^.^

#17

Actually, I think its fairly revealing…

aufr. Prog.: D:\WINDOWS\explorer.exe

This indicates that explorer.exe was the parent… and the “global hook” of dinput8.dll was done to explorer, by which ever game it was. But, because of that method of loading the DLL, it caused CFP to report this where ever explorer.exe was parent process (just about everything, unless your using a program launcher utility).

#18

Well, I’ve read it like this:
Explorer opened armyops.exe (of course, I double-clicked the icon)
But then it says that fearmp.exe loads the dll into armyops. And in that explorer.exe isnt mentioned anymore.

So, it doesnt happen the other way around (armyops.exe first and then fearmp.exe = same error) because somehow armyops.exe doesnt stay “registered” with dinput8.dll after closing?

#19

The problem is that the Global Hook remains in explorer. It is only removed if you reboot or the shell crashes, forcing explorer.exe to be restarted. Un-stated 3rd option is not advised. In any event, its harmless. So, Allow it remembered next time. Then you will not see it again unless something gets updated.

#20

OH nooooow I get it. Explorer.exe is the application still active that holds the information! searches the smiley banging his head against the wall

Case closed.

But be warned: Once I register for a forum I tend to lurk it for quite some time, some never got rid of me ^.^

Thank you all for your great help!

Cheers,
Lucky