Forum: PC-Programmierung Firmware entschlüsseln, Updateprogramm als Hilfe?


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 Kilo S. (kilo_s)


Angehängte Dateien:

Lesenswert?

Gibt es für einen von euch die Möglichkeit, aus diesem updater eventuell 
"nützliche" Informationen zu gewinnen "wie" man eventuell das Firmware 
Image entschlüsseln könnte?

Das Image der Ruyage dient als Beispiel, es ist ein ähnliches Gerät das 
die selben programmierbefehle nutzt. Man wählt es aus um das RT-890 mit 
chirp zu programmieren.

Hintergrund ist der das eine Gruppe versucht die Firmware (identisch mit 
dem UV5118) für das RT-890 in gleicher Weise zu modifizieren wie für das 
UV-5K.

Also RX/RTX Firmware mit allen Frequenzen die der Belken da drin 
schafft.

Ich versuche da nur zu helfen, vielleicht ist es ja für jemanden mit 
mehr Erfahrung "ganz einfach".

Vielen Dank schon mal für eventuelle Hilfe!

O.T:
Für die interessierten noch etwas über das RT-890: 
https://m.de.aliexpress.com/item/1005004886722419.html

Erster Eindruck, deutlich Dicker und schwerer als erwartet, bei gleicher 
Höhe wie ein UV-5R/Tecom Duo Dualbander.

RX ist ok, NF aus dem Lautsprecher ist für ein Handfunkgerät fast schon 
sehr gut. Nicht wie sonst zu dumfp oder quietschig vom Klang.

Positiv überrascht hat mich die TX Modulation, satter klang mit Tiefen 
vom Mikrofon. Kein Vergleich, selbst Team hat das Duo das für den 
dreifachen Preis (im Vergleich zum Angebotspreis!) angeboten wird, nicht 
so gut hinbekommen.

Die NOAA Funktion habe ich noch nicht verwendet.

Die mitgelieferte Antenne dürften die meisten, so wie ich auch, gleich 
entsorgt haben. Die ist leider nicht ein mal die Rohstoffe wert aus 
denen sie gemacht wurde.
Nicht mal UKW Radio war damit rauschfrei zu Empfangen.

Und jetzt der Grund den die meisten bei mir vermuten, wofür ich es 
überhaupt habe. ;-)
SATCOM RX.
Mit ner einfachen Gummiwurst/Teleskop-Antenne war nicht wirklich was zu 
hören, mal Fetzenweise. Aber was erwartet man mitten in der Stadt bei 
digitalem Kabel auf der selben Frequenz. ;-) kaum hatte ich aber die 
Turnstile am Gerät war ich sehr positiv überrascht.

Zuletzt noch Akkulaufzeit, ich hab es bisher nicht geschafft das Gerät 
leer zu hören. Sendebetrieb vermeide ich, ich würde wetten durch die 
breiten Filter kommt weit mehr durch als erlaubt.


Fazit: Wer es für 30-40€ als Angebot für Neukunden kaufen kann, macht 
nicht viel falsch.

Empfehlen würde ich es allerdings nur die fortgeschrittene Enthusiasten 
oder Funkamateure!

Nochmal ganz deutlich: Das ist kein "Prepper, ab in die Schublade" Gerät 
und auch nix für den Freenet oder PMR Freund im Alltag! Nicht ohne 
Zusätzliche Filterung am Ausgang an der Stationsantenne und selbst zu 
Fuß sollte man in der Nähe von "Grauen Kästen" nicht Senden! Ich war im 
Hausflur, da drückte ich den BK-Verstarker klein und Frauchen sachte: 
"Du hier oben flackert das Bild im Fernseher".

von NGC 5. (ngc5907)


Angehängte Dateien:

Lesenswert?

Hallo Kilo,

der angehängte Updater ist ein .net-Programm also quasi Sourcecode frei 
Haus :)

Ich habe den mal decompiliert und kurz drübergeschaut, was er macht.
Die Firmware ist in Form eines langen Strings im Binary enthalten 
(string allcode). Der String wird vom Programm decodiert und dann 
blockweise über einen seriellen Port an das Gerät geschickt.

Das decodierte File ist im Anhang.
Mit dem gezeigten Dump von Dir hat das allerdings nichts zu tun, aber 
evtl. hilft Dir das ja schon weiter.


LG

von Kilo S. (kilo_s)


Angehängte Dateien:

Lesenswert?

Guten Morgen.
Danke für deine Hilfe!


NGC 5. schrieb:
> Die Firmware ist in Form eines langen Strings im Binary enthalten
> (string allcode). Der String wird vom Programm decodiert

Öhm, mit welchem Programm genau betrachtest du das?
Ich hatte die exe mit IDAPro auseinander genommen und versucht etwas 
"lesbares" zu finden. Irgendwann landete ich dann bei 
chinechichen.zeichen die ich mit Google Lens versucht habe zu 
übersetzen. Mit 0 Erfolg!

Aber genau darum geht's, um das Codesegment das die Firmware decodiert 
bzw. vielleicht kennst du ja einen Weg wie wir die Firmware aus dem 
updater heraus Extrahieren können?

von Rüdiger B. (rbruns)


Lesenswert?

Das ERSTE was wichtig ist: WELCHE CPU?

von Kilo S. (kilo_s)


Lesenswert?

Wow! Ich bin echt erstaunt wie viel (von der Firmware) da bereits lesbar 
ist.

Man erkennt im Hex sogar die interne Menüstruktur des Funkgerät!

Laut den leuten in der Gruppe suchen wir nach dem String "404B4C00" 
innerhalb der Firmware. Angeblich könnten die Jungs dann eine Firmware 
schreiben die RTX von 18-1300MHz schafft, natürlich trotzdem mit der 
Lücke bei 600-850MHz.

Nochmal vielen lieben Dank für deine Hilfe!

von Kilo S. (kilo_s)



Lesenswert?

Rüdiger B. schrieb:
> Das ERSTE was wichtig ist: WELCHE CPU?

Moment! Info kommt gleich.

AT32F421C8T7

Bild anbei.

: Bearbeitet durch User
von Oliver (imonbln)


Lesenswert?

Irgendwas stimmt doch da nicht. Deine Gruppe kann eine Firmware 
modifizieren, ist aber nicht in der Lage ein .Net Programm zu 
dekompilieren?

Abgesehen davon gibt es in Deutschland rechtliche Aspekte, wer wann auf 
welchen Band funken darf. Ich kenne die Details davon zwar nicht und 
will einfach mal davon ausgehen, dass du alle nötigen Rechte und 
Lizenzen hast für diese Erweiterung.

Aber das Gefühl bleibt, dass du hier versuchst nach Wissen zu fragen, 
das im Augenblick zu groß für dich und deine „Gruppe“ ist.

Und du im besten fall ein shady Binary bekommst, von dem du keine Ahnung 
hast, was es wirklich macht, aber hoffst, dass es nur deine Wünsche 
erfüllt.

von Kilo S. (kilo_s)


Lesenswert?

Oliver schrieb:
> Irgendwas stimmt doch da nicht. Deine Gruppe kann eine Firmware
> modifizieren, ist aber nicht in der Lage ein .Net Programm zu
> dekompilieren?

Da fragst du den falschen, ich sehe da aber ein gewisses Potential das 
der zusammengewürfelte Haufen Leute in der Gruppe da durchaus Erfolge 
hinbekommen könnte.

Immerhin haben sie den Kontakt zu den Entwicklern der modifizierten 5K 
Firmware, die laut Aussage in der Gruppe behilflich sind zu modifizieren 
wenn wir das entschlüsselte Image bereitstellen.

Oliver schrieb:
> Abgesehen davon gibt es in Deutschland rechtliche Aspekte, wer wann auf
> welchen Band funken darf.

Wer redet von senden? Hast du nicht in meinem ersten Beitrag ziemlich am 
Ende, gelesen was ich schrieb?
Das Ding ist ab Werk bereits ein großzügiger "Spektrumkotzer" wie ich 
das bezeichne. Ohne Nachbesserung oder externe Filterung wird das Teil 
hier nie wieder auf Sendung Gehen!

Abgesehen davon daß die unangepassten Filter beim Senden außerhalb der 
originalen Frequenzbereiche, eventuell, den Final kosten können!

Mach dir übrigens mal keinen Kopf darüber ob das erlaubt ist, für die 
Chinesen denen die Software gehört ist kopieren doch ein Kompliment. Und 
alle die hier genannten Frequenzbereiche kann heute jeder mit einem 
20-30€ SDR abhören.

Oliver schrieb:
> Ich kenne die Details davon zwar nicht und will einfach mal davon
> ausgehen, dass du alle nötigen Rechte und Lizenzen hast für diese
> Erweiterung.

Wie gesagt, alles in chinesischer Hand. Und bis heute wüsste ich nicht 
das jemand für sowas verklagt wurde, von chinesischen Herstellern!

Oliver schrieb:
> Und du im besten fall ein shady Binary bekommst, von dem du keine Ahnung
> hast, was es wirklich macht, aber hoffst, dass es nur deine Wünsche
> erfüllt.

Hätten wir die Firmware Vorliegen, würde da jemand rangehen der mehr 
Ahnung hat. Und einen Tester gibt's  in der Gruppe auch, der hat zwei 
dieser Geräte und würde eines als Tester "Opfern".

Deine bedenken in allen Ehren, die sind aber in dem Fall unbegründet.

: Bearbeitet durch User
von Kilo S. (kilo_s)


Lesenswert?

Oliver schrieb:
> Aber das Gefühl bleibt, dass du hier versuchst nach Wissen zu fragen,
> das im Augenblick zu groß für dich und deine „Gruppe“ ist.

Für mich definitiv, aktuell sind es 122 Leute. Ich werde nur sicher 
nicht mit jedem einzelnen (vor allem nicht, weil es eine überwiegend 
Russische Gruppe ist) ein Privatgespräch anfangen um herauszufinden wer 
was kann.

Die letzten Nachrichten lassen mich allerdings hoffen das der "Tester" 
mehr davon versteht als ich.

von Lotta  . (mercedes)


Angehängte Dateien:

Lesenswert?

Kilo_s

wo hast Du denn eigendlich das 4 MB große Binary her,
der Prozzy AT32F421C8T7 hat ja maximal 64 Kb Flasch,
siehe mein Datasheet oben?

an alle:
Kanns sein, das beim Update jedesmal der ganze Inhalt
des Flash ausgewechselt und nicht gepatcht wird?

mfg

von Kilo S. (kilo_s)



Lesenswert?

Lotta  . schrieb:
> wo hast Du denn eigendlich das 4 MB große Binary her,
> der Prozzy AT32F421C8T7 hat ja maximal 64 Kb Flasch,
> siehe mein Datasheet oben?

An dem hangt noch ein Speicher.
Ich kann nur leider nicht entziffern welcher. (Bild)

Aber das Gerät ist sehr ähnlich zum UV-K5.

von Kilo S. (kilo_s)


Lesenswert?

Lotta  . schrieb:
> an alle:
> Kanns sein, das beim Update jedesmal der ganze Inhalt
> des Flash ausgewechselt und nicht gepatcht wird?

Genau das hoffen wir sogar!
Sonst wäre das Image ja unvollständig und für unseren Zweck unbrauchbar.

von Kilo S. (kilo_s)


Lesenswert?

Ach fuck... Falsches Bild!

Jedenfalls hängt am CPU aller dieser Geräte immer ein externer Speicher 
für die Firmware.

