Firmware Fn Draw ElectronicHorizon - krcenov/RNS510-Map-Viewer GitHub Wiki
Draw — ElectronicHorizon::Draw
Part of Firmware Reversing.
- File offset:
0x81e070(VA0xf70abd64) — confirmed as the real entry point via a reliable source: a direct, already-verifiedlis/addicall site onregisterBlocking(CArr_DYNA_Main::registerBlocking), not a cold symbol-table lookup. - Status: 🟡* Partially traced — fully bounded (672 bytes,
0x81e070-0x81e384, clean matchingblr), 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 utilityDrawjumps into, not code written exclusively forDrawitself. See the caveat section at the bottom before trusting the "Net read" below too literally. - UPDATE, confirmed via real Hex-Rays decompilation:
0xf70abd64is reachable, real code, but is not itself a function entry point — IDA/Hex-Rays reports the real containing function actually starts at0xf70abaf4(file offset0x81de00), a different and slightly earlier address than the previously-documented "fallthrough source" (0x81dfcc). Decompiling from0xf70abaf4immediately hits aJUMPOUTto0xf70abafc— 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 including0x09-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 asDraw'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.