Programm aus PIC12F508 laden und verstehen

H. H. schrieb:

Es geht danach einfach im Hauptprogamm weiter.

Der Hauptprogramm ist dann aber: GOTO LADR_0x0148 was zu NOPs führt. Am ende aber ist ein MOVLW 0x2A ; b'00101010' d'042' "*" das ist doch aber die Osszilator Kalibration.

Rest von Code sehe ich nicht angesprungen. Habe ich da etwas übersehen?

H. H. schrieb:

Nach 1ffh kommt 0h.

Ja klar. So hat man damals die Osszicaltor Trimmungswerte übergeben. Ich glaube bei einigen PICs war der Resetvector nicht 0 sondern 0x1FFF. Damit wurde W mit den Trimmwerten geladen, und man musste das abspeichern. Egal, das sind jetzt Detail Sachen.

Wenn ich mir den Code angucke, macht der meist garnix. Hälfte sind einfach NOPs und bisschen hin und her springen. Habe bestimmte etwas übersehen, aber so wie ich es verstanden habe, macht der etwas am Anfang, dann kommen irgendwie viele NOPs, dann überrollt der PC wieder auf 0 und fängt von vorne wieder an.

Hier bin ich unsicher: BTFSS STATUS,Z GOTO LADR_0x001F RETLW 0x00 ; b'00000000' d'000' MOVWF LRAM_0x09

Sprint der RETLW wieder auf GOTO LADR_0x0148 , richtig? Es gibt hier noch keinen Stack wo man die Rücksprungadressen gespeichert hat. Das Ding meine ich hatte einen Hardcoded Stack von 3 und man konnte nur da für den CALL verwenden.

Wenn das so der Fall ist, lässt sich der Code so vereinfachen: ; Reset-Vector NOP MOVWF OSCCAL GOTO LADR_0x0014

LADR_0x0014 CALL LADR_0x0016 GOTO DelayShort

LADR_0x0016 MOVLW 0x04 ; b'00000100' d'004' MOVWF GPIO MOVLW 0x08 ; b'00001000' d'008' TRIS GPIO MOVLW 0x4F ; b'01001111' d'079' "O" OPTION MOVLW 0x07 ; b'00000111' d'007' MOVWF FSR CLRF INDF LADR_0x001F INCF FSR,F CLRF INDF MOVLW 0xFF ; b'11111111' d'255' SUBWF FSR,W BTFSS STATUS,Z GOTO LADR_0x001F RETLW 0x00 ; b'00000000' d'000'

DelayShort NOP MOVLW 0x2A ; b'00101010' d'042' "*"

1

End

Das Ding macht nichts? Sehe ich das richtig? Die SW ist meiner Meinung nach Unsinn.

Habe eben mit MPLAB simuliert. Das Ding macht ja nix. Hälfte der Code ist meiner Meinung nach nur als Platzhalter da.

Andras H. schrieb:

Habe eben mit MPLAB simuliert. Das Ding macht ja nix. Hälfte der Code ist meiner Meinung nach nur als Platzhalter da.

Lustiger Zufall. Genau das Gleiche trifft auf die meisten Leute hier im Forum zu.

Bist Du Dir sicher dass das Auslesen ohne Fehler funktioniert hat? Womit hast Du ausgelesen, der PICkit ist nach meinen bisherigen Erfahrungen zuverlässig.

Ich frage weil der Code meiner Meinung nach wenig Sinn ergibt. Es gibt bei dem Code auch nichts zu verschleiern was eine eventuell absichtlich unsinnige Struktur erkären würde. Die erzeugte Modulation kann man ja einfach mit einem Logic-Analyzer abgreifen und damit weiss man bereits alles, wie genau das im Code gemacht wird spielt keine Rolle.

H. H. schrieb:

Andras H. schrieb:

Am ende aber ist ein MOVLW 0x2A ; b'00101010' d'042' "*" das ist doch aber die Osszilator Kalibration.

Nö, das ist ganz normaler Code.

auch bei PIC12F508 gilt https://www.sprut.de/electronic/pic/projekte/osccal/osccal.htm

H. H. schrieb:

Und hier eben ganz normaler Code, kein Kalibrierwert.

