Vraag:
Zoek de C ++ STL-functies in een binair bestand
m4524t
2014-03-17 21:36:44 UTC
view on stackexchange narkive permalink

Ik heb een binair bestand (eigenlijk een besturingssysteem voor een ARM-ingebed apparaat dat ook enkele apps op hoog niveau bevat (hard gecodeerd in de gebruikersinterface)).

Ik ken sommige delen van de besturingssysteem zijn van C ++ - code, dus het is waarschijnlijk dat het binaire bestand de C ++ STL bevat.

Ik weet echter niet veel over de STL.

Zou je een methode hebben om vind het adres van de STL-functies? (de basismethode voor het zoeken naar de "map", "vector", ... string was niet succesvol en ik ken geen specifiek kenmerk waarnaar ik in dit geval zou kunnen zoeken)

Is er een soort handtekening voor de STL-functies?

Bedankt!

Aanvullende informatie: ik gebruik IDA. Ik kan het besturingssysteem draaien met een GDB. Ik ken het adres van veel van de standaard C-functies (ctype / stddio / ...).

* Wat * is het besturingssysteem? Waarom denk je dat het C ++ gebruikt (in tegenstelling tot gewone C), en zelfs als dat zo is, waarom denk je dat het STL gebruikt?
@JasonGeffner: IDA doet dit altijd als ik uitvoerbare x86-bestanden demonteer. In dit geval (is het omdat het ARM is? Ik weet het niet.), IDA heeft geen enkele standaardfunctie gevonden.
@IgorSkochinsky: Het besturingssysteem is een eigen besturingssysteem (gebaseerd op Nucleus OS). Ik zou wel willen, maar ik kan je de naam niet geven. Het gebruikt C ++ omdat er enkele C ++ -structuren overblijven als debug-strings. Ik heb geen idee of het echt STL gebruikt, maar als dat niet het geval is, wil ik er zeker van zijn.
Een antwoord:
Igor Skochinsky
2014-03-17 22:29:11 UTC
view on stackexchange narkive permalink

Bibliotheken zoals STL of Boost zijn lastig. Omdat ze sterk op sjablonen zijn gebaseerd en de meeste code wordt gegenereerd tijdens het compileren, is het vrij moeilijk om handtekeningen in FLIRT-stijl voor hen te maken. Te veel hangt af van de specifieke compiler, build-opties, optimalisatie-instellingen enzovoort, dus tenzij je ze behoorlijk goed op elkaar afstemt bij het genereren van handtekeningen, is het onwaarschijnlijk dat je veel goede hits krijgt.

enkele tekenen ervan kunnen vinden. De typische std :: string -implementatie genereert in sommige gevallen uitzonderingen length_error of out_of_range . Mogelijk vindt u verwijzingen naar de fouttekst of de namen van uitzonderingen. Afgezien daarvan denk ik dat er niet veel is waar je naar kunt zoeken behalve het herkennen van een specifieke implementatie uit de eigenlijke code.

Maar aangezien je zegt dat het een RTOS is, betwijfel ik sterk dat het STL gebruikt. In een besturingssysteem is elk niet-deterministisch gedrag een slechte zaak, en met STL kun je in principe op elk moment een uitzondering krijgen. Ze kunnen wat beperkte C ++ gebruiken voor een betere inkapseling, maar alle klassen op hoog niveau zijn waarschijnlijk op maat gemaakt en niet van STL of Boost.

Misschien had ik er duidelijker over moeten zijn. Omdat het op een ingebed apparaat staat, bevat het besturingssysteem ook de hele gebruikersinterface en een soort "apps" die hard gecodeerd zijn in de gebruikersinterface. Het lage niveau van het besturingssysteem is in C / assembly.
Oké, in dat geval is het aannemelijk dat het UI-gedeelte in C ++ wordt gedaan. Maar dat is nog steeds geen garantie dat het STL gebruikt.
Ja, van het weinige dat ik weet van embedded ontwikkeling, gebruiken ze zelden sjablonen, en als ze wel een STL gebruiken / hebben, is het waarschijnlijk een geknipte / geoptimaliseerde (d.w.z. niet je standaard g ++ STL).
Het andere dat dit moeilijk maakt, is dat veel STL- / sjablooncode inline wordt gegenereerd, dus er zijn zelfs geen functieaanroepen om te labelen ...
Ik heb geprobeerd te zoeken naar tekenreeksen die verband houden met de twee uitzonderingen die u hebt opgegeven. Geen van deze heeft te maken met STL. Je hebt dus zeker gelijk. Er is waarschijnlijk geen "standaard" STL (of het kan een versie zijn zonder een specifieke functie). Bedankt allemaal!


ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...