Beiträge von misterspeed

Nunja vielleicht reicht es auch die Sicherheitsstufe von UAC zu senken. Alternativ gäbe es auch noch diverse Möglichkeiten die UAC Abfrage für bestimmte Anwendungen auszuhebeln. Google sollte da denke ich sogar zwei verschiedene Ansätze liefern. Die eine Funktioniert über die Aufgabenplanung und eine spezielle Verknüpfung, die andere denke ich über das Application Compatibility Toolkit. Beides muss mit einem Administrator Account einmalig eingerichtet werden. Das Problem wird vermutlich sein, dass die Bildschirmtastatur teilweise mit Systemprivilegien ausgeführt wird (deswegen funktioniert übrigens auch die genannte Backdoor Sache...) und UAC deswegen allen Anwendungen mit niederen Rechten diverse Dinge wie winmove() verbietet. Vermutlich will Microsoft so verhindern, dass man System Fenster manipuliert und einen User dazu verleitet "genau die richtige" Antwort anzuklicken.

Halte es zwar für unwahrscheinlich, dass es daran liegt, aber hast du UAC (Benutzerkontensteuerung) aktiviert und/oder arbeitest du mit Benutzerrechten? Wenn ja testweise mal deaktivieren (reboot nicht vergessen) und nochmal als Administrator testen. Wahrscheinlicher dürfte aber ein Problem mit der aktuellen Autoit Version sein, daher würde ich mal eine ältere Autoit Version testen.

Dann mach mal folgendes:

1. osk von Hand starten
2. Au3Info verwenden um alle Details des Fensters zu bekommen, also auch das Handle (kopier dir die infos vom tab summary und beende au3info)
3. nun starte das Testscript (siehe unten)
4. wurden Fenster mit dem Titel gefunden?
5. vergleiche die Konsolen Rückgabe von winmove mit dem vorher ausgelesenen Window handle, außerdem nochmals prüfen ob du den korrekten Fenstertitel angegeben hast (verschrieben?)
6. Wenn winmove 0 zurückgibt liegt definitiv ein Problem mit der winmove Funktion vor.

Die Rückgabe in der Scite Console sollte so ausschaun:

Folgende Fenster wurden gefunden:
Fenster 1: Bildschirmtastatur / 0x000000000003082E
Rückgabe von winmove (handle des fensters): 0x000000000003082E

getAllWindows("Bildschirmtastatur")
$test = WinMove("Bildschirmtastatur", "", Default, Default, 1000, 700)
ConsoleWrite("Rückgabe von winmove (handle des fensters): " & $test & @CRLF)

#cs
>>>> Window <<<<
Title: Bildschirmtastatur <--- (verschrieben?)
Class: OSKMainClass
Position: 318, 126
Size: 801, 231
Style: 0x16CE0000
ExStyle: 0x08040108
Handle: 0x000000000003082E <--- muss mit Rückgabe von winmove übereinstimmen
#ce

func getAllWindows($titel)
$aTest = WinList($titel)
If $aTest[0][0] = 0 Then
ConsoleWrite('FEHLER: keine Fenster mit dem Titel "' & $titel & '" gefunden !' & @CRLF)
Else
ConsoleWrite("Folgende Fenster wurden gefunden:" & @CRLF)
For $i = 1 to $aTest[0][0]
ConsoleWrite("Fenster " & $i & ": " & $aTest[$i][0] & " / " & $aTest[$i][1] & @CRLF)
Next
EndIf
EndFunc

Neben einem fehlerhaften Titel beim winmove Aufruf könnte ggf. eine Antivirenlösung Spielereien mit Systemfenstern unterbinden (eher unwahrscheinlich). Testweise mal deaktivieren.
Evtl ist auch deine Autoit Version verbuggt. Ich verwende noch Version 3.3.6.1

EDIT:

Winmove funktioniert btw nur bei Fenstern die nicht minimiert sind.

Hast du auch eine ausreichend dimensionierte Pause zwischen Start der osk.exe und winmove eingebaut? Das Fenster muss natürlich existieren bevor es verschoben werden kann. Das kannst du entweder über ein ausreichend langes sleep (siehe testscript von ilse) realisieren oder was eigentlich besser wäre mit einer Schleife die auf die Existenz des Fensters wartet:

shellexecute(...)
do
sleep(100)
until winexists("Bildschirmtastatur")
consolewrite("fenster sollte existieren" & @crlf)
winmove(...)

Ich zitiere einfachmal SEuBo aus einem anderen Thread bezüglich OSK.exe. Das Script muss als 64bit ausgeführt werden oder es muss eben fallabhängig die Ordnerumleitung deaktiviert werden, damit die osk.exe ohne Fehler startet. Die Größenänderung funktioniert bei mir nachwievor unter zwei verschiedenen Windows 7 64bit Systemen, genau wie damals unter Vista.

Wenn es bei euch nicht funktionieren sollte würde ich mal mit au3windowinfo prüfen ob euer Fenstertitel "Bildschirmtastatur" lautet oder ob ihr evtl. mit einer anderen Sprachversion arbeitet. Wenn ihr eine gecrackte Windowsversion habt würde es mich auch nicht wundern, wenn eine der genutzten Systemdateien nicht dem Original entspricht, denn die osk.exe bzw. utilman.exe (und noch einige weitere...) kann genutzt werden um sich eine Backdoor auf den Anmeldebildschirm zu zaubern.

Meine osk-Version: 6.1.7600.16385 631KB 14.07.2009
Win Version: Windows 7 Professional 64bit inkl. SP1 und allen Updates

Zitat von SEuBo

Wird meine Antwort hier bewusst ignoriert?! Ich WEIß nämlich zufällig, dass die Lösung funktioniert...

Hier nochmal für die ganz faulen...

[autoit]

Local $iState
If @CPUArch = "X64" And Not @AutoItX64 Then
DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "ptr", $iState)
EndIf

[/autoit] [autoit][/autoit] [autoit]

ShellExecute("osk")

[/autoit] [autoit][/autoit] [autoit]

If @CPUArch = "X64" And Not @AutoItX64 Then
DllCall("kernel32.dll", "int", "Wow64RevertWow64FsRedirection", "dword", $iState)
EndIf

[/autoit]

Verstehe dein Problem nicht. Das Bild wird innerhalb der 2. GUI erzeugt, so wie du es haben willst. Kannst du alleine daran sehen, dass das Bild seine Position nicht ändert wenn du GUI 1 verschiebst. Hier mal dein Code in lauffähiger Form (includes + while schleife haben gefehlt) und einem etwas deutlicher verschobenen Fenster 1, damit man definitiv sieht, dass das Bild in Fenster 2 ist:

#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

$GUI1 = GUICreate("Test", 420, 100, 400, 0, $WS_POPUP + $WS_CAPTION, $WS_EX_TOOLWINDOW)

$Button = GUICtrlCreateButton("TestButton", 20, 10, 80, 80)
GUISetState()

$GUI2 = GUICreate ("2.GUI", 350, 196, 0, 0, $WS_POPUP, $WS_EX_TOOLWINDOW)
$Pic = GUICtrlCreatePic(@ScriptDir & "\test.bmp", 0, 0, 350, 196)
GUISetState (@SW_SHOW, $GUI2)

while 1
if GUIGetMsg()=$Button Then Exit
wend

Wenn du die GUI's wirklich beide übereinander haben willst und nur haben möchtest, dass Fenster 1 immer im Vordergrund ist, dann kannst du bei Fenster 1 noch den extended style $WS_EX_TOPMOST setzen:

$GUI1 = GUICreate("Test", 420, 100, 0, 0, $WS_POPUP + $WS_CAPTION, $WS_EX_TOOLWINDOW + $WS_EX_TOPMOST)

Die aktuelle Version inklusive Hilfedatei findest du hier: http://code.google.com/p/autoit-winhttp/downloads/list

Keine Ahnung welche Version der winhttp.au3 du verwendest, aber meine hat jedenfalls keine Funktion namens "_WinHTTP_Post". Schonmal in die Hilfedatei der winhttp.au3 geschaut? Dort findest du jedemenge Beispiele. Ich würde dir jedenfalls mal ein Blick auf die Funktion

