CTL_CODE Funktion in Delphi

[peanut]

Hallo,

hat jemand zufälligerweise ein DDK installiert und kann mir kurz den Wert IOCTL_PROCVIEW_GET_PROCINFO berechnen:

#define FILE_DEVICE_UNKNOWN 0x00000022
#define IOCTL_PROCVIEW_GET_PROCINFO CTL_CODE(FILE_DEVICE_UNKNOWN, 0x0800, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)

ich habe zwar ne Delphi CTL_CODE-Variante im Internet gefunden

Delphi-Quellcode:

function CTL_CODE(DeviceType, _Function, Method, Access: Cardinal): Cardinal;
begin
  Result := (DeviceType shl 16) or (Access Shl 14) or (_Function shl 2) or (Method);
end;

aber anscheinend ist die nicht richtig oder ich vermurkse sonst noch etwas bei der Kommunikation mit dem Treiber...

Noch eine Frage: Ist BOOLEAN in C++ äquivalent zu Boolean in Delphi?

Danke im Voraus!!!

Viele Grüße

peanut.

[Der_Unwissende]

Zitat:

Zitat von peanut

Noch eine Frage: Ist BOOLEAN in C++ äquivalent zu Boolean in Delphi?

Hi,
ich denke dass ist nicht der Fall. Ich kann mich da natürlich auch irren, aber Boolean in Delphi ist imho nur 1 Byte groß. In C++ verwendet man hingegen einen 4 Byte Wert (LongBool in Delphi). Das hat Perfomancegründe.
Was du sonst unter äquivalent verstehst ist halt so eine Sache. Selbst für C gilt schon, dass die Wert 1,2,3,4,... und -1,-2,.. alle äquivalent sind, was den Wahrheitswert angeht. Es wird nur 0 und nicht 0 unterschieden, ein direkter Vergleich ob zwei Werte gleich sind ist also eine nicht sinnvolle Aussage (wenn es um Wahrheitswerte geht), ob beide ungleich null sind wäre hingegen eine sinnvolle Aussage.

Gruß Der Unwissende

[OregonGhost]

In C++ gibt es nur den Typ bool. Ich weiß nicht, inwieweit der Ähnlichkeiten mit dem Delphi-Boolean hat. BOOLEAN hingegen ist eine Definition der Windows-API und sie müsste kompatibel zu Delphis LongBool sein.

[Christian Seehase]

Moin Peanut,

also ich erhalte da $0022E000 als Ergebnis.
Die Werte kannst Du übrigens aus der WinIoCtl.h aus dem PSDK erhalten.

Die Funktion sieht auch gut aus.

Woher hast Du eigentlich IOCTL_PROCVIEW_GET_PROCINFO ?
Das kann ich auch im DDK (Windows 2003) nicht entdecken.

[peanut]

Hallo,