Also ja ist halt normaler Code. Aber der PIC kommt so aus dem Werk vorprogrammiert, dass da ein movlw Befehl liegt der einen Wert in W lädt. Der Wärt wird ja im Werk ermittelt. Beim flashen, muss der Flasher den Wert auslesen, und wieder reinschreiben. Sonst ist der wer, und man muss noch einmal den irgendwie (wie?) ermitteln. Ist nicht so schlimm.

Der Code erzeugt aber das Signal an der Antenne und am GP gemessen. Ausgelesen habe ich mit einem hochwertigen RT809H Flash Programmer, mehrmals, kam immer das gleiche Ergebnis. Habe noch einen anderen Trigger, kleinerer Buart, hat das gleiche PIC und die gleiche Software.

Einen partiellen Kopierschutz für den Code gibt es ja nicht. Es wäre jetzt noch eine Option für mich einen neuen PIC mit dem Code zu programmieren und zu schauen ob dieser die gleiche Funktion erfüllt.

Klaus K. schrieb:

Olli Z. schrieb:

Laut Datenblatt hat dieser PIC einen Flash-Speicher von 512 words, also 1024 Bytes (0x400)

Nö, weil bei dem Controller ist ein instruction-word zwölf und nicht sechszehn bit breit.

Wenn Du einen nativen 12 Bit Speicher kennst... also wird auf 16 gepadded und meine Aussage stimmt wieder.

H. H. schrieb:

Nirgendwo im Code wird an den GPIO gewackelt.

Ich bin komplett be Euch und versteh es selbst nicht...

Leider fehlt das Configuration Word im Hexfile. Aber der Prozessor ist vermutlich einfach Code Protected, deshalb stehen nach dem Auslesen von 0x040 bis 0x01fe nur Nullen (Kapitel 7.10 im Datenblatt).

7.10 Program Verification/Code Protection

If the code protection bit has not been programmed, the on-chip program memory can be read out for verification purposes.

The first 64 locations and the last location (OSCCAL) can be read, regardless of the code protection bit setting.

The last memory location can be read regardless of the code protection bit setting on the PIC12F508/509/16F505 devices.

Oliver F. schrieb:

Leider fehlt das Configuration Word im Hexfile. Aber der Prozessor ist vermutlich einfach Code Protected, deshalb stehen nach dem Auslesen von 0x040 bis 0x01fe nur Nullen (Kapitel 7.10 im Datenblatt).

Das erklärt warum der Code keinen Sinn macht. Allerdings frage ich mich warum das verwendete Tool zum Auslesen des PIC die Code Protection nicht anzeigt, Zugriff auf das Configuration Word hat es ja.

Ist das Code Protection Word eventuell die letzten Bytes E5 0F im Binary von hier (tpms-trigger-tool_small.zip) ?

Beitrag "Re: Funktion Reifendruckanlerngerät EL-50448; OEC-T5; Welches Bauelement ist das?"

Laut diesem Datenblatt http://ww1.microchip.com/downloads/en/DeviceDoc/41227B.pdf ist das im "Configuration Word" enthalten. Dieses liegt beim 12F508 an der statischen Adresse 0x3FF und ist nachdem einschalten vorhanden bis der erste PC increment stattfindet. Zuständig ist Bit 3. Im Dump ist das der Teil wo dieser als MOVLW 0x2A interpretierte Befehl.

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 000003F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2A 0C ..............*.

Ich meine 0x2A wäre das OSCCAL Byte und 0x0C müsste das Configuration word sein. 0x0C wäre 0b0000 1100 und somit wäre das CP-Bit gesetzt, was bedeuten würde der Chip hätte keine Copy protection.

Aber die Ausführungen meines Namensvetters sind absolut schlüssig und die einzige Erklärung für den merkwürdig funktionslosen Code mit den vielen NOPs.

Jetzt zu fragen ob man diesen alten PIC evtl. knacken kann spare ich mir, das wäre die Mühe nicht wert. Ich werde wohl meinen eigenen Code schreiben müssen und ihn dann in dem Tool zum laufen bringen.

Der Befehl an Adresse 0x01FF (= Adresse 0x03FE im Hexfile) - MOVLW 0x2A - ist der Kalibrierwert für den Oszillator.

Das Config Word steht im Flash an Adresse 0x03FF.

