Firmware Fn Draw ElectronicHorizon - krcenov/RNS510-Map-Viewer GitHub Wiki

Draw — ElectronicHorizon::Draw

Part of Firmware Reversing.

  • File offset: 0x81e070 (VA 0xf70abd64) — confirmed as the real entry point via a reliable source: a direct, already-verified lis/addi call site on registerBlocking (CArr_DYNA_Main::registerBlocking), not a cold symbol-table lookup.
  • Status: 🟡* Partially traced — fully bounded (672 bytes, 0x81e070-0x81e384, clean matching blr), but with a real stack-frame allocation (stwu r1,-0x30(r1)) appearing PARTWAY through rather than at the very start. Important: this address is also reached as the ordinary fallthrough continuation of a different, separate function (0x81dfcc, see Callees below) — meaning the logic described here is most likely a shared tag-scanning utility Draw jumps into, not code written exclusively for Draw itself. See the caveat section at the bottom before trusting the "Net read" below too literally.
  • UPDATE, confirmed via real Hex-Rays decompilation: 0xf70abd64 is reachable, real code, but is not itself a function entry point — IDA/Hex-Rays reports the real containing function actually starts at 0xf70abaf4 (file offset 0x81de00), a different and slightly earlier address than the previously-documented "fallthrough source" (0x81dfcc). Decompiling from 0xf70abaf4 immediately hits a JUMPOUT to 0xf70abafc — i.e. real control flow escapes almost immediately, consistent with this whole region being one larger, still only partially mapped function rather than two small cooperating ones as previously framed.
  • Full mangled name: Draw__17ElectronicHorizonRC8MapPoint

Real, confirmed behavior

A genuine, self-contained runtime tag/markup parser — not a geometry-drawing routine in the literal sense its name might suggest. Scans a string character-by-character (lbzu/lbz with extsb, a classic byte-by-byte string-scan idiom), explicitly checking for the literal characters 'X'/'x', 'M'/'m', 'L'/'l' in sequence (case-insensitive) — i.e. detecting the literal tag/attribute name XML (or xml) at the very start of its real logic. Continues scanning for a '>' (0x3e) tag terminator, handles multi-character lookahead (checking for several different fixed-length attribute-name candidates via small jump-table-like byte-value comparisons), and calls one real, confirmed LOCAL function via a direct relative branch (bl 0x81dfcc — a guaranteed-correct target, no relocation needed to resolve it, unlike most calls on this wiki) partway through.

Net read

ElectronicHorizon::Draw(const MapPoint&) almost certainly doesn't draw raw pixels/vectors itself — it parses an XML-like markup string associated with the given MapPoint (plausibly an icon/symbol description, or a styling/attribute string attached to electronic- horizon point data) as its first real step, looking for tag boundaries and named attributes, before presumably dispatching to real drawing logic based on what it finds (not reached in the traced portion). This is a genuinely unusual, concrete design detail for a real-time automotive ADAS display feature — using a small embedded markup parser rather than a fixed, compiled-in icon table.

Callees

  • 0x81dfcc (direct relative call) — traced. Turns out to be another real, separate piece of logic (character-range classification — checks a scanned byte against ranges including 0x09-0x0a/0x15/ 0x1e, consistent with whitespace/control-character detection in a tokenizer) that itself falls straight through, via ordinary execution, into the exact same address (0x81e070) this page documents as Draw's own entry point.

Important caveat, found while tracing the callee above

0x81e070 is reached TWO different ways: directly, via registerBlocking's own confirmed call (what this page is built on), AND as the natural fallthrough continuation of 0x81dfcc's own character-classification logic. This means 0x81e070 is most likely a shared, reused tag-scanning utility rather than code written specifically as ElectronicHorizon::Draw's own exclusive body — the real Draw may just be a thin wrapper whose whole job is to jump into this shared utility. This is consistent with (and adds a THIRD concrete, traced example to) the broader "fragments of a few larger structures, not independently-broken small functions" phenomenon documented on Firmware Reversing — not chased further, flagged honestly rather than overclaimed.