Beim UV-5K gibt's sogar bereits die Möglichkeit zum auslesen über die 
serielle Schnittstelle.

von Lotta  . (mercedes)


Lesenswert?

Kilo_s meinte:

> An dem hangt noch ein Speicher.
> Ich kann nur leider nicht entziffern welcher. (Bild)

> Aber das Gerät ist sehr ähnlich zum UV-K5.

Das sieht wie ein I2c-Flash aus.
Ich hatte mich nämich gewundert, regelmäßige Strukturen...
Und ne Menge Nullbytes, also ein Daten-ROM.

mfg

von Kilo S. (kilo_s)


Lesenswert?

Lotta  . schrieb:
> Das sieht wie ein I2c-Flash aus.

Ja, scheint aber der DC/DC zu sein.

Die Pins auf 12 Uhr gehen an die Spule. Das Gerät muss auch einen DC/DC 
Boost haben, es lässt sich über einen USB-C Anschluss aufladen. Besitzt 
einen 8,4V 2S 1000mAh Akku.

Lotta  . schrieb:
> also ein Daten-ROM.

Jepp, kannst du den Inhalt eventuell in etwas lesbares übersetzen?

Falls weitere Informationen nötig sind, bitte einfach anfordern!

Ich werde mein bestes geben die Informationen zu besorgen.

P.S
Ich suche auch gleich nach der Bezeichnung des flash! Ich Wette mit 
Datenblatt ist das Übersetzen deutlich einfacher.

von Kilo S. (kilo_s)


Lesenswert?


von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Kilo S. schrieb:
> Jedenfalls hängt am CPU aller dieser Geräte immer ein externer Speicher
> für die Firmware.

Das bezweifle ich stark. Der Controller kann von einem externen Flash 
nicht ausführen.

Die Dinger sind aber so billig (deutlich unter €0,20), dass es durchaus 
sein kann, dass die einen riesigen Flash statt eines kleinen i2c eeproms 
nehmen.

Wobei natürlich dieser Flash auch gut als Puffer nutzbar wäre.
Kann gut sein, dass die beim update, die eigentlichen Daten zuerst in 
den Flash schieben, dort die Integrität prüfen und dann erst übernehmen.
Wobei auch hier dann die Frage ist, ob die Daten dort dann nicht noch 
verschlüsselt sind.

Meine Update-Strategie ist üblicherweise einen einfachen "Container" um 
den verschlüsselten Update-BLOB zu legen (eigentlich nur ein paar Bytes 
mit Größe, CRC und Magic-Bytes). Nur der Bootloader weiß wie er den Blob 
entschlüsseln kann.

Damit ist ein Angriff auf den Updater oder die eigentliche Firmware 
sinnlos, weil die garnicht wissen, wie man zu den Daten kommt.

73

von Yalu X. (yalu) (Moderator)


Angehängte Dateien:

Lesenswert?

Hans W. schrieb:
> Kilo S. schrieb:
>> Jedenfalls hängt am CPU aller dieser Geräte immer ein externer Speicher
>> für die Firmware.
>
> Das bezweifle ich stark. Der Controller kann von einem externen Flash
> nicht ausführen.

Irgendwo müssen die 4 MiB von

Kilo S. schrieb:
> Ruyage_UV-58_Dump.Bin

ja hin.

Der Mikrocontroller selber hat

Lotta  . schrieb:
> 64 Kb Flasch

Dahinein kommen die 59 KiB aus dieser Datei:

NGC 5. schrieb:
> allcode_bytes.hex

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Yalu X. schrieb:
> Hans W. schrieb:
>> Kilo S. schrieb:
>>> Jedenfalls hängt am CPU aller dieser Geräte immer ein externer Speicher
>>> für die Firmware.
>>
>> Das bezweifle ich stark. Der Controller kann von einem externen Flash
>> nicht ausführen.
>
> Irgendwo müssen die 4 MiB von
>
> Kilo S. schrieb:
>> Ruyage_UV-58_Dump.Bin
>
> ja hin.
>
> Der Mikrocontroller selber hat
>
> Lotta  . schrieb:
>> 64 Kb Flasch
>
> Dahinein kommen die 59 KiB aus dieser Datei:
>
> NGC 5. schrieb:
>> allcode_bytes.hex

Nur dass diese 4MB File ja anscheinend nur zur Verwirrung angehängt 
wurde...

die 59k "HEX" (ist ja eigentlich ein binary) glaube ich dagegen eher.... 
also 4k Bootloader+59k APP

Der Anfang vom Binary sieht mir verdächtig nach Cortex-M aus (also stack 
im ram und dann vectoren in den flash)... strings sind auch enthalten... 
ich gehe also davon aus, dass das die gesuchte firmware ist.

73

von Dieter S. (ds1)


Lesenswert?

Die Firmware aus "allcode_bytes.hex" ist nicht sehr kompliziert. Was 
fehlt sind die ersten 5 kByte des Flash aus dem AT32F421, das steht der 
Bootloader, für das Verständnis der Firmware braucht man ihn aber nicht. 
Der externe SPI Flash wird per Bit-Banging angesprochen, warum sie nicht 
die SPI Peripherie verwenden ist unklar. Die UART wird scheinbar mit 
115200 bzw. 19200 Baud angesprochen, zumindest werden diese beiden 
Baudraten an zwei Stellen im Code verwendet.

Man sieht auch gut dass da noch einiges andere an Hardware durch rein- 
und rausschieben von Daten angesteuert wird (auch wieder per per 
Bit-Banging), es würde helfen wenn man wüßte was da sonst noch im Gerät 
verbaut ist. Eines davon wird relativ sicher das Display sein, 
interessant ist der Rest.

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> es würde helfen wenn man wüßte was da sonst noch im Gerät verbaut ist.
> Eines davon wird relativ sicher das Display sein, interessant ist der
> Rest.

Ein Beken BK4819.
https://de.scribd.com/document/659098729/BK4819-Datasheet-V1-01-2
Ein Beken BK1080.
https://datasheetspdf.com/mobile/688279/BEKEN/BK1080/1

Der eine ist der TRX, das andere Radio.

Hans W. schrieb:
> Nur dass diese 4MB File ja anscheinend nur zur Verwirrung angehängt
> wurde...

Nein, das 4mb File ist das flashdump eines "ähnlichen" Gerät.
Dort drin scheinen sich die Einträge für den Beken TRX IC zu befinden, 
welche die Firmware für die Register braucht.

Die beiden sind sich ähnlich, daher war diese als Beispiel gemeint.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Hans W. schrieb:
> Nur dass diese 4MB File ja anscheinend nur zur Verwirrung angehängt
> wurde...

Rate mal, wie ich den Anhang in meinem obigen Beitrag erstellt habe :)

von Kilo S. (kilo_s)


Lesenswert?

Yalu X. schrieb:
> Rate mal, wie ich den Anhang in meinem obigen Beitrag erstellt habe :)

Ja, das Image der Ruyage ist sozusagen die Referenz. Es ist für alle 
drei in Prinzip die gleiche Software, das Ruyage hat zwar andere 
Register drin stehen weil es einen anderen TRX IC verwendet, ist aber 
aktuell das einzige der Geräte von dem einer in der Gruppe ein dump 
hinbekommen hat.

Die Basis ist immer das iRadio UV-5118 .

https://www.qziradio.com/uv-5118-full-bands-ham-radio-with-air-band-receive_p80.html

Das Radtel hat das Gehäuse beibehalten und nur Display und TRX Chip 
getauscht.

Ich wüsste gerne wie du es geschafft hast die Sprachdateien zu 
Extrahieren?
Aber ja, das ist die Tante die mich auch beim ersten Mal einschalten aus 
der Funke angequatscht hat. ;-)

Ich frage gleich mal in die Gruppe ob es jemand von denen den flash vom 
Radtel Auslesen kann.

von Dieter S. (ds1)


Lesenswert?

Die Programmierung der Register des BK4819 sieht man recht gut in der 
Firmware. Allerdings ist in dem obigen Datenblatt keine Beschreibung der 
Register enthalten. Für einen BK4815N findet man ein Datenblatt mit den 
Registern, das wird aber vermutlich nicht passen.

Im externen SPI Flash steht u.a. auch der Font für die Textausgabe, man 
sieht dass die entsprechenden Zeichen bei jeder Ausgabe aus dem SPI 
Flash gelesen werden da nicht genügend interner Speicher vorhanden ist 
um den kompletten Font zu laden.

Meine Vorgehensweise bei so einem Gerät wäre erst mal zu schauen ob man 
per SWD auf den AT32F421 zugreifen kann. Falls der Chip gelockt ist kann 
man ihn eventuell komplett löschen und hat dann SWD Zugriff. Dass dabei 
der Bootloader verloren geht ist nicht so tragisch, man kann immer noch 
"allcode_bytes.hex" laden und mit ein paar Zeilen zusätzlichen Code ohne 
Bootloader direkt starten (nur das Firmware Update geht dann halt nicht 
mehr). Vorteil des SWD Zugriff: man könnte die vorhandene Firmware 
debuggen und auch leichter mit eigenem Code experimentieren.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Kilo S. schrieb:
> Ich wüsste gerne wie du es geschafft hast die Sprachdateien zu
> Extrahieren?

Die ersten ca. 1,8 MB der Datei enthalten unkomprimierte
8-Bit-Audiodaten mit einer Samplerate von etwa 8000 Hz (vielleicht sind
es auch 8192 Hz).

Mit SoX habe ich die Daten in ein MP3 konvertiert:
1
sox -t raw -e unsigned -c1 -b8 -r8000 Ruyage_UV-58_Dump.Bin das-ding-kann-sprechen.mp3 trim 0s 1800000s

Es sind 107 Sprachfragmente mit jeweils 2¹⁴=16384 Samples (ca. 2 s). Da
die Fragmente unterschiedlich lang und kürzer als 16384 Samples sind,
wird der Rest jeweils mit 0-Bytes aufgefüllt. Daher kommt das Knacken
zwischen den einzelnen Fragmenten im obigen MP3.

: Bearbeitet durch Moderator
von Dieter S. (ds1)


Angehängte Dateien:

Lesenswert?

In "allcode_bytes.hex" sind die Daten für die SRAM Initialisierung ein 
wenig gepackt, wenn man das auspackt sieht man die vollständigen 
Menütexte, siehe "Menu.txt"

: Bearbeitet durch User
von Kilo S. (kilo_s)


Angehängte Dateien:

Lesenswert?

Respekt!
Was ihr alles aus den Dateien auslesen könnt ist echt (für mich) 
beeindruckend!

Dieter S. schrieb:
> Die Programmierung der Register des BK4819 sieht man recht gut in der
> Firmware. Allerdings ist in dem obigen Datenblatt keine Beschreibung der
> Register enthalten.

Du wärst also in der Lage, mit den passenden Infos, den Teil um zu 
Schreiben?

Siehe Anhang!
Ich hab ehrlich keine Ahnung ob das zum TRx IC gehören soll.

Das kannst du besser bewerten!

: Bearbeitet durch User
von Kilo S. (kilo_s)


Lesenswert?

Yalu X. schrieb:
> Die ersten ca. 1,8 MB der Datei enthalten unkomprimierte
> 8-Bit-Audiodaten mit einer Samplerate von etwa 8000 Hz (vielleicht sind
> es auch 8192 Hz).
> Mit SoX habe ich die Daten in ein MP3 konvertiert:

Genial!
Du hilfst damit Stück für Stück die Struktur zu entflechten, bestimmt 
hilfreich beim Bauen einer neuen Firmware.

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Du wärst also in der Lage, mit den passenden Infos, den Teil um zu
> Schreiben?

Die Frage ist was genau Du unter "umschreiben" verstehst. Das Ganze ist 
in erster Linie eine Zeitfrage, also wie viel Aufwand man da reinstecken 
will. Ein paar kleinere Änderungen, z.B. eine Beschränkung für das 
Einstellen der Frequenz entfernen (falls es keine Beschränkung durch die 
Hardware gibt) ist vermutlich noch mit überschaubarem Aufwand machbar.

Allerdings brauche ich dazu so ein Gerät, nur wenn ich direkt per SWD 
darauf zugreifen kann macht das Sinn, alles andere kostet zu viel Zeit.

> Siehe Anhang!
> Ich hab ehrlich keine Ahnung ob das zum TRx IC gehören soll.

Ich habe jetzt nur ein paar der Register aus dem PDF geprüft ob das Sinn 
ergeben könnte, das hat soweit gepasst.

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Ein paar kleinere Änderungen, z.B. eine Beschränkung für das Einstellen
> der Frequenz entfernen (falls es keine Beschränkung durch die Hardware
> gibt) ist vermutlich noch mit überschaubarem Aufwand machbar.
> Allerdings brauche ich dazu so ein Gerät, nur wenn ich direkt per SWD
> darauf zugreifen kann macht das Sinn, alles andere kostet zu viel Zeit.

Es geht darum dem TRX IC (Belken) beizubringen (bzw. Der Firmware) sende 
sowie empfangsseitig seinen vollen Bereich auszuschöpfen.
(18-620-860-1300MHz, soweit mir bekannt!)

Und das nach Möglichkeit mit Umschaltung AM/FM.

Der Einfachheit halber würde uns ein Format helfen, (.bin) das nur die 
Instruktionen/Firmware enthält das die Grundfunktionen Enthalten sind, 
die der programmierer der auch die 5K Firmware betreut, versteht.

Also die die "decodierte" Firmware als binary den der updater ansonsten 
über serial an das Funkgerät sendet.

Dafür müsste es doch reichen den updater so zu zerlegen das dessen 
Decodierung reproduzierbar ist?

: Bearbeitet durch User
von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Kilo S. schrieb:
> Der Einfachheit halber würde uns ein Format helfen, (.bin) das nur die
> Instruktionen/Firmware enthält

Ähm... Das "Hex" File ist genau das... Die Endung ist nur suboptimal...

73

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Dafür müsste es doch reichen den updater so zu zerlegen das dessen
> Decodierung reproduzierbar ist?

Den Aufwand dafür werde ich nicht investieren, das müßt ihr dann schon 
selber machen. "allcode_bytes.hex" fängt bei Adresse 0x08001400 an, die 
Funktion zum Lesen eines Register ist bei 0x0800A944, Register Schreiben 
bei 0x0800A9A0 und ARM Disassembler gibt es jede Menge. Der Aufwand 
steckt darin das Disassembler Listing zu verstehen wenn man dessen 
Funktionalität nachbauen will.

von Kilo S. (kilo_s)


Lesenswert?

Hans W. schrieb:
> Ähm... Das "Hex" File ist genau das... Die Endung ist nur suboptimal...

Da ist doch auch der Teil mit bei, der mir die Oberfläche für das Update 
unter Windows zeigt und das Drumherum.
Ich brauche ja nur das was am ende per serial ans Funkgerät gesendet 
wird.

Dieter S. schrieb:
> Den Aufwand dafür werde ich nicht investieren, das müßt ihr dann schon
> selber machen. "allcode_bytes.hex" fängt bei Adresse 0x08001400 an, die
> Funktion zum Lesen eines Register ist bei 0x0800A944, Register Schreiben
> bei 0x0800A9A0 und ARM Disassembler gibt es jede Menge. Der Aufwand
> steckt darin das Disassembler Listing zu verstehen wenn man dessen
> Funktionalität nachbauen will.

Immerhin ein Anhaltspunkt.

Ich werde mal Schauen ob ich irgendwas auf die Beine stellen kann.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Dieter S. schrieb:
> Der Aufwand
> steckt darin das Disassembler Listing zu verstehen wenn man dessen
> Funktionalität nachbauen will.

Damit hab ich mich schon Ewigkeiten nicht mehr beschäftigt... was ist 
denn da heute empfehlenswert? Immer noch IDA bzw wie weit ist Ghidra ?

73

von Alexander (alecxs)


Lesenswert?

Immer nur so gut wie sein Nutzer.

von Dieter S. (ds1)


Lesenswert?

Hans W. schrieb:
>
> Damit hab ich mich schon Ewigkeiten nicht mehr beschäftigt... was ist
> denn da heute empfehlenswert? Immer noch IDA bzw wie weit ist Ghidra ?

Ob IDA Pro oder Ghidra spielt keine Rolle, man muß wissen wie man diese 
Tools benutzt und den Code verstehen, den man untersucht.

von Hans W. (Firma: Wilhelm.Consulting) (hans-)


Lesenswert?

Dieter S. schrieb:
> Hans W. schrieb:
>>
>> Damit hab ich mich schon Ewigkeiten nicht mehr beschäftigt... was ist
>> denn da heute empfehlenswert? Immer noch IDA bzw wie weit ist Ghidra ?
>
> Ob IDA Pro oder Ghidra spielt keine Rolle, man muß wissen wie man diese
> Tools benutzt und den Code verstehen, den man untersucht.

Naja, solche Tools können dabei aber auch durchaus helfen...

Damals, waren College-Block, Bleistift und SoftICE (damit meine ich den 
Debugger) bzw IDA Pro das Mittel der Wahl... da dürfte sich doch etwas 
getan haben in den letzten Jahrzenten :)

73

von NGC 5. (ngc5907)


Angehängte Dateien:

Lesenswert?

Kilo S. schrieb:
> Hans W. schrieb:
>> Ähm... Das "Hex" File ist genau das... Die Endung ist nur suboptimal...
>
> Da ist doch auch der Teil mit bei, der mir die Oberfläche für das Update
> unter Windows zeigt und das Drumherum.
> Ich brauche ja nur das was am ende per serial ans Funkgerät gesendet
> wird.

Ja die Endung .hex war sehr dämlich von mir gewählt - zu meiner 
Entschuldigung: das bytearray im Code, in dem die decodierte Firmware 
gespeichert wird, heißt "hex".

Yalu X. schrieb:
> Dahinein kommen die 59 KiB aus dieser Datei:
>
> NGC 5. schrieb:
>> allcode_bytes.hex

Die Datei enthält exakt das, was der Updater an das Gerät schickt.

Kilo S. schrieb:
> Öhm, mit welchem Programm genau betrachtest du das?
Ich habe dnSpy (https://github.com/dnSpyEx/dnSpy/releases/tag/v6.4.0) 
benutzt, nachdem klar war, dass es sich um ein .NET-Binary handelt.

Zum Extrahieren der Firmware hab ich mir schnell ein Programm 
geschrieben, das die Daten aus der UV5118Plus Update V1.34_230309.exe 
extrahiert.
Kannste haben falls es Dich interessiert und Du noch andere Versionen 
der Firmware aus anderen Updater.exe extrahieren willst - siehe Anhang. 
(Ist in dem Fall kein "shady Binary" wie Oliver schrieb :), Benutzung 
aber dennoch auf eigene Gefahr!)

NB: Das wird nur dann für andere Versionen funktionieren, wenn diese 
intern dieselben Variablen- und Methodennamen benutzen.

Ach ja: die extrahierte Firmware ließ sich hernach wunderbar in Ghidra 
(https://github.com/NationalSecurityAgency/ghidra/releases) laden (Arm 
Cortex).

Viel Erfolg!

LG

von Dieter S. (ds1)


Angehängte Dateien:

Lesenswert?

Zu dem HEX String im Update Program: Das ist nichts weiter als Intel-HEX 
bei dem das Zeilenende fehlt und die einzelnen Zeilen aneinander gehängt 
wurden.

Wenn man die Zeilenenden wieder einfügt bekommt man die Datei im Anhang. 
Mit der Intel-HEX Datei hat man dann auch automatich den Programmstart 
0x08001400.

von Kilo S. (kilo_s)


Lesenswert?

NGC 5. schrieb:
> Die Datei enthält exakt das, was der Updater an das Gerät schickt.

Also das ganze .net geraffel was inhaltlich nichts mit dem Funkgerät zu 
tun hat (GUI für Windows usw..) ist da gar nicht mehr drin gewesen?

Dann hab ich das wohl falsch verstanden.

Also haben wir jetzt hier das "verschlüsselte" Firmware Image das die 
CPU vom Updater bekommt.

Jetzt, kommt ein Punkt an dem ich tatsächlich auch selbständig anfangen 
kann zu helfen.

https://github.com/amnemonic/Quansheng_UV-K5_Firmware/blob/main/python-utils/fw_unpack.py

Eventuell, nur ganz vielleicht, könnte man dieses Tool umschreiben.

: Bearbeitet durch User
von Kilo S. (kilo_s)


Lesenswert?

NGC 5. schrieb:
> Ach ja: die extrahierte Firmware ließ sich hernach wunderbar in Ghidra
> (https://github.com/NationalSecurityAgency/ghidra/releases) laden (Arm
> Cortex).
> Viel Erfolg!

Ich werde mich einarbeiten.



Vielen lieben Dank so weit an alle die geholfen haben und sich hier 
beteiligt!

Ich werde berichten so bald es etwas neues gibt!

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Also haben wir jetzt hier das "verschlüsselte" Firmware Image das die
> CPU vom Updater bekommt.

Und nochmal (siehe auch etwas weiter oben): Die Firmware ist nicht 
verschlüsselt, das ist einfach nur Intel-HEX ohne Zeilenende. Und das 
was "binär" darin enthalten ist ist der CortexM4 Code für den AT32F421.

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Kilo S. schrieb:
>> Also haben wir jetzt hier das "verschlüsselte" Firmware Image das die
>> CPU vom Updater bekommt.
>
> Und nochmal (siehe auch etwas weiter oben): Die Firmware ist nicht
> verschlüsselt, das ist einfach nur Intel-HEX ohne Zeilenende. Und das
> was "binär" darin enthalten ist ist der CortexM4 Code für den AT32F421.

Jo, das hab ich jetzt auch langsam kapiert.

War noch vor dem ersten Kaffee!

von Kilo S. (kilo_s)


Lesenswert?

Boar!

Kotzt man da!

Jetzt hab ich euch zur Hilfe mobilisieren können, nu kommen die nicht zu 
Rande.

Die haben nun alles und es passiert einfach ert Mal Nix!


Gibt's hier jemanden für nen "crashkourse" (der den Assembler Kram 
versteht!) Und mir helfen kann folgende Dinge (nach Vorarbeit!) Zu 
verstehen:

1.) Welche Register für den Belken TRX IC wie geladen werden. (Können 
die im flash (.bin) stehen?

2.)Einen universellen "Updater" zu bauen. (*.bin laden und über serial 
ans Funkgerät senden)

3.) Den verdammten Leuten aus der Gruppe den mittleren zeigen weil die 
nicht glauben das der Intel Hex der Firmware Code ist!

Da passiert einfach gar nix!

