Forums Neueste Beiträge
 

OT: Waynes MouseWheelOff/Konsequenzen

07/10/2009 - 00:03 von Raimo Becker | Report spam
Hallo NG,

Erstens:
Ich bin total überfordert von Waynes Code, da ich bis eben nicht wusste,
dass man via VBA per Assembler in die laufende Maschine eingreifen kann.
(den NativeCode hàtte ich gerne übersetzt - wenn jemand Zeit hat :-) )
Habt ihr Links dazu - zum Assembler zur Laufzeit?

Zweitens:
Ich habe dem Admin meines Kunden gesagt, dass ich keine Rechte mehr brauche,
um Stephan Lebans DLL zu registrieren.
Ich zeigte ihm den Code, aber statt vollkommener Zufriedenheit und
hochjauchzender Glücksgefühle kam ein dumpfes...
"Wenn du das aus VBA kannst, kannst du mit jedem Rechner mit irgendwas
irgendwo machen!" (ich ja nicht weil ich es nich raffe)
...Nee. Das mache er nicht
Das er das gar nicht verhindern kann, weil es ja keine COM/DLL blablabla
ist; schien er nicht zu verstehen
Frage:
Wenn es so geht: Wird dann nicht die Büchse der Pandora geöffnet?
Kann man dann nicht ASS-Code in jedem VBA-Projekt verteilen und sich den
Compi Untertan machen?

Drittens: Waynes Code funktioniert bei mir in 3 Apps mit ca. 25
Einzelformularen.


LG
Raimo
 

Lesen sie die antworten

#1 Sascha Trowitzsch
07/10/2009 - 00:40 | Warnen spam
Hi Raimo,

Raimo Becker wrote:
Hallo NG,

Erstens:
Ich bin total überfordert von Waynes Code, da ich bis eben nicht
wusste, dass man via VBA per Assembler in die laufende Maschine
eingreifen kann. (den NativeCode hàtte ich gerne übersetzt - wenn
jemand Zeit hat :-) ) Habt ihr Links dazu - zum Assembler zur
Laufzeit?

Zweitens:
Ich habe dem Admin meines Kunden gesagt, dass ich keine Rechte mehr
brauche, um Stephan Lebans DLL zu registrieren.
Ich zeigte ihm den Code, aber statt vollkommener Zufriedenheit und
hochjauchzender Glücksgefühle kam ein dumpfes...
"Wenn du das aus VBA kannst, kannst du mit jedem Rechner mit irgendwas
irgendwo machen!" (ich ja nicht weil ich es nich raffe)
...Nee. Das mache er nicht
Das er das gar nicht verhindern kann, weil es ja keine COM/DLL
blablabla ist; schien er nicht zu verstehen
Frage:
Wenn es so geht: Wird dann nicht die Büchse der Pandora geöffnet?
Kann man dann nicht ASS-Code in jedem VBA-Projekt verteilen und sich
den Compi Untertan machen?

Drittens: Waynes Code funktioniert bei mir in 3 Apps mit ca. 25
Einzelformularen.



Schön!
;-)

Was hat nun Assembler-Code direkt mit geringerer Sicherheit zu tun?
Es ist doch egal, ob man
- Assembler nimmt,
- API-Funktionen
- oder die VBA-Funktion Kill,
um beliebige Dateien auf dem Rechner oder gar auf Netzlaufwerken zu löschen.

Für deren Sicherheit ist der Admin oder das OS verantwortlich.
Unter Vista etwa muss man Access schon als Administrator starten, um böse
Sachen zu machen.
Ansonsten kann auch Assembler-Code die kernel32.dll nicht löschen oder
modifizieren, wenn Windows was dagegen hat.

Das einzige, was einen mulmig machen kann, ist, dass man nicht weiß, wie der
Quellcode von Wayne aussieht - das verstehe ich. Man muss sich halt drauf
verlassen, dass er keine krummen Sachen eingebaut hat.
Das Problem hat man aber auch bei jedem beliebigen OCX oder einer DLL, die
man in die Verweise einklinkt oder per API anspricht - auch bei denen kennt
man den Quellcode nicht. Oder versteht der Admin den Quellcode von Lebans
DLL?
Ich weiß aber auch noch nicht mal, was MS mit dem ganzen Batzen anstellt,
der beim Windows Error Reporting übers Netz geschickt wird.

Also: Verantwortlich für die Sicherheit sind das OS, die Firewall, die
Antiviren-Software und die Policies, die der Admin vornimmt.
Assembler-Code kann das im Prinzip nicht außer Kraft setzen.
Es gibt aber findige Entwickler, die Rootkits entwerfen, denen mit keinen
Sicherheitsvorkehrungen beizukommen ist. Die müssen keineswegs in Assembler
programmiert werden.

Ich denke die Ängstlickeit, die hier entsteht, kommt von der Unkenntnis über
Assemblerprogrammierung. Ein VBA-Code ist nunmal wesentlich überschaubarer,
als ein pop eax.

Wegen Link, hier ist einer zum Thema:
http://www.ms-office-forum.net/foru...read.php?p55356#post1255356

Ciao, Sascha

Ähnliche fragen