um die Situation zu klären: Ich verwende einen Treiber von Ivo Ivanov (CodeProject: http://www.codeproject.com/threads/procmon.asp). Dieser sollte einem beim Erstellen und Beenden eines Prozesses über einen Event bescheid geben.

Ich möchte dann mittels

DeviceIoControl() und GetOverlappedResult()

die von ihm definierte Datenstruktur

typedef struct _CallbackInfo
{
HANDLE hParentId;
HANDLE hProcessId;
BOOLEAN bCreate; // (*)
}CALLBACK_INFO, *PCALLBACK_INFO;

auslesen. Leider scheitert bei mir folgender Aufruf

Delphi-Quellcode:

DeviceIoControl(m_hDriver, IOCTL_PROCVIEW_GET_PROCINFO, nil, 0, @CallbackInfo^, SizeOf(TCallbackInfo), dwBytesReturned, @ov)

Ich denke, dass es vielleicht an meiner TCallbackInfo-Datenstruktur liegt:

Delphi-Quellcode:

 TCallbackInfo = record
    ParentId : THANDLE;
    ProcessId: THANDLE;
    bCreate  : LongBool;
 end;
 PCallbackInfo = ^TCallbackInfo;

Nun wollte ich wissen, welches Delphi-Boolean nun dem BOOLEAN Typ aus C++ entspricht, siehe (*), denn THandle = HANDLE => das kann demnach nicht falsch sein. Auch das Initialisieren des Treibers und Warten bis ein Event gefeuert wird funktioniert, nur der Aufruf mittels DeviceIoControl scheitert.

Zitat:

Christian Seehase schrieb:

also ich erhalte da $0022E000 als Ergebnis.
...
Woher hast Du eigentlich IOCTL_PROCVIEW_GET_PROCINFO ?
Das kann ich auch im DDK (Windows 2003) nicht entdecken.

Danke, auch ich erhalte $0022E000 als Ergebnis, daran kann es also nicht liegen, dass ich Probleme beim Lesen vom Treiber habe...

Was die CTL_CODE Funktion betrifft. Ivo hat mit IOCTL_PROCVIEW_GET_PROCINFO wohl einen eigenen IoControlCode eingeführt, keine Ahung wieso? Definiert hatte er ihn aber wie folgt:

#define FILE_DEVICE_UNKNOWN 0x00000022
#define IOCTL_UNKNOWN_BASE FILE_DEVICE_UNKNOWN
#define IOCTL_NTPROCDRV_GET_PROCINFO CTL_CODE(IOCTL_UNKNOWN_BASE, 0x0800, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)

somit müsste doch IOCTL_NTPROCDRV_GET_PROCINFO auch ein FILE_DEVICE_UNKNOWN sein oder???

Viele Grüße

peanut.

[Christian Seehase]

Moin Peanut,

in der Winnt.h ist BOOLEAN als BYTE deklariert, dürfte also im Wesentlichen dem Delphi-Boolean entsprechen.
Probier auch mal die Struktur als Packed zu deklarieren.

Klingt alles interessant.
Vielleicht komme ich morgen mal dazu mir den Artikel durchzulesen, und die Sourcen anzusehen.

[Robert Marquardt]

BOOLEAN ist als Byte deklariert, waehrend BOOL als DWORD deklariert ist. Die Entsprechung ist daher ByteBool fuer BOOLEAN bzw LongBool fuer BOOL.
Records in DDK-C-Headern sind gerne auf 1-Byte-Grenze gepackt.
Das CTL_CODE Makro sollte man nicht in eine Funktion ueberfuehren, denn dann hat man keine Konstante die der Compiler direkt handhaben kann.

[peanut]

Hallo!

Vielen Dank für die Informationen. Ich habe die Datenstruktur nun als packed deklariert und den Booleanwert geändert. Statt des CTL_CODE Makros habe ich direkt eine Konstante mit dem entsprechenden Wert definiert.

UND...... es hat funktioniert!!! :-D

Nochmals DANKE! Wenn Interesse besteht, kann ich den Sourcecode hier rein posten. Es ist interessant, wenn man weiß, welcher Prozess wann gestartet und beendet wird.

Viele Grüße

peanut.

[Olli]

Zitat:

Zitat von peanut

Es ist interessant, wenn man weiß, welcher Prozess wann gestartet und beendet wird.

Interessant ja, aber der Mechanismus ist eigentlich für "andere Kundschaft" gedacht als für den Enduser. Wenn man bedenkt, daß es nur 8 Slots gibt, um als Treiber eine Callback zu registrieren, versteht man das sicher :zwinker:

[peanut]

Zitat:

Interessant ja, aber der Mechanismus ist eigentlich für "andere Kundschaft" gedacht als für den Enduser. Wenn man bedenkt, daß es nur 8 Slots gibt ...

Werden wirklich alle 8 Slots gebraucht? Ich könnte mir da nur einen Virenscanner, IDS und vielleicht noch ne Firewall mit Application-Gateway als "üblich Verdächtige" vorstellen, dann ist aber noch immer 1 Platz für meine kleine Überwachungsanwendung frei.

Nachdem ich in letzter Zeit von einem Fettnäpfchen ins nächste tappe: Kann mir jemand ein Buch empfehlen, das einem einen guten Überblick über die tiefere System-API gibt inkl. Verweise was sich gehört und was man aus Effizienz- oder anderen Gründen lieber sein lässt. DANKE :)

