Microsoft blocks Trend Micro code at center of driver 'cheatware' storm from Windows 10, rootkit detector product pulled from site Microsoft has blocked a Trend Micro driver from running on Windows 10 – and Trend has withdrawn downloads of its rootkit detector that uses the driver – after the code appeared to game Redmond's QA tests. Late last week, Trend removed downloads of its Rootkit Buster from its website. And last night it emerged the kernel-level …
In an ideal world all code would be peer reviewed. In the real world with understaffing and/or outsourcing, deadlines and pointy heads who wouldnt know one end of a linked list from another, it rarely is. Certainly not at the level of scrutiny that would spot a hack like this.
Normally, I would pull out the old Hanlon's Razor "Never attribute to malice that which is adequately explained by stupidity". BUT this is definitely not something slipped in by accident. You dont put a check for something that then defines further behaviour by accident - a) because its more lines of code that you really dont need if you were doing things above board, and b) who needs the hassle of then spending the time to test that works under two different behaviour scenarios.
This was put in deliberately. The question is why?
Trend have performed poorly in independent testing over the last 18 months or so. I would bet this is an extension of that since they've been reluctant to allow independent testing of their software being widely published since they started to perform poorly
>This was put in deliberately. The question is why?
I can understand that the original driver could have been written to use the executable non-paged pool and thus be in need of revision to use the non-executable non-paged pool.
But then having revised and tested the code there would be no need to maintain continued support for both memory pool models - necessary because it seems the driver can happily run with either memory pools.
The only possible reason is to do with compatibility with pre-Win10 systems, but then why have an intelligent runtime switch and not an install time switch.
I wonder if Trend will tell MS why their driver was implemented the way it was...
re: The question is why?
My theory is that they are trying to bypass the check so they can dynamically load changes without paying Microsoft the fees charged to resign driver changes.
I thought at first Microsoft would side with Trend, Trend is paying them money.
The fact that Microsoft has not tells us something about the why.
> "at no time was the Trend Micro team avoiding certification requirements."
Well then who wrote that code? The code is definitely there and someone had to write it so Trend's statement implies hackers are changing their code without their knowledge - an even worse situation than trying to fool certification tests!
I will believe them when they can provide some credible and convincing explanation as to why it was there, why the software only changed its behaviour to what it should have been when the software recognised it was being tested.
I'm not holding my breath but I've put £5 on a long-shot of the excuse being 'safeguarding a child'.
"The code is definitely there and someone had to write it"
Absolutely. It looks like the code literally reads as "Is certification testing active?" If so, pretend everything is ok, otherwise carry on....
It's a bit like customer phone support when the boss is/isn't standing next to you.... :)
A down vote storm, with so many I would expect at least someone to post a reply. If the point was missed I was highlighting MS hypocrisy, have they never pulled a fast one in software (answers on a toilet roll please). If the point wasn't missed then do they agree it's OK to diminish/hate individuals simply because they were born in some way different from them (answers in crayon please). Timely rush of opinion considering what is happening right now in US.
I don't care if it's clear or not, it should not be done, period.
Good on Borkzilla for reacting on this and pulling the driver. Now Trend is going to have to submit another one, and I'll bet it will get a lot more scrutiny the next time around.
A reputation takes years to build, but only a day to trash. Trend Micro has now trashed its reputation.
Is there a valid reason for a driver to ever look at VerifierCodeCheckFlagOn()?
If not, then I'd suggest MS update their certification requirements to include a statement along the lines of "Your drive must not access VerifierCodeCheckFlagOn() at any time", and then update the testing to include a scan of the code for any references to VerifierCodeCheckFlagOn() and automatically fail the driver if found.
There are legitimate reasons for checking if you are running under validation, just as there are reasons to check if you are running in a virtual machine.
But both types of checks should expect strict scrutiny.
As for getting rid of a way to check: no, that shouldn't be done. Because there *might* be legitimate reasons, established the proper way to check and audit code that checks. If you find code that uses a different way to check, hit it with the over-size ban hammer.
I can't agree with MS's "driver cert" requirement at ALL. The certification "through MS only for a fee" is JUST WRONG and indirectly harms open source drivers. That being said, writing software that deliberately alters itself to pass a test shouldn't be done, either (right VW?).
My office Lenovo laptop had to be restarted today for a Trend update.
It seems to have fixed the Intel graphics driver crashing almost immediately every boot, which crippled OpenGL acceleration and has been happening for months.
I wonder if crash telemetry from people like me caused MS to detect this memory abuse.
>I wonder if crash telemetry from people like me caused MS to detect this memory abuse.
Well given the timing of the public diclosure from a third-party and the subsequent action taken by MS, I suggest not.
Although, thanks to the third-party, it would not surprise me if MS can now make sense of some the crashdumps it received.
We have to suffer this software and I swear the antivirus software has caused us more problems than any virus ever has. It slows down every file operation, it randomly locks files (causing builds to fail for no reason) and it has false positives that kill software we're trying to test.
More likely managements lack any development experience and IT services are out sourced.
Previous place of work I arranged with IT services department to exclude build directories from virus scanning. When nightly builds finished they were scanned automatically by two sets of antivirus software.
When IT services were out sourced it all went to pot.
Your previous article referred to MysteriousCheck() as being the suspect function but you updated that to VerifierCodeCheckFlagOn() without mentioning it in the update text. Why is that? It makes it look like you're trying to hide something, but more so is confusing to anyone who read the original article.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