_WinHttpSimpleRequest($hConnect, $sType, $sPath [, $sReferrer = Default [, $sData = Default [, $sHeader = Default [, $fGetHeaders = Default [, $iMode = Default ]]]]])

empfehlen.

Mit logischen denken und dem Anwenden der bereits geposteten Beispiele?

Verwende einfach die Makros

@DesktopWidth
@DesktopHeight

für Breite und Höhe deiner GUI, bzw. bei Bedarf auch für Breite und Höhe deines eingebetteten IE Objekts. Was ist daran nun unverständlich?

Naja der Sinn und Zweck des Abgesicherten Modus ist es ja gerade sämtliche Drittanwendersoftware NICHT automatisch zu starten.

Per Google habe ich auch nur den Hinweis über Modifikationen der Registry gefunden. Ich könnte mir aufgrund sehr hartnäckiger Malware aber Vorstellen, dass Microsoft dieses Schlupfloch mittlerweile geschlossen hat.

Prinzipiell sollte es mittels (Linux-)BootCD auch möglich sein die originale explorer.exe durch eine eigene zu ersetzen, welche dann zum einen die originale explorer.exe startet und zusätzlich dein Sperrscript. Hier müsste man mittels Programmlogik noch aufpassen, dass weitere Aufrufe der "eigenen" explorer.exe nicht zu multiplen Instanzen des Sperrscriptes führen, sondern dann nur noch die originale explorer.exe starten. Soviel zur Theorie. Praktisch wird aber evtl. die Windowseigene Dateiprüfung manipulierte explorer.exe Dateien erkennen und dann ggf. den kompletten Bootvorgang blockieren. Außerdem könnten Windowsupdates deine manipulierte explorer.exe wieder überschreiben.

Neben der explorer.exe gibt es mit Sicherheit noch jedemenge andere automatisch startende Windowsdateien die man auf gleichem Wege austauschen könnte. Ich rate aber davon ab, da es massivst Probleme geben kann und das System dadurch ggf. unbrauchbar wird.

Möglicherweise sinnvoller wäre es den Boot in den abgesicherten Modus komplett zu unterbinden. Welche Möglichkeiten es je nach Betriebssystem gibt kannst du hier nachlesen:

http://www.raymond.cc/blog/disable-f…indows-startup/

Zitat von derBrot

P.S: Google spuckt auch nichts aus

Daran sieht man übrigens, dass selbst ein sehr guter heuristischer Algorithmus (zumindestens gehe ich davon aus, dass es einer ist) nicht immer zum gewünschten Ergebnis führt.
Und danke Andy für die Aufklärung.

Vielleicht solltest du dich erstmal mit Heurisitk beschäftgien:

http://de.wikipedia.org/wiki/Heuristik

Dein Script macht jedenfalls nichts besonders magisches, es schaut schlichtweg ob in der Datei ein bestimmter Binärcode vorkommt. Nach welchem Binärcode du hier sinnvollerweise suchen solltest musst du schon selbst wissen. Denn wie im Wikipedia Artikel sehr schön erklärt wird basiert Heurisitk auf begrenztem Wissen welches zur Entscheidungsfindung genutzt wird, dein begrenztes Wissen wäre hier welcher Binärschnippsel in der Datei niemals vorkommen darf. Kommt er doch vor wird die Datei gelöscht. Hier wird dir jedenfalls niemand sagen können nach was du suchen musst, wir wissen ja nichtmal was du machen willst.

PS: Ich bezweifle im übrigen, dass der Code da oben funktioniert, denn du willst die Datei löschen solange noch ein offenes Datei Handle dazu existiert. Das wird niemals klappen. Außerdem bezweifle ich, dass stringinstr mit Binärdaten funktioniert, außer Autoit macht die Umwandlung im Hintergrund ohnehin richtig. Aber selbst wenn würde ich mich da nicht unbedingt auf ein richtiges Ergebnis verlassen.

Ich nehme mal an es war so gemeint. Vermutlich kann mans aber geschickter und besser lösen, hab mir die Lösung von Bugfix nicht angesehn.

