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".
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".
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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"
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.
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.
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.
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?
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.
Ä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.
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.
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 :)
Ä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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. ;-)
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).
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!
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.
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).
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.
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.
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.
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.
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".
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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:
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.
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.
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.