[Olli]

Zitat:

Zitat von peanut

Zitat:

Interessant ja, aber der Mechanismus ist eigentlich für "andere Kundschaft" gedacht als für den Enduser. Wenn man bedenkt, daß es nur 8 Slots gibt ...

Werden wirklich alle 8 Slots gebraucht? Ich könnte mir da nur einen Virenscanner, IDS und vielleicht noch ne Firewall mit Application-Gateway als "üblich Verdächtige" vorstellen, dann ist aber noch immer 1 Platz für meine kleine Überwachungsanwendung frei.

Im Grunde ist jeder Dateisystemfilter ein verdächtiger, weil die das nämlich gut gebrauchen können. Und da gibt's auf so ziemlich jedem System schon mehr als 8 - auch ohne AV. Natürlich nutzen es trotzdem nicht alle.

Zitat:

Zitat von peanut

Nachdem ich in letzter Zeit von einem Fettnäpfchen ins nächste tappe: Kann mir jemand ein Buch empfehlen, das einem einen guten Überblick über die tiefere System-API gibt inkl. Verweise was sich gehört und was man aus Effizienz- oder anderen Gründen lieber sein lässt. DANKE :)

Gibt's nicht wirklich, weil es tiefer auf 2 Ebenen gibt:
- Native API (UM)
- Native API (KM) + Rest vom KM

UM == User-Mode
KM == Kernel-Mode

Ich stehe dir gern per PM zur Verfügung, soweit es meine Zeit zuläßt. Vielleicht könnten wir gemeinsam einen Artikel zu diesem Thema verfassen - für das "de-delphi"-Projekt auf SF.net!

[himitsu]

Zu dem BOOLEAN



wenn das wirklich ByteBoll ist, dann sollte das wohl auch besser als ByteBoll definiert werden und nicht mal einfach so als Boolaen(Delphi)

ich glaub das war so:

Delphi-Quellcode:

ByteBool(True) = $FF
Boolean(True)  = $01

ByteBool(False) = $00
Boolean(False)  = $00

ach ja, die C-Header im PSDK sind wohl an 8 Byte-Grenzen gepackt ... warum MS das im DDK anscheinend anders gemacht hat ... keine Ahnung ._.

[Olli]

Zitat:

Zitat von himitsu

... warum MS das im DDK anscheinend anders gemacht hat ... keine Ahnung ._.

Ich versuch's mal kurz zu umreissen: jeder Thread hat im KMode nur ca. 12kB Stack (Ausnahme GUI-Threads, die haben ~64kB). Es gibt keinen trivialen (geschweige denn dokumentierten) Weg um den eigenen Thread im KMode zum GUI-Thread zu promoten ...

Reicht das? :zwinker: :mrgreen:

Nachtrag: natürlich wissen wir ja alle, daß wir lieber Puffer mit Pointern benutzen sollten (über ExAllocatePoolWithTag), aber wenn man eben doch mal eine Struktur direkt auf dem Stack zu liegen hat, kann das kleinste Byte über Wohl oder Wehe des Threads entscheiden.

[peanut]

Zitat:

Olli hat folgendes geschrieben:
Ich stehe dir gern per PM zur Verfügung, soweit es meine Zeit zuläßt. Vielleicht könnten wir gemeinsam einen Artikel zu diesem Thema verfassen - für das "de-delphi"-Projekt auf SF.net!

Danke! Was den Artikel betrifft: Kein Problem, würde ich gerne schreiben.

[peanut]

Hallo,

anbei der Code zum Thema. Ich habe ihn überarbeitet und festgestellt, dass es auch ohne packed-Deklaration funktioniert.

Delphi-Quellcode:

{
  Based on an article and code by Ivo Ivanov at The Code Project: Detecting Windows NT/2K process execution
  url: [url]http://www.codeproject.com/threads/procmon.asp[/url]

  PLEASE NOTE: Download driver 'NTProcDrv.sys' at the url noted above!!!
}
program NTDriverController; {$APPTYPE CONSOLE}

uses
  SysUtils, Windows, psapi, WinSvc;