Geht bei mir auch nicht mit installiertem Visual Studio 2010. Die betreffende ocx Datei ist auch nirgendwo auf meinem System auffindbar. Eventuell noch Tipps welche Resdistributables oder Runtimes man genau benötigt? Ich vertraue Seiten wie der oben verlinkten nicht wirklich und würde direkte Downloads von Microsoft vorziehen.

Wozu brauchste da ne UDF? Kann ja nicht so kompliziert sein sich die benötigten Parameter aus der wget Hilfe rauszusuchen und sich den passenden Downloadbefehl selbst zusammenzubasteln um wget dann per run() aus Autoit heraus aufzurufen. Das selbe gilt für 7zip. Davon ab findest du hier genügend Entpack Scripte in den unterschiedlichsten Varianten, sogar mit nativen Windows Mitteln, anstatt 7zip. Nebenbei bemerkt gibt es auch für den Dateidownload native Autoit Mittel, z.B. inetget() oder eine der FTP Funktionen, jenachdem was du eigentlich von wo herunterladen willst.

Naja aber wozu 2 Scripte? Verwende doch einfach

_singleton(...)

um bereits vorhandene Instanzen zu erkennen.

Ich würde einfach nur mit singleton arbeiten und zusätzlich eine Möglichkeit schaffen um Daten der 2. "nicht erlaubten" Instanz des Programmes an die erste Instanz zu übertragen (siehe dazu die unzähligen Beispiele im Forum bezüglich Kommunikation zweier Scripte). Nach der Weitergabe des empfangene Parameters wird die 2. Instanz dann dank der singleton Bedingung beendet. Da du die nach und nach in der 1. Instanz eintrudelnden Dateipfade sammeln wolltest um sie zu zippen benötigst du wohl noch eine zeitbasierte Warteschlange, die erst dann abgearbeitet wird, wenn seit x (Mili)Sekunden keine neuen Daten hinzugefügt wurden. Dazu brauchts prinzipiel nur einen Timer und ein Array.

Ich würd das mit dem Timer etwa so lösen, allerdings ungetestet und nur schnell hier im Forum geschrieben, evtl ist auch ein Denkfehler drin...

EDIT: erstmal entfernt, irgendwas war falsch

Ich vermute mal, dass der Timer nicht resetet wird wenn man ausserhalb des einblenden Bereichs ist. Dadurch wird wenn er einmal aktiviert ist die gui immer nach 1 Sekunde eingeblendet. Habs mir aber auch nicht genau angesehen. Ich persönlcih finde 1 Sekunde Wartezeit aber ohnehin eher lästig/unnötig, lass sie doch einfach sofort Ein- bzw. Ausblenden.

Kleine Anmerkung zu der Art und Weise des Ausblendens:

Du bekommst so ggf. Probleme bei Multimonitor Setups, das Problem hatte ich mal mit meiner Sidebar GUI. Da du das Fenster oben hast ist es aber eher unwahrscheinlich, dass jemand den sekundären Monitor darüber aufgebaut hat, bei Links oder Rechts platzierten Sidebars ist es hingegen eher kritish die GUI in den negativen Bereich zu verschieben. Ich mache das bei mir deshalb mit zwei GUIs, die eine schmal, welche immer am Rand sichtbar ist und die andere normalbreit. Das Ein und Ausblenden wird dann durch GUI Transparenz geregelt. Die Breite wird schrittweise immer mehr sichtbar, die schmale wird zeigleich transparent und letzlich komplett ausgeblendet. Multimonitor Problem behoben.

Ich denke nicht, dass das was du vor hast mit den Forenregeln vereinbar ist. Du willst hier das Erstellen von multiplen Accounts automatisieren. Sowas braucht man nur dann wenn man große Mengen an Accounts auf der selben Webseite anlegen möchte. Ich kenne keine Webseite die solch ein Vorgehen erlauben würde.

Dein anderer Thread bezüglich Proxy Servern sagt mir btw auch, dass die Webseitenbetreiber keine multiplen Accounts wünschen: https://autoit.de/index.php?page=Thread&amp;threadID=39027