[KillMe] PC Lock

E

evilinside

0
Ich hatte vor ein Programm zu schreiben, welches bei bestimmten Events den PC sperrt/entsperrt...

Da das Programm auch automatisch entsperren sollte, fiel Win+L (Passwortabfrage) weg.

Jedoch wurde des öfteren behauptet, dass man den PC alternativ zu Win+L nichtz wirklich sperren könnte.

Ich denke meine "Sperrfunktion" ist ziemlich sicher, von daher würde ich euch bitten, euch selbst mal dran zu probieren, ob ihr es schafft, den PC zu entsperren ohne, dass ihr auf den "entsperren" button klickt...


pclockerz9u.jpg



noch ein paar infos:

- Bisher getestet unter XP im Single- und Dualmonitor Betrieb
- Fullscreen - Topmost
- Taskleiste per WinApi "versteck"
- Taskmanager geblockt (nicht per Registry deaktiviert!)
- Startmenü, Schließen (Alt+F4), etc. per Low-Level-Hook abgefangen
 
1. Unter Vista funktioniert der Taskmanager Aufruf teilweise. der (Benutzer wechseln/pc herunterfahren/taskmanager starten usw.) Bildschirm wird angezeigt.
2. Meine "Quickshell" wird mir angezigt; Ich habe auf meiner Mittleren Maustaste ein Skript, welches die cmd sofort startet (mit alwaysontop property). Das landet dann über deinem Fenster :P

Da du aber "Enter" usw. blockierst, kann man damit auch nicht viel anfangen.


Wenn man einen standard PC vorsich hat, wo der Lock drin ist, hat man keine Change. Kann man aber vorher am PC rumspielen und weiss was kommt, bringt der Schutz wenig. Man kann deinen lockprozess einfach abschiessen lassen. (in dem man ein Skript auf eine nicht geblockte Taste legt. Dafür eignet sich eben der mittlere Maus-button recht gut.) Aber das zweite Szenario gibts ja auch eher selten.

:D
 
Bei mir startet der Taskmanager ganz normal und dein Programm wirft eine Exception.

************** Ausnahmetext **************
System.ComponentModel.Win32Exception: Zugriff verweigert
bei System.Diagnostics.ProcessManager.OpenProcess(Int32 processId, Int32 access, Boolean throwIfExited)
bei System.Diagnostics.Process.GetProcessHandle(Int32 access, Boolean throwIfExited)
bei System.Diagnostics.Process.Kill()
bei USBDriveSerialNumber.Form2.timerKillTaskmgr_Tick(Object sender, EventArgs e)
bei System.Windows.Forms.Timer.OnTick(EventArgs e)
bei System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Zum Vergrößern anklicken....
 
Ich schließe mich 90nop an. Unter Vista kann man mit STRG-ALT-ENTF den PC neustarten lassen. Ansonsten habe ich keinen Weg daran vorbei gefunden.

PS: Interessantes Program, wofür willst du es in der finalen Version verwenden?

Maulwurf
 
Danke euch schonmal für eure Mitarbeit!

Das Vista Problem ist relativ unrelevant, da das Programm in den Autostart kommt... Das Script von dir werd ich auch ncoh blocken, indem ich die Maustasten "hooke"...

Wofür das alles dienen soll?
Das ganze Arbeit zusammen mit einer Routine, die die USB Ports absucht nach USB Sticks, werden USB Sticks gefunden, werden deren Hardware Seriennummern ausgelesen.

Ist der Stick angeschlossen kann man normals Arbeiten, wird der Stick entfernt, springt die Sicherung rein, von daher geht es mir auch nciht sosehr darum, ob man die .exe datei vorm blocken abschießen kann...

Ist halt nur die Methode die reinspringt, wenn der USB Stick entfernt wird, da ist ein neustart dann auch unrelevant, dank Autostart bzw. meistens User passwort...

Ich hoffe ihr könnt mir folgen ;)
 
Dein Programm laesst sich noch mit einem altem Trick aushebeln: Einfach eine Cd erstellen, diese mit 2 Dateien bestuecken autorun.inf und eben einem Programm, welches dein Programm beendet. Voraussetzung ist natuerlich, dass die Autostartfunktion aktiviert ist.
Um absolut sicher zu gehen, dass deine Sperre nicht umgangen wird, wuerde ich Filtertreiber erstellen um wirklich saemtlichen Userinput zu blockieren, sowie NtCreateSection hooken um zu verhindern, dass irgendein Programm waehrend des Locks gestartet wird.

