Domanda:
Plugin IDA che scrive domande generiche
bernd feinman
2013-10-05 21:13:58 UTC
view on stackexchange narkive permalink

Sto provando a scrivere un plug-in per IDA PRO, principalmente perché desidero utilizzare l'elegante funzionalità di rappresentazione grafica su un linguaggio intermedio personalizzato. Dopo il primo sguardo al sistema di plugin IDA, sono un po 'perso.

Prima di scavare più a fondo, ho alcune domande di comprensione generiche, che mi mettono a disagio:

  1. L'SDK impone un allineamento della struttura? In caso contrario, come posso ricevere o fornire puntatori a strutture compatibili tra compilatori?

  2. Perché i plugin esportano un strcut (PLUGIN) di dati e non funzioni esportate standard? Qual è il vantaggio? Ancora una volta, temerei problemi di allineamento tra i compilatori.

  3. Ancora più sorprendente, almeno la parte HexRays di sdk sembra offrire compatibilità ABI di classe, il che significa che posso derivare da un ha fornito la definizione della classe e usa il risultato con l'SDK (funzioni virtuali e tutto)! Come funziona?

  4. Inoltre, l'SDK può restituire puntatori a classi che dovrei distruggere con la parola chiave "delete". Non è destinato a finire nei guai?

Tutto ciò mi rende un po 'nervoso. Qualcuno sa come si fa?

Nel caso non avessi visto questo tutorial - http://www.binarypool.com/idapluginwriting/
Una risposta:
DCoder
2013-10-06 12:05:08 UTC
view on stackexchange narkive permalink

1. L'SDK impone un allineamento della struttura? In caso contrario, come posso ricevere o fornire puntatori a strutture compatibili tra compilatori?

Le intestazioni IDA SDK specificano il loro allineamento. È suddiviso tra 1 byte e 4 byte.

Ci sono anche commenti interessanti come questo:

  / * * A causa dell'uso di STL e funzioni virtuali, alcune parti di questa * interfaccia potrebbero essere incompatibili con compilatori diversi da BCB v6.0 * /  

Ma data l'età di Borland C ++ Builder 6, non sono sicuro che siano ancora rilevanti.

2. Perché i plugin esportano una struttura dati (PLUGIN) e non le funzioni esportate standard? Qual è il vantaggio? Di nuovo, temerei problemi di allineamento tra i compilatori.

plugin_t utilizza l'allineamento a 1 byte. Finché lo segui, non dovrebbero esserci problemi di allineamento. Immagino che la struttura venga utilizzata solo per comodità, poiché il caricatore deve solo trovare e tenere traccia di un solo simbolo esportato invece di diversi.

3. Ancora più sorprendente, almeno la parte HexRays dell'SDK sembra offrire compatibilità ABI di classe, il che significa che posso derivare da una definizione di classe fornita e utilizzare il risultato con l'SDK (funzioni virtuali e tutto)! Come funziona?

HexRays ti consente di ispezionare / modificare la rappresentazione dell'albero dei sorgenti decompilato e utilizza il pattern del visitatore per farlo.

È molto più facile passare un puntatore a una classe che contiene più puntatori che passare una tonnellata di puntatori di callback separati per operazioni diverse. Inoltre, una classe ti consente di catturare / tenere traccia dello stato locale, farlo con puntatori di callback separati richiederebbe un lavoro extra con i funtori.

4. Inoltre, l'SDK può restituire puntatori a classi che dovrei distruggere con la parola chiave "delete". Non è destinato a finire nei guai?

Di cosa sei preoccupato? Il fatto che stai liberando la memoria allocata da un altro modulo o il fatto che sei responsabile della durata dell'oggetto?

Il primo non dovrebbe essere un problema, pro.h contiene una macro DEFINE_MEMORY_ALLOCATION_FUNCS che sovrascrive la gestione della memoria per ciascuna di queste classi, quindi l'eliminazione andrà avanti Routine di gestione della memoria di IDA.

Quest'ultima è solo qualcosa con cui devi convivere.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...