I will do my level best once again to bring this to the team. I believe I had done so once before.
Edited: I have indeed notified the Norton team admin of the original thread posted and added this thread asking for a status. Hoping to get an answer ASAP.
SA
@SoulAsylum - sorry I only just picked up after re-reading your posts with the CERT pictures, that the date is AMERICAN format, and I was stupidly thinking that the CERT date was the 4th JAN, instead it is of course 1st April this year.
However, the fact remains that some sort of (internal and unknown) option is being used by the Windows Defender "mpcmdrun.exe" utility, to check certain security related items like this Symantec AMSI DLL, that I suspect is calling a Kernel Driver, and is reporting an issue. I had a quick read of the Microsoft AMSI document, and noticed this signing tool:
https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool SEE THIS:
"
Note
The Windows 10 SDK, Windows 10 HLK, Windows 10 WDK and Windows 10 ADK builds 20236 and above will now require specifying the digest algorithm. The SignTool sign command requires the /fd file digest algorithm and the /td timestamp digest algorithm option to be specified during signing and timestamping, respectively. A warning (error code 0, initially) will be thrown if /fd is not specified during signing and if /td is not specified during timestamping. In later versions of SignTool, the warning will become an error. SHA256 is recommended and considered to be more secure than SHA1 by the industry.
"
So, it begs the question (as AntiCorr3lation has hinted at), is the symamsi.dll just misconfigured (the CERT is there, but they used the wrong one, i.e pointed the /fd to tha SHA1 instead of the SHA256 one), or maybe they just used an older version of the SignTool, that is now NOT Compatible with newer Windows 10 levels??
Is there a way for someone to reach out to Symantec DEVS to ask this question? I don't want to be sitting here as a "man-in-the-middle" (i.e. a mere user), reporting this to Symantec, if there is ANY POSSIBILITY that it might be related to the above, OR is it Microsoft Defender code being too aggressive with the Code Integrity check??
Ideally Symantec should be talking to Microsoft about this, and develop a viable solution, as I do NOT want to keep seeing these security related errors (false or not), in MY event logs, created by an issue when I use Symantec (paid for) software!!
As an aside to all this, I beleive that the Windows 10 Code Integrity checks are ONLY kicking in when it detects that a program is making a call to a Kernel Driver (for Kernel Hooks, that AV software typically would need to do), otherwise there would be HUNDREDS of these if normal software was included. This is a GOOD way to ensure good security, and one would expect this in a good operating system!
Indeed, the issue does go back a way, linked here in this older post. In that thread Defender settings were the culprit at the time with Windows 10 ver. 1909. The dll certificates are correctly signed and the dates are good. MS Defender seems to be the common monkey wrench since that version was released. Each subsequent windows feature update is deleting the event logs so I cannot view any entries that would go back that far within the event log viewer. Microsoft has an article for amsi providers here. F-Secure talks about AMSI By-passes here as well. Powershell? Thoughts?
SA
Hi @SoulAsylum - thanks for confirming that this is still a valid issue, and posting the CERT properties of the offending Norton Code. Embarrassingly, it seems that they forgot to update the SHA-256 Internal Code CERT!
I did feel that when I saw the news about code certs (and other types I think) were being limited to a 368 day life, that this sort of thing would get more prevalent, as that sort of admin is most likely relegated to a separate "admin" department, and can be easily forgotten about, as it is "someone else's problem" while the DEV team just want to do all the fun and clever stuff. BUT, for a major AV company/player in the market, it does NOT show very good diligence for the need to release a QUALITY and robust product, against all the competition out there, like MalwareBytes and similar.
Yes indeed, CI ID 3033 has been throughly disregarded in the 22.21.1.151 update.
Both certificate signing dates are now valid which makes this still an addressible issue.
SA
Well I am pleased that at least ONE code integrity issue inside the Norton AV product has been fixed recently:
"EVENT ID 3004:
Windows is unable to verify the image integrity of the file \Device\HarddiskVolume1\Program Files\Norton Security\Engine\22.20.5.39\WSCStub.exe because file hash could not be found on the system. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source."
has now dissapeared with the latest 22.21.1.151 update.
HOWEVER: I am REALLY disappointed that the Norton developer teams did NOT take the chance to replace the offending "sysmamsi.dll" that this post/complaint/bug report is all about, with this update. It is STILL PRESENT - see below:
"Log Name: Microsoft-Windows-CodeIntegrity/Operational
Source: Microsoft-Windows-CodeIntegrity
Date: 27/02/2021 19:13:33
EVENT ID: 3033
Code Integrity determined that a process (\Device\HarddiskVolume1\Program Files\Windows Defender\MpCmdRun.exe) attempted to load \Device\HarddiskVolume1\Program Files\Norton Security\Engine\22.21.1.151\symamsi.dll that did not meet the Microsoft signing level requirements."
This is a piece of their CORE PRODUCT - are they asleep at the wheel, or do they just not care?? Surely we do not have to wait until a major release to 23.X comes along? Do they not realise, that while techies such as those that frequent this forum, KNOW to check the Event Logs to check over the health of their systems on occasion (with the lack of an AUTOMATED method by any Microsoft AI style "wizard" health report), and that EVENT ERRORS that are logged such as this, make it VERY CLEAR that the code-integrity of THEIR RELEASED AND PAID-FOR PRODUCT IS IN QUESTION?? I mean, the words CODE and INTEGRITY are actually part of the log, I did NOT have to put this in myself!!
Hey @td47,
I started using Winternals in 2008 and never looked back (well, I glanced back when Microsoft got their grimy paws on it). They actually handled it well. In stead of outright thievery, they let Russinovich maintain the code. They are the best collection of PC tools available. Sigcheck is a great utility. One thing I did for the command line applications, I built a library of notepad files with command lines set up for my specific uses (copy / paste). It's very helpful. I have had the latest full suite on every machine I have ever used. Process Explorer and Process Monitor are tools I use virtually every day.
I have always had a fascination of strings in binary code. It can give you a lot of information about function calls, cert data, textual components of integrated scripts, and undocumented information. I was looking at a dll file strings years ago and saw evidence indicating that the binary was collecting data, and with a primitive encryption algorithm wrote to a series of small files with benign and random filenames, along with a series of IP addresses of target upload servers. I watched what should have been a system resource act like a standalone executable in Dependency Walker (this is a stunning tool to watch an executable with). It was the first time I had found, at the time unknown, malicious code using only "strings" command line and Dependency Walker.
Microsoft "Authenticode" - This is a complex, two step process of signing a PE binary. It actually places the code in specific locations so that the binary can change its size while importing and exporting data. Because the sections can change size, the key is not to break the files "envelope integrity." If you do some research you will see that the date of the cert is trivial compared to the mechanics of authenticode. It will give you a much more clear picture of signing requirements and constraints. This was the "internal cert" I was referencing when I challenged by assertion the notion that the Symantec CA invalid date was the cause of Windows inability to load symamsi.dll.
Like I pointed out in my response to SoulAsylum, Windows allows the user to disable the invalid cert warning and allow any binary to download and install using the "Internet Options" Advanced tab.
Funny that uSoft would raise the authentication bar so high, then still allow the user, with IE, to easily disable all the checkpoints with the tick of a few boxes. This exists for the exact reason you point out in your post. The were unsigned drivers in the past, they are here in the present, and will be in the future. They will never go away fully, so there must be provision to use them.
I once pondered computer science as enigmatic; it can also be examined diametrically, where all functions follow a logic pattern, like a microprocessor - antithetical to an enigma with reliable predictability. When humans mangle the logic and attempt to create something that was never meant to be, an enigma, not unlike the birth of a new star, is born. The model for an enigma, to me, is a company that once provided professional, functional, no frills protection from evil, that turned to marketing cheese-ware, like LifeLock, using fancy, unauthentic, and unrealistic scenarios to entice a victim and convince them that they can be protected from themselves.
Coughing and Spluttering - no matter how much overcompensation a machine has with massive amounts of memory and multi GHz uP's, this phenomenon will, like unsigned drivers, always be close at hand. It is also the by-product of someone who tried to make something better that did not need to be. This - to be sure, is an Enigma.
So I wish all the best to you and SoulAsylum. Have an enlightening weekend.
In Peace
<>
Hey @SoulAsylum,
Thank you for your post and I agree with your assertions. I would like to say that from an overall perspective, SQA is, like ISO or AS9100, always is conflict with release. Money will always supersede quality. Quality functions are the first heads on the block, and on occasion, the last in line to explain to the CEO that the bug in the code is exploitable, and it cannot ship until fixed and revalidated. I know. I was a QE for many years. Having the authority to (re)direct virtually anyone in the company has a heavy downside.
The problems you identify with sustaining a working SQE function are difficult to solve. Users can still enable or disable revocation, invalid signatures, address mismatch, and authentication. These are all single points of failure that are openly available to a user with local admin privilege. There are methods to carve out data from a binary to place arbitrary code that can still find its way onto an unsuspecting user's hard drive - with the originating root CA. All the rules can be bypassed and the complexity of possible exploitation numbs the mind.
This is an interesting statement, mainly because it is a target condition, and generally false:
Root certificates also have a validity period and expiration date. After this expiration date, the root certificates and all certificates derived from them become invalid. But this is usually not a problem: Device manufacturers roll out an update that replaces the expired root certificate. If this is forgotten or is not possible, the devices can no longer establish secure Internet connections, install software, etc. because the protection provided by the root certificate has been broken.
As long as users have the ability to "Allow software to run or install even if the signature is invalid" it does a disservice to the idea that software vendors are implementing a "holy grail" security solution. As you clearly point out - uneducated end-users who could not possibly fathom that something like a CA exists in our world. Thank you also for pointing out the the expired MS cert and without asking, ask "Why does Microsoft maintain expired certificates in the TRCA store? Don't they belong among the "untrusted" so that they may do no harm." One just might utter the famous initialism "WTF?" A word to the wise: don't think that it is a good idea to take the responsibility of housekeeping the CA stores. Does a cert with an expired date (as the one you have shown) have operational value? Windows and parent Microsoft take care of it eventually.
I almost choked to death from laughing at this line: But this is usually not a problem: Device manufacturers roll out an update that replaces the expired root certificate.
It is inarguable that Norton's lack of diligence in the ongoing symamsi.dll case of is irresponsible - on multiple levels. I can't control what happens inside the SQA bowels of Norton, but as an informed consumer, I am the one who gets a POS antimalware binary that my operating system patently rejects. Silent update? So silent that it cannot exist.
Thanks again SoulAsylum. As a final note, I would like to say that I felt your passion in the first paragraph. I can't truly express the joy of reading someone's words that say what needs to be said. Gandhi said that in the end, only the truth will remain, while all else is buried beneath the sands of time.
Just awesome.
"I would rather intently and actively listen to someone for hours who was passionate about the man in the moon, than to listen to no passion at all"
@anticor3llation
In Peace
<>
@AntiCorr3lation - what a great post! Many thanks, I feel I should print and frame it... 
. Thanks for the heads-up on that neat file analyser utility, I DID look at the binary myself as well (the hard way with WordPad!). As for unsigned binaries, there is another neat utility called "sigcheck" by Windows OS Guru Mark Russinovitch, that you can check out your system with. A useful command line for it is ".\sigcheck64.exe -u -e c:\windows\system32" to look at the key important ones, but you can point it to any directory of interest. I am still reading up on "sigcheck", but I think there may be a way of checking for "past the use-by date" for any binaries or DLL's as well, I will post that when I know how. As it is, the "Microsoft Code Integrity" is triggering an event when it sees fit, as this is what this post is all about, it must be a couple of things that is making it "cough and splutter", not just the date, as I thought I had read that the expiration of the signing cert should NOT make it stop working, as it was validly signed AT COMPILATION time by the vendor that wrote it with a valid certificate at the time, so maybe there is something else that Microsoft finds suspect about this module? After all, there must be THOUSANDS of old signed drivers out there for old kit that will NEVER be recompiled and updated, so it remains a bit of of an anomaly wrapped in an enigma for me... 
What hypothesis? None afforded. My concise view is these certificates being outdated SHOULD allow Windows, when it detects it to disable that software as it is then vulnerable to manipulation. That is not the case due to tamper protection. Quality QA over the need to push out software that wasn't properly tested and vetted before being released for consumption is seriously needed. ALL vendors. Vice, allowing things like this to be found by the user, at a later time long after expiration has already taken place. Most users don't even know what the event viewer is on a computer and look for the OS to trigger an notification that something is amiss. Again, its not happening.
Microsoft, has/had an expired root certificate which will, if removed, cause system instability up to and including the possibility of system failure. They warned of it in advance. In the case of the Norton outdated certificate, they did not. Now it is Windows reporting an outdated share library certificate "signature". Repeatedly, as has been shown in system event logs. Malware can and does use certificates to fool the OS into doing its bidding. Symamsi.dll is a shared system resource. That is my concern. It doesn't take long protracted theory discussions to figure out its an issue of high order needing immediate attention on the part of Norton.
Root certificates also have a validity period and expiration date. After this expiration date, the root certificates and all certificates derived from them become invalid. But this is usually not a problem: Device manufacturers roll out an update that replaces the expired root certificate. If this is forgotten or is not possible, the devices can no longer establish secure Internet connections, install software, etc. because the protection provided by the root certificate has been broken.
The last statement COULD also be the cause of failures to install Norton software as well.
Edited: FWIW!! The MS root authority certificate remains expired as I have checked since the Jan. 2021 patch release. Not good for the OS as the expired certificate of Norton isn't for their software.
SA
Hi @td47,
I believe you have summed up the situation very crisply and forthright. I have been around this matter for almost as long as my first marriage, and just finished a post to soulasylum down at the bottom of the thread this evening. Fixing internal certs is not as simple as generating a class 2 root CA. The cert is not one in the certificate trust store, but inside the binary itself. I always recommend a very cool MWB program called FileAlyzer (v. 2.0.5.57...). You can look at any file, and filter strings and you can see in any MS signed driver, the embedded certs, almost always toward the end of the file. After you look at a few hundred of them, you get a more clear view on the whole matter.
I made mention of trust, as you have made use of the adjectives "Genuine" and "Valid." I always ask people if they believe that those two words apply to the last Microsoft update on their PC. When they respond affirmatively, I ask them if they had any objective evidence that the download even came from Microsoft, not to mention if they had any idea what was actually in the update, or if it even was an update. I am a skeptic, so please forgive my impingement on human nature, but these words connotate more "concrete" objects, like precious stones, than they do with software. When somebody laughed at Fletcher's Checksum after modifying a program without changing the checksum number, it stole a little of what we once had known to be Genuine, even if the algorithm weakness was as obvious as a man walking around without a head. I like the context of your thoughts and it made me smile. Someone who has not given up on higher objectives yet, and truly believes in them. I applaud you for that, and I will declaratively tell you to hang onto that belief - no matter what - for the duration of your natural life. That loss, if allowed to occur, changes you in perpetuity.
The "genuineness" (noun form of the adjective) of a company that has a mission statement to bleach all the blackhats into whitehats, should bloody well just focus on that, and not spend time pawning things that people don't really need. In this overtly simple business model, if you can manage to stay in business, with an optical focus on your mission statement, for 10+ years, purely by accident, you get really good at what you do. By doing so, that company would have a legion of proud and loyal customers. I was like this 30 years ago with NAV and NU. After I had a perchance encounter with Peter Norton in 1991, I genuflected uncontrollably when I would come near any Norton product. I have to say that it felt good, like actually being part of the Norton team; I was much less skeptical. A different lifetime, and I dare say that it was a better one than today.
In your closing sentence, the poetic end of your relationship with the AV is like those of a bouquet of roses, who served a brief but intense life in the pleasure of the recipient, and now only exist in the annals of forgotten history.
Awesome.
In Peace
<>
Hey @soulasylum,
What is your confidence level that your hypothesis is correct?
These are the reasons why I ask:
1.) The bad certificate has plagued symamsi.dll for at least two years. I can assert this to be true because it started filling my logues sometime in late 2018.
This I know for sure - remove and reinstall WILL NOT WORK. I tried it three times - three long and agonizing iterations of late nights and resentments stemming from the lack of any knowledge in the Norton community. All of my trials are documented in the Norton Community. I knew after the first round it would fail again, but I was reassured by a guru that I could log the data and send it to Symantec for evaluation. For three weeks I called and wrote emails trying to find someone who I could discuss the matter from a technical standpoint; well, that never happened. Even a little.
2.) It is not Device Guard that is the problem. I believe that the reason is Microsoft's increased security criteria for internal and external root certificates. As you most likely know, evil blackhats know how to inject bogus certificates into an encrypted transaction, thus stealing the session in a MITM attack. Many were generated from Microsoft, Thawte, and Comodo (now known as Sectigo, because Comodo really blew it). You are also aware of the certificate "Trust" store. Trust is the only thing between a MITM and Bob and Alice. You will see untrusted certificates in any PC's certificate store. Another story...and for reference, the external CA root, the Universal root, the trusted network CA, the class 2 CA, the RSA CA, the class 3 PP CA, the high assurance EV root CA and 150 others - are not part of the symamsi.dll problem.
3.)The offending certificate causing the symamsi.dll rejection is not from the Symantec cert shown. It can't be !
3A.) First, every signed MS driver binary has its own certificate - with the name of the binary embedded in the cert. How else could you possibly determine that any given binary is signed?
3B.) The offending certificate is embedded in the symamsi.dll binary code. I actually already knew this before I had seen it which is why it was so frustrating that none of the gurus knew anything about this.
3C.) I challenge anyone to go look at the strings in symamsi.dll. There you will find embedded Microsoft certs, not one, but potentially two or three. And guess what? IT'S NOT THE DATE ! ! ! without knowing the exact failure mode, I would guess three things. One is an archaic encryption method such as DES, two is an improper key length, and three is absolutely the most common - It's just misconfigured !
With Microsoft trying to do damage control on their public trust hammering, they raised the bar for third-party software vendors to get compliant certs so the binaries can join the ranks of code that sit in the System32 level signed trust. And get this - FTLOG - Microsoft will deploy certificates for you ! ! ! You don't really have to even think about it. Microsoft flew into action to reset cert requirements to a much higher standard - they did the right thing for the wrong reason - the "optics."
I have to say that I was extremely disappointed that Symantec, or anyone else for that matter, would assist me. Sitting behind my PC for several hours, doing the same thing and expecting different results really killed me. I will not light the guru who told me to "keep trying" on fire, but I had, once again to prove to myself, through a series of epic, reliable failures, that I actually knew what I was saying.
The fact this this sideshow is still going on, and there is still no clarity whatsoever from the Community, and people taking basic concepts out of context and spinning their own theories on how to solve this problem, does not speak well of Symantec, or the users who blindly trust root CA's - simply because they just don't know what the hell it is.
Anyway, I hope that you are able to wade through some of this; it's pretty straightforward and the logic is sound.
There needs to be one guru who knows certs well - that guru should be you. You could change your pseudonym to "CertAsylum." (LOL)
Anyway - I wish Peace to you and everyone at Symantec.
<>
Understand your frustration. FWIW!! Microsoft had a root certificate expire at the end of December and warned users who frequently clean their systems manually not to do so. Of course, the silence remains whether that certificate was/has been replaced. I'm of course of the old school gang, believing in quality over quantity. Unfortunately that isn't the "come-by-ya" corporations are singing in todays world.
SA
Hi @SoulAsylum - thanks for checking and verifying that this issue is still happening. I just cannot understand why a major AV vendor, with such important and mature products, cannot provide a timely fix for basic Certificate issues. Do they not understand that Windows 10 treats these as an important facet of OS security these days. Surely keeping on top of Software Security Certs is (or should be) an important admin function inside Norton, so users can be sure that their installed software is genuine and valid, and has not been compromised!! Maybe they are too busy trying to work on ways to push stuff that users don't need (VPN, PC Performance "interference", Password Managers - already in my browser thanks very much), to make extra revenue.
If this continues, my Norton will be just left to wither, and will be uninstalled soon.
Update: Looks like the sha1 certificate is still expired:
The sha256 certificate has ALSO NOT been updated:
SA
Yes. The SDS defs get updated by LiveUpdate.
Hi, thanks for the info. I assume that "SDS" is the Security Data Scanner module set that came in with 22.7? Is it correct that this will get updated via the standard "Live Update" funconality?
Hello again. DPC_WATCHDOG_VIOLATION on this machine was due to having fast startup enabled after an update. I had let is slip my mind to revert it to the normal off setting before shutting down the evening prior.
The Norton team has this issue for action. Unless one of those people posts directly here with a fix release or an update notice is posted a fix will most likely be a silent one. I believe an SDS update will be the avenue they take since addressing outdated certificate signing on more than one file is needed. WHEN, that will happen is anyones guess. Being that the pandemic now has an even tighter stranglehold on the global work environment, manpower shortages that are the direct result of it, it will take some time. I'd look for something released after the Christmas and New Year holidays are over.
Cheers
Hi @SoulAsylum - thanks for persevering and checking that the issue is repeatable on another 20H2 Windows 10 system. It is strange that your Event Viewer did not show it, maybe your 20H2 build was missing something that DISM fixed.
By the way, in regard to your other problem,I DID see a DPC_WATCHDOG_VIOLATION one time, that was when I attempted to stop the Windows Search service, without stopping the dependecy (Windows Media Player Network Sharing Service) first. If the Search service stop takes too long, it seems it might trigger this Watchdog timer. There are probably several other causes as well.
Anyway, do you know if any Norton Support or DEV's have taken any interest in fixing up their core product yet, for this oversight?? Are we likely to get any feedback from Norton on here, or would you expect them to fix it "silently" (i.e. no Release Notes like other products have)?