Ik ben onlangs begonnen met het reverse engineeren van de firmware, en daar kom ik toch wel dingen tegen die me een beetje verontrusten. Met name in de remote control deel mis ik allerlij input validatie en boundery checks die er toe kunnen leiden dat andere delen van het geheugen overschreven worden(memory corrupties).
Dit is een voorbeeld dat ik ook ergens anders gedeeld heb:
Dit is de functie die gebruikt word om het serial repsonse buffer leeg te maken, het buffer dat gebruikt word voor de data die terug gestuurd word.
ROM:FFF8C154 SerialBuffOut_Zero: ; CODE XREF: Serial__CommandHandler
ROM:FFF8C154 mov.l #78h, r3
ROM:FFF8C157 mov.l #0, r2
ROM:FFF8C159 mov.l #8D8h, r1
ROM:FFF8C15F sstr.b
ROM:FFF8C161 rts
Dit vertaald zich vrij naar een memset operatie waarbij buffer(#8D8h) met een lengte van van 0x78 gewist word met 0 bytes.
memset(#8D8h, 0, 0x78)
Dus de response buffer heeft een maximale lengte van 0x78 bytes. Later in de code komen we een functie tegen die gebruikt word om data toe te voegen aan dat buffer(aan het einde van de bestaande data)
ROM:FFF8C162 SerialBuffOut_Append: ; CODE XREF: sub_FFF8BFA7+6
ROM:FFF8C162 mov.l r1, r14
ROM:FFF8C164 mov.l #0FFh, r3
ROM:FFF8C167 mov.l #0, r2
ROM:FFF8C169 mov.l #8D8h, r1
ROM:FFF8C16F suntil.b
ROM:FFF8C171 sub #1, r1
ROM:FFF8C173 mov.l r14, r2
ROM:FFF8C175 smovu
ROM:FFF8C177 rts
Wat deze functie doet, het zoekt de eerste 0 byte in het buffer(#8D8h) wat het einde van de bestaande data markeert en plakt daar achter de nieuwe string. Echter word hier een upperlimit van max. 0xFF gebruikt wat ver boven de max van het buffer(0x78) ligt en wat kan resulteren in, dat er in een ander deel van het geheugen geschreven word.
Dit zijn foutjes die best wel een amateuristisch gehalte hebben.