Ich suche einen (am besten) Freeware Simulator für Motorolas 68000 CPU, der auf nem PC oder Raspi läuft. Hintergrund ist mein Marconi 6311 Sweep-Generator, den ich neu kalibrieren möchte. Leider hat MI den Zugang zur Kalibrierung in zwei Ebenen password geschützt, und wie bei Surplus-Geräten üblich, fehlen die originalen Unterlagen, in welchen die passwords standen. Das Service-Manual hilft hier auch nicht weiter, sondern verweist lediglich auf den Umschlag mit einliegendem Password, der mit dem Gerät geliefert wurde. Vermutlich gibt es eine Backdoor über den eingebauten Debug-Modus, aber die ist natürlich noch geheimer. Kurzum: Ich habe die EPROMs (4x 27512) ausgelesen und disassembliert und auch den EAROM (2816) ausgelötet und ausgelesen. Das EAROM enthält neben Kalibrierdaten vermutlich das password (eine 6-stellige Zahl), aber es ist nicht offensichtlich. Hinzu kommt, dass das EAROM nicht am CPU-Bus hängt, sondern der Zugriff (auch auf andere Peripherie) erfolgt über eine Intel 8255 PPI. Etliche Menütexte habe ich im Programmspeicher gefunden, aber leider nicht die Stellen, von denen darauf zugegriffen wird. Wenn ich der Disassembly händisch folge, komme ich kaum bis zum Ende der Initialisierung bevor die Sache zu unübersichtlich wird. Diverse Subroutines sind auch gut zu sehen, aber natürlich nicht, was sie tun. Allenfalls findet man noch ihre Einsprungpunkte in anderen Programmteilen. Weitere Schwierigkeiten ergeben sich daraus, dass auch sowohl der Tastaturscan, wie auch die Ansteuerung der LCD-Matrix nicht über den CPU-Bus, sondern über die reichlich vorhandenen 8255 erfolgt. Ausserdem kümmert sich der Prozessor auch noch um die HPIB-Schnittstelle. Insgesamt ist das ein recht unübersichtliches Programmgeflecht, zu dem mir der rote Faden fehlt. Deshalb möchte ich den Programmablauf mal simulieren um zu sehen, wo sich der Prozessor so rumtreibt, wenn er die Tastaturabfragen verarbeitet. Als letzte Möglichkeit könnte ich natürlich versuchen HP-Basic auf einem alten PC zu installieren und sämtliche 10^6 möglichen Zifferkombinationen über die HPIB-Schnittstelle abzuklappern. Wehe, wenn das Password dann in Wirklichkeit 8-stellig ist, wie es an einer Stelle im Wartungshandbuch zu lesen ist! Ich hoffe, dass das ein Druckfehler ist. Ideen?
:
Bearbeitet durch User
Hp M. schrieb: > Ideen? die NSA hätte das damit versucht: https://ghidra-sre.org/ (und wahrscheinlich auch hinbekommen). Das Tool unterstüzt auch m68k.
68000-Emulatoren gibt es einige, z.B. in den Konsolenemulatoren. Ich bezweifel aber, dass dir das irgendwie weiterhelfen wird, da die gesamte gerätespezifische Hardwareemulation fehlt - die Firmware wird ohne die nicht weit kommen. Disassemblieren dauert, ist mMn aber der sinnvollere Weg. Du solltest aber zumindest nen Schaltplan haben, um zu wissen, was wo dran hängt und unter welchen Adressen es angesprochen wird. Ohne das wird es seeehr mühsam. Im EEPROM (2816) zu suchen klingt eigentlich nicht verkehrt - wirklich nichts erkennbar? Evtl in einem abgetrennten Block? Wie verhält sich das Gerät bei leerem oder verändertem EEPROM?
Du könntes einen Driver für Mess/Mame schreiben. Da ist dann auch Debugger etc. drin.
Wenn im 2816 wirklich Dein Passwort steht, wie Du es vermutest, dann könntest Du probieren, darin nach und nach einzelne Abschnitte mit einem willkürlichen Pattern zu überschreiben. Beispielsweise 0x00. Irgendwann wirst Du den Bereich erwischen, in dem Dein Passwort steht. Das Pattern ist dann Dein Passwort. Mögliche Probleme: - Der 2816 ist mit einer Checksumme abgesichert. Die müsstest Du herausfinden und entsprechend einhalten. - Das Passwort ist nicht als Binärwert, sondern in anderer Form, bspw. als ASCII-Wert, abgespeichert. - Im Bereich des Passworts befinden sich Metadaten, die Du ungewollt mitüberschreibst (etwa dessen Länge). Alternativ zu dieser Brachial-Methode kannst Du es auch mit einem EPROM-Emulator probieren. Der kann Dir während der Passwortabfrage die Adresszugriffe anzeigen. Das Gleiche könntest Du, allerdings weniger komfortabel, auch mit einem Logikanalysator erreichen. Viel Erfolg!
Hp M. schrieb: > Deshalb möchte ich den Programmablauf mal simulieren um zu sehen, wo > sich der Prozessor so rumtreibt, wenn er die Tastaturabfragen > verarbeitet. Wenn das anständig programmiert ist (und ein 68k lädt dazu ein...), wird das nicht viel helfen. Vermutlich gibts einen Interrupthandler für die Tasten, ein GUI-Management und dann nur noch Callbacks für die anstehenden Möglichkeiten (OK, Cancel, ...) die dann auf den dialogspezifischen Code gehen. Dh. selbst wenn man per LA den Adressbus abscannt, wird man bis zum OK-Drücken wahrscheinlich dieselben üblichen Adressen sehen, wie während aller anderen Dialoge.
:
Bearbeitet durch User
http://www.rainer-foertig.de/td/Marconi%206300%20Serie%20TD.pdf nur um mal das Gerät und seine Daten zu sehen Foertig schreibt "Der 6311 von Marconi (heute Aeroflex) ist ein Wobbel-Synthesizer / Signalgenerator für den Frequenzbereich von 10 MHz bis 20 GHz. Mit aeroflex geht es weiter zu cobham, dort steht schließlich "Aeroflex Test Solutions is now part of VIAVI Solutions" dort landet man hier: https://www.viavisolutions.com/en-us/product-category/test-measurement Der 68k sollte in allen Atari und Amiga (und Macintosh) Emulatoren emuliert sein, ich habe selbst den Hatari mal ausprobiert. Damit ist natürlich die gesamte Peripherie falsch, ob das weiterhilft ist sehr fraglich. Vielleicht findet sich bei Viavi noch ein gutmütiger Mensch aus der Zeit dieses Gerätes, der weiterhelfen kann. Sonst helfen nur noch spezielle Messgeräte-Foren z.B. die Selbsthilfegruppe anonymer Messgerätesammler (Gear Acquisition Syndrome): https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/ https://www.eevblog.com/forum/chat/marconi-63116300-manual/ ein Leidensgenosse http://www.ko4bb.com/getsimple/index.php?id=manuals&dir=Marconi Manuals zu 6310 und 6313, und ein Eprom
:
Bearbeitet durch User
zum oben genannten ghidra gibt es auch einen Atari Disassembler https://forum.atari-home.de/index.php?topic=15146.0 https://github.com/czietz/ghidraScripts_for_Atari
Christoph db1uq K. schrieb: > Der 68k sollte in allen Atari und Amiga (und Macintosh) Emulatoren > emuliert sein, ich habe selbst den Hatari mal ausprobiert. Damit ist > natürlich die gesamte Peripherie falsch, ob das weiterhilft ist sehr > fraglich. Naja, man kann ihn recht leicht z.B. aus UAE extrahieren. Das Stück Code ist sehr gut isoliert. Aber klar: Es fehlt dann immer noch eine Emulation der neuen Zielhardware, die an die 68k-Emulation anzudocken wäre. Die nötigen Software-Schnittstellen dafür sind jedenfalls vollständig vorhanden und sauber herausgeführt. Jeder Buszyklus mit jeder beliebigen Peripherie ist damit exakt emulierbar. Guter Code. Trotzdem ist es natürlich sehr viel Arbeit, eine brauchbare Emulation einer komplexen Peripherie auf die Beine zu stellen und die korrekt an den emulierten 68k anzudocken. Die schlichte Tatsache, dass es möglich sein müsste, erzeugt ja leider noch nicht den nötigen Code...
Markus F. schrieb: > die NSA hätte das damit versucht: > > https://ghidra-sre.org/ Danke, das sieht vielversprechend aus. Ich hatte zwar schon teilweise in der Disassembly mittels Suchen und Austauschen Adressen durch Labels ersetzt, aber das versagt praktisch überall, wo mittels Register + Offset adressiert wird. Ein Simulator kann die Registerinhalte natürlich leicht verwalten.
foobar schrieb: > Im EEPROM (2816) zu suchen klingt eigentlich nicht verkehrt - wirklich > nichts erkennbar? Du kannst gerne danach suchen ;-) >Du solltest aber zumindest nen Schaltplan haben, um zu wissen, > was wo dran hängt und unter welchen Adressen es angesprochen wird. > Ohne das wird es seeehr mühsam. Schaltplan und Adressdecodierung habe ich, aber wie gesagt werden da nur die 8255 adressiert. Auch wenn die meistens nur als Output-Latches benutzt werden, haben sie doch Konfigurationsregister, die auch benutzt werden. Das fördert die Übersichtlichkeit nicht gerade. Und weil es so mühsam ist dem Programmablauf zu folgen, frage ich hier ja nach einem Simulator. foobar schrieb: > Wie verhält sich > das Gerät bei leerem oder verändertem EEPROM? Weiss ich noch nicht. Ich habe keinen Ersatz für die beiden Seeq DQ2816A-250. Allenfalls könnte ich da mal ein CMOS-RAM reinstecken, aber ich schätze, dass es dann nur eine Fehlermeldung gibt. Bezüglich Ersatz des (normalerweise eingelöteten) EEPROMs heisst es im Handbuch, dass man dafür die ganze Kiste einschicken soll, weil "bestimmte Aktionen" nötig wären.
:
Bearbeitet durch User
honk schrieb: > Du könntes einen Driver für Mess/Mame schreiben. Da ist dann auch > Debugger etc. drin. Habe noch nichts davon gehört, aber ich fürchte, dass dies ein Riesenaufwand wäre. Ich hatte mal einen Simulator getestet, der glaubt, dass das Programm zu einem Atari gehört, aber da stimmt natürlich nichts, und all die falschen Annahmen zu korrigieren ist nur zusätzliche Arbeit.
Steffen H. schrieb: > Wenn im 2816 wirklich Dein Passwort steht, wie Du es vermutest, dann > könntest Du probieren, darin nach und nach einzelne Abschnitte mit einem > willkürlichen Pattern zu überschreiben. Du ahnst nicht, wie mühsam das ist. Steffen H. schrieb: > Mögliche Probleme: > - Der 2816 ist mit einer Checksumme abgesichert. Die müsstest Du > herausfinden und entsprechend einhalten. > - Das Passwort ist nicht als Binärwert, sondern in anderer Form, bspw. > als ASCII-Wert, abgespeichert. > - Im Bereich des Passworts befinden sich Metadaten, die Du ungewollt > mit überschreibst (etwa dessen Länge). Du darfst davon ausgehen, dass alle diese Vermutungen zutreffen. Allenfalls ist das Password nicht als ASCII gespeichert, denn das wäre mir längst aufgefallen. Eine sechstellige Zahl braucht in Binärdarstellung ungefähr 20 Bit. Siehst du die irgendwo? Steffen H. schrieb: > Beispielsweise 0x00. Irgendwann > wirst Du den Bereich erwischen, in dem Dein Passwort steht. Das Pattern > ist dann Dein Passwort. Wie kommst du zu dieser blauäugigen Annahme?
Georg A. schrieb: > Wenn das anständig programmiert ist (und ein 68k lädt dazu ein...), Ist anzunehmen. Scheint aber Assembler zu sein, denn ich habe keinen Compiler-typischen Schmutz, wie Copyrights oder verirrte Duplikate von Textstrings gesehen. Georg A. schrieb: > Vermutlich gibts einen Interrupthandler für die > Tasten, ein GUI-Management und dann nur noch Callbacks für die > anstehenden Möglichkeiten (OK, Cancel, ...) die dann auf den > dialogspezifischen Code gehen. Mit Sicherheit. Zusätzlich noch Timer Interrupts für Uhrzeit und Datum sowie für den Sweep, sowie vom HPIB. Georg A. schrieb: > Dh. selbst wenn man per LA den Adressbus > abscannt, wird man bis zum OK-Drücken wahrscheinlich dieselben üblichen > Adressen sehen, wie während aller anderen Dialoge. Ja, aber irgendwo werden die Texte der geschützen Menüs aufgerufen, und da ist man schon im gesicherten Bereich und muss nur noch die Calls zurückverfolgen, die dorthin geführt haben. Hoffe ich zumindest :-)
Christoph db1uq K. schrieb: > Vielleicht findet sich bei Viavi noch ein gutmütiger Mensch aus der Zeit > dieses Gerätes, der weiterhelfen kann. Das hatte ich schon versucht, bevor Viavi über der Tür stand, aber leider hat Herr Ladurner von Aeroflex/Cobham auch nichts erreicht. Übrigens ist die Kiste vermutlich keine Marconi-Entwicklung, sondern stammt ursprünglich von Wavetek und wurde dort mit leicht geänderter Frontplatte als 8911 verkauft. Ich besitze nämlich noch das Pendant dazu, den Marconi 6501 "precision amplitude analyzer" (mit Farbbildschirm), und dort prangt auf dem Motherboard noch in riesiger Schrift "WAVETEK". Auch in diesem Gerät werkelt ein 68000. Christoph db1uq K. schrieb: > .B. die Selbsthilfegruppe anonymer Messgerätesammler > (Gear Acquisition Syndrome): > https://www.eevblog.com/forum/testgear/test-equipment-anonymous-(tea)-group-therapy-thread/ > > https://www.eevblog.com/forum/chat/marconi-63116300-manual/ > ein Leidensgenosse Werde ich mir mal ansehen. Die Manuals habe ich vor langem schon für teuer Geld gekauft und, wie gesagt, sämtliche Speicherchips ausgelesen.
willst Du den 68k-Binärcode hier einstellen? Vielleicht sticht einem ja was ins Auge.
Markus F. schrieb: > willst Du den 68k-Binärcode hier einstellen? > > Vielleicht sticht einem ja was ins Auge. Kann ich gerne machen, das macht ja keine Arbeit mehr. Vielleicht kann es ja auch jemand gebrauchen, dessen EPROM Daten verloren hat. IC30, IC31, IC32, IC33 sind die die vier einzelnen Hitachi EPROMs HN27512G-25 auf dem CPU Board A7. Texte befinden sich in den IC33,IC32 Chips - MSB first MI6311.BIN ist das ganze 256kB lange Programm des Sweepers. Als RAM dienen 4x NEC D43256C-12L Das Programm dürfte auch für die anderen Geräte der Serie gut sein. Im Innern gibt es nämlich einen, im Manual dokumentierten, DIP-Schalter, mit dem ich meinem 6311 schon vorgegaukelt habe, es sei ein 6313. Er meldet sich dann auch so. Leider fehlt aber dann doch ein bischen Hardware :-( Die auf den EPROMs vermerkte Versionsbezeichnung ist: 44533- 215 ISS. 1 (die 1 ist handschriftlich) 6311/700 Hier noch ein paar Anmerkungen zum Programm: IC30: Adressen 0 - 00 1 1111 1111 1111 1110 (0 - IC31: Adressen 1 - 00 1 1111 1111 1111 1111 1FFFF) IC32: Adressen 20000 - 01 1 1111 1111 1111 1110 (20000 - IC33: Adressen 20001 - 01 1 1111 1111 1111 1111 ( 3FFFF) Texte befinden sich in den IC33,IC32 Chips - MSB first Am Anfang befinden sich offenbar nur Code und Binärwerte, ab 34480 kommen nur noch 00 bis ab 37E2C Run-time error no. 101: STACK OVERFLOW dann folgen viele ähnliche und kleine 4-Byte-Werte, Evtl. sind das Default Kalibrierwerte für den Richtkoppler zur Leistungsmessung. Danach dann die Display Strings, ein Teil davon wird zur HPIB-Schnittstelle gehören. Besonders interessant sind die Strings ab 39FB0, die mit dem Aufruf der Kalibrierroutinen zu tun haben. Rätselhaft, was der String "SQ00010SH-BP0ESHSS0ESHSP10ESH52LTX" bei 3911E besagt. Doch ein Compiler und dies ist die Lizenznummer? Die bei 3928B genannte "Position Brightline" gehört eigentlich nicht zum Sweeper, sondern ist eine Cursorposition des Network Analyzers (meist ein monochromer Marconi 6500). Aber natürlich kommuniziert der 6500 auch mit dem Sweeper, sodass dieser Text nicht völlig abwegig ist. 38134 ~_________ rest 00 38142 F1~_______ ditto 38150 F2~_______ ditto 3815E CF~_______ ditto 3816B ^\F~______ Diese Sequenz fängt mit 03 an 38187 B~________ Diese Sequenz fängt mit 02 an 38195 C~________ Diese Sequenz fängt mit 02 an 381A3 D~________ Diese Sequenz fängt mit 02 an 381B2 E~________ Diese Sequenz fängt mit 02 an 381BF MK_FREQ~__ Diese Sequenz fängt mit 02 an 381CC ^\~_______ Diese Sequenz fängt mit 08 an F^\~______ AM_FREQ~__ P1~_______ P2~_______ P^\(dB)~__ SLP~______ P1~_______ P2~_______ P^\(mW)~__ TIME~_____ T^\~______ H~________ M~________ S~________ 382A0 OP_HRS~___ USR_HRS~__ CONTRST~__ INT^\~____ S_ADR~____ P_ADR~____ RECALL~___ STORE~____ ALT_MEM~__ RATE~_____ LAST_KEY~_ mks_on~___ 6500_mks~_ RAMP~_____ OFFSET~___ LEVEL~____ SCALE~____ VERN~_____ BAND~_____ CONTROL~__ CNTRL_A~__ CNTRL_B~__ PROG~_____ cntr_tr~__ filter~___ swp_tr~___ 3840B alc~______ sweep~____ 38427 ~_________ Password entry? beginnt mit 06 am~_______ blank~____ 38451 ~_________ Password entry? beginnt mit 06 38460 ~_________ Password entry backdoor? davor steht 00 3846E ~_________ Password entry backdoor? davor steht 00 mode~_____ mk_on~____ analysr[8] pwr_mtr[9] counter[6] plotter[5] mk_swp~___ cal_type~_ altern~___ man_alt~__ 38508 vernier~__ mk_ref~___ mk_stp~___ on/off~___ mkr_^\~___ init~_____ s_swp~____ cf=ref~___ transfr~__ skip~_____ off~______ f1 ~______ f2 ~______ mk ~______ ~_________ leeres Feld? diese Felder sind eng gepackt off~______ on ~______ ~_________ leeres Feld? ~_________ leeres Feld? ~_________ leeres Feld? int ~___ 38602 ext ~___ line ~___ single~___ ~_________ leeres Feld? int ~_____ ext+~_____ ext-~_____ mtr ~_____ ~_________ leeres Feld? int~______ ext~______ ~_________ leeres Feld? ~_________ leeres Feld? ~_________ leeres Feld? ~_________ leeres Feld? ~_________ leeres Feld? ~_________ leeres Feld? ~_________ leeres Feld? ~_________ leeres Feld? off~______ on ~______ ~_________ leeres Feld? ~_________ leeres Feld? ~_________ leeres Feld? 386F3 off ~__ retrace~__ viele leere Felder: ~_________ 3881E off~______ on ~______ ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld off~______ on ~______ ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld off~______ on ~______ ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld off~______ on ~______ ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld off~______ on ~______ ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld 38949 off ~_____ man ~_____ auto~_____ ~_________ leeres Feld ~_________ leeres Feld current~__ memory ~__ ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld off~______ on ~______ ~_________ leeres Feld ~_________ leeres Feld ~_________ leeres Feld A~________ B~________ C~________ D~________ E~________ A~________ B~________ C~________ D~________ E~________ 5x ~_________ leeres Feld 38A77 off ~___ on ~___ on[^\F]~-- 7x ~_________ leeres Feld ready ~_ sweeping~_ inactive~_ viele ~_________ leere Felder ab 38BA2 etliche Controlsequenzen dazwischen 38C0E UNLV~_____ binärkram oder control 38C60 UNLV~_____ binärkram 39068 SP0;~_____ 39096 DPG~______ DPL~______ DPA~______ DPB~______ binärkram 3911E SQ00010SH-BP0ESHSS0ESHSP10ESH52LTX viele 0a und 07 39182 STASTBSTR~ binär 3928B Position Brightline -crlf- -tab- Press [ENTER] 39440 Marconi 3951E WTSTO/RCL& Pending Hier beginnen die calibration menüs: 39FB0 PRIMARY~ USER1 ~ USER2 ~ 3A190 TRANSFER IN PROGRESS 3A1B9 TRANSFER COMPLETE 3A1E0 TRANSFER IN PROGRESS 3A209 TRANSFER COMPLETE 3A3E7 CALIBRATION 3A40D AUTHORISATION CODE 3A475 EXIT 3A47B ID .... 3AD64 WARNING: CALIBRATIONDATA NOT STORED .... 3B05D 10 MHz 30 MHz 50 MHz 100 MHz 300 MHz 500 MHz GHz GHz .... 3B1AD DEFAULT Fehlermeldungen ab 3B611 3CF00 Modellbezeichnungen und andere Daten ab 3CF00 für 6310 (2G-20G), 6311 (10M-20G), 6312 (2G-26.5G), 6313 (10M-26.5G), 6314 (10G-15G),, 6316 (20G-26.5G), 6317 (2G-8G), 3D7AA GENERIC FIRMWARE ISSUE 1 44533.215 Serial Number ~_____________________ .... 3E4BA DIAGNOST~ ... 3EA5C USER KEY PROGRAMMER ======================================================================== === hth
:
Bearbeitet durch User
Hp M. schrieb: > Am Anfang befinden sich offenbar nur Code und Binärwerte, > ab 34480 kommen nur noch 00 bis Das muß so. m68k liest von den ersten beiden 32-Bit Worten den initialen Stackpointer und den initialen PC (den Reset-Einsprung findest Du also an Adresse $4). Danach kommt die Vektortabelle mit den Fehler-, TRAP- und Interrupt-Vektoren (bis $3FF).
https://www.eevblog.com/forum/testgear/wavetek-rf-sweeper-last-on-earth/ der hat den Wavetek 8911 "It seems my 8911 is the last on earth. Is anyone a happy owner of the dinosaur..." Gigatronics 8911 gab es auch noch, gleicher Sweepbereich.
:
Bearbeitet durch User
bei 0001667c beginnt offensichtlich die Menüführung für die Eingabe des Authorisierungscodes: lea xxx, ax xxx: "CALIBRATION ENTER AUTHORISATION CODE" da solltest Du wohl weiter suchen.
Christoph db1uq K. schrieb: > https://www.eevblog.com/forum/testgear/wavetek-rf-sweeper-last-on-earth/ > der hat den Wavetek 8911 "It seems my 8911 is the last on earth. Is > anyone a happy owner of the dinosaur..." > > Gigatronics 8911 gab es auch noch, gleicher Sweepbereich. Die Wavetek Geräte dürften die ältesten sein, so Anfang der 80er. Danach kam Marconi und zum Schluß Gigatronics. Letztere haben das Gerät noch Mitte der 90er verkauft, mit kleinen Änderungen wie 74HC Logik anstelle von 74LS. Meiner hatte übrigens auch einen Fehler im Netzteil, als ich ihn bekam. Schuld war ein defekter NTC, der Übertemperatur signalisierte und das Netzteil sofort wieder abschaltete. Pfiffig dort die Warnung vor den noch geladenen HV-Elkos: Ein Glimmlämpchen das blinkt, solange dafür noch genug Spannung vorhanden ist (70V oder so).
Markus F. schrieb: > bei 0001667c beginnt offensichtlich die Menüführung für die Eingabe des > Authorisierungscodes: > > lea xxx, ax > xxx: "CALIBRATION ENTER AUTHORISATION CODE" > > da solltest Du wohl weiter suchen. Ja danke, diese Stelle kannte ich bereits. Sie liegt aber etwas ungünstig, weil sie sich noch außerhalb der geschützten Menüs befindet, und das Programm bei einer Fehleingabe einfach wieder im normalen Bediener Menü landet, also noch vor dem Aufruf des Calibration Wunsches. Wenn man diesen Punkt aufruft, erscheint im Display nur dieser Text. Keine Zeichen, keine Sternchen bei der Zifferneingabe, kein Cursor, nix. Man da auch beliebig viele Ziffern eingeben, ohne dass etwas passiert. Erst wenn man die Eingabe abschliesst (mit "int" vermute ich; Enter gibts nicht) landet man kommentarlos wieder im normalen Anwendermodus, weil die Eingabe natürlich falsch war. In diesem Zusammenhang gibt es auf einer Platine noch einen DIP Schalter, aber der tut nichts, als bei passender Stellung diese Passwordabfrage gar nicht erst zu ermöglichen. Das steht auch so im Manual.
Hp M. schrieb: > Steffen H. schrieb: >> Wenn im 2816 wirklich Dein Passwort steht, wie Du es vermutest, dann >> könntest Du probieren, darin nach und nach einzelne Abschnitte mit einem >> willkürlichen Pattern zu überschreiben. > > Du ahnst nicht, wie mühsam das ist. Ich verwende diesen Ansatz selbst. Die Mühsamkeit hängt davon ab, wie groß Du die Abschnitte wählst. Wenn Du ihn Beispielsweise 2kByte groß machst, musst Du nur 1x brennen. Das würde dann diesem Ansatz entsprechen: foobar schrieb: > Wie verhält sich > das Gerät bei leerem oder verändertem EEPROM? . Hp M. schrieb: > Steffen H. schrieb: >> Beispielsweise 0x00. Irgendwann >> wirst Du den Bereich erwischen, in dem Dein Passwort steht. Das Pattern >> ist dann Dein Passwort. > > Wie kommst du zu dieser blauäugigen Annahme? Wenn Dein Passwort im 2816 steht und Du den 2816 mit einem Pattern überschreibst, überschreibst Du auch Dein Passwort. Folglich ist Dein Pattern nun Dein neues Passwort. Möglicherweise nicht 1:1 (die Einschränkungen habe ich Dir oben aufgezählt). Aber die Wahrscheinlichkeit ist meiner Erfahrung nach hoch. Jetzt habe ich auch mal eine Frage an Dich: Warum findest Du die Annahme blauäugig? Genau mit diesem Angriff lassen sich diverse Systeme aus dieser Ära knacken. Wertend darfst Du gerne werden, wenn Du schlauer bist als ich. Das ist dann zwar immer noch nicht nett - immerhin hatte ich versucht, Dir zu helfen - aber wenigstens ist es nicht mehr anmaßend.
Markus F. schrieb: > Das muß so. m68k liest von den ersten beiden 32-Bit Worten den initialen > Stackpointer und den initialen PC (den Reset-Einsprung findest Du also > an Adresse $4). Danach kommt die Vektortabelle mit den Fehler-, TRAP- > und Interrupt-Vektoren (bis $3FF). Danke auch dir. Ich wusste auch schon, wie der 68k startet, und wo die Vektoren liegen. Ich hatte mich nur lange nicht mehr darum gekümmert, und der obige Speicherauszug ist nur ein handlicher Teil der Ergebnisse. Ich habe mal meine Disassembly mit Kommentaren soweit ich damals gekommen war als pdf ausgedruckt, aber ich weiss nicht, ob ich sie hier hochladen kann. Das sind über 3MB bzw. über 2000 Seiten. Mal probieren. Schön wäre es, wenn jemand ein Codeschnipsel wie atoi erkennen könnte, denn dann braucht man sich nicht mehr durch den Keyboardscan zu quälen. Vorhanden ist so etwas wahrscheinlich, denn die Maschine empfängt ja auch ASCII-Eingaben vom HPIB, und da liegt es nahe, dass auch der Keybordscan zunächst in ASCII verwandelt wird, und später wird dann beides zusammen verwurstet.
Steffen H. schrieb: > Jetzt habe ich auch mal eine Frage an Dich: Warum findest Du die Annahme > blauäugig? Wenn ich dir damit auf die Füsse getreten sein sollte, tut mir das leid. Es war nicht beabsichtigt. Andererseits habe auch ich damals kommerzielle Programme geschrieben, und manchmal war es nötig, diese vor Kopierern zu schützen. Aber niemals mit einem derartig simplen Verfahren. Ein Profi liest Maschinencode von einem vertrauten Gerät fast so schnell wie Klartext, und manchmal stolpert er dabei sogar über Fehler. Auf mich trifft das im Falle des 68k leider nicht zu, denn ich hatte nur wenig mit diesem Prozessor zu tun. Allerdings weiss ich mittlerweile, was passiert wäre, wenn ich deinem Vorschlag gefolgt wäre: Dass die Daten mit Prüfsummen geschützt sind, war ja klar. Insbesondere gibt es da vier Bereiche mit unterschiedlichen Einstellungen etc., von denen jeder auf diese Weise geschützt ist. Auch das kann man nachlesen. Zwar nicht den verwendeten Prüfsummen-Algorithmus, aber das ist auch nebensächlich. Interessanter ist schon, dass das Gerät auch einen batteriegepufferten CMOS-Speicher "NVRAM" hat, in welchem automatisch letzte Einstellungen, Makros und -password geschützt- auch spezielle Benutzerkalibrierungen abgelegt werden. Nicht so offensichtlich ist, das in diesem NVRAM auch eine Kopie des EEPROM aufbewahrt wird. Beim Einschalten des Geräts werden die Daten des EEPROM mit der Kopie im NVRAM verglichen, und falls dabei ein Fehler festgestellt wird, werden die fehlerhaften Daten mit den richtigen Daten überschrieben. Das funktioniert in beide Richtungen und so wären die mühsam im EEPROM untergebrachten Nullen einfach verschwunden. Lediglich wenn beide Datensätze defekt sind, werden sie durch Defaultwerte aus dem EPROM überschrieben, und die Maschine meldet einen Error 42. Error 42 ! Was sich die Entwickler von Wavetek dabei wohl gedacht haben ;-)
Für mich wäre das Disassemblieren nicht in Frage gekommen. Anstatt tausende Codezeilen einer mir fremden Prozessorarchitektur zu analysieren, empfinde ich es als einfacher, Checksummen zu hacken. Ob das nun im NVRAM oder im EEPROM stattfindet, macht da keinen Unterschied. Aber das ist sicher Geschmackssache und es freut mich, dass Du weitergekommen bist!
Beitrag #6788364 wurde von einem Moderator gelöscht.
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.