Ist das Code Protection Word eventuell die letzten Bytes E5 0F im Binary von hier (tpms-trigger-tool_small.zip) ?

Beitrag "Re: Funktion Reifendruckanlerngerät EL-50448; OEC-T5; Welches Bauelement ist das?"

Das könnte durchaus sein. Wenn man es entsprechend interpretiert, kommt etwas sinnvolles heraus:

0x0FE5 = 1111 1110 0101

1111 111 unbenutzte Bits

0 MCLRE GP3 ist digitaler Eingang, Reset intern erzeugt

0 CP Code Protection on

1 WDTE Watchdog Timer enabled

01 FOSC XT Oscillator

So, nun mal mit einem PICKit2 (Clone) - Guess what: "Protected"

Davon ab das es natürlich nicht lohnen wird, gäbe es nun zwei Möglichkeiten doch an den Code zu kommen:

Hack-Methode 1) Decap vom Chip, Fuses localisieren, den Flash-Bereich mit Tonband abdecken und UV-Licht schräg auf die Fuses geben um diese zurück zu setzen. Aufwand ist sehr hoch, Decap benötigt spezielle Chemikalien (einige davon dienen auch zum Bau von Sprengstoffen, also nicht einfach erhältlich) und man kann den Chip dabei schnell komplett ruinieren.

Hack-Methode 2) Ein interessanter Ansatz bei dem nicht der ganze Flash gelöscht wird, sondern nur ein Teil, eine Bank. Dabei werden die Fuses mit zurückgesetzt und man kann den Chip auslesen. Eine erweiterte Option davon ist, in die erste Bank, in der sich normalerweise ein Bootloader befindet, ein kleines Stück Dump-Software zu programmieren, welches dann beim Reset den Inhalt des Flash auf einen IO-Port (bei größeren Chips ein UART) pumpt. Hat man dann noch einen zweiten Chip programmiert man alles bis auf den Bootloader (1st Bank) mit NOP und schreibt den Dump-Code ans Ende des Flash. Der Bootloader wird irgendwann an eine Speicherstelle springen wo er normalerweise den Main-Code ausführt, dort führen ihn die NOPs dann unweigerlich zum eigenen Trojaner-Code. Durchführen kann man diesen partiellen Erase/Program nicht aus einem MPLAB o.ä. sondern nur mit Big-Banging der Signale.

Methode 2 wäre nicht schlecht, aber der kleine 12F508 hat keine Banks und keinen Bootloader, wird also vermutlich nicht funktionieren. Toll wäre ja wenn man genau die ersten Bytes die man ohnehin frei auslesen kann überschreiben könnte um an den Rest zu kommen. Laut Datenblatt hat der PIC12F508 nur zwei Bulk-Erase Modes, die jeweils angestoßen, den gesamten Chip leeren.

Ich habe mir das Timing mal etwas näher angesehen und folgendes daraus ermittelt: Modulationsverfahren: ASK 1 Impuls = 1 µS + 7 µS Pause (=125 kHz) Symbole K = 16 Pulse (120 µS) + 134 µS Pause K' = 16 Pulse (120 µS) + 262 µS Pause M = 32 Pulse (248 µS) + 262 µS Pause M' = 32 Pulse (248 µS) + 138 µS Pause L = 48 Pulse (376 µS) + 376 µS Pause

Sendefolge = Sync + Data Sync = 17 x K Data = L K M M K K' M K M M' K' M K M M M M M K K M M M M

Das entspricht dem was Dieter schon vor langer Zeit in dem anderen Thread mitteilte:

Schau Dir mal im Datenblatt des SP40T (Infineon-SP400-15-11-DataSheet-v01_01-EN.pdf) auf Seite 54 "Figure 5-17 LF telegram modulated on a 125 kHz carrier" an. Das passt ganz gut:

• 17 Bits Preamble
• Synchronization pattern (laut Datenblatt fest vorgegeben)
• 32 Bits Daten (Manchester codiert)

Ein "K" entspricht also einem Bit.

Lieber Moderator, lösche bitte den vorherigen Beitrag von mir, ich habe ihn im falschen Thread platziert. Der richtige ist hier Beitrag "Re: Funktion Reifendruckanlerngerät EL-50448; OEC-T5; Welches Bauelement ist das?" Danke!