Dabei war ich doch so zuversichtlich weil auch metasploit von den Russen 
kommt. Ein paar von denen habens echt drauf !

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Gibt's hier jemanden für nen "crashkourse" (der den Assembler Kram
> versteht!) Und mir helfen kann folgende Dinge (nach Vorarbeit!) Zu
> verstehen:

Reverse-Engineering gibt es nicht als "Crashkurs", das ist hauptsächlich 
eine Sache von viel Erfahrung ("viel" wie in "viele Jahre"). Und wie 
weiter oben schon steht: Was man mit Tools wie IDA Pro oder Ghidra aus 
einem Binary herausholt hängt vom Benutzer und dessen Erfahrung ab, die 
Tools sind nur Hilfsmittel.

Abgesehen davon: was ist denn der Vorteil von dem RT-890 gegenüber dem 
UV-K5 wenn in beiden fast die selbe RF-Hardware verbaut ist? Für das 
UV-K5 gibt es jede Menge Informationen und diverse Modifikationen, der 
Preis der Geräte ist noch dazu sehr niedrig.

Zu der Firmware aus dem Gerät: Warum nicht einfach schauen ob SWD des 
AT32F421 offen ist und darüber auslesen? Dann hat man alles, inklusive 
Bootloader. Beim UV-K5 scheint ja SWD nicht gesperrt zu sein und wird 
auch von einigen Leuten für alles mögliche verwendet, eventuell ist also 
SWD beim RT-890 ebenfalls offen.

von Alexander (alecxs)


Lesenswert?

schon mal über eine entsprechende Bezahlung nachgedacht bevor Du Dich 
darüber auskotzt?

von Kilo S. (kilo_s)


Lesenswert?

Alexander schrieb:
> schon mal über eine entsprechende Bezahlung nachgedacht bevor Du Dich
> darüber auskotzt?

Ich soll Leute bezahlen, welche eine Gruppe gegründet haben, um ihr Ziel 
kostenlos zu erreichen? Ja neee, ist klar!

Damit du verstehst was ich meine, die Gruppe existiert sozusagen nur 
dafür das einer mal die Firmware zur Verfügung stellt um sie zu 
"hacken".

Dieter S. schrieb:
> Abgesehen davon: was ist denn der Vorteil von dem RT-890 gegenüber dem
> UV-K5 wenn in beiden fast die selbe RF-Hardware verbaut ist?

Die Filter im Gerät sind für 6 anstelle zwei Bänder ausgelegt, die 
Filterbreite macht das Gerät im erweiterten Zustand empfindlicher für 
Signale außerhalb der eigentlichen Frequenzen. Und ja da ist es bon 
Vorteil das die Finger im Gerät für den eigentlichen Zweck schlecht 
sind.

von Alexander (alecxs)


Lesenswert?

Genau, die Gruppe von Experten dient ausschließlich dafür den Noobs die 
Hausaufgaben zu machen. Selbstverständlich auf Abruf und zu deren 
Zeitvorstellung. Erstaunlich dass Du noch nicht gekickt wurdest mit 
Deiner Einstellung.

von Kilo S. (kilo_s)


Lesenswert?

Alexander schrieb:
> Genau, die Gruppe von Experten dient ausschließlich dafür den Noobs die
> Hausaufgaben zu machen.

Ach du ahnst es nicht, das sind eben keine Experten! Aber, den Kontakt 
zum Entwickler der gehackten K5 Firmware wollen die mit der 
fadenscheinigen Begründung das die Firmware ja angeblich noch 
verschlüsselt sei, nicht herstellen. In der Gruppe gibt's auch nur einen 
wie es scheint der den Kontakt erfolgreich hergestellt hat.

Ich bekomme ihn nicht erreicht bzw. habe noch keine Rückmeldung von ihm.

von Harald K. (kirnbichler)


Lesenswert?

Vielleicht ist das ganze auch ein Sprach- oder gar Kulturproblem:

Kilo S. schrieb:
> ... weil es eine überwiegend Russische Gruppe ist

Die haben möglicherweise derzeit andere Schwerpunkte.

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Die Filter im Gerät sind für 6 anstelle zwei Bänder ausgelegt, die
> Filterbreite macht das Gerät im erweiterten Zustand empfindlicher für
> Signale außerhalb der eigentlichen Frequenzen.

Und damit ist es eine andere Fragestellung die man herausfinden muss: 
Wenn im RT-890 ebenfalls ein BK4819 verbaut ist wie im UV-K5 dann werden 
die Register ziemlich sicher fast identisch für den Empfang beschrieben.

Die Unterschiede liegen darin wie die Filter umgeschaltet werden. Beim 
UV-K5 werden die zwei Filter über GPIO Pins des BK4819 umgeschalten. Das 
wird vermutlich beim RT-890 ähnlich sein, es könnten aber auch GPIO Pins 
des AT32F421 verwendet werden. Und diese Umschaltung der Bänder muß man 
herausfinden, zumindest für den reinen Empfang sollte das ausreichen 
(wenn man also z.B. die Ansteuerung per serielle Schnittstelle vom PC 
aus macht und auf die Anzeige auf dem Gerät und die Bedienung über die 
Tasten verzichtet).

Wenn man allerdings eine vollständig eigene Firmware basten will (die 
gibt es für das UV-K5) dann kommt noch viel mehr dazu, u.a. wie das 
Display angesteuert werden muss und wie man die Tasten abfrägt.

von Kilo S. (kilo_s)


Lesenswert?

Harald K. schrieb:
> Die haben möglicherweise derzeit andere Schwerpunkte.

Jain, bei einem könnte das definitiv so sein.
Also das er aktiv bei dem scheiß dabei ist. Und ich würde nicht 
ausschließen daß es auch mehrere In der Gruppe sind, die 
gezwungenermaßen da mitmachen müssen!

Die meisten, wirklich Aktiven Leute dort haben aber mit dem scheiß nix 
am Hut.

Wir gesagt, die Aussage bisher war das die Firmware angeblich 
verschlüsselt wäre und die somit keinen Bock haben die datei weiter zu 
leiten.

Damit könne man angeblich nichts Anfangen. Wenn ich also irgendwann mal 
ein Ergebniss haben will, so muss ich mir das jetzt wohl selbst 
aneignen!

Rein theoretisch, laut dem was bei der K5 Firmware bekannt ist, suche 
ich nach dem String 404B4C00 in der Firmware. Der muss zum ändern der 
Frequenzbereiche editiert werden.
Da dieser für beide Geräte theoretisch gleich sein soll/muss... So 
wird's behauptet.

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Wenn im RT-890 ebenfalls ein BK4819 verbaut ist wie im UV-K5 dann werden
> die Register ziemlich sicher fast identisch für den Empfang beschrieben.

Und nur genau dort, Brauch ich theoretisch die Änderung um die Limits 
neu zu setzen.

Die Umschaltung ist erst Mal völlig wumpe für mich, die Dämpfung der 
Filter, egal welchem, ist auf den Frequenzen unter und oberhalb sowieso 
hoch und ich kann damit sowieso nur starke Signale empfangen. Also ob 
ich jetzt nun den Filterzweig für 2m/1,25m/70cm schalte oder nicht, das 
Ergebniss ist immer das gleiche.

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Rein theoretisch, laut dem was bei der K5 Firmware bekannt ist, suche
> ich nach dem String 404B4C00 in der Firmware. Der muss zum ändern der
> Frequenzbereiche editiert werden.
> Da dieser für beide Geräte theoretisch gleich sein soll/muss... So
> wird's behauptet.

Stimmt so nicht. In der UV-K5 Firmware gibt es eine Funktion die auf die 
Bereichsgrenzen 5000000 (0x4C4B40, also 40 4B 4C 00 in Little-Endian) 
und 60000000 (0x3938700) prüft (vermutlich 10 Hz Schritte, also 50 MHz 
und 600 MHz).

In der UV5118Plus_Update_V1.34_230309 Firmware gibt es so eine Funktion 
nicht und auch 0x4C4B40 findet man dort nicht. Es gibt allerdings andere 
Funktionen die die Frequenz prüfen.

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Es gibt allerdings andere Funktionen die die Frequenz prüfen.

Ok, da ich heute dann endlich mal die Zeit habe die ersten Versuche zu 
unternehmen, schaue ich mir das mal an.

Dieter S. schrieb:
> Warum nicht einfach schauen ob SWD des AT32F421 offen ist und darüber
> auslesen?

Meines Wissens nach müsste ich es dafür öffnen, da kann ich mich aktuell 
noch nicht zu durchringen!

von Kilo S. (kilo_s)


Lesenswert?

Tja, neues vom Radtel.

Flash protekt ist an, SWD funktioniert nicht so recht deshalb.

Aber wir haben ein komplettes dump.

Bald geht es weiter.

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Aber wir haben ein komplettes dump.

Stell den Dump doch mal hier rein, dann kann man schauen ob das zu der 
Firmware aus dem Updateprogramm passt. Das wurde ja weiter oben 
angezweifelt.

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Stell den Dump doch mal hier rein, dann kann man schauen ob das zu der
> Firmware aus dem Updateprogramm passt. Das wurde ja weiter oben
> angezweifelt.

Das werde ich aktuell noch nicht tun.
Grund: der dump beinhaltet u.a auch den "hack" mit dem der eigentlich 
geschützte Flash ausgelesen wurde.
Der wurde mit einem modifizierten Updater eingespielt, also ja. Es ist 
ganz sicher die Firmware zu diesem Gerät.

Ein bisschen Geduld noch, in ca. 3-4 Tagen hat er sein eigenes Gerät und 
legt nochmal Hand an. Wenn er so weit ist kann ich mein Gerät auch ein 
Mal neu beschreiben ohne den "schutz" des Flash und softwareseitige 
Hindernisse. (Die swd Pins werden eigentlichen für was anderes 
verwendet)

Mit Glück sind es dann noch 3-4 Wochen bis auf github die rekonstruierte 
Firmware als Sourcecode zu haben ist.

Ich kann es glaube noch weniger erwarten als ihr.  ;-)

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Das werde ich aktuell noch nicht tun.
> Grund: der dump beinhaltet u.a auch den "hack" mit dem der eigentlich
> geschützte Flash ausgelesen wurde.

Da der Bootloader offensichtlich beim Einspielen eines Update keine bzw. 
nur ganz einfache Prüfungen durchführt kann man relativ problemlos ein 
modifziertes Update einspielen. Wenn das dann so gepatcht ist dass es 
den Speicher über die UART ausgibt hat man den Bootloader.

> Wenn er so weit ist kann ich mein Gerät auch ein
> Mal neu beschreiben ohne den "schutz" des Flash und softwareseitige
> Hindernisse. (Die swd Pins werden eigentlichen für was anderes
> verwendet)

Die SWD Pins werden für die Ansteuerung von zwei LEDs verwendet. Das ist 
aber kein Schutz, man braucht halt alle Pins des Chip (wenn der Chip die 
Readout-Protection nicht gesetzt hätte könnte man nach wie vor per SWD 
den Chip auslesen, nur Debuggen im laufenden Betrieb geht nicht). Der 
eigentliche Schutz ist die gesetzte Readout-Protection des AT32, die ist 
ähnlich wie beim STM32 (es ist ja ein STM32 Klon).

von Frank O. (frank_o)


Lesenswert?

Interessanter Beitrag!

Hilft das evtl. etwas weiter?

https://www.youtube.com/watch?v=716U0zXs4Uo

