Impressum: Andreas Hötker Buddenkamp 12 49324 Melle Deutschland (Germany) E-Mail: andreas.hoetker'at'ah-shareware.de ('at' bitte durch @ ersetzen!) Telefon: D-05422/46946 Downloads: BJack Ein kleines in Profan programmiertes Kartenspiel, Vor einigen Jahren von meinem Sohn und mir erstellt. Die kleine Mathemaus Die kleine Mathemaus ist ein kleines Lernprogramm für Windows 95/98 und Windows 3.1 um das Kopf- und schriftliche Rechnen zu trainieren. Dabei werden Fähigkeiten im Einmaleins, im Plus- und Minusrechnen geprüft. Außerdem gibt es die Möglichkeit freie Aufgaben zu erstellen, wie zum Beispiel Umrechnungsaufgaben oder die Lösung Binomischer Formeln. Am Ende gibt es die Möglichkeit, ein frei wählbares Belohnungsspiel zu spielen. Die Zeit, die man spielen darf, hängt ab von den erreichten Punkten. Optional wird der PC dann heruntergefahren. Rechtschreibung für Mäuse Das Programm Rechtschreibung für Mäuse ist ein Programm für Windows 95/98 und Windows 3.1, beim dem auf dem Prinzip der Veränderung durch Anklicken das richtig geschriebene Wort gewählt werden soll. Bei einer falschen Auswahl wird eine Regel zur Rechtschreibung oder ein Hinweis genannt. Zur Belohnung kann im Anschluss an das Programm ein frei einstellbares Spiel gespielt werden, das sich in Abhängigkeit von der Punktzahl selbst beendet. Das Programm ist in Profan, Version 6.0 geschrieben. Alle Funktionen Sind in der Hilfe Datei zu diesem Programm erklärt. PC-Zeitkonto Kleine Bemerkung am Anfang: Auch das Spielen und Ausprobieren des PC´s gehört zum Lernen dazu. Doch manchmal kennen die Kinder hier kein Maß. Muss deshalb gleich die ganze Freizeit dafür verloren gehen? Oft leiden sogar die Freundschaften unter dem PC-Konsum! Was kann man tun? Mein Programm leistet hier Hilfe. Zum Programm: Das PC-Zeitkonto ist ein kleines Programm, mit dem es möglich ist, Ihren Kindern für einen von Ihnen bestimmbaren Zeitraum eine beliebige Zeit am PC zur Verfügung zu stellen. Das Programm läuft dabei im Hintergrund mit und fährt Windows herunter, sobald die Zeit verstrichen ist. Das Programm ist getestet unter Windows 95/98/2000/XP. Was bietet mein Programm? - Große Einstellmöglichkeiten für die Zeitvergabe - Kleiner Passwortschutz für Windows - Es ist möglich, eine für jeden User einstellbare Tageszeit einzugeben, ab der Windows erst gestartet werden kann. - Es kann auch eine Tageszeit eingegeben werden, nach der Windows nicht mehr gestartet werden kann. - Es können anhand des Fenstertitels verbotene Programme festgelegt werden, bei deren Start Windows automatisch herunterfährt - ....... usw. ....... Systemvoraussetzungen: - Windows 95/98/2000/XP - 3 MB freier Festplattenspeicher - Soundkarte (wünschenswert) - Mindestens zwei installierte Benutzer unter Windows mit Administratorrechten für die Eltern Easy CD-Covering Ein noch zu meinen Windows 3.1 Zeiten entstandenes Tool um CD-Hüllen, Inlays und Aufkleber selbst zu erstellen. Das Programm ist selbsterklärend, einfach zu bedienen und sucht sogar auf Festplatten und CD´s nach vorhandenen Bitmaps im BMP-Format. Easy CD-Covering ist in Profan² Version 6.0 geschrieben. Alle Funktionen Sind in der Hilfe Datei zu diesem Programm erklärt. Was bietet mein Programm ? - Eine kinderleichte Bedienung. - Suche und Einbindung der auf Ihrem PC vorhandenen Bitmaps zur Erzeugung eines Hintergrundbildes. Systemvoraussetzungen: - ab Windows 95 - ab 486/66MHz Prozessor - 1 MB freier Festplattenspeicher - 4 MB RAM - Soundkarte (nicht unbedingt) - mindestens Highcolor Grafiktreiber PrivAktivate Programmbeschreibung: Da ein Admin unter Windows2000/XP zwar alle Privilegien hat, diese aber längst nicht alle aktiv sind, hatte ich irgendwann einmal das Bedürfnis zu erfahren, was genau passiert wenn ich für bestimmte Anwendungen bei deren Ausführung Privilegien gezielt aktivieren. Daraus entstanden ist das erst nur aus mehreren Checkboxen bestehende "Abfallprodukt" PrivAktivate. Im Laufe der Zeit sind weitere verschiedene Eingriffsmöglichkeiten in das Windows(-NT) Sicherheitssystem hinzugekommen. Die neuese Version ist jetzt (nach einigen Schwierigkeiten) mit Profan2Cpp compiliert. Was kann PrivAktivate: - Privaktivate kann eine Anwendung starten und in deren Token (=Speicherbereich, der Infos über den User enthält, der einen Prozess ausführt) Privilegien aktivieren (natürlich nur, sofern diese vorhanden sind). - PrivAktivate kann einer Gruppe oder einem bestimmten User nicht vorhandene Privilegien hinzufügen. Ein anschließender Reboot ist Pflicht! - Privaktivate kann vorhandene Privilegien von einer Gruppe oder einem User entfernen. - PrivAktivate kann Policies, das sind in der Registry festgeschriebene Zugriffsbeschränkungen für Systemprogramme, setzen und entfernen. - PrivAktivate kann Zugriffsrechte auf Ordner, Dateien, Prozesse, Threads und die Registry editieren. Zugriffsrechte sind Rechte, die vorhanden sein müssen, um ein bestimmtes Handle in einer bestimmten Art und Weise (z.B. zum Schreiben oder Lesen) öffnen zu können. - PrivAktivate kann unter Windows2000/XP einen StringSID im Dateisystem oder der Registry direkt in einen Gruppen- oder Usernamen umwandeln und diesen anzeigen. - PrivAktivate kann Unicode-Strings in einer Registrystruktur als Zeichenfolge anzeigen. - PrivAktivate kann erweiterte Informationen über einen Registryschlüssel anzeigen, wie z.B. Anzahl von Unterschlüsseln und Werten etc. - PrivAktivate kann alle im System vorhandenen Fenster in deren Zusammenhang auflisten - PrivAktivate kann den Token eines Prozesses auslesen und dessen Informationen anzeigen Tasks and Token (TNT) Neugier ist der Ursprung allen Forschungsdrangs; und Ende 2005 hatte mich die Neugier ganz und gar gepackt. Kann man den Inhalt einer Listbox oder Listview irgendwie komplett in einem Rutsch an eine andere Stelle kopieren? Sind bestimmte Speicherbereiche eines Fensters immer an der gleichen Adresse zu finden? Welche Exportfunktionen befinden sich in einer DLL? Kann man irgendwie an deren Parameter kommen?? Warum werden Prozesse immer mit bestimmten Rechten gestartet, obwohl ich gar keine Zugriffsrechte direkt festlege? Welche Privilegien müssen aktiviert werden um sie zu benutzen und welche nicht? Wie sind in etwa fremde Programme aufgebaut und welche optischen und programmtechnischen Spielereien werden dort benutzt? Wofür sind einzelne Threads in fremden Programmen zuständig? Fragen sind wie geschlossene Türen - und hinter jeder dieser Türen befinden sich neue Möglichkeiten und Ideen. Um Türen zu öffnen zu denen man den Schlüssel nicht hat, benötigt man Werkzeug - und aus diesem Gedanken heraus ist 'Tasks and Token' (TNT) entstanden, ein Proggi das mir helfen sollte, verschlossene Türen einen ganz kleinen Spalt weit zu öffnen um einen Blick zu riskieren. Einen Blick, bei dem ich dann doch wesentlich mehr gesehen habe, als ich mir am Anfang ausgemalt habe und der auch an einigen Stellen schon Früchte getragen hat... Was kann TNT? 1.) Verschlossene Türen öffnen: TNT kann Zugriffsrechte auf Prozesse, Threads, den Access-Token und Prozessspeicher ändern oder sich selbst als Systemservice starten und sich so mehr Möglichkeiten verschaffen, Daten fremder Prozesse auszulesen und zu ändern... 2.) Daten lesen: TNT kann den Userspeicher fremder Prozesse und dessen Attribute auslesen und dort nach Daten suchen. Ausgelesene Daten können in die Zwischenablage kopiert werden. Außerdem können Heaps fremder Prozesse mit ihren Speicherblöcken gelistet und ausgelsesen werden. Eine Zuordnung von Handles zu bestimmten Speicherbereichen innerhalb fremder Prozesse kann mit TNT in vielen Fällen mit diesen MItteln umgesetzt werden. TNT kann den Access-Token fremder Prozesse lesen und zeigt dessen Daten auswertbar an. Daten fremder Fenster, wie z.B. Fensterstile, Fenstergröße, Position, Klassenname und Fenstertext liest TNT aus. Fensterstile werden (soweit bekannt) ausgewertet und mit ihren Flagnamen angezeigt. Module werden nach Exportfunktionen gesucht und deren Adressen innerhalb des fremden Prozesses angezeigt. Moduldaten fremder Prozesse wie Einsprungsadresse, Ursprungsname bei der Kompilierung oder verschiedene Versionsinformationen kann man ebenfalls über TNT erhalten. 3.) Daten ändern: TNT kann einstellbbare Daten des Tokens eines fremden Users ändern. Dazu gehört z.B. das Aktivieren oder Deaktivieren von Gruppen und Privilegien. Aber auch der Default-DACL eines Fremdprozesses - der die Rechte eines Kindprozesses bestimmt, wenn kein Security-Descriptor mitgegeben wurde (z.B. bei @Winexec(), RUN, Shell...) - kann geändert werden. TNT ist in der Lage, die Zugriffsrechte auf Speicherseiten in anderen Prozessen zu ändern und deren Inhalt neu zu setzen. Fensterstile, Fensterpositionen und Größen fremder Fenster können bei Bedarf geändert werden 4.) Beenden und anhalten: TNT kann Fremde Fenster schließen, Prozesse beenden und Threads anhalten, fortsetzen und beenden... 5.) Messages senden: TNT kann Messages an fremde Fenster senden und in vielen Fällen auch deren Rückmeldung einholen. 6.) DLLs Injizieren: TNT kann unter Windows2000/XP eigene DLLs in den Virtuellen Speicher eines Prozesses einschleusen und die enthaltenen Exportfunktionen direkt anspringen. 7.) TNT kann in fremden Prozessen Speicher für eigene Verwendung bereitstellen. MWatch MWatch ist ein kleines Tool zum Auslesen der Meldungstexte der API-Fehler fremder compilierter Programme, deren virtuellem Speicherverbrauch und im Prozess momentan geöffneter Handles unter Windows2000/XP. MWatch liest dabei die Werte alle 250ms aus und zeigt den belegten Virtuellen Speicher grafisch an. Zugriff Zugriff zeigt Zugriffsrechte auf verschiedene lokale Objekte des Betriebsystems unter 2000/XP an und kann diese ändern. Grafdat Ein noch zu Windows3.1 entstandenes Programm, mit dem man zwei Dateien grafisch vergleichen und zu Not auch editieren kann. Hab's mal geproggt umd mir anzuschauen, was ein Virus genau mit meinen Dateien macht. Da ich es in letzter Zeit wieder häufig für andere Sachen (u.a. zum Untersuchen von DLLs bei der Entwicklung von TNT) gebraucht habe, habe ich es für 32-Bit neu compiliert. YourFault YourFault ist ein kleines Tool, das von GetLastError zurückgegebene Fehlercodes in Fehlerbeschreibungen umwandelt. Unter NT basierenden Systemen ist es auch mittels Ankreuzen der Checkbox möglich, NT_STATUS Fehlercodes (z.B. von den LSA- oder Native-APIs) in Fehlerbeschreibungen zu konvertieren. Pw-Show PW-Show (eine TrayIcon-Anwendung) deckt in Passwortedits mittels Rechtsklick ins Edit dort eingegebene Passwörter auf. Damit PW-Show funktioniert, muß es sich aber um ein wirkliches Windows Edit handeln! Mister Root Mister Root als eine Art "Taskmanager" für Treiber unter Windows2000 zu sehen. Treiber werden per Native-API gelistet und sind, ohne viel mehr als die Ladeadresse zu wissen, dynamisch entladbar. Des weiteren verfügt Mister Root über die Möglichkeit, Treiber zu laden, ohne das irgendwelche Einträge in die Registry durchgeführt werden oder ein Treibername vergeben wird. Auch ein Laden von Treibern in die Systemroot ohne die Treiber-Eintrittsfunktion (DriverEntry) auszuführen, ist mit Mister Root möglich. Mister Root wurde als Experimentalsoftware für den persönlichen Gebrauch unter Windows2000 entwickelt, unter anderen NT-Versionen werden nur Treiberinfos angezeigt und die Buttons zum Laden und Entladen von Treibern fehlen. Ein Entladen von Treibern während Windows läuft ist immer ein Risiko und es kann dabei zu schweren Crashes kommen - also bitte genau überlegen, was man da tut. Ich übernehme keine Haftung! ProcHunter Unter Windows2000 und WindowsXP gibt es einige Möglichkeiten, Prozesse für einen Taskmanager unsichbar zu machen. Dieses "Unsichtbarmachen" wird vor allen Dingen von Viren, Würmern und Spyware genutzt - d.h. also von schädlichen Programmen, die man normalerweise nicht auf seinem Rechner haben möchte. Sind solche "RootKits" (wie man sie unter Programmierern nennt) erst einmal auf einem Rechner installiert, können sie in vielen Fällen nicht mehr von Virenscannern gefunden werden, da oft auch Registryeinträge und ganze Verzeichnisse versteckt werden. ProcHunter bietet die Möglichkeit nach solchen versteckten Prozessen zu suchen und diese mit großer Sicherheit zu finden. Versteckte Prozesse werden dabei in der Prozessliste mit einem roten Dreieck, sichtbare Prozesse mit einem grünen Dreieck markiert. Klickt man einen Prozess in der Liste an, wird darunter in der Regel der dazugehörige Dateiname angezeigt, der sich markieren und mit der Tastenkombination 'STRG + C' in die Zwischenablage kopieren lässt. Prozesse können von ProcHunter beendet werden, die dazugehörige Datei oder auf diese Datei verweisende Einträge in der Registry werden aber nicht gelöscht. ProcessHider ProcessHider ist ein komplett in XProfan geschriebenes Programm, das in der Lage ist, unter Windows2000 und XP beliebige Prozesse für die Prozessliste des Taskmanagers unsichtbar zu machen. Obwohl ProcessHider ein reiner Usermode Prozess ohne Treiber ist, verwendet er die Technik von Kernelmode RootKits und ändert aus dem Usermode heraus die sich im Kernelspeicher befindende Prozessliste. ProcessHider darf nur für Testzwecke auf eigenen Rechnern benutzt werden, jegliche Verwendung auf Fremdrechnern ohne ausdrückliche Genehmigung des Besitzers ist untersagt! ModHunter ModHunter sucht unter 2000/XP in anderen Prozessen nach Modulen (DLL/EXE) und zeigt diese mit Ladeadresse und gegebenenfalls auch Dateinamen an. Module, die mit hoher Wahrscheinlichkeit Malware sind, werden mit einem roten Dreieck versehen, graue Dreiecke markieren in der Regel Memory-Module, das sind in den virtuellen Prozessspeicher kopierte Module ohne eigenes Handle. Nach injizierten Modulen scannt ModHunter ebenfalls, aber nur in den mit dem Windowszeichen versehenen Prozessen. ModHunter gibt Hinweise auf Malware, die auf Ihrem System läuft - findet aber längst nicht alles. KeyBlock KeyBlock ist ein kleines Programm, das unter Windows95/98/ME/2000 und XP nach über einen WH_KEYBOARD Hook installierten Keyloggern sucht. In der Regel sind dies schädliche Programme, die Tastatureingaben abgreifen und speichern (Viren), aber auch andere Programme (sogar Virenscanner) können solch einen Hook im System installieren. KeyBlock zeigt dann den Namen der injizierten Hook-Dll an und unter Windows2000 und XP gibt es dann die Möglichkeit, über das Drücken des Entladen Buttons alle Prozesse von dem Hook zu befreien. KeyBlock ist kein Virenscanner, er sucht nur nach Hooks des Typs WH_KEYBOARD! LittleSpy Kleiner Keylogger für alle 32-BIt Windowsversionen, den ich mir zu Testzwecken gebaut habe. Gibt man in irgendein Edit keylogger zeige dich ein, erscheint das Fenster des Keyloggers. Tastatureingaben werden in die Datei Eula.txt gespeichert, die sich im Stammverzeichnis des Keyloggers befindet. Injektor Kleine Spielerei die andere Programme durch das Injizieren einer (fast) beliebigen DLL dazu veranlasst, in einem festlegbaren Zeitintervall in einem bestimmten Thread fremden Code auszuführen. Dafür muss das Programm Injektor.exe mit bestimmten Paramtern geastartet werden - C:\Injektor\Injektor.exe "C:\Injektor\kill.dll" "_killdoku@0" "100" "SHELL_TRAYWND" " " würde zum Beispiel den in der Funktion _killdoku@0 enthaltenen Code (der das Fenster Dokument - WordPad schließt) in den WindowsExplorer injizieren und den Thread der das Fenster mit dem Klassennamen SHELL_TRAYWND erzeugt anweisen, diesen Code alle 100ms auszuführen (bitte den Leerstring am Ende nicht vergessen). 1.Parameter: Der Name und Pfad der DLL, die den Code (in Form einer Exportfunktion) enthält, der ausgeführt werden soll. 2.Parameter: Der Name der Funktion innerhalb der DLL, die den Code enthält, der injiziert werden soll. Der Code sollte nicht zu umfangreich sein und darf keine langwierigen Schleifen enthalten, damit der gehookte Thread, der den Code ausführen soll, weiterhin noch seinen anderen Arbeiten nachgehen kann. 3.Parameter: Ein Zeitintervall in Millisekunden, nach dem der injizierte Code erneut ausgeführt werden soll. Dieser Zeitintervall darf nicht kleiner als 100 Millisekunden sein. 4.Parameter: Der Klassenname eines Fensters, das von dem Thread erzeugt wurde, in dem der Code laufen soll. Ist nur der Fenstername bekannt, kann hier auch ein Leerzeichen stehen. 5.Parameter: Der Fenstername eines Fensters, das von dem Thread erzeugt wurde, in dem der Code laufen soll. Ist nur der Klassenname bekannt, kann hier auch ein Leerzeichen stehen. Um die Verwendung für Virenschreiber zu erschweren, wird nach der Ausführung von Injektor.exe immer eine Messagebox angezeigt. Zur Not kann das Erscheinen dieser Messagebox aber auch verhindert werden. Das Proggie ist größtenteils ungetestet und die Benutzung erfolgt komplett auf eigene Gefahr. Wachhund Kleine Spielerei die ab Windows2000 (in einem Administratoraccount) im Subsystem einen neuen Thread erzeugt, der überwacht, ob der Prozess desssen ID als erster Parameter (in Anführungszeichen) angegeben wurde noch läuft. Läuft dieser Prozess nicht mehr, wird das System heruntergefahren. Beispiel: C:\Wachhund\Wachhund.exe "496" Überwacht das laufende Programm (den Prozess) mit der ID 496 daraufhin, ob es noch läuft. Das Proggie ist größtenteils ungetestet und die Benutzung erfolgt komplett auf eigene Gefahr. Beyhond API Die Registry und Privilegien Der folgende Artikel bezieht sich auf die Betriebsysteme Windows2000/XP. Die hier aufgeführten Tests wurden unter Windows2000 unter einem Administratoraccount durchgeführt. Für das Nachvollziehen der hier gemachten Aussagen sind folgende Zusatzprogramme erforderlich: - PrivAktivate - Eine Version von Profan² bzw. XProfan. Einen etwas genaueren Blick auf eine Sache zu riskieren, kann manchmal sehr interessante Ergebnisse hervorbringen, und dieser "genauere Blick" soll hier einmal auf den Registryschlüssel 'Security' unter HKEY_LOCAL_MACHINE fallen, der normalerweise ziemlich unscheinbar aussieht: Aber ist das wirklich alles, was dieser Schlüssel zu bieten hat? Wir schauen jetzt mal etwas genauer! Dazu starten wir zuerst PrivAktivate. Über den Menüpunkt 'Programm' und 'PrivAktivate als Service starten' verleihen wir PrivAktivate den Access Token des Betriebssystems mit dessen Privilegien und Zugriffsrechten. Über den zweiten Button von links kann nun RegEdit gestartet werden. Jetzt sieht die Sache schon ganz anders aus... Diesen Schlüssel darf also offensichtlich nur das Betriebsystem auslesen. Ein Blick auf die Zugriffsrechte bestätigt dieses: Unter dem Schlüssel 'SECURITY\Policy\Accounts' finden wir jetzt einige cryptische Unterschlüssel. Ein Blick in PrivAktivate zeigt, das es sich bei diesen Unterschlüsseln um String-SIDs, also quasi um verschlusselte Gruppen- und Accountnamen, handelt. Auch unter den "Gruppen- und Accountnamen" befinden sich wiederum Unterschlüssel, und unser Augenmerk richten wir jetzt auf den Unterschlüssel 'Privlgs' unter dem String-SID für die Gruppe Administratoren. 'Privlgs' klingt irgendwie nach "Privileges" also "Privilegien" - stehen dort etwa die Privilegien der jeweiligen Gruppen? Und wenn ja, in welcher Form stehen die da??? Also erst einmal ein Blick auf den dort stehenden Standardwert: Das ganze sieht etwas verwirrend aus, deshalb hier das was bei mir da unter Windows2000 zu finden ist jetzt mit mehr Struktur: So, jetzt vergleichen wir das ganze mal mit den Rückgaben dieses Quelltextes, der die Privilegien über LsaEnumerateAccountRights ausliest: DEF @LsaOpenPolicy(4) !"advapi32","LsaOpenPolicy" Hier die Ergebnisse: SeSecurityPrivilege Luid des Privilegs=$08000000 SeBackupPrivilege Luid des Privilegs=$11000000 SeRestorePrivilege Luid des Privilegs=$12000000 SeSystemtimePrivilege Luid des Privilegs=$0C000000 SeShutdownPrivilege Luid des Privilegs=$13000000 SeRemoteShutdownPrivilege Luid des Privilegs=$18000000 SeTakeOwnershipPrivilege Luid des Privilegs=$09000000 SeDebugPrivilege Luid des Privilegs=$14000000 SeSystemEnvironmentPrivilege Luid des Privilegs=$16000000 SeSystemProfilePrivilege Luid des Privilegs=$0B000000 SeProfileSingleProcessPrivilege Luid des Privilegs=$0D000000 SeIncreaseBasePriorityPrivilege Luid des Privilegs=$0E000000 SeLoadDriverPrivilege Luid des Privilegs=$0A000000 SeCreatePagefilePrivilege Luid des Privilegs=$0F000000 SeIncreaseQuotaPrivilege Luid des Privilegs=$05000000 SeChangeNotifyPrivilege Luid des Privilegs=$17000000 SeUndockPrivilege Luid des Privilegs=$19000000 SeInteractiveLogonRight SeNetworkLogonRight In dieser Registrystruktur scheint also zuerst ein Longwert zu stehen, der die Anzahl der Privilegien angibt. Danach kommen offensichtlich die LUIDs der einzelnen Privilegien, die durch eine weitere LongInt Zahl voneinander getrennt sind. Aber was ist das für eine LongIntzahl? Aufschluss darüber könnte die LUID_AND_ATTRIBUTES Struktur aus der WIN32.HLP geben: Zitat:" The LUID_AND_ATTRIBUTES structure represents a locally unique identifier (LUID) and its attributes. Members: Luid Specifies an LUID value. Attributes Specifies attributes of the LUID. This value contains up to 32 one-bit flags. Its meaning is dependent on the definition and use of the LUID. Remarks: An LUID_AND_ATTRIBUTES structure can represent an LUID whose attributes change frequently, such as when it is used to represent privileges in the PRIVILEGE_SET structure. Privileges are represented by LUIDs and have attributes indicating whether they are currently enabled or disabled." Zitat:" SE_PRIVILEGE_ENABLED = $2 SE_PRIVILEGE_ENABLED_BY_DEFAULT = $1" Diese dort zu findenden Attribute scheinen also die Grundeinstellungen der Privilegien zu verkörpern. Sehr interessant ist in diesem Zusammenhang auch die MSDN Beschreibung der Funktion LsaRemoveAccountRights: Zitat:" LsaRemoveAccountRights The LsaRemoveAccountRights function removes one or more privileges from an account. You can specify the privileges to be removed, or you can set a flag to remove all privileges. When you remove all privileges, the function deletes the account. If you specify privileges not held by the account, the function ignores them." Hier wird gesagt, das ein Account gelöscht wird, wenn alle Privilegien des Accounts entfernt wurden. Das ist natürlich nicht so - was wirklich entfernt wird ist das Account Objekt, das durch den hier angesprochenen Registryschlüssel mit dem Namen des jeweiligen Accounts oder der Gruppe verkörpert wird. Was also gelöscht wird, ist der Eintrag in der Registry und nicht die Möglichkeit, sich einzuloggen. Chaos um das Heaplisting Der folgende Artikel bezieht sich auf die Betriebsysteme Windows2000/XP sowie Windows98. Die hier aufgeführten Tests wurden unter Windows98 sowie unter Windows2000 unter einem Administratoraccount durchgeführt. Für das Nachvollziehen der hier gemachten Aussagen sind folgende Zusatzprogramme erforderlich: - Eine Version von XProfan. Demjenigen, der sich schon einmal mit dem Listen von Heaps und Heapblöcken über die Toolhelp Funktionen befasst hat, werden wohl spätestens ab Windows2000 graue Haare wachen. Auf der MSDN Homepage findet man folgende Dokumentationen: Zitat:" HEAPLIST32 Describes an entry from a list that enumerates the heaps used by a specified process. typedef struct tagHEAPLIST32 { SIZE_T dwSize; DWORD th32ProcessID; ULONG_PTR th32HeapID; DWORD dwFlags; } HEAPLIST32, *PHEAPLIST32; Members: dwSize The size of the structure, in bytes. Before calling the Heap32ListFirst function, set this member to sizeof(HEAPLIST32). If you do not initialize dwSize, Heap32ListFirst will fail. th32ProcessID The identifier of the process to be examined. th32HeapID The heap identifier. This is not a handle, and has meaning only to the tool help functions. dwFlags This member can be one of the following values. Value Meaning HF32_DEFAULT => Process's default heap" Zitat:" HEAPENTRY32 Describes one entry (block) of a heap that is being examined. typedef struct tagHEAPENTRY32 { SIZE_T dwSize; HANDLE hHandle; ULONG_PTR dwAddress; DWORD dwFlags; DWORD dwLockCount; DWORD dwResvd; DWORD th32ProcessID; ULONG_PTR th32HeapID; } HEAPENTRY32, *PHEAPENTRY32; Members: dwSize Size of the structure, in bytes. Before calling the Heap32First function, set this member to sizeof(HEAPENTRY32). If you do not initialize dwSize, Heap32First fails. hHandle Handle to the heap block. dwAddress Linear address of the start of the block. dwBlockSize Size of the heap block, in bytes. dwFlags This member can be one of the following values. Value Meaning LF32_FIXED The memory block has a fixed (unmovable) location. LF32_FREE The memory block is not used. LF32_MOVEABLE The memory block location can be moved. dwLockCount This member is no longer used and is always set to zero. dwResvd Reserved; do not use or alter. th32ProcessID Process identifier of the process that uses the heap. th32HeapID Heap identifier. This is not a handle, and has meaning only to the tool help functions." Wer das ganze der Beschreibung entsprechend versuchsweise umsetzt, wird in etwa zu ddiesem Quelltext kommen: Der von mir hier als Beispiel genommene Quelltext startet die Anwendung Wordpad und listet deren Heaps und Heapblöcke. Unter Windows98 sieht das ganze in etwa so aus: Hier mal ein kleiner Auszug der zurückgegebenen Daten: Holla! Was ist denn das? Haben da alle Heapblöcke das gleiche Handle (458752)? Unter Windows98 funktionierte doch alles? Unter Windows2000 scheint (im Gegensatz zu Windows98) beim Member hHandle nicht das Handle des Heapblocks zu stehen, das steht fest! Mehrere Speicherobjekte können nicht das gleiche Handle haben, also stimmt die MSDN Erklärung beim besten Willen nicht mit den Gegebenheiten unter Windows NT überein. Aber was gibt dann hHandle unter NT basierenden Windowsversionen an? Dieser Quelltext gibt da etwas näheren Einblick: Def @GetWindowThreadProcessId(2) !"USER32","GetWindowThreadProcessId" Wie man hier sieht, gibt [i]hHandle[/i] unter Windows2000 (und XP) nicht das Handle des Heapblocks, sondern das Handle des Heaps an. Auch diese Aussage Zitat:" th32HeapID Heap identifier. This is not a handle, and has meaning only to the tool help functions." scheint hier nicht zuzutreffen. Jetzt schauen wir uns mal die Heapflags an: Erzeugt wurde der Heap durch folgenden Code: Erzeugt man den Heap so , sehen die Flags so aus: Und erzeugt man den Heap so Was hier bei den Heapflags zurückgegeben wird, hat also - anders als unter Nicht-NT - etwas mit den Flags zu tun, die bei der Erzeugung des Heaps übergeben wurden. Demzufolge ist dieses hier Zitat:" dwFlags This member can be one of the following values. Value Meaning HF32_DEFAULT => Process's default heap" ebenfalls mit Vorsicht zu genießen! Aber - wie sieht das mit Vista aus? Dazu (mit bestem Dank an Rolf Koch) folgende Rückmeldungen des ersten Quelltextes: Windowsversion: WindowsVista oder Longhorn () Auch hier stimmt also offensichtlich das Handle des Heapblocks nicht! Bei den Flags scheint Microsoft aber wieder auf den dokumentierten Standard zurückgegriffen zu haben. Fazit: Wer beim Heaplisting auf die Dokumentation baut, hat sein Haus wohl auf Treibsand gesetzt... Das Handle von beweglichen Speicherobjekten Der folgende Artikel bezieht sich auf die Betriebsysteme Windows2000/XP. Die hier aufgeführten Tests wurden unter Windows2000 unter einem Administratoraccount durchgeführt. Für das Nachvollziehen der hier gemachten Aussagen sind folgende Zusatzprogramme erforderlich: - Tasks and Token - Eine Version von Profan² bzw. XProfan. - Profan2Cpp Es geht erst einmal um folgenden Quelltext: Da Profan etwas verschwenderisch mit Heaps umgeht, habe ich den Quelltext der Einfachheit halber mit Profan2Cpp compiliert. Auf dem Bildschirm wird hier das Handle des mit LocalAlloc erzeugten Speicherobjektes ausgegeben (bei mir 44564492): Zuerst liste ich dann mit Tasks and Token Heaps des mit dem Quelltext erzeugten Prozesses: Jetzt tue ich mal so, als wäre das mit LocalAlloc erlangte Handle eine Adresse und lese mit Tasks and Token 4 Bytes ab dieser Adresse als dezimales Doublewords aus: Bei mir erhalte ich die Zahl 38118320. Jetzt tue ich wieder mal so als wäre die erhaltene Zahl eine Adresse. Wenn ich mir jetzt die vorher ausgelesenen Heapblöcke ansehe, finde ich diese Adresse bei mir im 1.Heap wieder: Als nächtes schaue ich mir mal mit Tasks and Token den Inhalt dieses Heapblocks etwas genauer an, und zwar als dezimale Doublewords: Nach dem Kopieren in die Zwischenablage kommt bei mir das heraus: Am Ende dieses Heapblockes steht hier scheinbar die in der WIN32.HLP beschriebene Heapkontrollstruktur - und am Anfang dieser Struktur steht wiederum das Handle des vorher mit LocalAlloc erzeugten Speicherbereichs (bei mir, wie gesagt, 44564492). Die ganze Sache läßt sich mittels folgendem Code auch nochmals näher überprüfen: Fazit: Hat man ein Handle eines Speicherbereichs - beweglich oder nicht ist egal - kommt man auch in fremden Prozessen relativ unproblematisch an die Adresse, an der die dazugehörigen Daten stehen. Eine Listbox im Speicher Der folgende Artikel bezieht sich auf die Betriebsysteme Windows2000/XP. Die hier aufgeführten Tests wurden unter Windows2000 unter einem Administratoraccount durchgeführt. Für das Nachvollziehen der hier gemachten Aussagen sind folgende Zusatzprogramme erforderlich: - Tasks and Token - Eine Version von Profan² bzw. XProfan. - Profan2Cpp Als Ausgangslage nehmen wir mal folgenden kleinen Quelltext: Da Profan etwas verschwenderisch mit Heaps umgeht, empfehle ich, das Programm mit Profan2Cpp zu compilieren. Nach dem Ausführen sieht man folgendes auf dem Bildschirm: Danach starten wir Tasks and Token und lassen uns erst einmal die Heaps des Testprozesses mit der Listbox listen: Unter "Programm/Optionen" befindet sich der Menüpunkt "String in Bytefolge umwandeln". Nach dem Anklicken geben wir das Wort "Hallo" ein und drücken OK. Nach einem Rechtsklick ins Treeview von Tasks and Token wählen wir "Speicher durchsuchen" aus. Im Unteren Edit steht nun das Wort "Hallo" bereits als hexadezimale Bytefolge. Alle Texte von Controls stehen im Speicher als Unicodestrings, wir müsse da also noch nach jedem Byte ein Nullbyte einfügen, d.h. nach jedem zweiten Zeichen zwei Nullen. Das ganze sieht dann so aus: Was gefunden wird, sieht in etwa so aus: Wir wählen nun ein paar beliebige Adressen aus, einmal aus dem oberen drittel, einmal aus der mitte und einmal aus dem unteren drittel und schauen nach, in welchem Heapblock diese Adressen liegen. Die Blöcke, in denen die Adressen liegen, lassen wir uns als Strings anzeigen. Der Heapblock, den wir suchen, ist in etwa 48136 Bytes groß und liegt wahrscheinlich am Ende des ersten Heaps. Das Wort "Hallo" steht komplett am Anfang des Blockes, so wie hier zu sehen: Jetzt kopieren wir mittels Rechtsklick die Startadresse des Blocks - dann ein Rechtsklick ins Treeview und "Speicherbereich ändern" auswählen. Als Adresse des Speicherbereichs fügen wir hier die vorher kopierte Startadresse ein, den hexadezimalen neuen Inhalt setzen wir auf 41 und klicken danach auf "Speicherbereich ändern". Wenn wir uns jetzt die Listbox ansehen, ist mit ihr folgendes passiert: Das was wir da gefunden haben ist also der Speicherbereich, an dem alle Einträge der Listbox gespeichert sind! Das ist ja schon mal ganz Interessant - aber wo ist der Rest der Listbox? Danach suchen wir jetzt! Wenn die Zeilen einer Listbox in einem Speicherbereich stehen, müßte ein anderer Speicherbereich wiederum auf diese Adresse verweisen - ist doch logisch, oder? Wir gehen also folgendermaßen vor: Zuerst kopieren wir wieder die Adresse des Heapblocks mit den Listviewzeilen. Danach klicken wir unter "Programm/Optionen" auf den Menüpunkt "Zahl in Bytefolge umwandeln" und fügen hier die Adresse ein. Danach klicken wir auf OK. Nun durchsuchen wir wieder den Prozessspeicher des Testprozesses mit der Listbox - und zwar nach der Adresse als Doubleword in hexadezimaler Bytefolge (siehe Bild): Das wurde bei mir gefunden: Unter den gefundenen Adressen suchen wir nach einer Adresse innerhalb eines Heapblocks des ersten Heaps (bei mir 38184396). Der gesuchte Bereich dürfte 720 Bytes groß sein. Wir stellen nun den Inhalt dieses Bereichs als dezimale Doublewords da (bei mir 38183824): Danach kopieren wir den ganzen Bereich mittels Rechtsklick in die Zwischenablage: Das kommt bei mir dabei heraus: Was wir hier sehen, dürften die Daten der Listbox sein - an Stelle X144 steht dabei die schon bekannte Adresse, die die Zeilen der Listbox enthält. Wir schauen uns nun Stelle X141 mal etwas genauer an, die Zahl 1000. Kommt sie jemandem bekannt vor?. Die Adresse von X141 berechnen wir folgendermaßen: Startadresse des Heapblock+(141*4)-4 Bei mir wäre das 38183824+(141*4)-4 = 38184384 Zur Kontrolle bitte einmal 4 Bytes ab dieser Adresse als dezimale Doublewords auslesen lassen, es müßte die Zahl 1000 herauskommen! Nun ändern wir das Doubleword an dieser Stelle wie im Bild zu sehen auf den dezimalen Wert 10: Jetzt sschauen wir mal zwischendurch die Listbox an: Oops - die Zeilenzahl hat sich (wie beabsichtigt) auf 10 verringert! PS: X143 hat übrigens was mit der Sortierung der Listbox zu tun... Ein Multiedit im Speicher Der folgende Artikel bezieht sich auf die Betriebsysteme Windows2000/XP. Die hier aufgeführten Tests wurden unter Windows2000 unter einem Administratoraccount durchgeführt. Für das Nachvollziehen der hier gemachten Aussagen sind folgende Zusatzprogramme erforderlich: - Tasks and Token - Profan2Cpp Als Ausgangspunkt soll folgender Quelltext dienen: Danach starten wir Tasks and Token, klicken im Fenstermenü auf 'Zahl in Bytefolge umwandeln' und geben hier das Fensterhandle (bei mir 131840) ein. Nun klicken wir den Prozess an, den unser Quelltext erzeugt hat und wählen nach einem Rechtsklick ins Treeview 'Speicher durchsuchen'. Die Startadresse setzen wir auf 0, hinter die Bytefolge hängen wir eine 01 an und klicken dann auf 'Speicher durchsuchen'. Die letzte gefundene achtstellige Adresse schauen wir uns mal etwas genauer an und lassen uns 4000 Bytes ab dieser Adresse als dezimale Doublewords auslesen: Das steht bei mir (der Windows-Taschenrechner hilft beim Umwandeln der hexadezimalen Fensterstile ins Dezimalsystem): Mittels EM_GETHANDLE läßt sich dann das Handle des Textes (der DLL) im Edit ermitteln. Mittels folgendem Quelltext wollen wir uns jetzt mal etwas näher um die Adresse kümmern - unter 2000/XP natürlich: Da Profan etwas verschwenderisch mit Heaps umgeht, sollte man den Quelltext mit Profan2Cpp compilieren. Beim mir sieht das ganze dann in etwa so aus: Im Edit steht hier das Handle des Textes. Nun starten wir Tasks and Token, wählen den Testprozess mit dem Multiedit aus und lassen uns dessen Heaps listen. Nun tun wir mal so als wäre das Handle des Textes (bei mir 44630028) eine Adresse und lassen uns das Doubleword an dieses Adresse von Tasks and Token einmal auslesen. Heraus kommt bei mir: Jetzt tun wir wiederum so, als wäre 38184920 und schauen unter den Heaps nach, ob wir irgendwo diese Adresse finden und lassen uns den Inhalt des Heapblocks als String darstellen: Wie man sieht, haben wir die Adresse des Textes im Edit gefunden! Die Sicherheitsbeschreibung des Policy Objekte Der folgende Artikel bezieht sich auf die Betriebsysteme Windows2000/XP. Die hier aufgeführten Tests wurden unter Windows2000 unter einem Administratoraccount durchgeführt. Für das Nachvollziehen der hier gemachten Aussagen sind folgende Zusatzprogramme erforderlich: - PrivAktivate - Eine Version von Profan² bzw. XProfan. Auch hier soll wieder um einen Wert unter dem Registryschlüssel Security unter HKEY_LOCAL_MACHINE gehen, dessen Werte und Unterschlüssel normalerweise selbst für einen Administrator unsichtbar sind: Um das wirklich sichtbar zu machen, um das es geht, müssen wir auch hier wieder "zu einem Teil des Betriebssystems werden". Dazu starten wir zuerst PrivAktivate. Über den Menüpunkt 'Programm' und 'PrivAktivate als Service starten' verleihen wir PrivAktivate den Access Token des Betriebssystems mit dessen Privilegien und Zugriffsrechten. Über den zweiten Button von links kann nun RegEdit gestartet werden. Jetzt sieht die Sache schon ganz anders aus... Unter dem Schlüssel Policy finden wir einen Unterschlüssel mit dem Namen SecDesc, der einen etwas längeren Binärwert enthalt: SecDesc lässt uns als erfahrene Windowstüftler gleich an einen Security Descriptor, also an eine Sicherheitsbeschreibung denken. Aber ist das, was da steht, wirklich ein Security Descriptor? Wir schauen da mal mit dem unten stehenden Quelltext etwas genauer nach: Dieser Quelltext liest zuerst den besagten Schlüssel aus der Registry aus und vergleicht dann mittels IsValidSecurityDescriptor, ob es sich um eine gültige Sicherheitsbeschreibung handelt (1 als Rückgabe, wenn dem so ist). Zum Schluss wird dann versucht, das Policy Object zu öffnen - 0 bei Erfolg. Diese Quelltext compilieren wir zu einer EXE und starten ihn dann mit der als Service gestarteten Anwendung PrivAktivate über den Button Anwendung auswählen Wir bekommen dann folgende Rückmeldungen: Fehlercode beim Öffenen des Schlüssels: 0 Fehlercode beim Auslesen des Schlüssels: 0 Ausgelesener Wert: 01 00 04 80 48 00 00 00 58 00 ... Typ des Schlüssels: 0 Länge des Wertes: 100 Bytes Rückgabe von IsValidSecurityDescriptor: 1 Rückmeldung von LsaOpenPolicy: 0 Rückmeldung von LsaClose: 0 Wie die Rückgabe von IsValidSecurityDescriptor beweist, steht hier also wirklich eine Sicherheitsbeschreibung in der Registry - aber welche? Um das zu testen, benennen wir einfach den Schlüssel einmal folgendermaßen um: Starten wir jetzt wie vorher wieder unseen compilierten Quelltext über PrivAktivate, kommen wir diesmal zu folgenden Ergebnissen: Fehlercode beim Öffenen des Schlüssels: 2 Rückgabe von IsValidSecurityDescriptor: 0 Rückmeldung von LsaOpenPolicy: 2 Wie man sieht, lässt sich jetzt das Policy Objekt nicht mehr öffnen - die dort in der Registry gefundene Sicherheitsbeschreibung bezieht sich also definitiv auf das Handle des Policy Objektes! PS: Das Zurückbenennen des Schlüssels nicht vergessen! Falschen Prozesspfad vorgaukeln Der hier angebotene Testdownload soll unter WindowsNT, Windows2000, Windows2003, WindowsXP und Vista den unter anderem über die API GetModuleFileNameEx ermittelbaren Pfadnamen des Prozesserzeugers (also des ausgeführten Programmes) ändern und egal wo sich dieses kleine Programm auf der Festplatte befindet immer svchost.exe aus dem Windows-Systemverzeichnis als Prozesserzeuger zurückgeben. Im Prinzip bedeutet das, dass das laufende Proggie manchen Windowsfunktionen vorgaukelt, sich in einem ganz anderen Ordner zu befinden, als es sich in Wirklichkeit aufhält. Das Programm ist kein Virus und erzeugt keinerlei Registryeinträge. Die Änderung erfolgt durch direkte Speicherzugriffe und Zugriffe auf undokumentierte Native-API Funktionen unter NT-basierenden Windowssystemen. Testen lässt sich dies mit jedem "Taskmanagertool", das zu einem Prozess (also einem momentan ausgeführten Programm) auch den dazugehörigen Pfad liefert. ModHider Der hier angebotene Testdownload ModHider soll es unter Windows2000, Windows2003, WindowsXP und Vista ermöglichen, ausgewählte geladene Module (DLLs) einer laufenden Anwendung vor dem Anwender zu verstecken. Im Prinzip bedeutet das, dass unter anderem die APIs Module32First und Module32Next das versteckte Modul (die versteckten Module) nicht mehr listen können. Das "Verstecken" mittels RootKit Technologie und ist unabhängig davon, ob das ModHider nach dem Verstecken beendet wird oder nicht. Es werden keine DLLs injiziert und keine APIs gehookt. Das Programm ist kein Virus und erzeugt keinerlei Registryeinträge. Die Änderung erfolgt durch direkte Speicherzugriffe und Zugriffe auf undokumentierte Native-API Funktionen unter NT-basierenden Windowssystemen. Testen lässt sich dies mit jedem "Taskmanagertool", das neben einem Prozess auch dessen geladene Module (DLLs) anzeigt.
Leider ist dies eine Seite, die Frames nutzt. Ihr Browser unterstützt keine Frames, deshalb kann Ihnen meine Seite auch nicht richtig angezeigt werden!
Impressum