Firmware Fn getId

getId — CfcMsgStreamedServicePoint::getId

Part of Firmware Reversing.

• File offset: 0x815a80
• VA: 0xf70a3774 (= 0x815a80 + 0xf688dcf4)
• Status: 🟢 Fully traced (prologue to blr)
• Real name source: symbol/EH-descriptor table, field 4, exact match

History

Originally found and disassembled via the string "findSegIndex", which this function's own code happens to compute the address of internally — it was called "the findSegIndex-referencing function" for a while. This was a misattribution, corrected once the real symbol table was found and parsed: the table's own record for this exact address gives the name getId__C26CfcMsgStreamedServicePoint. "findSegIndex" was never this function's name — almost certainly an internal debug-trace tag for one step of its own algorithm. This is also the concrete example proving a general rule: a function's own string references tell you nothing reliable about its identity; only the symbol table's own name field does.

Disassembly

0x815a80: stwu     r1, -0x60(r1)
0x815a84: mflr     r0
0x815a88: stw      r29, 0x54(r1)
0x815a8c: stw      r30, 0x58(r1)
0x815a90: stw      r31, 0x5c(r1)
0x815a94: stw      r0, 0x64(r1)
0x815a98: mr       r29, r4
0x815a9c: stw      r5, 0x10(r1)
0x815aa0: lwz      r9, 0(r29)
0x815aa4: lwz      r0, 0(r29)
0x815aa8: stw      r6, 0x14(r1)
0x815aac: cmpw     r9, r0
0x815ab0: stw      r3, 0x1c(r1)
0x815ab4: stw      r9, 0x20(r1)
0x815ab8: beq      0x815ac4
0x815abc: li       r3, -5
0x815ac0: b        0x815b80
0x815ac4: lis      r9, -0x8ba
0x815ac8: addi     r30, r1, 0x10
0x815acc: addi     r9, r9, 0x2d98
0x815ad0: lis      r4, -0x872
0x815ad4: mtlr     r9
0x815ad8: addi     r4, r4, 0x31cc
0x815adc: mr       r3, r30
0x815ae0: li       r5, 0x38
0x815ae4: li       r0, 0
0x815ae8: stw      r0, 0x34(r1)
0x815aec: stw      r0, 0x30(r1)
0x815af0: blrl
0x815af4: or.      r31, r3, r3
0x815af8: mr       r3, r31
0x815afc: bne      0x815b80
0x815b00: lis      r9, -0x8ba
0x815b04: addi     r0, r9, 0x2fb8
0x815b08: mr       r3, r30
0x815b0c: mtlr     r0
0x815b10: li       r4, 4
0x815b14: blrl
0x815b18: mr       r31, r3
0x815b1c: cmpwi    r31, 1
0x815b20: beq      0x815b64
0x815b24: lis      r9, -0x8ba
0x815b28: addi     r0, r9, 0x4968
0x815b2c: mr       r3, r30
0x815b30: mtlr     r0
0x815b34: blrl
0x815b38: cmpwi    r31, 2
0x815b3c: beq      0x815b54
0x815b40: cmpwi    r31, -5
0x815b44: bne      0x815b5c
0x815b48: lwz      r0, 0x14(r1)
0x815b4c: cmpwi    r0, 0
0x815b50: bne      0x815b5c
0x815b54: li       r3, -3
0x815b58: b        0x815b80
0x815b5c: mr       r3, r31
0x815b60: b        0x815b80
0x815b64: lwz      r0, 0x24(r1)
0x815b68: lis      r9, -0x8ba
0x815b6c: stw      r0, 0(r29)
0x815b70: mr       r3, r30
0x815b74: addi     r0, r9, 0x4968
0x815b78: mtlr     r0
0x815b7c: blrl
0x815b80: lwz      r0, 0x64(r1)
0x815b84: mtlr     r0
0x815b88: lwz      r29, 0x54(r1)
0x815b8c: lwz      r30, 0x58(r1)
0x815b90: lwz      r31, 0x5c(r1)
0x815b94: addi     r1, r1, 0x60
0x815b98: blr

Analysis

Same argument pointer read twice (0x815aa0/0x815aa4), compared to itself — always true, a defensive/paranoid-check idiom, not a bug. Constructs a 0x38-byte local C++ object (0x815ac4-0x815af0: explicit vtable pointer via mtlr + a size argument 0x38 + blrl = a virtual "constructor" call), then calls 2-3 more virtual methods on it, checking the returned integer (r31) against {1, 2, -5} — a real iterator/container "find" pattern. Writes a result into *arg2 (0x815b6c: stw r0, 0(r29), an out-parameter) on the success path, then makes one more virtual call (cleanup?) before the shared epilogue at 0x815b80.

This operates on already-in-memory C++ objects, not raw on-disk bytes — it does not explain the topology link-id values' on-disk encoding (the original motivating map-format question). Real, but orthogonal to that goal.

Caller

Not found. 3 independent methods tried across the full 24MB region (bl scan, lis/addi absolute-load scan) plus a whole-file literal-pointer scan — genuine dead end, not for lack of trying.