PY32F002AW15, Dump trotz RDP Level 1.

Flash Löschen war jetzt nicht so das große Ding. Grundsätzlich wäre der nun (immer noch mit NRST als GPIO, grrr!) benutzbar.

Geht nun auch endlich zuverlässig in halt.

Jetzt noch eine Idee wie ich die Option Bytes ohne ISP Tool weg bekommen kann. Hab kein Boot0 und das Tool erkennt meinen J-Link OB Natürlich nicht.

Dann wären das zumindest vernünftig wiederverwendbare IC.

Man kann mit JLink die zum Löschen benötigten Kommandos manuell ausführen, in etwa so wie hier

https://github.com/IOsetting/py32f0-template/issues/36

im letzten Post beschrieben.

Dieter S. schrieb:

Man kann mit JLink die zum Löschen benötigten Kommandos manuell ausführen

Über J-Link wollte er nicht direkt. RDP1 hat erfolgreich sämtlichen Zugriff auf den Flash verhindert.

Moment, Lösung kommt gleich vom Laptop aus. (J-Link, Sprung in Bootloader -> UART und puyaisp.py -u/-e/-o nacheinander.)

Vollständig auf "Werkszustand", inklusive NRST.

Flashzugriff ist zum Löschen nicht nötig, es wird ja nur auf die IO Register zugegriffen um das Löschen zu starten.

J-Link (Geht nur wenn ihr das device aus dem template vorher hinzufuegt!)

Sprung in den Bootloader:

1

JLinkExe

2

device PY32F002Ax5

3

si SWD

4

speed 4000

5

connect

6

h

7

wreg MSP 0x20000200

8

setPC 0x1FFF00D5

9

g

10

exit

danach mit puyaisp, nach jedem schritt (-u/-o/-e) muss der sprung in den bootloader erneut erfolgen.

puyaisp.py https://github.com/wagiminator/MCU-Flash-Tools (direkt: https://raw.githubusercontent.com/wagiminator/MCU-Flash-Tools/main/puyaisp.py ) Template https://github.com/IOsetting/py32f0-template

Und warum dann nicht die Kommandos wie in dem oben verlinken Beitrag (das was "main()" im letzten Post macht) ausführen?

Dieter S. schrieb:

Flashzugriff ist zum Löschen nicht nötig, es wird ja nur auf die IO Register zugegriffen um das Löschen zu starten.

Der erase in JLink wird von mir noch mal getestet. Ich hab noch genügend im Originalzustand.

Es scheint als ob der nicht funktioniert hat. (Timeout usw..) Sicher bin ich da allerdings nicht.

Und weil wir alle Bilder mögen, das fliegende Setup. ;-)

Dieter S. schrieb:

Und warum dann nicht die Kommandos wie in dem oben verlinken Beitrag (das was "main()" im letzten Post macht) ausführen?

Wie gesagt, ich hatte teils Probleme den IC anzusprechen.

Ungelogen! Reset (fast schon Power Cycle) hab ich mit dem feuchten Finger gemacht, zwischen VCC und GND Spannung mit nassem Finger einbrechen lassen hat gereicht, erst dann ging er in halt und ließ mich den Sprung in den Bootloader machen.

Der war zickig, da hat Fumot sich was bei gedacht glaube ich, wobei ich nicht verstehe weshalb die 0815 Vapes dieser marke geschützt waren und die teureren 25k mit LCD nicht? Verhinderung von Kopien?

Ich hab tatsächlich dran gedacht gehabt aus dem RAM heraus die Option Bytes zu klären. Aber so gut das sowas auf Anhieb klappt bin ich noch nicht. Daher der Umweg über den Sprung in den Bootloader und das ISP Tool.

Ich lach mich schief!

Warnt mich gerade die KI (Research über Glitches bei STM/PY32) das dies die Vermischung zwischen Hobby und "Grey Hat" wäre.

Jedenfalls, das komplizierteste ist tatsächlich den MCU für den ersten erase (der klappt tatsächlich wohl nicht, denn nach dem Reset spult der ganz gemütlich sein Programm wieder ab...?) bzw. Sprung in den Bootloader zu erreichen und anzuhalten.

JLink sagt zwar das es den MCU gelöscht hat, ich glaub aber irgendwas ist da faul. (PC bei start im Flash auf 0x08000xxx usw. Je nach Timing mal eine andere Adresse im Flash.)

Erst der Glitch zum halt, Sprung in den Bootloader und unlock mit dem ISP Tool löst den Mass erase wirklich aus. Danach muss ich mit dem ISP Tool -R/-o (in der Reihenfolge) NRST zurück konfigurieren.

Irgendwo hab ich einen Fehler drin, vermute ich.

Den richtigen "Glitch" zum halt mit den Fingern reproduzieren ist echt mühselig, durchschnittliche 15 Versuche und wehe man wackelt mit der Hand nochmal an einen der GPIO, sofortiger Reset.

Kilo S. schrieb:

Warnt mich gerade die KI (Research über Glitches bei STM/PY32) das dies die Vermischung zwischen Hobby und "Grey Hat" wäre.

Manch KI soll angeblich schon bei den Behörden gepetzt haben :D

J. T. schrieb:

Manch KI soll angeblich schon bei den Behörden gepetzt haben :D

Und?

Selbst wenn, gibt's keinen Grund mich für meine private autodidaktische Weiterbildung zu verknacken.

Wäre das jetzt was brisanteres, ein Kartenterminal zb. das wäre wieder ne andere Nummer. Das Dump der Vape enthält aber weder Cryptologisch noch "Geistig" irgendwelche Schützenswerten Ergüsse. Wirtschaftsschäden macht's auch keine, Fakes der Dinger gibt's bereits genügend.

Nö, da hab ich keine Angst!

Ich sehe das so: Ich kann nur sicher machen was ich auch knacken kann. Ohne den Angriff zu kennen kann ich keine Gegenmaßnahmen umsetzen.

Und wie viele Seiten ich zu meinen aktiven PHP zeiten mit verschiedensten Methoden und versteckten shells (weevely war immer mein Liebling ;-) ) erkundet habe, ohne Schäden anzurichten. Gerade kostenpflichtige Webanwendungen wo du keinen direkten Einblick in deren Code bekommst, hab lieber Sourcecode gelesen als was zu verunstalten. (Alles verjährt oder zu der Zeit noch gar nicht als Straftat erfasst! Scheiße ist das lange her...)

In diesem speziellen Fall, das bekomm ich aber noch nicht umgesetzt, müsste ich den Code so komplex machen das sich die Funktion aus dem dump für andere nur schwer oder gar nicht logisch nachvollziehen lässt.

Das weiß ich allerdings auch nur weil ich mich mit dem Angriff beschäftige.

Wie wollen die eigentlich Fachkräfte Ausbilden wenn keiner mehr tief in die Materie einsteigen darf? Bei den Studenten damals (F0 RDP) gab's ja auch keinen Ärger, mal unabhängig davon das die nur ihr eigenes "blink" dumpen konnten, vorbereiten ist eigentlich auch schon ne Straftat...