Natuerlich bleiben die Angriffsmoeglichkeiten, dass der PC einfach neugestartet wird, offline auf die Daten zugegriffen wird usw., aber dies ist wohl nur durch eine autarke Stromversorgung und einen dicken Kaefig außen herum zu unterbinden...

Fakt ist, will man dran vorbei, kommt man auch dran vorbei ;)
 
Ähm. Es gibt auch die Möglichkeit mit dem normalen LockWorksation zu arbeiten UND das automatische Entsperren zu realisieren. Wie wäre es mit einem Service? (Programm, dass mit Local System Rechten läuft)

Warum denken alle gleich immer an umständliche und potentiell unsichere Neukonstrukte?
 
Von Filtertreibern hab ich nicht so wirklich Ahnung... Könntest du mir vielleicht nen kleinen Anstoß geben, wie ich das in/mit C# realisieren kann?
 
Original von evilinside
Von Filtertreibern hab ich nicht so wirklich Ahnung... Könntest du mir vielleicht nen kleinen Anstoß geben, wie ich das in/mit C# realisieren kann?
Zum Vergrößern anklicken....

Mit C#? Gar nicht, da auf Kernelebene kein .net-Framework zur Verfügung steht. Dafür musst du schon C oder C++ verwenden(und brauchst das Windows DDK). Für andere Sprachen keine ich für Windows keinen Weg Kernelmodule zu erzeugen.
 
schade, dachte würde vll nen paar dll's einbinden können und des dann über c# lösen können... :D

Naja, hab nochmal fleißig gegoogelt - wie schauts dann mit deinem vorschlag aus - +++Atho?! Hast du nen Beispiel, wie man "LockWorkstation()" autmatisch wieder entsperren kann?
 
Tach,

sag, hast du das alles in C# geschrieben? Teilweise sieht mir der Sourcecode ganz schön nach VB .NET aus... z. B.:
Code: 
Public Sub CheckUsbPorts()
    If (((Me.usbdrive = "") OrElse (Me.usbdrive = "A:")) OrElse (Me.usbdrive = "none")) Then
        Dim strArray As String() = New String(&H100  - 1) {}
        Dim index As Integer = 0
        Dim drives As DriveInfo() = DriveInfo.GetDrives
        Dim info As DriveInfo

Ich wusste garnicht, dass man ohne weiteres VBNET in C# integrieren kann...

EDIT: ich sehe grad, dass du einfach den Taskmanager immer wieder killst.. wenn man aber z. B. den Namen davon ändert hat das auch keine Wirkung mehr ;) Aber da muss man auch erstmal drauf kommen...
 
Original von M4CH!N3

Ich wusste garnicht, dass man ohne weiteres VBNET in C# integrieren kann...

EDIT: ich sehe grad, dass du einfach den Taskmanager immer wieder killst.. wenn man aber z. B. den Namen davon ändert hat das auch keine Wirkung mehr ;) Aber da muss man auch erstmal drauf kommen...
Zum Vergrößern anklicken....

Stammt dein Sourcecode aus dem Reflector? Wenn ja, der kann soweit ich weiß nicht bestimmen in welcher .net-Sprache die Anwendung geschrieben wurde, allerdings lässt sich die Sprache in der das angezeigt wird auch umstellen.
 
scheint aus'm reflector zu kommen, denn im original siehts so aus ;)