type

 TCallbackInfo = record
    ParentId : THANDLE;
    ProcessId: THANDLE;
    bCreate  : ByteBool;
 end;
 PCallbackInfo = ^TCallbackInfo;

const
  IOCTL_PROCVIEW_GET_PROCINFO = $0022E000; //CTL_CODE(FILE_DEVICE_UNKNOWN, 0x0800, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)

var
  m_hSCM             : SC_HANDLE;
  m_hDriver          : SC_HANDLE;
  nServiceStatus     : SERVICE_STATUS;
  
  strServiceName     : String = 'NTProcDrv';
  strDisplayName     : String = 'Process creation/termination detector for Windows XP';
  strFileName        : String = '';
  lpServiceArgVectors: PAnsiChar = nil;

  m_hShutDownEvent   : THandle;

////////////////////////////////////////////////////////////////////////////////

function GetExeNameByPID(dwPID: DWord): String;
var
  h: THandle;
begin
  Result := '';
  h := OpenProcess(PROCESS_QUERY_INFORMATION or PROCESS_VM_READ, False, dwPID);
  if (h <> 0) then
  try
    SetLength(Result, MAX_PATH);
    ZeroMemory(@Result[1], MAX_PATH);
    SetLength(Result, GetModuleFileNameEx(h, 0, @Result[1], MAX_PATH));
  finally
    CloseHandle(h);
  end;
  Result := LowerCase(Result);
end;

////////////////////////////////////////////////////////////////////////////////

function KeyboardThread(dwArg: DWORD): DWORD;
var
  nEvents  : Cardinal;
  dwNumRead: DWORD;
  InputRec : TInputRecord;
begin
  Result := 0;
  while (true) do
  begin
    GetNumberOfConsoleInputEvents(GetStdHandle(STD_INPUT_HANDLE), nEvents);
    if (nEvents > 0) then
    begin
      ReadConsoleInput(GetStdHandle(STD_INPUT_HANDLE), InputRec, 1, dwNumRead);
      if (InputRec.Event.KeyEvent.AsciiChar = 'q') then break;
    end;
    Sleep(800);
  end;
  writeln('# shutting down, please wait...');
  SetEvent(m_hShutDownEvent);
  ExitThread(0);
end;

////////////////////////////////////////////////////////////////////////////////

function WaitForState(dwDesiredState: DWORD; pss: SERVICE_STATUS): Boolean;
var
  dwWaitHint: DWORD;
begin
  Result := False;
  if (m_hDriver <> 0) then
    while (True) do
    begin
      // Get current state of driver
      Result := QueryServiceStatus(m_hDriver, pss);
      // If we can't query the driver, we're done
      if not(Result) then 
        break;
      // If the driver reaches the desired state
      if (pss.dwCurrentState = dwDesiredState) then 
        break;
      // We're not done, wait the specified period of time
      dwWaitHint := pss.dwWaitHint div 10;  // Poll 1/10 of the wait hint
      if (dwWaitHint <  1000) then dwWaitHint := 1000;  // At most once a second
      if (dwWaitHint > 10000) then dwWaitHint := 10000; // At least every 10 seconds
      Windows.Sleep(dwWaitHint);
    end;
end;

////////////////////////////////////////////////////////////////////////////////

procedure RetrieveProcessInfo(hDriver: THandle; CallbackInfo, CallbackTemp: PCallbackInfo);
var
  dwBytesReturned: DWORD;
  ov             : OVERLAPPED;
begin
  ZeroMemory(@ov, SizeOf(OVERLAPPED));
  dwBytesReturned := 0;

  ov.hEvent := CreateEvent(nil, True, False, nil);
  if DeviceIoControl(hDriver, IOCTL_PROCVIEW_GET_PROCINFO, nil, 0, @CallbackInfo^, SizeOf(TCallbackInfo), dwBytesReturned, @ov) then
    GetOverlappedResult(m_hDriver, ov, dwBytesReturned, True)
  else
    writeln('! Error while DeviceIoControl, code: ' + IntToStr(GetLastError));

    if ((callbackTemp^.ParentId <> callbackInfo^.ParentId) or (callbackTemp^.ProcessId <> callbackInfo^.ProcessId) or (callbackTemp^.bCreate <> callbackInfo^.bCreate)) then
    begin
      if(callbackInfo^.bCreate) then
      begin
        Sleep(300); // sleep some ms or image name could not be determinated :-(
        writeln('# process created, PID   : ' + IntToStr(callbackInfo^.ProcessId) + ' ' + GetExeNameByPID(callbackInfo.ProcessId))
      end else
        writeln('# process terminated, PID: ' + IntToStr(callbackInfo^.ProcessId));
    end;

  CloseHandle(ov.hEvent);

  // Store the data for next time to prevent doubled events
  callbackTemp^ := callbackInfo^;