Ich verstehe zwar nur die Hälfte und grob, aber ich würde erstmal 
schauen, ob es so etwas nicht schon gibt.

: Bearbeitet durch User
von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Da der Bootloader offensichtlich beim Einspielen eines Update keine bzw.
> nur ganz einfache Prüfungen durchführt kann man relativ problemlos ein
> modifziertes Update einspielen. Wenn das dann so gepatcht ist dass es
> den Speicher über die UART ausgibt hat man den Bootloader.

Genauso wurde das ausgenutzt, allerdings, hab ich keine Ahnung WIE.

Ich habe vertraut, es hat funktioniert, es war alles gut.

Ich hatte auch keinen Moment lang angst das mir irgendein Mist 
untergekommen ist. Aber: nicht mein Code, ich hab keine Ahnung ob das 
unerwünschte Verhaltensweisen des Gerät hervorruft usw...

Sicherheitshalber nicht!

Sorry, ihr müsst drauf vertrauen das ich mein bestes gebe um zusammen 
(wer einsteigen will benötigt Telegram) mit UP *(synonym) wenigstens die 
rekonstruierte Firmware zur Verfügung stellen.

Das ist POC! Das noch keine Fehler aufgetaucht sind ist beachtlich!
Garantiert ist nichts!

von Kilo S. (kilo_s)


Lesenswert?

Frank O. schrieb:
> Ich verstehe zwar nur die Hälfte und grob, aber ich würde erstmal
> schauen, ob es so etwas nicht schon gibt.

Was du da gefunden hast betrifft ja nur die Programmierung der Speicher.

Was wir da gerade machen....

Das Gerät kann mit passender Programmierung wie das quanscheng k5  ssb!

Versteckte register usw....
Das 890 kann später mit 128MHz takt Spektrum auf Farbdisplay....

Wir reden davon die Firmware, also den Code des CPU zu verändern. 
Funktionen hinzufügen, display neu gestalten usw...


So als würdest du dir was eigenes as display +touch für zuhause mit ei 
em esp selbst schreiben!

von Frank O. (frank_o)


Lesenswert?

Das habe ich schon verstanden.
Ich dachte nur, dass es vielleicht auch da eine Hintertür geben könnte.

von Dieter S. (ds1)


Angehängte Dateien:

Lesenswert?

Falls sich jemand den Bootloader des RT-890 selber ansehen will: siehe 
Anhang.

Der Bootloader steht direkt am Anfang des Flash (0x08000000), 
unmittelbar dannach kommt dann die Firmware (z.B. 
UV5118_Plus_Update_V1.34_20230309) ab Adresse 0x08001400. Zusammen sind 
das die 64 KByte Flash des AT32F421.

Der Bootloader ist wirklich sehr einfach gehalten, es gibt ein Kommando 
zum Löschen des Flash ab 0x08001400 und eines zum Schreiben von genau 
0xEC00 Bytes ab 0x08001400. Eine Prüfsumme gibt es nur zur Absicherung 
der Datenübertragung vom PC beim Update.

von Kilo S. (kilo_s)


Lesenswert?

Frank O. schrieb:
> Das habe ich schon verstanden.
> Ich dachte nur, dass es vielleicht auch da eine Hintertür geben könnte.

Die Hintertür liegt im Update selbst (kein CRC/Checksum....)

Was du da einbaust, wie, und vor allem wie du die Daten aus dem 
eigentlich geschützten Speicher bekommst...

Keine Ahnung!

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Falls sich jemand den Bootloader des RT-890 selber ansehen will: siehe
> Anhang.

Hmm.

Bist dir da auch wirklich sicher?

von Dieter S. (ds1)


Lesenswert?

Falls sich jemand mit dem RT-890 und der Firmware näher beschäftigen 
will: Man kann das Gerät auch im Betrieb per SWD debuggen. Die beiden 
SWD Pins werden zwar für die Ansteuerung der roten und grünen LED 
verwendet, man hat aber vorgesehen dass man die Firmware dennoch 
debuggen kann.

Dazu muss beim Einschalten die Versorgungsspannung deutlich unter 6.0 
Volt liegen, so lange bleibt die Firmware in einer Endlosschleife. Zu 
diesem Zeitpunkt sind die SWD Pins noch nicht als Ausgänge konfiguriert, 
das passiert erst unmittelbar wenn die Schleife verlassen wird. Man kann 
sich also per SWD verbinden, einen Breakpoint auf die Funktion für die 
Konfiguration der SWD Pins setzten, die Versorgungsspannung auf den 
normalen Wert erhöhen (ca. 7.4 Volt) und dann beim Erreichen des 
Breakpoint die Konfigurationsfunktion überspringen. Danach funktioniert 
das Debuggen per SWD, lediglich die grüne und rote LED haben nun keine 
Funktion.

Voraussetzung für das Ganze ist dass man einmalig die Readout Protection 
zurückgesetzt hat, das bewirkt ein Löschen des kompletten Flash. Da aber 
der Bootloader und die Firmware verfügbar sind (siehe weiter oben) kann 
man diese einfach neu programmieren.

Alternativ kann man auch den Aufruf der SWD Pin Konfiguration mit "NOP" 
patchen, dann ist das Debuggen jederzeit und ohne Vorbereitung möglich 
(die fehlende Funktion der roten und grünen LED sollte beim Debuggen 
nicht weiter stören).

von Kilo S. (kilo_s)


Lesenswert?

Danke für die Info. Hab das Mal So weitergeleitet.

Wurde erstmal gefragt wo ich das gelesen habe, bekam dazu promt die 
Antwort:"we don't have the bootloader yet".

Ich frage also nochmals: Bist du sicher das der Bootloader mit 
enthaltenen ist?!

von Kilo S. (kilo_s)


Lesenswert?

Der Nebel lichtet sich:
"
if the flash wipe also deleted 0x1fffxxxx, then you have a soft brick
potentially, because id ont know if 0x1fff is flash or not
it seems flash in some documentation but ROM in other docs
so it's a risk to wipe the flash and not know for sure if that part can 
be restored"

Es geht also nicht um den Bootloader sondern um einen anderen.

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Es geht also nicht um den Bootloader sondern um einen anderen.

Ab 0x1FFFE400 bis 0x1FFFF3FF liegt die "Boot code area", das ist der ROM 
Bootloader des AT32F421. Der ist für die RT-890 Firmware irrelevant (der 
ROM Bootloader ist nur aktiv wenn man den BOOT0 Pin auf High setzt).

Abgesehen davon ist der ROM Bootloader des AT32F421 dokumentiert, ich 
sehe momentan keinen Grund warum man den braucht (ausser man sucht nach 
Sicherheitslücken). Und ja, auch den ROM Bootloader kann man auslesen 
sobald man die Readout Protection zurückgesetzt hat.

: Bearbeitet durch User
von Dieter S. (ds1)


Angehängte Dateien:

Lesenswert?

Weiter oben steht dass die Filter des RT-890 für sechs Bänder ausgelegt 
sind. Ich bin mir inzwischen relativ sicher dass das nicht der Fall ist.

Die Firmware unterscheidet zwischen "low" und "high" Band, genauso wie 
beim UV-K5, entsprechend diesem Flag werden über die GPIO Ausgänge des 
BK4819 die Filter umgeschaltet.

Der einzige Unterschied zwischen RT-890 und UV-K5 bei der Behandlung der 
Bänder liegt in der Firmware: Durch den großen SPI Flash hat das RT-890 
mehrere vom Frequenzband abhängige Tabellen für die Konfiguration des 
BK4819, das betrifft so Dinge wie Squelch und den PA Bias beim Senden. 
Das UV-K5 hat nur einen 8 KByte großen EEPROM.

Im Anhang sind zwei Platinen-Bilder der Geräte, wenn das RT-890 
tatsächlich 6 Filter anstelle zwei wie beim UV-K5 haben sollte würde der 
Unterschied vermutlich deutlich sichtbar sein.

von Michael H. (micha_22)


Lesenswert?

Dieter S. schrieb:
> Und ja, auch den ROM Bootloader kann man auslesen
> sobald man die Readout Protection zurückgesetzt hat.

Dieter S. schrieb:
> Weiter oben steht dass die Filter des RT-890 für sechs Bänder ausgelegt
> sind. Ich bin mir inzwischen relativ sicher dass das nicht der Fall ist.

Dieter S. zerlegt gerade eure Experten Gruppe.

von Kilo S. (kilo_s)


Lesenswert?

Michael H. schrieb:
> Dieter S. zerlegt gerade eure Experten Gruppe.

Ähm, nein!

Dieter S. schrieb:
> Ich bin mir inzwischen relativ sicher dass das nicht der Fall ist.

Bandbreite gemessen? Durchansdämpfung bekannt?

Wie sollte ich sonst mit einer notdürftig angepassten 62cm vertikal 
direkt auf dem Gerät Satcom empfangen können, wenn die filter nicht 
Breit genug sind hätte ich dafür zu viel Dämpfung.

Bedenke, Vertikal! Und nicht Zirkular, Ohne nennenswerten gewinn.
Ich schrieb auch nie was von 6 filtern sondern nur das die Filter für 6 
Bänder angepasst (dafür auch entsprechend "schlecht" bei der 
Unterdrückung von nebenaussendungen) sind.

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Bandbreite gemessen? Durchansdämpfung bekannt?
>

Hast Du das gemacht? Wenn ja, dann bitte mehr Details.

Abgesehen davon: Du könntest den Schaltplan für das RT-890 aufnehmen, 
für das UV-K5 hat das bereits jemand gemacht. Dann hätte man einen 
objektiven Vergleich. Sonst habe ich hier bisher fast nur Spekulationen 
gelesen, die am Ende nicht gestimmt haben (u.a. "die Firmware ist 
verschlüsselt", "die Firmware hier im Thread ist nicht für das RT-890" 
oder auch "wir haben den Bootloader der Firmware").

Im übrigen habe ich versuchshalber in der Firmware die 
Empfangsmöglichkeiten bereits auf 60 MHz bis 630 MHz erweitert (die 
Werte kommen daher weil das im Prinzip schon vorhanden ist), allerdings 
ist die Empfindlichkeit an den Rändern ziemlich schlecht.

Nachtrag:

Woher kommen denn die "sechs Bänder"? Die Firmware hat einen 
duchgehenden Empfangsbereich, die Bereiche für die oben erwähnten 
Tabellen sind so aufgeteilt:
1
 64 MHz ... 136 MHz    "low Band"
2
136 MHz ... 174 MHz    "low Band"
3
174 MHz ... 240 MHz    "low Band"
4
240 MHz ... 320 MHz    "high Band"
5
320 MHz ... 400 MHz    "high Band"
6
400 MHz ... 480 MHz    "high Band"
7
480 MHz ... 560 MHz    "high Band"

In der Hardware gibt es also nichts was mit sechs Bändern zu tun hat, 
lediglich die Filter für "low" und high".

: Bearbeitet durch User
von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Hast Du das gemacht? Wenn ja, dann bitte mehr Details.

Noch nicht, aber muss logischerweise so sein.

Dieter S. schrieb:
> Woher kommen denn die "sechs Bänder"?

Die Unterteilung in der Tabelle ist eine andere als das was der 
Hersteller schreibt.

https://de.aliexpress.com/i/1005004886722419.html

"6 Band Ham Radio"...

UKW, Air, 1,25m, 2m, 70cm und die darüber.

