[Tiptoi] Mehr zu OidMain

[Ulrich Sibiller]

On Tue, Nov 24, 2020 at 12:31 AM Joachim Breitner via tiptoi
<tiptoi at lists.nomeata.de> wrote:
>
> Hi,
>
> Am Sonntag, den 22.11.2020, 19:30 +0100 schrieb Joachim Breitner via
> tiptoi:
> > Am Sonntag, den 22.11.2020, 13:09 +0100 schrieb Joachim Breitner via tiptoi:
> > > Mein aktuelles Ziel ist es, das Binary durch ein selbst-assembliertes
> > > zu ersetzen; erstmal mit gleicher Ausgabe, und dann immer weiter
> > > vereinfachen, bis ich das kleinste habe was trotzdem noch tut.
> >
> > leider nicht sehr erfolgreich bisher. Zwar stört es den Stift nicht,
> > wenn man z.B. APP_DEMO in APPPDEMO im entsprechenden Binary ändert (das
> > heißt, es gibt zumindest schon mal keine Integritäts-Prüfung). Aber
> > wenn ich das Program einfach direkt beende, also mit
> >
> >      bx      lr
> >
> > am Anfang, oder auch
> >
> >    push    {r4, r5, r6, r7, r8, r9, sl, lr}
> >    pop     {r4, r5, r6, r7, r8, r9, sl, pc}
> >
> > dann beobachte ich das gleiche als wenn ich das Program einfach lösche:
> > Der Stift gibt nach dem Antippen des Anschaltsymbols gar keinen Mux
> > mehr von sich.
> >
> > Das heißt entweder, die Firmware erwartet von dem Programm, dass es
> > einen sinnvollen Rückgabewert hat (aber das Assembly sieht jetzt nicht
> > sehr danach aus), oder dass das Programm sonst irgendwas besonderes
> > macht, damit der Stift danach weiter funktioniert.
>
> Ich hab es jetzt tatsächlich geschafft, das Binary in eine lesbare
> Assembly-Datei zu übertragen, die ich mit arm-none-eabi-as wieder in
> ein bit-gleiches Binary übertragen konnte. Das macht es deutlich
> einfacher damit rumzuspielen.

Kannst du den Source in github ablegen? Dann kann man sich die Arbeit
besser aufteilen und einzelne Funktionen analysieren. Nicht, dass ich
Zeit hätte, aber Interesse schon ;-)

> Das Argument (r0) zum Programm wird ziemlich gleich als r4
> weggespeichert, und dann nicht mehr beschrieben, aber oft benutzt.
> Scheint wichtig zu sein. Alles was damit gemacht wird ist von Offsets
> davon aus zu lesen, und zwar kommen viele Offsets von 12 bis 396 vor.
> Davon sind einige eindeutig Funktionspointer, die anderen irgendwelche
> Arrays… das sieht alles sehr interessant aus, auch wenn ich mir noch
> keinen Reim draus mache:
>
> 12 // function
> 24 // function
> 36 // function
> 44 // function
> 48 // function
> 72 // u16, wird mit 48 verglichen
> 76 // ptr to u32
> 80 // ptr to u32, wird mit obigem verglichen
> 84 // ptr, ziel 2. argument von #44
> 88 // ptr, ziel 3. argument von #44
> 96 // ptr, byte, ziel wird nach *sl geschrieben, wenn 0 beendet

Was heisst das, "wenn 0 beendet"?

> 100 // ptr, byte, wird geschrieben (von r8, r9)
> 104 // ptr, byte, wird geschrieben (von r9)
> 124 // function, argument: r5->4
> 128 // function, argument: array offset from 288, result compared against 0
> 136 // function
> 140 // function, arguments(*h(#288+2*r6), -256, *b(#236+r6), *h(#240+2*r6))

Bitte erläutere mal, damit wir uns über die Nomenklatur und Syntax
einig sind. Ich hab da Vermutungen, aber stimmen die?
- #288 heisst "Inhalt des Speicheroffsets 288?
- b heisst "Byte"?
- h heisst "halfword"? Wieviel Bit hat das dann?
- * heisst Inhalt der Speicherstelle?

Desweiteren finde ich den Wert -256 irgendwie verdächtig. ubyte get
von -128 bis + 127, also ein bit mehr oder wie?

#288 ist wohl ein sehr wichtiges Array, vermutlich entweder die
Register oder sogar die Playlist. Oder alles zusammen. Wir haben #288
+ r6, #288 + 2xr6 und #288+3xr6, also stecken da wohl mindestens 3
Infos pro Offset drin.
Man müsste irgendwie an den Inhalt rankommen, da würde extrem
weiterhelfen. Kannst du mal schnell Code hinzufügen, der den Inhalt
laut vorliest? Oder auf den Stick dumpt? ;-)

...

> 192 // ptr, target used as addition to to *(#288+3*r6), to be writtento *#200
...

> Das müsste ja eigentlich eine Datenstruktur sein, mit der man
> vermutlich den Stift schön steuern kann.
>
> Naja, genug für heute. Mal schauen wann der Groschen fällt.

Kommt Zeit, kommt Groschen!

Uli