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.
Wie meinst du Host? Also wir möchten das halt so ausgeben, dass es in HyperTerminal angezeigt wird. Tastaur --> Mikrocontroller ---> HyperTerminal
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.