6 Bänder!

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> 6 Bänder!

Darum steht auch im User Manual des RT-890 unter "Specification":
1
RX:  64-108MHz (FM Band)
2
    108-136MHz (Aviation frequency band)
3
    136-520MHz
4
TX: 136-520MHz

von Axel R. (axlr)


Lesenswert?

Kilo S. schrieb:
> Michael H. schrieb:
>> Dieter S. zerlegt gerade eure Experten Gruppe.
>
> Ähm, nein!

Wohl! 😂😂

verbreitet schon Kurzweil.

von Michael H. (micha_22)


Lesenswert?

Axel R. schrieb:
> Kilo S. schrieb:
>> Michael H. schrieb:
>>> Dieter S. zerlegt gerade eure Experten Gruppe.
>>
>> Ähm, nein!
>
> Wohl! 😂😂
>
> verbreitet schon Kurzweil.

Alleine die Tatsache wie viele Informationen Dieter hier im Vergleich zu 
der Gruppe raus haut, obwohl er davon vermutlich eher wenig hat spricht 
Bände.

von Michael H. (micha_22)


Lesenswert?

Dieter S. schrieb:
> Kilo S. schrieb:
>>
>> 6 Bänder!
>
> Darum steht auch im User Manual des RT-890 unter "Specification":
>
>
1
> RX:  64-108MHz (FM Band)
2
>     108-136MHz (Aviation frequency band)
3
>     136-520MHz
4
> TX: 136-520MHz
5
>

Ich bin kein Funk Experte, würde das aber so sehen, dass das Gerät 
intern mit 2 Bändern arbeitet, die den Frequenzbereich der 6 Bänder 
abdeckt und deswegen damit beworben wird.

Das bedeutet ja nicht zwangsweise dass für jedes Band ein extra Filter 
vorhanden sein muss.

Kann man das so stehen lassen?

von Dieter S. (ds1)


Lesenswert?

Michael H. schrieb:
>
> Kann man das so stehen lassen?

Wenn man es vom Marketing aus betrachtet kann man das so stehen lassen.

Für eine Erweiterung der Möglichkeiten des Geräts in der Firmware ist 
allerdings entscheidend wie die technische Realisierung in der Hardware 
aussieht (man muss ja z.B. wissen wie viele Filter die Firmware 
ansteuert).

Und in der Hardware sieht es beim RT-890 so aus:

Der BK1080 ist ein FM Receiver für den Bereich 64..108 MHz (FM Radio).

Der eigentlich interessante Teil ist der BK4819 für den Bereich 18..660 
MHz und 840..1300 MHz. Die Firmware nutzt davon 100..520 MHz (für das 
Senden gibt es weitere softwareseitige Einschränkungen).

Und der Empfangsbereich wird durch Filter in zwei Bereiche "Low" und 
"High" eingeteilt (Grenze bei etwa 240 MHz).

Das Ganze ist sehr ähnlich zum UV-K5, dort sieht es in der Hardware 
vergleichbar aus. Ob jetzt das RT-890 empfindlicher als das UV-K5 ist 
spielt für die Firmware keine Rolle solange dafür nicht irgendetwas 
gemacht werden muss (z.B. Eingansstufen umschalten). Danach sieht es 
momentan nicht aus und irgendwas mit sechs Bändern gibt es in der 
Hardware ebenfalls nicht.

von Kilo S. (kilo_s)


Lesenswert?

Michael H. schrieb:
> Alleine die Tatsache wie viele Informationen Dieter hier im Vergleich zu
> der Gruppe raus haut, obwohl er davon vermutlich eher wenig hat spricht
> Bände.

Ne, die Flut an Informationen betrifft ja nicht nur das radtel sondern 
auch das k5.

Bis ich das hier alles geschrieben habe vergehen Stunden.

Sagen wir so, eine vollständige Firmware des radtel als Sourcecode wird, 
noch dauern.
Die wichtigsten Informationen fürs erste sind aber gefunden.
Was aber aktuell im Raum steht ist eine RT-890 Version der aktuellen K5 
Firmware.

Da nur weniger geändert werden muss um schnell mehr Funktionalität zu 
bekommen.

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Ne, die Flut an Informationen betrifft ja nicht nur das radtel sondern
> auch das k5.
>
> Bis ich das hier alles geschrieben habe vergehen Stunden.

Du meinst das UV-K5? Warum stellst Du nicht einfach Links zu den 
entsprechenden Informationen hier rein, zum UV-K5 ist so gut wie alles 
online verfügbar.

Zum Beipiel hier, das ist ein guter Einstieg mit Links auf noch mehr 
Informationen:

https://github.com/amnemonic/Quansheng_UV-K5_Firmware

Technische Details und Schaltpläne gibt es hier:

https://github.com/ludwich66/Quansheng_UV-K5_Wiki/wiki

Und hier gibt es eine nachprogrammierte Firmware für das UV-K5:

https://github.com/DualTachyon/uv-k5-firmware

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Du meinst das UV-K5?

Ja.

Dieter S. schrieb:
> Warum stellst Du nicht einfach Links zu den entsprechenden Informationen
> hier rein


Weil es keine links gibt und auch nich beim k5 gefunden wurden Sondern 
im Code des radtel!

Und noch dazu sind das teils undokumentierte Sachen die nicht im 
Datenblatt stehen.

Wie Viele genau klärt sich ja erst noch.

von Alexander (alecxs)


Lesenswert?

mindestens einer in den Links hat TG (fagci)

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Weil es keine links gibt und auch nich beim k5 gefunden wurden Sondern
> im Code des radtel!
>
> Und noch dazu sind das teils undokumentierte Sachen die nicht im
> Datenblatt stehen.

Wenn Du stundenlang darüber schreiben könntest dann nenne doch 
wenigstens zwei oder drei Punkte ganz konkret damit man weiß worum es 
überhaupt geht.

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Wenn Du stundenlang darüber schreiben könntest dann nenne doch
> wenigstens zwei oder drei Punkte ganz konkret damit man weiß worum es
> überhaupt geht.

Undokumentierte register des BK4819.

Das K5 hat scheinbar welche verwendet und das Radtel ebenfalls.

Bei beiden unterschiedliche.

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Undokumentierte register des BK4819.
>
> Das K5 hat scheinbar welche verwendet und das Radtel ebenfalls.
>
> Bei beiden unterschiedliche.

Das ist alles? Das UV-K5 verwendet bei der Initialisierung des BK4819 
die folgenden undokumentierten Register, die stehen vermutlich im 
Zusammenhang mit der AGC:
1
BK4819_WriteRegister(0x49, 0x2A38);
2
BK4819_WriteRegister(0x7B, 0x8420);

Das RT-890 macht genau das selbe mit diesen beiden Registern.

Darüber hinaus setzt das RT-890 bei der Initialisierung des BK4819 
folgende undokumentierte Register:
1
BK4819_WriteRegister(0x1E, 0x4C58);
2
BK4819_WriteRegister(0x2A, 0x4F18);
3
BK4819_WriteRegister(0x53, 0xE678);
4
BK4819_WriteRegister(0x2C, 0x5705);
5
BK4819_WriteRegister(0x4B, 0x7102);
6
BK4819_WriteRegister(0x77, 0x88EF);
7
BK4819_WriteRegister(0x26, 0x13A0);

Das UV-K5 verwendet diese nicht. Wenn man wissen will was sie bewirken 
müsste man das nur in die nachprogrammierte Firmware des UV-K5 einbauen 
(Link siehe oben) und schauen ob sich etwas ändert (z.B. die 
Empfangseigenschaften). Das ist in weniger als 30 Minuten erledigt.

von Dieter S. (ds1)


Angehängte Dateien:

Lesenswert?

Im Anhang ist als "Proof of concept" eine etwas erweiterte Firmware für 
das RT-890. Der Frequenzbereich ist auf 60..630 MHz erweitert. Das Ganze 
ist nur im "Frequency Mode" möglich, wenn man also mit gespeicherten 
Channel-Listen arbeiten will geht die Erweiterung vermutlich nicht (dazu 
müssten noch ein paar mehr Prüfungen erweitert werden).

Basis ist die Firmware "UV5118 Plus Update V1.34 20230309" hier im 
Thread, es wurden lediglich ein paar Prüfungen der Frequenzbereiche 
erweitert.

Das Update Protokoll ist sehr einfach, da darf sich jeder gerne seine 
eigene Lösung bauen, das sollte z.B. mit ein paar Zeilen Python machbar 
sein.

Zum Update muss man beim Einschalten des RT-890 die beiden Sidekeys 
(aber nicht die PTT Taste) gedrückt halten, es leuchtet dann die grüne 
LED dauerhaft, das Display zeigt nichts an.

Baudrate für das Update ist 115200 Baud (8N1, also keine Parity).

Als erstes wird "0x39 0x33 0x05 0x10 0x81" zum RT-890 geschickt und man 
wartet auf Bestätigung (Byte 0x06).

Als nächstes wird "0x39 0x33 0x05 0x55 0xC6" zum RT-890 geschickt und 
man wartet wieder auf Bestätigung (Byte 0x06).

Jetzt wird das Update in einzelnen Blöcken geschickt, nach jedem Block 
wartet man auf Bestätigung (Byte 0x06). Jeder Block enthält jeweils 128 
(0x80) Update-Bytes und sieht so aus:
1
  0x57
2
  Offset High-Byte
3
  Offset Low-Byte
4
  128 Bytes des Update (ab Position "Offset" aus der Firmware Datei)
5
  Prüfsumme (ein Byte, die unteren 8 Bits)

Der Offset fängt bei 0x0000 an und wird bei jedem Block um 128 (0x80) 
erhöht.

Die Prüfsumme ist einfach die Summe aller Bytes davor (bei den obigen 
zwei Kommandos zum Start des Updates ist die Prüfsumme bereits 
enthalten),

Man muss insgesamt genau 0xEC00 Update-Bytes schicken, also 472 Blöcke.

Am Ende sollte das Update automatisch gestartet werden.

Falls irgendetwas schief geht kommt keine Bestätigung (Byte 0x06) oder 
auch 0xFF für einen Fehler.

Der Empfang an den erweiterten Bereichsgrenzen scheint zu funktionieren, 
ich habe allerdings nur auf die Schnelle ein paar Frequenzen getestet. 
Genau 630 MHz funktioniert übrigens nicht, vermutlich ist das eine harte 
Grenze des BK4819. Knapp darunter funktioniert aber.

von Kilo S. (kilo_s)


Lesenswert?

So sehr ich auch an einer Erweiterung des Empfangsbereich interessiert 
bin.

Und sei es nur im VFO Mode, ich warte noch.

Du sagst indirekt aus, du könntest mehr, doch die "verborgenen" Details, 
die gibst du nicht preis.

Startadresse?
Welches SVD?
Decompiler Optionen?

Usw...

Ich möchte gerne irgendwann mit helfen, auch wenn das noch lange dauern 
wird.


Aber wenn MIR jeder nur Teile des kontext hinwirft, kann ich nicht dazu 
lernen.

Und sorry wenn ich jetzt direkt werde, aber wenn du (der eben schon seit 
ewigkeiten dissasembler benutzen und das versteht) nicht in der Lage ist 
Wissen zu vermitteln... wie soll die nächste Generation das können ohne 
das Leute wie du der Lage seid zu lehren!

