Hallo, Habe mir vor ca.6 Jahren eine LCD Anzeige mit Ladedruck, Öldruck, Öltemperatur, Ansaugluft usw. gebaut, nun habe ich die LCD Anzeige von 2x16 auf eine 4x20 umgebaut, jetzt Funktionieren nur die oberen zwei Zeilen, jetzt habe ich den PIC16F877A ausgelesen und kann leider die Hex Datei nicht Decodieren, habe jetzt die Person angeschrieben wo das Programm geschrieben hat, bei ihm ist leider vor 2 Jahren die Festplatte kaputtgegangen und damit auch der Originalquellcode. Habe schon viele Stunden Gegoogelt aber nichts gefunden. Wie kann ich noch die Hex Datei decodieren?
Angehängte Dateien:
-
16-09-_2019_18-27-44.jpg
200 KB -
16-09-_2019_18-32-16.jpg
140 KB -
16-09-_2019_18-27-21.jpg
250 KB
Alexander M. schrieb: > habe jetzt die Person angeschrieben wo das Programm geschrieben hat, bei > ihm ist leider vor 2 Jahren die Festplatte kaputtgegangen und damit auch > der Originalquellcode. Komisch das dies immer nur dann passiert wenn man selbst nicht der Urheber ist
Niemand jpg kann man nicht entschlüsseln. Warum baust du nicht einfach wieder ein 2x16 Display ein? Thomas
>Wie kann ich noch die Hex Datei decodieren?
Das ist so als würde man versuchen aus einem Hamburger wieder ein Rind
zu machen. Mit ein bißchen kneten geht das wohl, sieht aber nicht
wie das Original aus;)
MaWin schrieb: > Alexander M. schrieb: >> habe jetzt die Person angeschrieben wo das Programm geschrieben hat, bei >> ihm ist leider vor 2 Jahren die Festplatte kaputtgegangen und damit auch >> der Originalquellcode. > > Komisch das dies immer nur dann passiert wenn man selbst nicht der > Urheber ist Das Liegt daran das man nicht Programmieren kann. Ich möchte das alle 4 Werte angezeigt werden ohne dass man einen Taster betätigen muss damit die anderen werte angezeigt werden.
Du möchtest also auch die Programmfunktion grundlegend ändern. Wenn der Originalquellcode nicht mehr da ist, hilft wohl nur noch das Programm komplett neu zu schreiben. Mit der .hex Datei ist da nicht viel anzufangen.
Ohne Quelltext kann niemand das Programm ändern. Das Programm muss man wohl komplett neu entwickeln.
Beitrag #5974608 wurde von einem Moderator gelöscht.
Beitrag #5974611 wurde von einem Moderator gelöscht.
Beitrag #5974615 wurde von einem Moderator gelöscht.
Alexander M. schrieb: > und kann leider die Hex > Datei nicht Decodieren, habe jetzt die Person angeschrieben wo das > Programm geschrieben hat, bei ihm ist leider vor 2 Jahren die Festplatte > kaputtgegangen und damit auch der Originalquellcode. > Habe schon viele Stunden Gegoogelt aber nichts gefunden. Ja, schade...dumm gelaufen! Wenn du selbst keinen Schimmer vom Programmieren hast, dann bau' die Anzeige einfach zurück und bleibe glücklich. Gruß Rainer
>Als es mir gestern schon mehrfach auffiel
Nur gestern? Das macht der seit Jahren schon so;)
Alexander M. schrieb: > Ich möchte das alle 4 Werte angezeigt werden ohne dass man einen Taster > betätigen muss damit die anderen werte angezeigt werden. Baue die Zweiteilen Anzg. wieder ein und statt Taster, einen Timer der im bestimmten Intervall die Werte umschaltet. Oder mache mit einen zusätzlichen Microk. einen Zeilensprung auf deiner 4Zeilen Anzeige...
Beitrag #5974721 wurde von einem Moderator gelöscht.
Beitrag #5974760 wurde von einem Moderator gelöscht.
Beitrag #5974762 wurde von einem Moderator gelöscht.
Beitrag #5974766 wurde von einem Moderator gelöscht.
Beitrag #5974769 wurde von einem Moderator gelöscht.
Vergiss es! Es ist nicht damit getan, eine 2 in eine 4 zu verändern. Das ist Unabhängig davon ob Du in der Lage bist die Stelle zu finden, an der Du kitzeln musst. Einzige Ausnahme: Du bist ein direkter Nachfahre des Korinthers Sisyphos. Für den währe das der richtige Job. Übrigens: Mit den richtigen Tools ist es gar nicht mal so schwer, den Inhalt eines Hex-Files zu disassemblieren. Ob Du aber damit etwas anfangen kannst steht auf einem anderen Blatt.
Beitrag #5974782 wurde von einem Moderator gelöscht.
Sebastian S. schrieb: > Übrigens: Mit den richtigen Tools ist es gar nicht mal so schwer, den > Inhalt eines Hex-Files zu disassemblieren. hat er mit dem IDA doch. Allerdings muss man damit auch umgehen können. So als Hinweis: die Tasten <a> <p> <d> <u> und immer schön sichern es gibt kein undo in IDA Thomas
>hat er mit dem IDA doch. Allerdings muss man damit auch umgehen können.
Eigentlich wollte ich auf etwas anderes hinaus.
Das Beste, das Du bekommen kannst ist eine schier endlose Kette von
Assemblerbefehlen, bei denen Du noch die Unterscheidung treffen musst,
was ist jetzt wirklich Befehl und was sind Daten. Die ursprüngliche
Struktur, egal ob aus Assembler oder C-Code existiert ja nicht mehr.
Erst wenn Du das auseinander klamüsert hast, kannst Du Dich daran machen
die Stelle zu finden, wo es juckt.
Also ohne einiges an Übung: Ein Job für den guten alten Sisyphos.
Beitrag #5974824 wurde von einem Moderator gelöscht.
Es fängt schon damit an, dass du einige zig Kilobytes an Daten hast, ohne dass deren Bedeutung und Struktur irgendwo erklärt wäre. Du siehst am Code, dass er z.B. zwei Bytes von Position 32452135412 und 124123 addiert und das Ergebnis nach 215153523 schreibt. Was sagt einem das? Nichts. Und so wird das durch den ganzen Code gehen. Mit zig tausenden von Anweisungen. Wenn man wenigstens die Namen der Variablen und Sprungmarken (bzw. Funktionen) hätte. Aber so ein Maschinencode gibt das nicht her.
Alexander M. schrieb: > habe jetzt die Person angeschrieben wo das > Programm geschrieben hat, bei ihm ist leider vor 2 Jahren die Festplatte > kaputtgegangen und damit auch der Originalquellcode. Wenn man sowas in Auftrag gibt vereinbart man vorher(!) immer auch die Übergabe aller notwendigen Quelldateien und bei der Übergabe überzeugt man sich davon daß es auch kompiliert und keine einzige Datei fehlt. Nur so als Tipp für die Zukunft.
:
Bearbeitet durch User
Sebastian S. schrieb: > Übrigens: Mit den richtigen Tools ist es gar nicht mal so schwer, den > Inhalt eines Hex-Files zu disassemblieren. > Ob Du aber damit etwas anfangen kannst steht auf einem anderen Blatt. Hi, die strukturierenden Kommentare fehlen dann. Bin immer noch dabei, den 2500 Zeilen-Uhren-Hex vom disassemblierten File zu einem lesbaren ASM-File umzuwandeln. Die Registernamen erscheinen nicht, wie man es gewohnt ist, mit Funktionsbeschreibung. Man muss im Dabla nachsehen, was der Code bedeutet. Und was noch viel teuflischer ist, die Sprünge werden nicht als Labels ausgeführt. Die Sprungweite in hexadezimal angegeben und Einbyte-Zweibyte-Dreibyte-Befehle "springen" anders. Spätestens nach Label 64 gebe ich es auf. Und dann noch Im EEPROM Sprung ins Nirgendwo mit STD Store with displacement. Kannte ich bis dato überhaupt noch nicht. ciao gustav
:
Bearbeitet durch User
Stefanus F. schrieb: > Es fängt schon damit an, dass du einige zig Kilobytes an Daten hast, > ohne dass deren Bedeutung und Struktur irgendwo erklärt wäre. Wenn die Screenshots oben alles richtig zeigen, dann hat er 8 kB Programm. Das wäre aber immer noch mehr als genug. Bernd K. schrieb: > Wenn man sowas in Auftrag gibt Wahrscheinlich handelt es sich um Code, der in irgendeiner Community publiziert wurde, damit man sich das Gerät nachbauen kann.
Karl B. schrieb: > Und was noch viel teuflischer ist, die Sprünge werden > nicht als Labels ausgeführt Das ist allerdings schwach. Ein Disassembler könnte selbstverständlich Labels erzeugen, die heissen dann halt Label0001, Label0002 usw., aber das ist schon viel besser lesbar. Aber wenn das dein Tool nicht kann, pk (Pech kett). Georg
Ich habe mich recht lange mit dem Disassemblieren von x86-Code (Viren) beschäftigt. Das schwerste finde ich ist zu unterscheiden, was Daten und was Code ist. Das schaffen die Disassembler oft nicht zu trennen, man muß sich den Anfang und das Ende der Programmteile selbst raussuchen und entsprechend definieren. Wenn sich der Programmierer Späße gönnt wie etwa seinen Daten irgendwo in den Code einzustreuen und dann auch noch zu verschleiern (einfache Verschlüsselung reicht), wird das recht umfangreich. Die Disassembler können durchaus Labels im Quellcode setzen, was fehlt sind sinnvolle Bezeichnungen und natürlich alle Kommentare. Funktionen erkennt man recht schnell (push/pop's und der Rücksprung am Ende). Allerdings ist das was der TE hier vor hat schon eine recht große Änderung am Programm (anderes Display). Wenn das nicht von Anfang an ein Assembler-Programm war (etwa C), wird das sportlich. Das ist etwas mehr als z.B. einen Schutz auszuhebeln oder so, wo man im einfachsten Fall nur einen Sprungbefehl löschen muß.
Naja, wenn die zwei Ausgaben, die mit Taste umschaltbar sind, jeweils in einem Ritt rausgeschrieben werden, dann ist das ja sicherlich nur eine kleine Schleife, die die 32 Zeichen rausschreibt. Die kann man ja aufbohren auf seine 80 Zeichen, und beide Teilstrings rausschreiben lassen. So richtig aufwendig betrachte ich die letztendliche Lösung also gar nicht, aber dafür die Analyse des Codes vorher. Wenn man's schlau anfängt, dann fängt man als erstes beim Schaltplan an, bzw. bei den Displayanschlüssen, um die Displayports/Pins rauszufinden. Dann muß man eigentlich nur die Stelle im Code suchen, wo diese Pins manipuliert werden. Dann hat man schonmal den Anfang für das Loshangeln. Für die Taste dann genau so. Natürlich bleibt das rel. großer Aufwand, aber wenn man Ahnuung vom genutzten LCD und µC hat, und Gedult, kann das sicherlich vergleichsweise schnell gehen.
Ich finde, ihr solltet dem TO keine falschen Hoffnungen machen. Er kann es nie und nimmer und ihr wollte es sicher nicht für ihn machen - selbst wenn ihr könntet. Also ist das Vorhaben damit gestorben.
Das Programm neu zu schreiben geht vermutlich schneller, selbst in Assembler. Was ist das eigentlich für ein neues 4x20 Display? Kommt das weiterhin mit einem einzigen Enable-Eingang aus oder wird da auch noch eine Änderung an der Hardware fällig? Wenn es ein 4x20 mit nur einem Controller ist, könnte man zwischen den Zeilen auch einfach einen Haufen Leerzeichen schreiben um die nächsten beiden Zeilen zu erreichen. Die meisten Displays tolerieren es, wenn man auf diese Weise den RAM-Bereich überschreibt.
Ben B. schrieb: > Das Programm neu zu schreiben geht vermutlich schneller, selbst in > Assembler. das sowieso. Der TO kann das aber vermutlich nicht. 4x20 haben genauso wie 40x2 Displays nur einen Enable. Zwei Enable sind erst bei Displays mit mehr als 80 Zeichen notwendig. Dann sind einfach 2 Controller verbaut. Thomas
Angehängte Dateien:
-
18-09-_2019_19-03-47.jpg
100 KB -
TARGET__Ladedruck.T3001.jpg
230 KB
Das mit dem Timer ist ein guter Tipp, mir fehlt leider die Zeit um mich in das Programmieren einzuarbeiten, wenn ich Täglich nur ca.1 Stunde Zeit habe komme ich da nicht weit, und wenn ich es schaffen würde das Programm zu schreiben, dann währe es noch ein aufwand alles abzustimmen damit die Werte ziemlich genau sind wieder.
:
Bearbeitet durch User
Naja wenn ich mir den Schaltplan so anschaue... Vermutlich ist der Code auch so strukturiert. Der Taster ist auch nirgens zu sehen, und das Hexfile immer noch nicht da..... Was erwartest du also genau von uns? Thomas
Alexander M. schrieb: > nun habe ich die LCD Anzeige von > 2x16 auf eine 4x20 umgebaut Alexander M. schrieb: > jetzt die Person angeschrieben wo das > Programm geschrieben hat, bei ihm ist leider vor 2 Jahren die Festplatte > kaputtgegangen und damit auch der Originalquellcode. Alexander M. schrieb: > und wenn ich es schaffen würde das > Programm zu schreiben, dann währe es noch ein aufwand alles abzustimmen > damit die Werte ziemlich genau sind wieder. Angesichts obiger Gegebenheiten denke ich, das ursprüngliche 2x16 Display wieder einzubauen und es damit dann auch gut sein zu lassen wäre wohl gar nicht so schlecht.
Hallo Alexander M.! Alexander M. schrieb: > Das mit dem Timer ist ein guter Tipp, mir fehlt leider die Zeit um mich > in das Programmieren einzuarbeiten, wenn ich Täglich nur ca.1 Stunde > Zeit habe komme ich da nicht weit, und wenn ich es schaffen würde das > Programm zu schreiben, dann währe es noch ein aufwand alles abzustimmen > damit die Werte ziemlich genau sind wieder. Aber die anderen haben die Zeit, die Du nicht aufbringen kannst/willst? Vielleicht solltest Du jetzt mal sagen, was Dir diese Auftragsarbeit wert ist. Des Weiteren solltest Du den Mitforisten mal die Datenblätter aller Sensoren verlinken. Wenn man die Kiste nachbaut, muss man sich schon etwas einfallen lassen, um die korrekte Berechnung der Werte der Drucksensoren überprüfen zu können. Offensichtlich hat Dein Gerät ja einen Taster zur Umschaltung der Bildschirmanzeige, den ich auf dem Schaltplan nicht gefunden habe. Wer das drauf hat, findet die Abfrage des Schalters, patcht die heraus und kombiniert die beiden Routinen für die beiden Sensorsichten in eine neue, die alle vier Zeilen ausnutzt. Irgendwie bist Du mir aber nicht ganz glaubwürdig. Einerseits behauptest Du, nicht programmieren zu können, andererseits veröffentlichst Du hier Screenshots von IDA Pro? Das passt einfach nicht zusammen. Andererseits lieferst Du Informationen in der altbekannten Anfänger-Salamitaktik.
:
Bearbeitet durch User
Sorry, habe vergessen das ich die schon rausgenommen habe, Programmieren kann ich ein wenig ist halt 20Jahre her, sprich verlernt da ich seit der Ausbildung nicht mehr was damit zu tun hatte, aus diesem Grund behaupte ich das ich es nicht kann. Zum Thema Zeit, mir fehl eben die Zeit da ich alleinerziehend bin und nach der Arbeit ich meine Tochter von der Schule hole und es mir wichtiger ist für sie da zu sein, daher habe ich gehofft das man mit der Hex Datei noch was anfangen kann damit eben nicht so viel Zeit in Anspruch genommen wird. Werde die Taster jetzt nochmal einfügen und hochladen.
Und warum nimmt man sich als so viel beschäftigter Mensch solche total unwichtige (und aussichtlose) Projekte vor?
:
Bearbeitet durch User
Angehängte Dateien:
Habe jetzt die Taster eingefügt.
Alexander M. schrieb: > Um mal abzuschalten und Abends nicht als vor dem Fernseher zu hengen. du bist echt ein Held. Welcher Taster ist jetzt zum Umschalten das Displays? Was ich dir schon sagen kann. Das Ding besteht aus 26 Unterprogrammen und einer großen Mainschleife. Ziemlicher Spageticode Der Code gebt bis knapp unter 0x1000. Woher ich das habe? Ich hab das Ding mal 5 min in IDA angeschaut und eben nicht vor dem Fernseher gehengt. Wer das programmiert hat hat hat auch nicht so den Durchblick. Thomas
:
Bearbeitet durch User
Thomas Z. schrieb: > Ich hab das Ding mal 5 min in IDA angeschaut und eben nicht vor dem > Fernseher gehengt. Wer das programmiert hat hat hat auch nicht so den > Durchblick. Du scheinst hingegen den mega Durchblick zu haben. 5 Minuten aufs Hexfile geschaut und schon kannst du Kaffeesatz lesen und Aussagen über den Programmierer orakeln. Was für ein dummes Geschwätz hier gelegentlich auftaucht ist schon echt bemerkenswert.
Bernd K. schrieb: > 5 Minuten aufs > Hexfile geschaut und schon kannst du Kaffeesatz... lern lesen bevor du solchen mist schreibst... wo steht dass ich aufs Hexfile geschaut habe? Ich habs einfach in IDA geladen. Wenn du nicht weist was das ist dann geh googlen. Ich arbeite lange genug mit dem IDA um eine Aussage über die über die Codequalität zu machen. Thomas
37kB .hex?? Sorry aber da kämpfe ich mich nicht durch. Bis ich damit fertig bin, habe ich das Programm ja dreimal neu geschrieben. Die .hex für das Terminal meiner Alarmsau ist nur 8kB groß und das kann vermutlich mehr als diese Anzeige. Ist aber auch ein AVR und kein PIC, der AVR kann deutlich mehr was Assemblerbefehle angeht. War mein Hauptgrund zu den AVRs zu wechseln obwohl ich mit dem PIC angefangen habe.
Angehängte Dateien:
-
ida.png
200 KB
ist etwas weniger als 4k. Der Rest sind wohl Tabellen IDA zeigt 26 kurze Unterprogramme (insgesammt 500bytes) und eine Mainschleife mit etwa 3.3kb Also eher wenig Code. Thomas
Nur mal so.... wenn der Eingang für den Taster durch ein externen 0,5 oder 1Sek Impuls getaktet würde, dann hätte er doch was er will. Beide Anzeigen ohne Drücken zu müssen. Nur nicht gleichzeitig :-o
Das sieht doch schon ganz gut aus. Ich hab' früher auch ab und zu mal Code disassembliert, allerdings mehr 68k Plattform (Amiga). Da konnte man am Code teilweise schon erkennen mit welchem C-Compiler er übersetzt war, und Compilercode ist nochmal eine andere Herausforderung zu verstehen. Sofern dieses Programm hier in ASM geschrieben wurde, sollte man es doch relativ leicht verstehen können, Thomas hat ja schon gute Arbeit geleistet. Als absoluter No-PICler bin ich aber hier definitiv raus.
Thomas Z. schrieb: > Ich arbeite lange genug mit dem IDA um eine Aussage über die über die > Codequalität zu machen. Ach? Na erzähl mal. Lass uns doch mal teilhaben an deinem unglaublichen Wissen, wie du aus Code, der von einem optimierenden Compiler erzeugt wurde, auf den Programmierer schließen kannst.
vn nn schrieb: > Thomas Z. schrieb: >> Ich arbeite lange genug mit dem IDA um eine Aussage über die über die >> Codequalität zu machen. > > Ach? Na erzähl mal. Lass uns doch mal teilhaben an deinem unglaublichen > Wissen, wie du aus Code, der von einem optimierenden Compiler erzeugt > wurde, auf den Programmierer schließen kannst. von welchem Compiler redest du genau? Das Teil wurde in Assembler geschrieben. Bei einem C Compiler würde man Libcode im dissam flile finden. Zumindest wäre startup code zu identifizieren.Der IDA kann solche Codeausschnitte finden und markieren. (flirt) Jede Art von Compiler hinterläßt immer einen Fingerabdruck im Code. Kein C Programmierer würde alles in main packen. @Freizeitfrickler ich hab keine Vorarbeit reingesteckt, was ich gezeigt habe ist der initiale IDA Output. Die Arbeit würde von dieser Basis erst beginnen. Thomas
Thomas Z. schrieb: > Kein C Programmierer würde alles in main packen. Wenn er keine Interrupts benutzt ist zwangsläufig alles in main()
Bernd K. schrieb: > Wenn er keine Interrupts benutzt ist zwangsläufig alles in main() Er meint hier nicht den Interrupt-Level, auf dem die Abarbeitung passiert, sondern die Struktur des Codebaums auf dem Main-Level, also all das, was sich nicht in ISRs abspielt. Compiler neigen z.B. dazu, unnütze, zeitraubende Unterprogrammaufrufe zu realisieren. Und man kann es ihnen nur begrenzt abgewöhnen. Selbst bei der Optimierung auf Geschwindigkeit bleiben fast immer solche Artefakte über. Nur bei sehr trivialen Programmen schaffen es die besten Compiler, diese unnützen Redundanzen selbstständig vollständig zu eleminieren. Dabei ist die Optimierung eines Codebaums noch ihre stärkere Seite. Das richtige Elend zeigt sich meist in der Optimierung des Waldes, der sich aus den Codebäumen von main und jeder ISR ergibt. Das ist meist richtig grottig, denn das können Compiler nicht selbstständig optimieren. Nur gute Kenner des jeweiligen Compilers können unter Verwendung (natürlich nichtportabler) Features des jeweiligen Compilers hier noch etwas retten... Es gibt aber noch viel mehr typische Compiler-Artefakte, nicht nur Unterprogrammaufrufe. Ein gelernter Assemblerprogrammierer erkennt im Disassemblat sofort, ob der Code von einem Compiler stammt, von einem Assembler-Anfänger oder von einem Assembler-Profi. I.d.R. kann man sogar recht leicht erkennen, von welchem Compiler der Code stammt, allerdings natürlich nur, wenn man den typische Output des Compilers für die jeweilige Plattform bereits vorher kennt.
"Compiler neigen z.B. dazu, unnütze, zeitraubende Unterprogrammaufrufe zu realisieren." Das ist die Meinung eines armen Tropfs, der sich weder in der Informatik noch im Compilerbau auskennt. Also genau richtig für die Seite mikrocontroller.net.
c-hater schrieb: > Compiler neigen z.B. dazu, unnütze, zeitraubende Unterprogrammaufrufe zu > realisieren. Und man kann es ihnen nur begrenzt abgewöhnen. Also Du scheinst einen komischen Compiler zu haben, der den ich benutze neigt dazu alles zu inlinen was nicht bei 3 auf dem Baum ist oder mehrfach aufgerufen wird und selbst dann inlined er manchmal wenn die Funktion kurz genug ist. Daran kann ich ihn nur mit expliziten Funktionsattributen oder anderen schmutzigen Tricks hindern für den seltenen Fall dass ich das wirklich mal verhindern will. Normalerweise find ich es aber absolut begrüßenswert daß er inlined was zu inlinen geht, selbst über Modulgrenzen hinweg und durch 3 Wrapper-Schichten hindurch. Als ich mir mal den Spaß gemacht habe zum Zeitvertreib einen Startupcode in C zu schreiben hat er kurzerhand die ganze main und alles was sie aufrief in einem einzigen langen Schlauch direkt in den reset-Vektor geinlined. In der Regel ist der Maschinencode der rauskommt wenn der Compiler und der Linker mit allen Optimierungen fertig sind eine vollkommen unleserliche strukturlose Instruktionsbuchstabensuppe bei der Anweisungen sich verschoben haben oder weit auseinandergezogen und mit anderen verflochten wurden und hat mit der Struktur des Quelltextes praktisch nichts mehr gemein und einzelne Anweisungen lassen sich auch kaum noch explizit einzelnen Quelltextzeilen zuordnen, bestenfalls noch ganz grob daß diese oder jene Instruktionswolke irgendwo zum Dunstkreis dieser 5 Codezeilen gehören muss (und auch zu jenen 2 weiter unten und auch zum Schleifenkopf weiter oben denn von dem steckt auch noch ein Fetzen irgendwo mitten drin), liebevoll interleaved und verknotet mit 3 anderen Sachen gleichzeitig und dann wieder langgezogen daß die Knoten zugehen. So extrem wird der Code zerhäckselt und neu gemischt.
:
Bearbeitet durch User
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.