(Suunnittelin tehdä siitä kommentin, mutta se osoittautui melko pitkäksi ja se vastaa itse)

Jotkut kommentit mainitsivat Hex-Rays-dekompilaattorin. Sen perusideat eivät ole liikesalaisuus, ja ne on itse asiassa kuvattu Ilfak Guilfanovin valkoisessa kirjassa, joka liittyy hänen vuonna 2008 pitämään esitykseen. Liitän asiaankuuluvan osan tähän:

Paikallisen muuttujan allokointi

Tässä vaiheessa datavirran analyysi yhdistää rekisterit eri peruslohkoista niiden muuntamiseksi paikallisiksi muuttujat. Jos lohko määrittelee rekisterin ja toinen käyttää rekisteriä, luomme paikallisen muuttujan, joka kattaa sekä määritelmän että käytön. Toisin sanoen paikallinen muuttuja koostuu kaikista määritelmistä ja kaikista käyttötavoista, jotka voidaan yhdistää toisiinsa. Vaikka perusajatus on yksinkertainen, asiat monimutkaistuvat tavu- / sana- / sanasanarekistereiden takia.

Se on yksinkertainen pinnalta, mutta tietysti toteutuksessa on otettava huomioon lukuisia yksityiskohtia. Ja siellä on aina parantamisen varaa. Tässä on tämä kohta:

Toistaiseksi emme analysoi pinomuuttujien live-alueita (tämä vaatii ensin hyvän aliaksen analyysin: meidän on kyettävä osoittamaan, että pinomuuttuja ei ole kahden sijainnin välillä). Epäilen, että täysipainoinen live-alue-analyysi on saatavilla pinomuuttujille lähitulevaisuudessa.

Joten pinomuuttujien lähestymistapa on nyt yksinkertainen: kutakin pinopaikaa pidetään yhtenä muuttuja koko toiminnolle (joitain pieniä poikkeuksia lukuun ottamatta). Dekompilaattori luottaa tässä IDA: n työhön purkamisen aikana, jossa käskyn avulla luodaan pinoportti jokaiselle pääsylle.

Yksi nykyinen ongelma on useita nimiä samalle muuttujalle. Esimerkiksi kääntäjä voi tallentaa välimuistin pinon var rekisteriin, välittää sen jollekin toiminnolle ja ladata sen myöhemmin uudelleen toiseen rekisteriin. Dekompilaattorin on oltava tässä pessimistinen. Jos emme pysty osoittamaan, että sama sijainti sisältää saman arvon kahdessa ajankohdassa, emme voi yhdistää muuttujia. Esimerkiksi aina, kun koodi välittää muuttujan osoitteen puhelulle, dekompilaattorin on oletettava, että puhelu saattaa pilata mitä tahansa tämän osoitteen jälkeen. Joten vaikka rekisteri sisältää edelleen saman arvon kuin pino var, emme voi olla 100% varmoja. Siten muuttujien nimien ylimäärä. Käyttäjä voi kuitenkin ohittaa sen manuaalisella kartoituksella.

On joitain ideoita funktiomerkintöjen käyttöönotosta, jotka määrittelevät tarkalleen kuinka funktio käyttää ja / tai muuttaa argumenttejaan (samanlainen kuin Microsoftin SAL), mikä lievittäisi tätä ongelmaa , mutta siellä on joitain teknisiä toteutukseen liittyviä ongelmia.

Se, mitä kuvaat, on juuri se ongelma, jonka Gogul Balakrishnan käsitteli arvonmääritysanalyysiä koskevassa tohtorintyössään [1]. Erityisesti hän määrittelee x86-muistimallin käsitteiden kuten "abstraktit sijainnit". Tässä on hänen kuvaus tälle käsitteelle:

Kuten aiemmin todettiin, suoritettavilla tiedostoilla ei ole sisäisiä kokonaisuuksia, kuten lähdekoodimuuttujia, joita voidaan käyttää analyyseihin; siksi seuraava vaihe on palauttaa muuttujan kaltaiset entiteetit suoritettavasta tiedostosta. Kutsumme sellaisia ​​muuttujan kaltaisia ​​kokonaisuuksia kuin a-locs ("abstrakteja sijainteja").

Kuulostaako kysymyksestäsi tuttu? Sinun tulisi lukea tämä opinnäytetyö, vaikka varoitatkin, että - kuten useimmat abstraktista tulkintaa käsittelevät asiakirjat - se on suppea ja epäystävällinen lukeminen.

[1] http: //pages.cs.wisc. edu / ~ bgogul / Tutkimus / Opinnäytetyö / thesis.html

Soo ..... tämä on yksi syy siihen, että binaarinen analyysi on kova , semanttisen tiedon menetys. Muuttuja ei ole tietokonearkkitehtuurissa tunnettu käsite, se muistuttaa korkeampaa ymmärrystä.

Paras vastaus, jonka voin antaa sinulle, on, jos teet Compiler Output Analysis (mikä olet), voit etsiä käytäntöjä, joita kääntäjä käyttää muuttujien tallentamiseen, luultavasti rekisterien ja muuttuvan "vuotamisen" yhdistelmänä pinokehyksen paikkoihin.

Huono uutinen on se on kääntäjäriippuvainen. Hyvä uutinen on, että useimmat kääntäjät ovat enemmän tai vähemmän samankaltaisia.

Voit yrittää selvittää allekirjoituksen tarkkailemalla ehdollisia operaatioita, jotka tuottavat arvon (olettaen, että kehittäjä ei tehnyt virhettä kuten vertaamalla allekirjoitettua ja allekirjoittamatonta arvoa).

Yksi makea temppu binäärin sisällä olevista merkkijonoista on komentorivityökalu merkkijonot . Voi olla tärkeää mainita, että se ei etsi "muuttujia". Se vain etsii jatkuvia kelvollisia merkkejä ja tulostaa ne. Joten tästä on hyötyä myös merkkijonojen purkamiseen kaikentyyppisistä tiedostoista (kun ne on tallennettu selkeään tekstiin).

Esimerkkiohjelma:

  int main (int argc, char * argv [ ]) {char pw [] = "SecretPW"; if (! strcmp (pw, argv [1])) {printf ("Oikea! \ n"); } else {printf ("False ... \ n"); } return 0;}  

Merkkijonojen käyttäminen merkkijonojen purkamiseen:

  $ ./test FalsePWFalse ... $ strings testSecretPWCorrect! False ... $ ./test SecretPW 139 orrectOikein!