Windows Defender aufrufen

SideWinder

Hi!

Ich möchte den Windows Defender via C++ aufrufen. Das klappt schon ganz gut mittels MpScanStart (siehe https://docs.microsoft.com/en-us/windows/desktop/lwef/mpscanstart). Jetzt möchte ich eine Callback-Funktion registrieren die dann Fortschritts-Informationen bekommt, dafür scheint der Parameter pCallbackInfo genau der richtige zu sein, er ist vom Typ PMPCALLBACK_INFO (sprich Pointer auf MPCALLBACK_INFO).

Allerdings finde ich in der MSDN (im Gegensatz zu MpScanStart selbst) weder eine Doku für MPCALLBACK_INFO noch existiert die Header-Datei mpclient.h im Windows SDK. Wie finde ich jetzt heraus wie diese MPCALLBACK_INFO struct auszusehen hat?

In .NET könnte ich jetzt einfach die MpClient.dll disassemblen, habe das sogar mit HexRays für C probiert, aber da stimmt für MpScanStart nicht einmal die Parameteranzahl (auch die Größe der Parameter insgesamt stimmt nicht überein), scheint also nicht so einfach zu sein.

Ideen?

MfG SideWinder

hustbaer

Ich nehme an du verwendest Visual Studio. Schreib MPCALLBACK_INFO* foo; in eine deiner Funktionen, stell den Cursor irgendwo innerhalb von MPCALLBACK_INFO rein und drücke F12.
Tadaa.

EDIT:

noch existiert die Header-Datei mpclient.h im Windows SDK

Sorry, hatte ich überlesen.

Th69

Ich denke, bei MPCALLBACK_INFO handelt es sich um MPCALLBACK_DATA, welches ja auch in der Doku direkt referenziert wird: MPCALLBACK_DATA.

PS: Habe auch d(ein)en SO-Beitrag Callback function for MpScanStart gefunden. Dort wird ja in einem der Kommentare auf MpClient.h verwiesen. Auch dort gibt es nur MPCALLBACK_DATA(und nicht MPCALLBACK_INFO).

hustbaer

MPCALLBACK_DATA ist mit "data passed to the callback function" dokumentiert. Die Callback-Funktion muss also noch irgendwo anders definiert sein. Und eine MPCALLBACK_DATA Instanz an MpScanStart zu übergeben würde keinen Sinn machen.

@th69 sagte in Windows Defender aufrufen:

Dort wird ja in einem der Kommentare auf MpClient.h verwiesen. Auch dort gibt es nur MPCALLBACK_DATA(und nicht MPCALLBACK_INFO).

Das ist bloss leider ziemlich sicher nicht das original Header-File. Das scheint MS nämlich einfach nicht auszuliefern. Womit jetzt auch klar wäre dass wir hier ein kleines Problem haben.

Th69

Das Readme zu dem Projekt MpEnum liest sich aber anders:

Build

MpEnum comes with full source code written in C. Please note that included MpClient.h is build on official available Microsoft documentation with fixes and updates that actually make it work. It maybe different from MS private version. In order to build from source you need Microsoft Visual Studio 2015 and later versions.

hustbaer

Da steht genau das was ich vermutet habe. Vielleicht nochmal lesen?
Du kannst auch davon ausgehen dass der Callback-Parameter von MpScanStart Bullshit ist, und da drin einfach überlebt hat weil es keiner ausprobiert hat. Oder evtl. weil es keiner zum Laufen gebracht hat, sie dann aufgegeben haben und einfach irgendwas reingeschrieben statt void* weHaveNoIdeaWhatThisReallyPointsTo reinzuschreiben.

Ein Zeiger auf MPCALLBACK_DATA an dieser Stelle ist auf jeden Fall semantisch Quatsch und die MS Doku sagt auch dass es eben nicht ein Zeiger auf MPCALLBACK_DATA ist.

Th69

Ja, du hast Recht.

Es müßte mindestens ein Funktionszeiger sein (bzw. enthalten sein), welcher dann MPCALLBACK_DATAals Parameter hat.

In dem Projekt wird, soweit ich gesehen habe, MpScanStart auch nicht benutzt.

Edit:
Ich würde es mit folgender Struktur versuchen:

typedef struct tagMPCALLBACK_INFO {
    int padding[N];
    void (*fCallback)(PMPCALLBACK_DATA data);    
} MPCALLBACK_INFO, *PMPCALLBACK_INFO;

(und dann N entsprechend von 0-X durchprobieren, bis MpScanStart keinen Fehler zurückgibt und die Callback-Funktion aufgerufen wird - anschließend natürlich dann noch schauen, ob die Parameter der Callback-Funktion so passen).

SideWinder

Danke mal für euren Input!

Hm, gute Idee Th69, tatsächlich, mit einem entsprechendem Padding "funktioniert" es. Meine Callback-Funktion wird aufgerufen ... wenn auch der MPCALLBACK_DATA Parameter noch falsch ist (sein muss, weil nur nonsens drinsteht). Evtl. ist dort auch ein Padding notwendig, weil im Original noch ein anderer Parameter vorher steht...

Aber mir ist das alles zu unsicher, was wenn eigentlich ein Return-Value verlangt wird, was wenn die als Padding etwas übergebe was gar nicht meine Intention ist...Gibt's da echt mit native DLLs so gar keine Möglichkeiten das im Nachhinein herauszufinden? Die DLL hab ich ja...ich bin so verwöhnt aus dem .NET Bereich. Dort kann ich mir jeglichen Source-Code ansehen : o

MfG SideWinder

hustbaer

Ich wüsste nicht wie. Also klar, Disassembler/Decompiler und raten/beten dass man nix falsch gemacht/alles richtig verstanden hat. Die wirklich guten Disassembler (z.B. IDA) kosten allerdings $$$.

Die API ist aber anscheinend sowieso deprecated - "Legacy Windows Environment Features". Header/Import-Lib File hat's wohl auch nie gegeben. Also vermutlich nicht so voll die gute Idee sein Programm davon abhängig zu machen.

Martin Richter

Was spricht dagegen eine Supportanfrage zu stellen bei MS?

SideWinder

@martin-richter Du meinst abgesehen vom Preis?

@hustbaer: Ja, stimmt. Hmm. Das neuere AMSI Interface funktioniert zwar und ist gut dokumentiert, dafür gibt es kaum Informationen aus die über "Virus Ja/Nein" hinausgehen. Gibt es andere Wege programmatisch via Windows Boardmittel ein File auf Viren hin zu überprüfen? Wenn ich verzweifelt werde muss ich den Windows Defender via Process.Start aufrufen und seinen Output parsen

MfG SideWinder

Martin Richter

@SideWinder
Wieso Preis? Die meisten Softwarehäuser sind Microsoft Partner. Da habt Ihr x Anfragen frei.
Wenn Ihr ein ISV als Partner seid verdoppelt sich fast die Anfragezahl.

Ansonsten in einer MS community (also bei Answers Anfragen) Manchmal treiben sich auch Microsofties dort herum und beantworten vernünftig und gut.

Weiterhin gibt es Stackoverflow, wo sich eigentlich alles herumtreibt was Rang Namen und Grips hat.

Wir verbrauchen unsere Anfragen nie. Bei berechtigten Anfragen (Bugs) wird nicht mal was abgezogen...