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".
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
Angehängte Dateien:
-
IMG_20230825_114114.jpg
240 KB
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?
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!
Angehängte Dateien:
Rüdiger B. schrieb: > Das ERSTE was wichtig ist: WELCHE CPU? Moment! Info kommt gleich. AT32F421C8T7 Bild anbei.
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.
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.
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.
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
Angehängte Dateien:
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.
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.
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.
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
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.
Hoffentlich auch den richtigen gefunden: https://pdf1.alldatasheet.com/datasheet-pdf/view/1656401/PUYA/P25Q32H.html
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
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
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
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.
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.
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 :)
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.
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.
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.
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"
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!
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.
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.
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?
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
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.
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.
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
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.
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
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
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.
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.
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!
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.
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!
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 !
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.
schon mal über eine entsprechende Bezahlung nachgedacht bevor Du Dich darüber auskotzt?
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.
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.
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.
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.
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.
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.
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.
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.
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!
Tja, neues vom Radtel. Flash protekt ist an, SWD funktioniert nicht so recht deshalb. Aber wir haben ein komplettes dump. Bald geht es weiter.
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.
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. ;-)
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).
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.
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!
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!
Das habe ich schon verstanden. Ich dachte nur, dass es vielleicht auch da eine Hintertür geben könnte.
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.
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!
Dieter S. schrieb: > Falls sich jemand den Bootloader des RT-890 selber ansehen will: siehe > Anhang. Hmm. Bist dir da auch wirklich sicher?
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).
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?!
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.
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.
Angehängte Dateien:
-
RT-890.JPG
160 KB -
UV-K5.JPG
190 KB
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.
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.
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.
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".
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!
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 |
Kilo S. schrieb: > Michael H. schrieb: >> Dieter S. zerlegt gerade eure Experten Gruppe. > > Ähm, nein! Wohl! 😂😂 verbreitet schon Kurzweil.
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.
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?
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.
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.
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
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.
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.
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.
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.
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.
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?
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 |
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.
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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
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
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.
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.
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.
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.
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.
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
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
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
Angehängte Dateien:
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.
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?"
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?
Völlig vergessen... Bin Sei einigen Tagen damit am Spielen: https://github.com/DualTachyon/radtel-rt-890-oefw
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.