Du kommunizierst hier mit einem TECHNIKER, ich kann dir jedes Smartphone 
und Tablet reparieren, aber außerhalb meines Fachgebiet bzw. dem Was ich 
ich im Job brauche... ist alles eigenleistung!

Aber wenn du meinst du seiest so viel besser... zeig doch mal deinen 
übersetzten Code aus dem dissasembly.

Und zwar das was du herausgearbeitet hast, und nicht das was noch nicht 
übersetzt ist.

von Michael H. (micha_22)


Lesenswert?

Kilo S. schrieb:
> Aber wenn MIR jeder nur Teile des kontext hinwirft, kann ich nicht dazu
> lernen.

Dass du etwas lernen möchtest, schreibst du doch jetzt zum ersten Mal? 
Bislang war doch die Rede davon, dass du Hilfe benötigst um Infos an 
eure Expertengruppe weiterzugeben.

Quasi eine Art Koordinator.

Kilo S. schrieb:
> Aber wenn du meinst du seiest so viel besser... zeig doch mal deinen
> übersetzten Code aus dem dissasembly.

Ich finde deine Reaktion jetzt sehr unfair. Dieter hat dir ziemlich 
viele Infos geliefert, sogar eine komplett gepatchte Firmware gebaut...

Worauf möchtest du eigentlich hinaus? Was ist dein Ziel?

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Beim Reverse-Engineering ist Erfahrung entscheidend, das wurde hier 
schon geschrieben. Und auch dass das dazu verwendete Tool Nebensache 
ist.

Wenn man einsteigen will gibt es genügend Tutorials im Netz und einige 
Bücher zu der Thematik. Damit muss man sich dann aber auch selber 
beschäftigen und bereit sein viel Zeit zu investieren. Die jeweiligen 
Assembler Befehle der Ziel-CPU lernt man aus der entsprechenden Doku, 
auch das muss man selber machen.

Es gibt auch Kurse über mehrere Tage, die setzten aber meistens voraus 
dann man zumindest grundlegende Assembler Kenntnisse hat.

Und man sollte natürlich auch grundlegende Kenntnisse im Programmieren 
haben, man will ja herausfinden was ein Binary macht und das wurde von 
jemandem programmiert.

Als ganz einfacher Einstieg kann man sich ja z.B. das Assembler Listing 
ansehen dass ein Compiler aus bekanntem Code erzeugt (dabei am Anfang 
die Optimierungen des Compiler abschalten). Damit sollte man 
einigermaßen klar kommen bevor man weitermacht.

von Dieter S. (ds1)


Lesenswert?

Hier sind nochmal die undokumentierten Register des BK4819 wie sie von 
der Firmware des RT-890 bei der Initialisierung gesetzt werden. Ergänzt 
sind die Werte, die nach dem Reset im entsprechenden Register stehen:
1
// RT-890 and UV-K5 (maybe AGC related ?)
2
3
BK4819_WriteRegister(0x49, 0x2A38); // after reset: 0x2830
4
BK4819_WriteRegister(0x7B, 0x8420); // after reset: 0xAE34
5
6
// RT-890
7
8
BK4819_WriteRegister(0x1E, 0x4C58); // after reset: 0x4C51
9
BK4819_WriteRegister(0x2A, 0x4F18); // after reset: 0x4711
10
BK4819_WriteRegister(0x53, 0xE678); // after reset: 0xE66C
11
BK4819_WriteRegister(0x2C, 0x5705); // after reset: 0x5B05
12
BK4819_WriteRegister(0x4B, 0x7102); // after reset: 0x7100
13
BK4819_WriteRegister(0x77, 0x88EF); // after reset: 0xA8FF
14
BK4819_WriteRegister(0x26, 0x13A0); // after reset: 0x33B0

von Kilo S. (kilo_s)


Lesenswert?

Michael H. schrieb:
> Ich finde deine Reaktion jetzt sehr unfair.

Findest du?

Nun, es ging mir hier nicht darum eine fertige Firmware zu bekommen 
sondern den Sourcecode davon.

Natürlich ist es nett das er sich die mühe macht und eine gepachte 
version bereit stellt.

Michael H. schrieb:
> Dass du etwas lernen möchtest, schreibst du doch jetzt zum ersten Mal?
> Bislang war doch die Rede davon, dass du Hilfe benötigst um Infos an
> eure Expertengruppe weiterzugeben.

Du hast mitgelesen das ich aktuell in der Dev Gruppe des k5 bin und dort 
die richtigen Leute sitzen?

Oder auch das sich durch die gemeinsamen Eigenschaften des K5/890 die 
bereits für das k5 bestehende Firmware an das 890 anpassen lässt?

Und was das Lernen angeht, glaubst du die würden alles für einen zurecht 
machen? Ich muss anfangen das ganze selbst zu verstehen um später in der 
Lage zu sein Anpassungen nach meinen Vorstellungen vor zu nehmen.

Dieter S. schrieb:
> Hier sind nochmal die undokumentierten Register des BK4819 wie sie
> von der Firmware des RT-890 bei der Initialisierung gesetzt werden.
> Ergänzt sind die Werte, die nach dem Reset im entsprechenden Register
> stehen:
>
> // RT-890 and UV-K5 (maybe AGC related ?)
>
> BK4819_WriteRegister(0x49, 0x2A38); // after reset: 0x2830
>
> BK4819_WriteRegister(0x7B, 0x8420); // after reset: 0xAE34
>
> // RT-890
>
> BK4819_WriteRegister(0x1E, 0x4C58); // after reset: 0x4C51
>
> BK4819_WriteRegister(0x2A, 0x4F18); // after reset: 0x4711
>
> BK4819_WriteRegister(0x53, 0xE678); // after reset: 0xE66C
>
> BK4819_WriteRegister(0x2C, 0x5705); // after reset: 0x5B05
>
> BK4819_WriteRegister(0x4B, 0x7102); // after reset: 0x7100
>
> BK4819_WriteRegister(0x77, 0x88EF); // after reset: 0xA8FF
>
> BK4819_WriteRegister(0x26, 0x13A0); // after reset: 0x33B0

Ein Datenblatt das diese register und ihre Funktion erklärt fehlt 
allerdings noch.

Dieter S. schrieb:
> Als ganz einfacher Einstieg kann man sich ja z.B. das Assembler Listing
> ansehen dass ein Compiler aus bekanntem Code erzeugt (dabei am Anfang
> die Optimierungen des Compiler abschalten). Damit sollte man
> einigermaßen klar kommen bevor man weitermacht.

Mache ich zwischendurch, mit jedem versuch eigene Codes zu analysieren 
wird es auch bei der Firmware des radtel besser. Trotzdem kommt da immer 
noch genug Mist bei raus.

Daher wäre es fürs Lernen hilfreich wenn ich mein disassembly mit dem 
von anderen vergleichen könnte.

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Ein Datenblatt das diese register und ihre Funktion erklärt fehlt
> allerdings noch.

Und das Datenblatt dazu soll ich bei Beken für Dich besorgen?

Durch den Vergleich der Werte nach dem Reset und den neu geschriebenen 
Werten sieht man ganz gut wo z.B. nur einzelen Bits geändert werden 
(etwa bei 0x7100 und 0x7102 in Register 0x4B).

Und wie schon weiter oben geschrieben, man könnte die unterschiedliche 
Initialisierung einfach mal in die nachprogrammierte Firmware des UV-K5 
einbauen und schauen wie sich das Gerät danach verhält.

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Und wie schon weiter oben geschrieben, man könnte die unterschiedliche
> Initialisierung einfach mal in die nachprogrammierte Firmware des UV-K5
> einbauen und schauen wie sich das Gerät danach verhält.

Machen Sie doch bereits.

Dieter S. schrieb:
> Und das Datenblatt dazu soll ich bei Beken für Dich besorgen?

Das Datenblatt hab ich bereits angehangen. Sowohl von CPU als auch den 
beiden BK und dem des Flash.
Sogar eine "Secret programming guide" der in der russischen Gruppe dabei 
war.

Aber das des BK ist nun mal nicht vollständig.

Sollte dir also mal ein DB in vollständig zulaufen, fur den 4819, wäre 
es echt nett wenn du das hier hochladen könntest.

: Bearbeitet durch User
von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Machen Sie doch bereits.

Ich beziehe mich auf diesen Link (siehe auch weiter oben):

https://github.com/DualTachyon/uv-k5-firmware

Die Initialisierung der undokumentierten Regiser wie beim RT-890 wird im 
aktuellen Master-Branch nicht gemacht.

Wenn ihr aber schon eine andere Fimware für das UV-K5 mit diesen 
Änderungen gemacht habt: merkt man einen Unterschied durch diese 
Initialisierung?

: Bearbeitet durch User
von Alexander (alecxs)


Lesenswert?

Kilo S. schrieb:
> Michael H. schrieb:
>> Ich finde deine Reaktion jetzt sehr unfair.
>
> Findest du?
>
> Nun, es ging mir hier nicht darum eine fertige Firmware zu bekommen
> sondern den Sourcecode davon.

Ist noch schwerer, merkste selber.

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Wenn ihr aber schon eine andere Fimware für das UV-K5 mit diesen
> Änderungen gemacht habt: merkt man einen Unterschied durch diese
> Initialisierung?

Da kann ich nix zu sagen.

Ich habe kein K5, durchgesickert ist noch nicht wirklich was.

Dieter S. schrieb:
> Die Initialisierung der undokumentierten Regiser wie beim RT-890 wird im
> aktuellen Master-Branch nicht gemacht.

Wie gesagt, keine ahnung wann das kommt. Es befassen sich ja mehrere 
leute damit und wann was getestet wird bekommt man nur am rande mit.

Alexander schrieb:
> Ist noch schwerer, merkste selber.

Für uns ja...

Du hättest dabei sein müssen um zu erleben wie schnell das Binary 
zerlegt wurde.
Die ersten Funktionen haben nach kürzester Zeit schon Namen bekommen 
usw.

Kurz drauf entstand der updater mit "patch" um über die serielle 
Schnittstelle den kompletten Inhalt des MCU zu dumpen.
Und seit zwei Tagen ist mein Gerät nun "offen" und per SWD ein mal neu 
geflasht. Noch mit der originalen Firmware.

Alles funktioniert bisher reibungslos.

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
>
> Kurz drauf entstand der updater mit "patch" um über die serielle
> Schnittstelle den kompletten Inhalt des MCU zu dumpen.

Der dazu nötige Patch ist fast schon trivial: Es gibt eine Funktion, die 
beim Lesen der Geräte-Einstellungen einen Datenblock zum PC per UART 
sendet. Wenn man die Parameter des Funktionsaufruf (Adresse der Daten 
sowie Anzahl Bytes) entsprechend patcht kann man einen beliebigen 
Speicherbereich anstelle der Geräte-Einstellungen übertragen.

Ein kleines Problem ist dass die Funktion bei der Länge auf die unteren 
8 Bit kürzt, das löst ein weitere Patch.

So wurde der Bootloader der Firmware ausgelesen (siehe weiter oben).

Nachtrag: Wer das selber nachvollziehen will: Die IO Adresse für die 
USART1 wird in der RT-890 Firmware in vier Funktionen referenziert. Eine 
ist der USART Interrupt, zwei sind für die USART Initialisierung 
zuständig und die letzte gibt genau ein Byte per USART aus. Die Funktion 
zum Senden eines Bytes wird sieben mal referenziert, eine Funktion davon 
gibt mehrere Bytes auf einmal aus. Und da die Doku des AT32F421 
öffentlich ist (abgesehen davon dass es ein STM32 Klon ist) kann man die 
Funktionsweise der USART auch problemlos verstehen.