end;

////////////////////////////////////////////////////////////////////////////////

procedure ProcessMonitor;
var
  szDriverName   : String;
  hDriver        : THandle;
  m_hProcessEvent: THandle;
  CallbackInfo   : TCallbackInfo;
  CallbackTemp   : TCallbackInfo;
  lpHandles      : TWOHandleArray;
  dwResult       : DWORD;
  dwThreadID     : DWORD;
begin
  szDriverName := '\\.\Global\NTProcDrv'#0; // Change to '\\.\NTProcDrv'#0 if CreateFile failes...

  hDriver := CreateFile(@szDriverName[1], GENERIC_READ or GENERIC_WRITE, FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
  if (hDriver <> INVALID_HANDLE_VALUE) then
  begin
    m_hShutdownEvent := CreateEvent(nil, False, False, nil);
    m_hProcessEvent := OpenEvent(SYNCHRONIZE, False, 'NTProcDrvProcessEvent');

    ZeroMemory(@lpHandles, SizeOf(lpHandles));
    lpHandles[0] := m_hShutdownEvent;
    lpHandles[1] := m_hProcessEvent;

    CreateThread(nil, 0, @KeyboardThread, nil, 0, dwThreadID);
    
    ZeroMemory(@CallbackInfo, SizeOf(TCallbackInfo));
    ZeroMemory(@CallbackTemp, SizeOf(TCallbackInfo));

    while (True) do
    begin
      dwResult := WaitForMultipleObjects(2, @lpHandles, False, INFINITE);
      if (dwResult = 0) then
        break; // user pressed 'q'
      RetrieveProcessInfo(hDriver, @CallbackInfo, @CallbackTemp);
    end;
    Sleep(1000); // ExitThread(0) and cleaning stack might take some ms

    CloseHandle(m_hProcessEvent);
    CloseHandle(m_hShutdownEvent);
    CloseHandle(hDriver);
  end;
end;

////////////////////////////////////////////////////////////////////////////////

begin
  writeln('# opening Servive Control Manager (SCM)...');
  m_hSCM := OpenSCManager(nil, nil, SC_MANAGER_ALL_ACCESS);
  if (m_hSCM <> 0) then
  begin
    writeln('# opened SCM');
    strFileName := ExtractFilePath(ParamStr(0)) + strServiceName + '.sys';

    m_hDriver := OpenService(m_hSCM, PChar(strServiceName), SERVICE_ALL_ACCESS);
    if (m_hDriver <> 0) then
    begin
      if ControlService(m_hDriver, SERVICE_CONTROL_STOP, nServiceStatus) then
        WaitForState(SERVICE_STOPPED, nServiceStatus);
      DeleteService(m_hDriver);
      CloseServiceHandle(m_hDriver);
      writeln('! driver was not deleted last time.');
      CloseServiceHandle(m_hDriver);
      Sleep(1000);
    end;
    
    m_hDriver := CreateService(m_hSCM, PChar(strServiceName), PChar(strDisplayName), SERVICE_ALL_ACCESS, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, SERVICE_ERROR_NORMAL, PChar(strFilename), nil, nil, nil, nil, nil);
    if (m_hDriver <> 0) then
    begin
      writeln('# service created, starting kernel driver...');
      if (StartService(m_hDriver, 0, lpServiceArgVectors)) then
        WaitForState(SERVICE_RUNNING, nServiceStatus)
      else begin
        DeleteService(m_hDriver);
        CloseServiceHandle(m_hDriver);
        CloseServiceHandle(m_hSCM);
        writeln('! error while starting driver');
        exit;
      end;
      writeln('# kernel driver started');

      // interact with driver now...
      ProcessMonitor;

      writeln('# stopping kernel driver...');
      if ControlService(m_hDriver, SERVICE_CONTROL_STOP, nServiceStatus) then
        WaitForState(SERVICE_STOPPED, nServiceStatus)
      else
        writeln('! could not stop kernel driver');

      // Mark the service for deletion.
      if DeleteService(m_hDriver) then
        writeln('# service deleted')
      else
        writeln('! could not delete service');

      CloseServiceHandle(m_hDriver);
    end;
    CloseServiceHandle(m_hSCM);
  end;
  Sleep(1000);
end.

[Olli]

Zitat:

Zitat von peanut

Ich habe ihn überarbeitet und festgestellt, dass es auch ohne packed-Deklaration funktioniert.

Das ist korrekt. Packed hat dann eine Auswirkung, wenn sich ein Element, welches nicht "ausgerichtet" ist, zwischen anderen ausgerichteten Elementen befindet. Bsp., nähmen wir folgende Records an:

Delphi-Quellcode:

 TCallbackInfo1 = packed record
    ParentId : THANDLE;
    bCreate  : ByteBool;
    ProcessId: THANDLE;
 end;

 TCallbackInfo2 = record
    ParentId : THANDLE;
    bCreate  : ByteBool;
    ProcessId: THANDLE;
 end;

sizeof(TCallbackInfo2) == 12
sizeof(TCallbackInfo1) == 9

Übrigens, wenn du deinen Code noch etwas würzen willst, könntest du PutBinResTo benutzen und den Treiber in dein Programm einbetten.

[peanut]

Zitat:

Zitat von Olli

Übrigens, wenn du deinen Code noch etwas würzen willst, könntest du PutBinResTo benutzen und den Treiber in dein Programm einbetten.

:-D Werde ich machen, danke.

[Olli]

Ist nicht nur Kosmetik. Ich hatte vergessen, daß die etwas ausgereiftere Variante ExtractResTo heißt.

[peanut]

Zitat:

Zitat von Olli

Ist nicht nur Kosmetik.

Habe das bei Tools von Mark Russinovich und anderen bemerkt...das machen also die Profis! Ich dachte mir zwar, dass dies über Ressourcen sicher gut realisierbar wäre, hatte aber noch nicht wirklich an eine Umsetzung gedacht. :zwinker:

Gruß peanut.

[Olli]

Zitat:

Zitat von peanut

Habe das bei Tools von Mark Russinovich und anderen bemerkt...das machen also die Profis! Ich dachte mir zwar, dass dies über Ressourcen sicher gut realisierbar wäre, hatte aber noch nicht wirklich an eine Umsetzung gedacht. :zwinker:

Allerdings. Das hat ihm einer von den Jungs bei OSR gezeigt (lt. Bekunden eben jener Jungs ;)). Ich benutze das, wie man anhand der Postdaten sehen kann, auch schon seit Jahren. Mit dem Rootkit Remover hat's der Code sogar in ein quasi kommerzielles Produkt geschafft ;)

Macht sich besonders bei Treibern sehr sehr schön.

[himitsu]

szDriverName könntest du auch als Konstante deklarieren ... sie bräuchte dann och keinen eigenen Platz im RAM.
Und die #0 könnte auch weg ... Delphi-Strings sind ja schon von Haus aus #0-terminiert.

[peanut]

Hallo,

baue gerade meine eigene Version des Treibers... Wenn es fertig ist, poste ich das gesamte Paket hier rein.

Zitat:

Zitat von Olli

Allerdings. Das hat ihm einer von den Jungs bei OSR gezeigt...

Das hätte ich nicht gedacht :shock: , dachte immer, er ist "einer DER Gurus"...???

Zitat:

Zitat von himitsu

szDriverName könntest du auch als Konstante deklarieren ...
Und die #0 könnte auch weg...

szDriverName als Konstante ohne #0 deklariert, danke.

Viele Grüße

peanut.