HitmanPro.ALERT Support and Discussion Thread

Thanks very much, Erik.
But, er .. Tracker Update (TrackerUpdate.exe) is PDF-XChange Viewer's component for updating from within the program. It doesn't produce executables, or so I would think. I do not understand why HMPA would lockdown TrackerUpdate.exe.
Nor do I understand how PDF-XChange Viewer could be updated successfully, while I used the updater component for updating and the updater component was locked down.
Perhaps it could be wise if SurfRight could have a look at HMPA's reaction to TrackerUpdate.exe.

Just to be sure, I ran PDF-XChange Viewer's current installer, PDFXVwer.exe 2.5.316.0. That worked fine, without interruption.

 

@erikloman
@markloman

HMP.A 3.1 Build 347
W8.1 x86-64 OEM (Toshiba)

HMP.A does not auto-add WordPad to protected applications.

This issue with Word Pad persists from Build 344.

I know others will chime in here and say that WordPad is automatically added on their specific system.

On my specific system the issue is reproducible every time I install HMP.A Builds 344 and 347.

 

You have two Word Pad applications on your machine, a 32-bit and a 64-bit Word Pad. Maybe that is cause of the confusion?

 

I have replied via email.

 

@erikloman

I have to manually add to Applications list and apply Office mitigations.

I thought HMP.A used to auto-add WordPad to Applications upon initial installation ?

 

Alert reads from the registry which apps should be protected. For example, the apps attached to the .rtf extension are automatically added. On standard systems, WordPad is attached to .rtf files. On your system WordPad seems no longer attached to .rtf? Please have a look in the registry under HKCR\.rtf and see what is listed there.

 

That is interesting information.
LibreOffice, for instance, automatically associates .rtf. If you don't want that, you need to restore the association with WordPad.
Erik, do you mean that when, for instance, LibreOffice associates .rtf, HMPA won't protect WordPad?

Perhaps you remember that once I reported that first HMPA automatically added GOM Media Player for exploit mitigation, but later GOM Player was no longer among HMPA's protected applications? I reported that, but there never was a response to that report.
Could it be that I changed GOM Player's file associations (I did, but I don't remember if it was in connection to that case), and that because of that GOM Player was no longer among HMPA's protected applications?

If that would be true - I don't think it would be very wise to only protect applications that are associated to certain file extensions, as the same files can also be opened with other applications.

However, I guess that is not what you meant, at all.

 

Was you able to block Norton?

 

Not yet implemented.

 

HitmanPro.Alert 3.1.1 build 350 PreRelease

Changelog

• Improved Webcam Filtering to support Windows Hello.
• Improved overall performance (compared to build 348 ).
• Changed BadUSB default to off for new installs.
• Changed Action mode to be only accessible from Advanced Interface.
• Updated network component.

Download
http://test.hitmanpro.com/hmpalert3b350.exe

Please let me know how this version runs on your computer

 

No problems upgrading build 350 PreRelease. About Action mode. Maybe warn the user like 'Are you sure? YES/NO'

Win10 1511 build 10586.63 x64/Norton Security with Backup v22.5.5.15

 

Updated to build 350 without incident. After rebooting BadUSB was off as expected (turned it back on)

 

If BadUSB is only default to off for new installs, it shouldn't be off after updating, should it?

 

@erikloman @markloman
Please update the translation, the new strings have been added. Just download it from the usual link.

 

Here too.
Bad USB was set to off, after update from 347 to 350.

No way this should happen, when auto updating productive used machines.

 

was there a 348...?
3.1.1 build 350 + Enabled BadUSB

 

Updated from build 347 (BadUSB on) to build 350 without any issues.
After the reboot BadUSB in build 350 was off and I turned it back on.
However b350 was not a new install but an update from b347.

 

Will be fixed in 351. Thanks all!

 

Disable mitigations feels like on-the-fly. > No warning.
Remove mitigations feels like not on-the-fly. > Warning.

 

HitmanPro.Alert 3.1.1 build 350 upgraded perfectly on my W8.1 machine with BadUSB turned off after a reboot (from ON previously)
I also updated my PDF X-Viewer to the latest v2.5 b316 without any issues on this build.

I've been closely following this thread for well over a year, but only post when I've got something relevant to say.

Please explain why BadUSB is OFF by default now as this is an important security feature surely?

 

Strange ... Heimdal is not blocking the site on my machine - unless it has been fixed now.
Edit: Stranger still. I see now that it is in the Websites Blocked list in the log, but it did not prevent me from downloading.

 

I have asked support at Heimdal to whitelist test.hitmanpro.com (and some others).

 

build 350 run fine for me

 

@erikloman
@markloman

"Upgrade" process from b347 to b350 without incident.

BadUSB disabled as reported earlier.

*** MAJOR PROBLEM ***

• Windows 8.1 x86-64 - Clean Install
  
• COMODO Internet Security Pro 8.2
• COMODO sandbox is configured to force-run Cyberfox\Internet Explorer inside the sandbox
  
• With build 347 installed, Cyberfox\Internet Explorer will force-run sandboxed

• Install build 350, Cyberfox\Internet Explorer will NOT force-run sandboxed; when executed it will run OUTSIDE of COMODO's sandbox
  
• build 350 messes with COMODO's sandbox

• Uninstall build 350 (or revert back to build 347), and Cyberfox\Internet Explorer will again be able to be be force-run inside COMODO sandbox