: Bearbeitet durch User
von Michael H. (micha_22)


Lesenswert?

Kilo S. schrieb:
> Nun, es ging mir hier nicht darum eine fertige Firmware zu bekommen
> sondern den Sourcecode davon.

Dir ist aber schon bewusst, dass er das Binary nur durch einen 
Disassembler gejagt hat und dessen Ergebnis (Assembler) mit einem 
klassischen Quellcode einer Hochsprache wie C wenig zu tun hat?

Also woher soll er den Quellcode denn haben?

Kilo S. schrieb:
> Ein Datenblatt das diese register und ihre Funktion erklärt fehlt
> allerdings noch.

Auch die kann er sich nicht aus dem Ärmel zaubern. Er hat zumindest von 
den undokumentierten Registern berichtet und einen Vorschlag gemacht um 
deren Funktion zu prüfen.

Kilo S. schrieb:
> Das Datenblatt hab ich bereits angehangen. Sowohl von CPU als auch den
> beiden BK und dem des Flash.

Nun, dann schau doch du nach ob dir Register dort aufgeführt sind. Wenn 
nicht, dann sind so wohl "undokumentiert".

Alexander schrieb:
> Ist noch schwerer, merkste selber.

Ich wäre mir da nicht so sicher, dass er das merkt. Die Anspruchshaltung 
ist schon grandios. Ich finde Dieter hat super geholfen, soweit das 
möglich ist.

von Dieter S. (ds1)


Lesenswert?

Noch mal allgemein zum Reverse-Engineering: Es ist meistens ein sehr 
großer Aufwand bis man das vollständige Assembler Listing (bzw. 
Dekompilat wenn man einen Decompiler verwendet) wieder in ein Binary 
übersetzten kann dass dann auch tatsächlich funktioniert (abgesehen 
vielleicht von ganz kurzen oder trivialen Beispielen).

Kleine Änderungen an einem bereits vorhandenen Binary ("Patches") sind 
dagegen deutlich einfacher. Manchmal muss danach eine Prüfsumme/CRC 
anpassen, im Fall der RT-890 Firmware gibt es aber keine Prüfung.

von Kilo S. (kilo_s)


Lesenswert?

Michael H. schrieb:
> Dir ist aber schon bewusst, dass er das Binary nur durch einen
> Disassembler gejagt hat und dessen Ergebnis (Assembler) mit einem
> klassischen Quellcode einer Hochsprache wie C wenig zu tun hat?

Ghidra zeigt dir Beispielsweise direkt einen "pseudo code" an.

Und nicht nur Assembler!
Klar ist das nicht vollständig und vor allem nicht ausführbar.
Aber wie ich bereits sagte, es gibt Leute die das deutlich schneller 
zurück übersetzen können als andere.

Michael H. schrieb:
> Ich finde Dieter hat super geholfen, soweit das möglich ist.

Hat er, ist schon richtig, alerdings wäre es noch hilfreicher wenn ich 
den code den er aus dem binary übersetzen konnte, sehen könnte.

Dieter S. schrieb:
> Noch mal allgemein zum Reverse-Engineering:

Ich suche sie ganz zeit nach einem SVD file für die AT32F4xx Familie 
hast du zufällig eine Bezugsquelle?

von Alexander (alecxs)


Lesenswert?

Der gängige Weg ist dass man sich in Ghidra die Offsets raus sucht und 
die Binärdatei hexeditiert. Ich glaube nicht dass er dazu einen 
brauchbaren Code rekonstruieren musste.

von Dieter S. (ds1)


Lesenswert?

Alexander schrieb:
> Der gängige Weg ist dass man sich in Ghidra die Offsets raus sucht und
> die Binärdatei hexeditiert. Ich glaube nicht dass er dazu einen
> brauchbaren Code rekonstruieren musste.

Ja, dazu brauche ich keinen Decompiler, es reicht das Disassembly. Und 
wer bei "RT-890_V1_34_patched1" wissen will was gepatched wurde: Der 
Vergleich mit der original Firmware ist trivial, das kann sogar Windows 
("fc /b", "fc" gibt es seit MS-DOS). Dann kommen ein paar Offsets raus, 
damit kann man sich das im Disassembly selber ansehen.

Abgesehen davon: der TO scheint hier hauptsächlich Forderungen zu 
stellen und erwartet dass irgendwer die Arbeit für ihn macht. Und selbst 
die Suchmaschine kann/will er nicht bedienen. SVD Dateien gibt es u.a. 
hier:

https://gitee.com/RT-Thread-Studio-Mirror/sdk-csp-at32f4/tree/master/debug/svd

von Kilo S. (kilo_s)


Lesenswert?

Alexander schrieb:
> Ich glaube nicht dass er dazu einen brauchbaren Code rekonstruieren
> musste.

Das macht er aber.

Du musst das so sehen, K5 und 890 haben neben den gemeinsamkeiten (BK 
IC's) natürlich auch Unterschiede.

Also schaut er sich erst mal an was radtel da gemacht hat.

von Dieter S. (ds1)


Lesenswert?

Kilo S. schrieb:
> Alexander schrieb:
>> Ich glaube nicht dass er dazu einen brauchbaren Code rekonstruieren
>> musste.
>
> Das macht er aber.

Und wieder eine Deiner Behauptungen die falsch ist. RT-890 und UV-K5 
haben vom Aufbau der Firmware her wenig gemeinsam, ausser dass sie die 
selbe RF Hardware verwenden. Wenn man das nicht sieht macht man solche 
Fehler wie nach einer Bereichsgrenze in der Firmware zu suche, die es 
beim RT-890 gar nicht gibt.

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Und selbst die Suchmaschine kann/will er nicht bedienen.

Wenn du meinst!

Ih bekomme bei der Suche zwei Sachen angzeigt: die Hauptspeise von 
artery zum MCU und der link zu einer AN0028.

Nirgendo dort gab es bisher ein Hinweis wie de SVD für diese Familie zu 
finden ist.

Dieter S. schrieb:
> SVD Dateien gibt es u.a. hier:
> https://gitee.com/RT-Thread-Studio-Mirror/sdk-csp-at32f4/tree/master/debug/svd

Tja, frag mich nicht wieso google mir die links nicht ausgespuckt hat.

Egal ob "Atery AT32F4 SVD, AT32F421 SVD..." usw. als suchbegriffe.
Sämtliche andere Software inklusive programmbeispiele habe ich finden 
können.

von Alexander (alecxs)


Lesenswert?

Man kann nicht die Gesamtheit aller Informationen in Suchergebnissen 
darstellen, dass ist immer nur ein Bruchteil dessen was gefunden wird. 
Suchmaschinen filtern gemäß deiner Werbe-ID. Es ist logisch dass Dieter 
mehr Treffer bekommt als Du. Aber dazu haben wir ja dieses Forum. Es 
gibt hier genug Spezialisten.

von Kilo S. (kilo_s)


Lesenswert?

Alexander schrieb:
> Suchmaschinen filtern gemäß deiner Werbe-ID. Es ist logisch dass Dieter
> mehr Treffer bekommt als Du. Aber dazu haben wir ja dieses Forum.

Deswegen finde ich den Vorwurf ich würde selbst nicht suchen ganz schön 
mies!

Würde ich nicht suchen, gäbe es diesen Beitrag überhaupt nicht.

Die updater sind nicht öffentlich verfügbar!

https://www.radtels.com/pages/software-download

Bei iradio bekommt man nicht mal ein CPS für das baugleiche UV-58 Plus.

: Bearbeitet durch User
von Oliver S. (oliverso)


Lesenswert?

Alexander schrieb:
> Man kann nicht die Gesamtheit aller Informationen in
> Suchergebnissen
> darstellen, dass ist immer nur ein Bruchteil dessen was gefunden wird.
> Suchmaschinen filtern gemäß deiner Werbe-ID. Es ist logisch dass Dieter
> mehr Treffer bekommt als Du. Aber dazu haben wir ja dieses Forum. Es
> gibt hier genug Spezialisten.

Das ist eine dieser unausrottbaren urban legends. Wenn überhaupt, gibt 
es vielleicht leichte Unterschiede in der Reihenfolge, gefunden und 
angezeigt wird aber immer alles.

Oliver

von Kilo S. (kilo_s)


Lesenswert?

Oliver S. schrieb:
> Wenn überhaupt, gibt es vielleicht leichte Unterschiede in der
> Reihenfolge, gefunden und angezeigt wird aber immer alles.

Wurde es nicht.

Zwei links, mehr hat google nicht ausgespuckt

von Oliver S. (oliverso)


Lesenswert?

Kilo S. schrieb:
> Oliver S. schrieb:
>> Wenn überhaupt, gibt es vielleicht leichte Unterschiede in der
>> Reihenfolge, gefunden und angezeigt wird aber immer alles.
>
> Wurde es nicht.
>
> Zwei links, mehr hat google nicht ausgespuckt

Was dann einfach daran liegt, daß es nicht mehr gibt, aber nicht daran, 
daß Google dich über deine Werbe-ID als „Noob“ einstuft.

Oliver

von Dieter S. (ds1)


Angehängte Dateien:

Lesenswert?

Siehe Bild, das zeigt mir "meine" Suchmaschine bei "AVRE32 SVD", 
markiert ist der interessante Bereich.

Mein Browser speichert keine Daten zwischen den Sitzungen, sonst gibt es 
keine besonderen Maßnahmen für Anonymität.

von Alexander (alecxs)


Lesenswert?

Oliver S. schrieb:
> Was dann einfach daran liegt, daß es nicht mehr gibt, aber nicht daran,
> daß Google dich über deine Werbe-ID als „Noob“ einstuft.

Das hat auch keiner behauptet.

Beitrag "Re: Zensiert Google bestimmte Begriffe?"

von Kilo S. (kilo_s)


Lesenswert?

Dieter S. schrieb:
> Siehe Bild, das zeigt mir "meine" Suchmaschine bei "AVRE32 SVD",
> markiert ist der interessante Bereich.

Jetzt kommen wir der Sache näher!

Ich hab nur nach AT32F2/AT32F421 SVD gesucht. Mit und ohne Hersteller 
dazu usw..

Oliver S. schrieb:
> Was dann einfach daran liegt, daß es nicht mehr gibt, aber nicht daran,
> daß Google dich über deine Werbe-ID als „Noob“ einstuft.

Davon bin ich auch nicht ausgegangen.

Wie du siehst lag es scheinbar am suchbegriff.

Nach dem ds nun abgehakt ist...

Ich kann euch versichern das mir mühe gebe so viel wie möglich selbst zu 
finden.

Wer der hier beteiligten hat den ein RT-890 in Besitz?

: Bearbeitet durch User
von Kilo S. (kilo_s)


Lesenswert?

Völlig vergessen...

Bin Sei einigen Tagen damit am Spielen: 
https://github.com/DualTachyon/radtel-rt-890-oefw

von Kilo S. (kilo_s)


Lesenswert?

Einige von euch müssen sich ja echt "geknickt" vorkommen...
Ihr habt trotzdem einen Anteil an diesem Ergebniss!

Nuja, "ER" war euch wohl einen vorraus. Die kurze Zeit die das ganze 
brauchte...

Jedenfalls gibt es hier nun das Ergebniss einer mehr oder weniger 
seltsamen Kooperation.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.