[English]Kurze Information, die hier bei mir bereits seit August 2021 vorliegt, die ich aber noch nicht im Blog thematisiert habe. David Xanatos hat mich darauf hingewiesen, dass Microsoft ohne weitere Angabe von Gründen die Treibersignierung für den neuen Process Hacker verweigert. Das Ganze wird auf GitHub in diesem Thread angesprochen. Damit können neuere Versionen dieses Tools (und auch Tools wie der ProcessExplorer) nicht mehr eingesetzt werden.
Anzeige
Process Hacker ist ein leistungsstarkes und vielseitiges Tool, mit dem man kostenlos Systemressourcen überwachen, Software debuggen und Malware erkennen kann. David Xanatos hatte bereits vor längerem – auf meinen Hinweis – einen Kommentar im Diskussionsbereich dazu gepostet. Ich ziehe seinen Text mal hier in den Blog-Beitrag, da ich den Diskussionsbereich von Zeit zu Zeit bereinige.
Viele kennen sicher das Tool ProcessHacker, ein sehr fortgeschrittener Task Manager mit sehr gewöhnungsbedürftiger UI.
So wie es aussieht hat der Entwickler des Tools massive Probleme ein neuen Treiber bei MSFT signiert zu bekommen, wie er auf einer github Diskussion berichtet:The signing process fails each time without any error messages and Microsoft claimed "this surpasses our support"… They've just fucked me around endlessly until the certificates expire.
[…]
The exact same issue happened when submitting to Microsoft Winget:
I tired emailing him but never got a response about this behavior. You can also see how many times the package failed for unexplained reasons and that exact same problem happens when submitting the driver: microsoft/winget-pkgs#373
Microsoft Process Explorer has the same functionality so they don't have standing to block competitors then go and include the exact same features in their own software.
Microsoft has been secretly adding more powerful features than Process Hacker via their SAC product – SAC has no security whatsoever by design – they're clearly targeting the project not because of any actual technical issues but rather because we're more popular than their products, so they're using the same (illegal and anti-competitive) tactics they used against Netscape Navigator to eliminate competition but also labeling the project malicious in an attempt to mislead the competition regulators.
[…]
The large majority of changes by Microsoft are limited to restricting the Windows API with signature checks that block competitors software (e.g. CreateWindowInBand, NtQuerySystemInformation, NtQueryInformationProcess to name a few) rather than directly targeting the drivers themselves.
The signature checks added to those functions and classes only block third-parties and this includes signed binaries. We won't be able to implement the same functionality as Task Manager and Process Explorer because of those Microsoft-only signature checks even after we sort out the submission issue.
Always-on-top, Auto-elevation, DPS statistics, Default taskmgr application preferences (Microsoft hardcoded taskmgr.exe blocking competitors), GPU statistics (deliberately broken on Win10 and Win11 recently) and the DirectUI framework are some examples of features that I want to implement and are currently implemented by Task Manager but are Microsoft-only signature restricted while newer more advanced security like PPL that we desperately need are also Microsoft-only signature restricted.
The only certificate allowed to use these and other functionality is now limited to Microsoft Windows certificates – the same certificates used with Task Manager and Process Explorer – while SAC has even more powerful functionality than anything else (including Process Hacker) with absolutely no security whatsoever.
I've been complaining to Microsoft employees for years about this stuff but the attacks keep getting worse and I've since started demanding our competition regulator prosecute the company after they labeled the project malicious last year… Microsoft claims to love open source and be more transparent these days but the bullshit they're doing with SAC, taskmgr and procxp while attacking competitors and trying to limit competition and kill off the project is insane.
[…]
I was around during the 90's and they killed Netscape with this exact same behavior by changing APIs and blocking Netscape from those same APIs.
Windows owns the market for the simple reason it's not some locked down garbage controlled system so they need to start communicating these changes if they intend to kill off third party task managers or instead doing something about the numerous complaints and issues that I have complained about or they'll end up getting prosecuted and charged by regulators again just like last time when they did this exact same bullshit with Netscape.
Anzeige
Ich finde die Tools klasse, aber die Behauptungen, die er hier aufstellt, stehen im krassen Widerspruch zu seinen Release-Notes:
"The xprocesshacker.sys driver must be signed, and since the appropriate certificates are prohibitively expensive, I head to use a leaked code signing certificate I found laying around the Internets. This means some anti malware applications wrongfully flag it as potentially dangerous or a virus."
"The driver is now only test signed as the leaked certificate was blacklisted in the windows kernel, hence you need to enable test mode to use all of the features."
Nein Moment mal!
Ich bin der David Xanatos und ich mach den Task Explorer, und mein TE hatte noch nie einen signierten Treiber.
Der da das schreibt ist der Dmex und der macht den ProcessHacker der schon immer mit korrekt signiertem Treiber angerückt ist.
Bitte uns beide nicht verwechseln.
Und der Dmex der schon immer alles korrekt signiert hatte, wird jetzt vom MSFT veräppelt und obwohl er sich ein neues frisches EV Cert zugelegt hat bekommt den aktualisierten KernelProcessHacker Treiber nicht signiert.
Also er erfüllt per offizielle Vorgaben alle Voraussetzungen, dennoch weigert sich MSFT seinen Treiber zu signieren, resp. lässt den Singnaturvorgang fehlschlagen mit nichts aussagender Fehler Meldung und wen darauf angesprochen sagen sie sie wären nicht zuständig.
Also das ist doch schon mal starker Tobak!
Mea Culpa, ich ging davon aus, daß Du Beides geschaffen hast.
"KernelProcessHacker" – einige Nutzer auf github empfehlen ja, einen anderen Namen zu wählen, der den Begriff "Hacker" nicht beinhaltet.
Ob das die Lösung für das Signaturproblem sein wird, kann ich nicht sagen, dafür bin ich aus der Thematik zu lange raus. Es wäre allerdings nachvollziehbar, bei der ganzen Pseudo-Automatisierung dort.
Was denkst Du denn? Wäre das ein gangbarer Weg? Vielleicht als Fork zu Testzwecken?
Also ich vermute das die PH Leute schon ein anderen nahmen probiert haben.
Ich habe versucht an der stelle an Details zu fragen in dem Thread auf github aber die Antwort war nicht klaar.
Also Fork ist mir das ehrlich gesagt zu riskant, ich braucht mein EV cert für sandboxie die um 2 Größenordnungen mehr Nutzer hat. Zumal die TaskExplorer anzudienen viel eher einfach mal testsignign anschalten kann.
Ich denke wenn dan würde ich für den TE ein neuen Treiber von Grund auf schreiben so das was auch immer MSFT gegen PH hat sie nciht auf den trichter kommen das mein treiber sowas ähnliches ist. Und ich würde einpaar sachen weg lassen bei denen ich vermute MSFT auch eher dagegen wäre, wie die möglichkeit PPL prozesse zu killen, was der PH ja kann.
Dieser Rant auf github ist von dem ProcessHacker Maintainer dmex, dieser hatte bis jetzt immer einen Signierten Treiber.
TaskExplorer ist so eine Art Fork davon mit komplett neuer UI.
also ich meine da auch eher anderswo gelesen zu haben das ihm das Signieren zu "teuer" wurde und nicht das Microsoft das nicht mehr macht!
Ist dann doch ein kleiner aber entscheidender Unterschied!
Ist durchaus eine Entscheidung die man akzeptieren muss, aber dann den Schwarzen Peter MS zuzuschieben ist unter aller Sau! Ob die das für "Konkurrenzprodukte" extra teuer machen kann ich nicht beurteilen, ist aber auch dann eine vollkommen andere Sachlage.
Nein Moment mal!
Ich bin der David Xanatos und ich mach den Task Explorer, und mein TE hatte noch nie einen signierten Treiber.
Der da das schreibt ist der Dmex und der macht den ProcessHacker der schon immer mit korrekt signiertem Treiber angerückt ist.
Bitte uns beide nicht verwechseln.
Und der Dmex der schon immer alles korrekt signiert hatte, wird jetzt vom MSFT veräppelt und obwohl er sich ein neues frisches EV Cert zugelegt hat bekommt den aktualisierten KernelProcessHacker Treiber nicht signiert.
Also er erfüllt per offizielle Vorgaben alle Voraussetzungen, dennoch weigert sich MSFT seinen Treiber zu signieren, resp. lässt den Singnaturvorgang fehlschlagen mit nichts aussagender Fehler Meldung und wen darauf angesprochen sagen sie sie wären nicht zuständig.
Also das ist doch schon mal starker Tobak!
Zudem ist da noch der teil mit Windows API's die nicht MSFT Programme nicht benutzen können, das schrammt doch auch knapp an der Illegalität!
Danke für die Klarstellung, aber ich bezog mich auch auf den ProzessHacker und nicht auf den TaskExplorer.
(und so eindeutig ist beim ProcessHacker die Lage nicht)
Darum gings ja in dem Blogbeitrag und der TaskExplorer wurde nur am Rande erwähnt.
Ah ok, also das der dmex irgendwas in richtung zu teuer geschrieben hätte wäre mir neu.
Das mit zu teuer war immer ein problem für TE und vor allem sandboxie.
Nein Moment mal!
Ich bin der David Xanatos und ich mach den Task Explorer, und mein TE hatte noch nie einen signierten Treiber.
Der da das schreibt ist der Dmex und der macht den ProcessHacker der schon immer mit korrekt signiertem Treiber angerückt ist.
Bitte uns beide nicht verwechseln.
Zudem habe ich inzwischen Zugang zu einem EV cert damit ist auch mein sandboxie-plus signiert, aber genau wegen solcher Probleme wie dmex da hat, werde ich es nicht riskieren mit dem cert ein TE Treiber zu signieren, ich brauch das cert ja für sandboxie-plus.
Apropos
https://www.neowin.net/news/microsoft-whql-signed-fivesys-driver-was-actually-malware-in-disguise/
Wirre Theorie: So kann und wird jede für den OS Hersteller "unliebsame" Drittsoftware, die Einblick in das, was real auf dem Rechner passiert, ermöglichen könnte, ausgebremst bzw. beseitigt werden. War da nicht was prinzipiell ähnliches bei Apple mit Little Snitch? Als weiteren Schritt kann man über "fehlende" Signaturen dann auch Konkurrenzsoftwae zur eigenen Office Suite usw. ausbremsen, alles für die Sicherheit.
Ja, die alten API's die Little Snitch benutzt hat wurden abgeschafft und an den neuem API's Konten alle Apple System Dienste vorbei ins Internet.
Hier mal ein anderer Dev der sich auch über die zugenagelten API's auslässt: https://blog.adeltax.com/window-z-order-in-windows-10/
In dem Fall nur eine UI API aber dennoch überaus ärgerlich was MSFT da veranstaltet.
1-DavdiX sagt: (23. Oktober 2021 um 10:44)
2-DavidXanatos sagt: (23. Oktober 2021 um 10:41)
Wer ist jetzt wer – was stimmt? Einer/eines ist iwie "gelogen"…
Es steckt bei beiden der Gleiche Kopf dahinter – David ist darüber gestolpert, dass ich einen Filter gesetzt habe, der alle gmail.com-Kommentare in den Papierkorb befördert. Aktuell steht der Blog massiv unter Beschuss von SEO-Spammern, die mir über wechselnde Absender-IPs Werbung für diverse Telco-Unternehmen in Asien unterjubeln möchten.
Ist zwar schon ein bischen her
Wie eine Suche nach
"Commonly Abused Legitimate Tools" ergibt,
wurde der Process Hacker von Ransom erfolgreich mißbraucht.
Das könnte auch ein Hintergrund sein.
Der Treiber könnte erlauben auf Ring 0 laufen
und natürlich von Ransomeware entführt werden.
Das Marketing macht dann gleich einen stunt daraus.