PY32F002AW15, Dump trotz RDP Level 1.

[Kilo S. (kilo_s)]

Moin.

Nach einer längeren Suche hab ich leider nur QFN16 Adapter gefunden.
Ausnahmsweise auch eine "Empfehlung" meinerseits, wer diese Größe als 
Adapter sucht: https://ebay.us/m/DfTbyZ
Die lassen sich wirklich gut Löten, stabile Leiterbahnen auch bei 
längerer Hitzeeinwirkung.(kein Ablösen wenn man mal korrigieren muss)
QFN20 wäre natürlich schöner gewesen, wer Bezugsquellen für 3x3mm QFN20 
mit 0,5mm Pitch kennt, immer her mit den links. ;-) (Boot0 Herausgeführt 
bei QFN20, wäre schön nützlich.)

Per SWD ansprechbar ist er, lässt sich aber unter keinen Umständen 
Anhalten. (?)
Option Bytes per SWD lesen geht: NRST=GPIO (Richtig nervig!), IWDG_SW=1, 
RDP=0x00 (Level 1).

Bezüglich RDP, Level 1, Voltage Glitch hat bisher nicht funktioniert, 
scheiß Timing oder was auch immer, will nicht so Recht.

Ideen?

Ein Dump der Randm Tornado 12.000/15.000 (Oval, Rund) mit den charlyplex 
LED anzeigen wäre zur Vervollständigung der Informationssammlung 
eigentlich ganz cool.

Ich schau gleich ob die sich mit J-Link wenigstens löschen lassen, mit 
dem ISP Tool teste ich später noch.

[Kilo S. (kilo_s)]

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.

[Dieter S. (ds1)]

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.

[Kilo S. (kilo_s)]

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.

[Dieter S. (ds1)]

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

[Kilo S. (kilo_s)]

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

Sprung in den Bootloader:

JLinkExe
device PY32F002Ax5
si SWD
speed 4000
connect
h
wreg MSP 0x20000200
setPC 0x1FFF00D5
g
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

[Dieter S. (ds1)]

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

[Kilo S. (kilo_s)]

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. ;-)

[Kilo S. (kilo_s)]

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.

[Kilo S. (kilo_s)]

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.

[J. T. (chaoskind)]

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

[Kilo S. (kilo_s)]

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...