mikrocontroller.net

Forum: Compiler & IDEs Suche Simulator für Motorola 68k


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Hp M. (nachtmix)


Bewertung
0 lesenswert
nicht lesenswert
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
von Markus F. (mfro)


Bewertung
2 lesenswert
nicht lesenswert
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.

von foobar (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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?

von honk (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Du könntes einen Driver für Mess/Mame schreiben. Da ist dann auch 
Debugger etc. drin.

von Steffen H. (steffenh)


Bewertung
1 lesenswert
nicht lesenswert
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!

von Georg A. (georga)


Bewertung
1 lesenswert
nicht lesenswert
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
von Christoph db1uq K. (christoph_kessler)


Bewertung
1 lesenswert
nicht lesenswert
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
von Christoph db1uq K. (christoph_kessler)


Bewertung
1 lesenswert
nicht lesenswert
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

von c-hater (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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...

von Hp M. (nachtmix)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hp M. (nachtmix)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Hp M. (nachtmix)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hp M. (nachtmix)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Hp M. (nachtmix)


Bewertung
0 lesenswert
nicht lesenswert
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 :-)

von Hp M. (nachtmix)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
willst Du den 68k-Binärcode hier einstellen?

Vielleicht sticht einem ja was ins Auge.

von Hp M. (nachtmix)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Christoph db1uq K. (christoph_kessler)


Bewertung
0 lesenswert
nicht lesenswert
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
von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hp M. (nachtmix)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Hp M. (nachtmix)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Steffen H. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hp M. (nachtmix)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Hp M. (nachtmix)


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Steffen H. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.