Domanda:
Programma senza dipendenze
PhoeniX
2013-05-25 01:33:55 UTC
view on stackexchange narkive permalink

durante la lettura delle risposte a Posso collegare staticamente (non importare) le DLL del sistema Windows? mi è venuta un'altra domanda. Quindi:

  1. C'è un modo per scrivere un programma che non ha dipendenze (niente è anche compilato staticamente - ha solo il mio codice) e tutto viene risolto durante l'esecuzione -time supponendo che kernel32.dll verrà caricato / mappato nel processo, non importa cosa?
  2. La mia ipotesi su kernel32.dll è corretta?

Durante il runtime, intendo utilizzare la struttura PEB .

Tieni presente che le regole su `kernel32.dll` si applicano solo alla piattaforma NT. Non che mi aspetto che qualcuno usi ancora 9x / Me, ma per ogni evenienza;)
Quattro risposte:
Jason Geffner
2013-05-25 03:22:26 UTC
view on stackexchange narkive permalink

Se stai chiedendo informazioni sui file PE e con "nessuna dipendenza" intendi "nessuna DLL importata staticamente", allora sì.

Vedi \ yoda \ NoImports.exe in https://corkami.googlecode.com/files/BinaryCorpus_v2.zip come esempio.

Grazie, questa è una soluzione carina e interessante e in effetti presume che lo stack abbia l'indirizzo di ritorno da qualche parte nello spazio `kernel32` (che ha esplorato qui) e da lì la strada è" semplice ":)
il modo più comune in questi giorni per risolvere l'indirizzo di base di kernel32.dll è camminare nell'elenco InMemoryOrderModuleList, poiché l'ordine delle DLL non è cambiato nemmeno in Windows 7. Tecnicamente, non è necessario risolvere nient'altro che GetProcAddress (), se si dispone di una tabella di esportazione, poiché è possibile utilizzare riferimenti inoltrati alle DLL di interesse e GetProcAddress () sulle proprie esportazioni causerà il caricamento delle DLL da parte di Windows.
Avery3R
2013-05-25 03:02:28 UTC
view on stackexchange narkive permalink

Questo non è un trucco molto portabile, ma kernel32.dll viene sempre caricato allo stesso indirizzo quando viene avviato l'eseguibile, il che significa che LoadLibraryA e GetProcAddress sono sempre allo stesso indirizzo. Potresti codificare questi offset e partire da lì.

Quindi, `kernel32.dll` sarà sempre caricato nell'evento dei processi se l'immagine di PE non fa riferimento ad esso da nessuna parte nel codice?
@ph0sec sì, anche il caricatore di Windows carica sempre in kernel32.dll e sempre allo stesso indirizzo.
`@MMavipc` riguardo allo stesso indirizzo non è sempre corretto come nella famiglia Vista e Win 7, l '[ASLR] (http://en.wikipedia.org/wiki/Address_space_layout_randomization) è stato introdotto per frenare questa ipotesi.
@MMavipc quel comportamento è stato introdotto in Windows XP, per evitare il problema di crash quando un processo non veniva importato da kernel32.dll, e quindi non veniva caricato esplicitamente.@ph0sec che non è esattamente corretto, neanche ASLR si applica solo alla prima volta che kernel32 .dll (e anche ntdll.dll) viene caricato. Dopodiché, si trova a un indirizzo comune a tutti i processi.
"@peter ferrie" di causa in quanto viene caricato solo una volta e successivamente mappato su altri processi. La cosa a cui mi riferivo qui è che non puoi (non dovresti) codificare l'indirizzo di base `kernel32.dll` nell'eseguibile stesso.
Ange
2013-05-25 21:33:43 UTC
view on stackexchange narkive permalink

Sì, è possibile un programma che non ha dipendenze.

Per importare APi, deve prima individuare kernel32 (tramite stack + scansione MZ o PEB ) quindi individuare le esportazioni (tramite analisi export o valori hardcoded).

shebaw
2013-05-26 10:50:30 UTC
view on stackexchange narkive permalink

Sì.

  1. Trova l'indirizzo di kernel32 usando uno qualsiasi dei trucchi conosciuti (PEB o qualsiasi altro modo)
  2. Implementa un semplice parser di sezione di esportazione e trova l'indirizzo di LoadLibrary e GetProcAddress .
  3. Utilizzali per caricare qualsiasi altra API che desideri.


ⓘ
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...