Does CPF 3.0 Do MD5/SHA?

Hi there!

When i upgraded Mediamonkey recently i recognized that Comodo D+ does NOT ask me again whether running MM should be allowed or not. Thats strange, as the checksum of the executeable has changed. Did i miss some option to enable checksum hashing?

thanks in advance


There’s no checksum vertification in CFP 3. I’m not sure why they removed it tho, hope that it’ll be back in the future. If it’s not default, there should be an option to enable it.


thanks for the fast reply! i was just wondering because imo thats a security flaw, but maybe someone more experienced could explain whether checksum verification gives additional security.


AFAIK there is no hash check in cfp because it doesn’t need it. It monitors your system so thoroughly for changes that it will alert you in every case something is modified (depending on your configuration). So to update your program first you have to allow the changes in cfp. As you KNEW about the file (its hash as well) being changed moreover you initiated the process and also allowed it cfp considers the modified file safe so why would it alerted you that the file had been changed when you received an alert BEFORE it was modified.
Hope I made it a bit clearer.


Good explanation!
When viewed in that light a MD5/SHA alert does seem redundant.


CPF 3 has packet checksum verificationm…it shows in Firewall–>Advanced–>Attack Detection Settings–>Miscellaneous.

It’s there, it’s just hidden deeply in the app.

I believe that this is something different.
WotC was inquiring about the checksum of the executable.
Normally when this is changed, one would receive an alert to that effect, and whether or not it should be allowed to run.


The file will end up in 'Your Pending files, but you will not necessarily receive an alert as described by me here.


This is why I said “depending on your configuration”. You refered to your post where cureit.exe was modified and you did not receive any alert. I assume that cureit was installed before cfp. CFP installs default with cleanpc mode which means all your files are considered safe on your harddrive so every action of cureit and its updater will be learned. This is why you not always receive popups. Or if instead of using an own updater of the program (I dont know if it has) you downloaded a newer version and installed it over the old one you should have received an alert when executing the setup file and another one when it tried to modify your old ‘cure it’ files (this stage is when you can select “installer or updater” in the popup to avoid more alerts). If you put defense+ to paranoid mode for testing and delete all the auto-created rules for cureit.exe Im sure you will be alerted.

I don’t use Clean PC mode even when it’s installed as the default. Here’s a simple test that I did. I have various versions of an application called cports.exe. I delete the d+rule for cports and launch using the old version. I get three pop-ups which I allow with remember. I copy the new version over the old . I get a prompt that cmd.exe wants to change the file. I allow once (without remembering) so the file will be replaced. Cport is now a totally new version. I launch it and no pop-ups. I do not consider this normal behavior and will call it a bug. A lookup on cports reveals unknown.


I don’t use cleanpc mode either, I prefer more control. The fact that you allowed the change of the original version means that the change happened with your consent, moreover you wanted to change it this is why it is considered safe as well. Cfp 3 works in a different way compared to v2. V3 monitors the files actions as v2 monitored the file itself with hash signature changes. V3 does not check the files signatures so cryptographically it wont make a difference between two files, BUT it will catch any attempt to modify the given file. Anybody feel free to correct me but as far as I know this is the way how cfp v3’s mechanism works.

Yes, but this is normal day to day business. If I download files, I will allow the target to be created/replaced. Your argument is that I since I allowed the download, the file is considered safe. Files that end up in my pending files are not considered clean/safe. Why should current rules for a file that has been changed be valid if you no longer know what will happen when you execute the file?

Let’s say cports is a trusted application. I download cports thinking that it is an update snd replace the original file. In reality cports.exe is now a keylogger. Not only that, the keylogger is treated as a trusted application because of the cports rule. If this is the way CFP was designed to work then someone needs to take another look at the design.

I tried the above scenario and for me the results are worrisome. Normally, I would block such activity, but in this case, I was not able to. Simply saying I wanted it this way because I updated the file is a bit simplistic.


[attachment deleted by admin]

I absolutely agree, nothing replaces a file signature or checksum verification. That’s a security flaw, when you compare to 2.4 behavior that didn’t even have a HIPS.

Update: read the help files description about Image Execution Control Settings:

"The Image Execution Control Settings is an integral part of Defense+ engine. It is responsible for authenticating every executable image being loaded into the memory.

Comodo Firewall Pro verifies the integrity of executable files by creating a hash of the file at the point it attempts to load itself into memory. It then compares this hash with the one on record for that application which is stored in the Comodo safe list. If the two are different then the file has been modified since it was last run - possibly by a malicious program such as a virus or worm. You will receive an alert if an executable file fails authentication in this way. If you know you this file has recently been modified by a legitimate process (such as an application update) then it can be considered safe to allow it to run. If not, then you should be very careful before allowing the process to run"

f that really works, then fine, haven’t been able to verify that until now, I’ll watch the def+ alerts closer next time I have updated some software, when I first run it. But I doubt I would receiive any alert when I have allowed the update to install in the first place. Something I’m sure about, is that I would get an alert if some malware was attempting to modify an *.exe, and say I’d be, for some reasons ( ???) willing to allow it, I would then get another alert when I launch the exe I suppose, this time about the change that occurred.

That’s what should happen, again from the help files:

“The default and recommended setting is *.exe. This means every .exe file will be authenticated by Defense+ before it is allowed to run. If Defense+ is unable to authenticate a particular .exe file then you will receive an alert which will ask your permission before the application allowed to run.”

[attachment deleted by admin]

at adric:

Well I need to admit Im stuck with your keylogger example. Good point. It showed that my post was rather simplistic and close minded as well. I don’t know what comes next. According to the help file and some official forum posts (at least what I have understood from them) programs in the pending file list shouldn’t be considered trusted, instead they should fire alerts and they actions shouldn’t be learned automatically unless you move them to “my own safe files”. But then again this raises the question of prevention vs detection again, that is how the hell can I determine that the keylogger (pretended to be cports.exe) on the list is safe or not. Lets say my av can’t detect the keylogger. Then what? Play lottery? I suppose cfp should alert you of the keylogger-like activity. But as you said you did not receive any alerts for the new cports. I need to admit that we reached a point which is beyond my knowledge. To be honest I am also a bit confused too (maybe just 'cos of lack of sleep) Right now I can only make assumptions.
I hope a developer will shed some light on how things are working (or should work) in the background in this particular and/or similar situations.

at leopard:

That part of the helpfile was reported as bug in another topic discussing the same. It is quite misleading.

Does Comodo development consider my example above a vulnerability or not?


Using v3.0.14.276 on XP Pro SP2, I have verified the following, which would indicate that a change to an executable might not be recognized:

removed Microsoft from trusted vendors
copied cmd.exe to a new dir
ren cmd.exe to cmd.bak
debug cmd.bak to update 1 byte in a string (offset 0x14e)
save the modified cmd.bak
ren cmd.bak to cmd.exe
run cmd.exe
no notification

That was related in another thread, and I could check it myself, you never get an alert when you replace an executable with a modified one, at least not related to the signature change. You’ll only get an explorer access right alert if you change the default settings of Def+, nothing more.;msg123203#msg123203

Def+ makes definitely no signature verification between files.
I really think it’s about time Comodo pays more attention to this thread, or that might be the end for DEF+, at least for the users expecting full HIPS functionality. A HIPS that does not do checksum verifications is not a HIPS.
I find it hard to believe that CFP 3.0 + HIPS desn’t do what CFP 2.4 was able to do without a HIPS, as I’m absolutely sure that I’ve had such alerts about signature changes after a software update for instance with CFP 2.4. I mean guys, that’s not funny.

Maybe I don’t understand something, but if you were warned about trying to change executable, why do you want to be warned about executable have changed? I think that one-time-warning is enough.

the default settings of CFP allow explorer to change any protected file/folder. When you change the permission (in access rights) to ask then you get a warning because you, the user, initiate the action using explorer. Now if a trojan x or y tries to do the same, and not necessarily using explorer, you wouldn’t be notified at all, as signature changes are not detected by Def+.

yeah but the trojan wont have any permissions thus it will fire an alert if tries to run/modify something. Or if it wants to use explorer.exe to do the job it has to interact with it, which would (should ???) be intercepted by cpf. Not the change of the signature is detected by cfp instead the change itself as an action.