Exception not caught in Delphi 11.2 Alexandria 64 bit

[CharlieHeaps]

No. I'm still getting the message "..exe faulted with message: ' c000041d', which I'm afraid is beyond my powers to comprehend!

[madshi]

Ouch, I was hoping madExcept would catch that for you, but I'm not sure, maybe ASLR is beyond of madExcept can catch? I would have thought it would raise a simple access violation, though. In any case, if ASLR crashes your project even without madExcept, then it's obviously not madExcept's fault. In which case I wonder if you have to bother with ASLR. What is the big benefit of using it? Did you wish for ASLR to be there when Delphi didn't have it? I don't think it's an important feature, to be honest.

[CharlieHeaps]

Those are all reasonable questions that I don't have an answer to! For now, I've just switched it off, with the hope that eventually I can track down the cause. I suppose the high entropy ASLR will eventually become something that everyone is expected to do, but for now its not needed I think. And anyway, only works for 64-bit apps.

Thanks for all your help!

[aehimself]

Keep reporting it as Microsoft defender even considers it potentially unwanted:

MS MadCollection.png (11.38 KiB) Viewed 132355 times

[madshi]

This is really annoying. I've done a quick search and can't even find a way to properly report this false positive to Microsoft myself. Maybe you guys should get rid of that clearly bad software and use some decent anti-virus software instead?

[iconic]

Definitely disappointing indeed, seems some of these AVs are all of a sudden flagging a product setup that's been around for over 2 decades. More confusing is that the Installer is even signed with SHA-256 and the cert was never abused I guess all you can really do is continue to pressure them and mention potential loss of business over their false detection, in this case labeling it (PUA)

--Iconic

[madshi]

FWIW, I recently renewed the certificate, and that of course changed the certificate ID. That might have something to do with it. But other than the ID, everything else is the same.

[iconic]

@aehimself

As a test only, does it happen if you remove the cert embedded in madCollection.exe?

Some quick code I wrote to do this programmatically, easy to port to c/c++ if required.

// Uses ImageHlp

Code: Select all

function RemoveDigitalCerts(const lpFileName: PWChar): BOOL;
var
       hFile: THandle;
begin
       // file might be read-only, clear the attributes
       SetFileAttributesW(lpFileName, 0);
       // attempt to open the file for R/W access
       hFile := CreateFileW(lpFileName, (GENERIC_READ or GENERIC_WRITE),
                            FILE_SHARE_READ, nil, OPEN_EXISTING, 0, 0);
       if (hFile <> INVALID_HANDLE_VALUE) then
       begin
       // remove ALL certs from the signature PE section
try
       result := ImageRemoveCertificate(hFile, 0);
finally
       // closing the file handle is a MUST!
       CloseHandle(hFile);
end;
       end
else
       result := False;
end;

If the problem goes away then it's definitely (unfortunately) related to Madshi's cert, which would be odd, however would like to see if this is the case. I haven't been able to reproduce here with Win10 Pro 21H2 x64 and the latest madCollection despite having all Windows Defender settings enabled. You might also run the actual madCollection binary through Virus Total to see if other AV's are similarly detecting it so we can contact each of them and submit the latest madCollection installer. I hate when false positives happen and it's literally outside of our control mostly as the detections are based upon 3rd-party applications ;/


--Iconic

[madshi]

I don't think that it's the cert being bad or anything like that. I rather think that the various AV providers might have an internal list of known "good" certs, and since my "good" cert timed out, the new one is not known yet. So it might take a bit of time for AV providers to add the new one to their known list of good certs again. Which is really annoying, because that's not how AV software should work...

[iconic]

I don't think that it's the cert being bad or anything like that

I agree, however something related is the most likely determinant. Unfortunately, we have no way of identifying whatever metrics they're using to decide risk factors. The days of plain signature-based detection is long over and most AV and similar have moved to run-time behavioral analysis and reputation scores to gauge threat risk. I ran a quick test with WinVerifyTrust() and as expected your newer madCollection cert checked out 100% fine. There are no revocations, expirations, malformations etc. even when testing the whole certificate chain. If they are collecting a pool of "known" certs then it's a rather horrible way to determine if software is potentially malicious or not, hopefully the false positive is cleared up soon however.

I've written low-level anti-rootkits as well as aided in writing full AV engines and this is definitely not a great approach whatsoever, assuming this is the case however. As I said previously, we don't know what metrics and flags Windows Defender or Smart Screen is determining this by. I'm sure it will get sorted out soon, it's just a matter of when I guess. PUA's aren't considered a virus, which is much better than the alternative, but it should still be removed.

PUA is not considered a virus, malware, or other type of threat, but it might perform actions on endpoints that adversely affect endpoint performance or use. The term PUA can also refer to an application that has a poor reputation, as assessed by Microsoft Defender for Endpoint, due to certain kinds of undesirable behavior.

Source: https://learn.microsoft.com/en-us/micro ... -worldwide

For anyone (the more the better) willing to report this false positive, you can do so below, or at least take similar steps.

https://learn.microsoft.com/en-us/micro ... -worldwide


--Iconic