Guten Morgen.
Wir machen zur Zeit in der Schule ein Informatik Projekt, wo sich jeder
aussuchen kann, was man gerne verwirklichen möchte.
Ich habe mich für einen Hardware Keylogger entschieden. Der Kursleiter
meinte auch, dass dies kein allzugroßes Problem darstellen sollte. Nunja
wir haben bisher nur LED´s angesteuert....
Gedacht ist es, dass wir mit unsererm uController (Atmel) eine Tastatur
anschließen, und über die serielle Schnittstelle direkt ausgeben.
Wollten dies erst mit einem EEPROM lösen, ist aber noch viel
komplizierter.
Was wir brauchen (vermuten):
- +5V
- GND
- DATA
Pinbelegung am PS2 Stecker ist uns klar und auch wie das Protkoll mit
den Scancodes fungiert. Allerdings wissen wir nicht wie wir damit
Anfangen sollen und zerbrechen uns jeden Tag den Kopf darüber.
Würde mich über eine Antwort freuen.
PS: Wir programmieren in Assembler.
CLOCK haste vergessen.
www.marjorie.de
Anfangen tut man am Anfang. Empfehlenswert ist das AVR-Tutorial und die
ATMEL Datenblätter. Das Programm selber fängt die Scancodes ab und formt
sie in ASCII- oder HEX-werte um, die über die Serielle Schnittstelle
ausgegeben werden. Mit einem Terminal-Programm oder Portmonitor
kontrolliert man das Ergebnis am PC.
Ja die Seite ist mir bereits bekannt. Ist die Variante mit dem EEPROM.
Also auf der Seite die Travel Rec. gepostet hat, findet zumindest schon
mal die Scancodes.
Wir müssen es halt irgendwie schaffen CLK abzufragen, und dann das ganze
mit einer Tabelle lösen (Scancodes).
Uns ist schon klar, wie es funktioniert, nur es scheitert dann am
Programmieren..
die tastatur ist immer ein slave. im normalfall ist pc der host. Wenn du
die µC kiste vorschaltest sind zwei modi denkbar:
µC ersetzt pc und bedient die Tastaur mit allen konfig-daten
oder
(was für mich in eurem Fall für bessere Alternative erscheint): ein
transparentmode, sprich eure kiste steckt zwischen pc und tastatur und
gibt die daten 1:1 weiter. nebenbei kann der zweite pc die daten über
serielle oder usb mithören.
CLOCK hängst Du ein einen Interruptpin. In der ISR fragst Du dann DATA
auf den aktuellen Pegel ab und schiebst ihn als Bit 1 oder 0 in eine
Variable. Nach dem Stopbit hast Du dann Dein Byte eingesammelt. Jetzt
mußt Du noch die Auswertung entsprechend der Codetabellen vornehmen und
das ganze dann als Tastenwert ausgeben.
>die tastatur ist immer ein slave. im normalfall ist pc der host. Wenn du
Ja, aber die Tastatur gibt immer die CLOCK und im Sendefall auch DATA
vor und diese muß also abgefragt werden. Was der PC damit macht, kann
dem Logger relativ Schnitte sein. Er muß allerdings unterscheiden
können, ob die Tastatur oder der PC (zum Beispiel Konfig- oder
Steuerdaten) sendet
richtig
deswegen transparent mode.
jeder pc behandelt tastatur anders, warum also sich etwas ausdenken,
wenn es schon da ist (bez. auf config string).
die tastatur sendet (gibt CLK und Data raus) wenn sie darf. Dies muß der
host auch können.
Auf der Atmel Homepage gibt es eine Application Note (für Atmega) mit
Beispielcode in C zum einlesen der Zeichen einer PS2-Tastatur. Ist recht
schön geschrieben, wirste schon finden.
Dort wurde für die Scan-Codes ein hübsches Array geschrieben.
Ihr schreibt ihr von "Transparent Mode" und von irgendwelchen Strings,
ich weiß nichtmal wo anfangen ^^
Hab das hier gefunden:
http://www.atmel.com/dyn/resources/prod_documents/doc1235.pdf
Ist aber in C geschrieben.
Da ist doch bereits die Serielle Schnitstelle im Quellcode?
Allerdings versteh ich die Pin Belegung nicht so ganz. (Quellcode)
Wäre es einfach wenn man es in Assembler schreibt?
solange das gilt:
> Ihr schreibt ihr von "Transparent Mode" und von irgendwelchen Strings,> ich weiß nichtmal wo anfangen
ist diese Frage
> Wäre es einfach wenn man es in Assembler schreibt?
eindeutig mit NEIN zu beantworten.
Solange du die grundlegende Idee (=Algorithmus) nicht verstanden hast,
ist es egal ob das in C, Assembler oder in klingonisch formuliert ist.
LOL!
Also ein einfaches Projekt ist das nicht. PS/2 ist ein ziemlich
grottiges Interface, das zudem noch schlecht dokumentiert ist.
Als Keylogger ist das Problem, dass man keinerlei
Handshaking-Möglichkeiten hat und damit die Daten akzeptieren können
muss wann immer sie ankommen. Damit wird die Programmierung sehr
zeitkritisch. C oder andere Hochsprachen würde ich auf keinen Fall für
diese Anwendung empfehlen, das wird nur was in Assembler mit
handverlesenem Code.
Mokka schrieb:
> Guten Morgen.>> Wir machen zur Zeit in der Schule ein Informatik Projekt, wo sich jeder> aussuchen kann, was man gerne verwirklichen möchte.>> Ich habe mich für einen Hardware Keylogger entschieden. Der Kursleiter> meinte auch, dass dies kein allzugroßes Problem darstellen sollte. Nunja> wir haben bisher nur LED´s angesteuert....
Dann solltest du keinen derart grossen Sprung machen.
Mach dein Projekt über etwas, von dem du wenigstens ein bischen Ahnung
hast. Zb. Ein Knight-Rider Lauflicht mit fliessenden Übergängen zwischen
den Leds oder eine LED-Matrix aus 8 * 8 Led auf denen man PONG spielen
kann, oder ...
> PS: Wir programmieren in Assembler.
Dann solltest du erst recht bei deinen Leisten bleiben und dich in
bekanntem Wasser bewegen.
Also wenn es nur eine Ausgabe der von der Tastatur gesendeten Daten und
nur derer über die serielle Schnittstelle geht, dann hab ich da schon
was fertiges für euch:
Beitrag "Re: AT-Tastatur - PC - µC "einschleifen" -> RS232"
Die Scancode->ASCII-Umwandlung ist nicht dabei, aber aus der Atmel
Appnote oder woanders zu entnehmen.
Danke für deine Hilfe damals, Travel Rec. !!!
MisterMime
@ Mister Mime: Ist leider alles in C geschrieben. Kann nur etwas
Assembler und Java..
Bin bereits soweit...
-------------------------------------------
clk equ P3.0 ;Pins belegen
daten equ P3.1
org 0
;negative flanke prüfen // Datenaustausch von Tastatur zum PC
loop:
jnb clk,loop
loop1:
jnb daten,loop1
jb daten,loop
jb clk,loop1
mov a,#0
acall datenerfassung
datenerfassung:
mov R7,#0
inc R7
cjne R7,#11,ziel2
;xxxxxxxxxxxxxxxxxxx
; verglich von Z0
;xxxxxxxxxxxxxxxxxxx
mov R5,#daten
rlc a
mov a,R5
ret
;xxxxxxxxxxxxxx
; ausgabe von R5 (serielle schnittstelle)
;XXXXXXXXXX
ziel2: ret
--------------------------------------------------------------
wenn org = 0 dann sollte ein Sprung in die Main erfolgen.
Da vorne liegen Vectoren für die Int. Und den SP ordentlich laden.
zB.: jmp main
; die Vectoren
; die Main zB. ab 30h
mov sp,#20h
Die Main könnte dann wegen mir bei 30h beginnen. Kommt darauf an
wieviele Call nachher kommen. Entsprchender Platz für den Stack muss
sein.
Du kannst den Stack auch nach hinten legen, wenn Du weist wo Dein Proggi
zu Ende ist..
nach "Acall Datenerfassung" fehlt was. Er würde danach "endlos" laufen,
bzw. von Vorne beginnen. Er kommt ja mit Ret zurück.
Im einfachsten fall einen Jmp auf den richtigen Anfang.
Typischer Weise läuft eine Main als Endlosschleife in welcher Zustände
und Variablen abgefragt und entsprechende Aktionen ausgeführt werden.
Danach geht´s wieder von vorn los.