Code: 
public void CheckUsbPorts()
        {
            if (usbdrive == "" || usbdrive == "A:" || usbdrive == "none")
            {
                string[] UsbSticks = new string[256];
                int Arraycount = 0;
                DriveInfo[] drives = DriveInfo.GetDrives();

hab mir grad noch was anderes überlegt... wenn man im gerätemanager die tastatur und die maus deaktiviert, dann dürften das doch auch nur Änderungen in der Registry sein, die ich auch so in c# durchführen könnte... Mal sehen, das wär glaub ich jedenfalls am effektivsten...
 
Jo, war ausm Reflector. Komischerweise hat er mir bis heute immer die richtige Sprache angezeigt.. also C#-Code als C# und VB-Code als VB... man lernt nie aus :)
 
Why this Technique is a Hack

Essentially, this application (which I call "RemoteUnlock") bypasses the actual "unlocking" code in the winlogon process and simply switches the visible desktop back to Default. An interesting side-effect of this is that Windows (specifically winlogon) still thinks the computer is locked. You can see this when you run RemoteUnlock because while the computer is "unlocked", hitting Ctrl-Alt-Delete does nothing. Why? Because, Ctrl-Alt-Delete is handled by the winlogon process and, as far as it's concerned, the system is still locked. Since a locked computer should already be showing the Winlogon desktop, the system (incorrectly) sees no need to activate the Winlogon desktop again.

For this reason, RemoteUnlock will "re-lock" the workstation upon termination. (More specifically, it will switch back to the Default desktop.) Otherwise, the system would be in some weird limbo-state where Ctrl-Alt-Delete doesn't work as expected.

Maybe someday I'll figure out a way to truly unlock the workstation, but for now, this should be sufficient.
Zum Vergrößern anklicken....

Das scheint mir nicht sehr geeignet.
 
Da seine Technik das Ziel hat den LockOut Mechanismus sowieso zu ersetzen, denke ich ist das schon geeignet. Wenn man die Workstation wieder locken möchte, dann erledigt das sein Programm indem es wieder zu dem anderen Desktop switched.
Strg+Alt+Entf kann man dann auch abfangen und dann switchen lassen. Wenn man den Trusted Communication Path in Anspruch nimmt, muss man dann halt das Passwort eintippen.

Alternativ kann man Forschungen anstellen den LockOut komplett wieder zu entfernen.
Oder es gibt natürlich auch die Möglichkeit des msgina.dll Ersatzes. Da sollte man auch aufpassen, dass man alles richtig macht.
Either way, it's a hack. Aber allemal besser als selbstgemachte Experimente.

Grundsätzlich bin ich aber immer dafür vorhandene und schon implementierte Security-Policies und Mechanisms des Betriebsystems zu nutzen, da diese getestet sind, schon lange vorhanden und bestimmt schon so einige gute Patches durchgemacht haben. Sich also bewährt haben.

Vlt. kann man jetzt an dieser Stelle mal hinterfragen, warum das wieder einloggen automatisch geschehen muss? Da gibt es bestimmt andere Möglichkeiten.
 
Original von evilinside
...
Wofür das alles dienen soll?
Das ganze arbeitet zusammen mit einer Routine, die die USB Ports absucht nach USB Sticks, werden USB Sticks gefunden, werden deren Hardware Seriennummern ausgelesen.

Ist der Stick angeschlossen kann man normal Arbeiten, wird der Stick entfernt, springt die Sicherung rein
...
Zum Vergrößern anklicken....

Wird der USB eingesteckt, wird seine Hardware Seriennummer ausgelesen, mit der Seriennummer im Programm verglichen und bei übereinstimmung soll dann der Desktop freigegeben werden...

Deshalb auch ne "automatische" Methode zum wieder einloggen... Wenn ich noch das Passwort eingeben muss, dann wärs ja langweilig, dann könnt ich auch gleich Win+L benutzen...
 
So da ich heut ein bisschen Zeit hatte, dachte ich, dass ich meinen Vorschlag von einem Filtertreiber kurz umsetze. Ich habe nur einen fuer die Tastatur erstellt, weil es fuer die Maus Sinnbefreit waere, da die sich ja auch aus dem Usermode blockieren lässt (oke Tastatur prinzipiell auch, aber eben nicht [ctrl]+[alt]+[del]...). Egal im Anhang also der Treiber+Sourcecode. Das Ganze basiert mehr oder weniger auf Klog und blockiert, sobald der Treiber geladen ist, sofort saemtliche Tasten. Wird der Treiber wieder entladen kann man die Tastatur normal weiter benutzen.

Getestet wurde der Treiber in ner VM XP Prof Sp2.

Falls Fragen auftauchen wie es genau funktioniert, empfehle ich den Sourcecode von Klog, der ist gut dokumentiert.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben