Ci sono aspetti negativi di utilizzare UPX per comprimere un file eseguibile di Windows?

voti
34

Ho usato UPX , prima di ridurre le dimensioni dei miei file eseguibili di Windows, ma devo ammettere che io sono ingenuo effetti collaterali negativi questo potrebbe avere. Qual è il lato negativo di tutto questo imballaggio / disimballaggio?

Ci sono scenari in cui chiunque avrebbe consiglia di non UPX-ing un file eseguibile (ad esempio, quando si scrive una DLL, servizio di Windows, o quando il targeting Vista o Win7)? Scrivo la maggior parte del mio codice in Delphi, ma ho usato UPX per comprimere gli eseguibili C / C ++ pure.

Su un lato nota, sto non correre UPX in qualche tentativo di proteggere il mio exe da disassemblatori, solo per ridurre le dimensioni del file eseguibile e prevenire la manomissione superficiale.

È pubblicato 09/12/2008 alle 18:53
fonte dall'utente
In altre lingue...                            


12 risposte

voti
2

L'ultima volta che ho cercato di usarlo su un assembly gestito, è munged così male che il runtime è rifiutato di caricarlo. Questa è l'unica volta che mi viene in mente che non si desidera utilizzarlo (e, in realtà, è passato tanto tempo da quando ho provato che la situazione può anche essere meglio ora). Ho usato ampiamente in passato su tutti i tipi di file binari non gestiti, e mai avuto un problema.

Risposto il 09/12/2008 a 19:00
fonte dall'utente

voti
4

La dimensione finale del file eseguibile sul disco è in gran parte irrilevante in questi giorni. Il vostro programma può caricare pochi millisecondi più veloce, ma una volta che inizia a scorrere la differenza è indistinguibile.

Alcune persone possono essere più sospettoso del vostro eseguibile solo perché è compresso con UPX. A seconda delle vostre utenti finali, questo può o non può essere una considerazione importante.

Risposto il 09/12/2008 a 19:05
fonte dall'utente

voti
45

Il motivo è che ci sono aspetti negativi di utilizzare compressori EXE. Soprattutto:

All'avvio di una compressa EXE / DLL, tutto il codice viene decompresso dal disco immagine nella memoria in un unico passaggio, che può causare thrashing disco se il sistema è basso sulla memoria ed è costretto a accedere al file di scambio. In contrasto, con compressi EXE / DLL, il sistema operativo alloca memoria per tabelle codici su richiesta (cioè quando vengono eseguiti).

Più istanze di una compressa EXE / DLL creare più istanze del codice nella memoria. Se si dispone di un file EXE compresso che contiene 1 MB di codice (prima della compressione) e l'utente avvia 5 istanze di esso, a circa 4 MB di memoria è sprecato. Allo stesso modo, se si dispone di una DLL che è di 1 MB e 'utilizzato da 5 applicazioni in esecuzione, di circa 4 MB di memoria è sprecato. Con non compressi EXE / DLL, il codice viene memorizzato solo nella memoria una volta ed è condivisa tra le istanze.

http://www.jrsoftware.org/striprlc.php#execomp

Risposto il 09/12/2008 a 19:11
fonte dall'utente

voti
9

Le uniche le dimensioni contano tempo è durante il download da Internet. Se si sta utilizzando UPX poi è effettivamente ottenere prestazioni peggio che se si utilizza 7-zip (in base alla mia test 7-Zip è due volte più buono come UPX). Poi, quando in realtà è rimasto compresso sul computer di destinazione la vostra performance è diminuito (vedi risposta Lars'). Quindi UPX non è una buona soluzione per le dimensioni del file. Basta 7Zip il tutto.

Per quanto riguarda per evitare la manomissione, è un FAIL pure. UPX supporta la decompressione troppo. Se qualcuno vuole modificare il file EXE Allora vedranno è comprimere con UPX e poi decomprimerlo. La percentuale di possibili cracker si potrebbe rallentare non giustifica la perdita sforzo e prestazioni.

Una soluzione migliore sarebbe quella di utilizzare la firma binaria o almeno solo un hash. Un semplice sistema di verifica hash è quello di prendere un hash del binario e un valore segreto (di solito un GUID). Solo il tuo EXE conosce il valore segreto, in modo che quando si ricalcola l'hash per la verifica è possibile utilizzare di nuovo. Questo non è perfetto (il valore segreto possono essere recuperate). La situazione ideale sarebbe quella di utilizzare un certificato e una firma.

Risposto il 09/12/2008 a 19:39
fonte dall'utente

voti
0

Credo che ci sia una possibilità che potrebbe non funzionare su computer che hanno DEP (Data Execution Prevention) attivata.

Risposto il 09/12/2008 a 19:48
fonte dall'utente

voti
2

Se il vostro unico interesse è in diminuzione delle dimensioni dei file eseguibili, poi hai provato a confronto la dimensione del file eseguibile con e senza pacchetti di runtime? Certo si dovrà includere anche le dimensioni dei pacchetti complessiva insieme al tuo eseguibile, ma se si dispone di più file eseguibili che utilizzano gli stessi pacchetti di base, quindi il risparmio sarebbe piuttosto elevato.

Un'altra cosa da guardare sarebbe la grafica / glifi che usate nel vostro programma. È possibile salvare un po 'di spazio da loro consolidando ad un unico TImageList incluso in un modulo di dati globali piuttosto che li hanno ripetuto su ogni modulo. Credo che ogni immagine viene memorizzata nella risorsa forma esagonale, in modo che significherebbe che ogni byte occupa due byte ... è possibile ridurre questo un po 'caricando l'immagine da una risorsa RCDATA utilizzando un TResourceStream.

Risposto il 09/12/2008 a 22:32
fonte dall'utente

voti
18

Sono sorpreso questo non è stato ancora citato, ma utilizzando eseguibili UPX-confezionati aumenta anche il rischio di produrre falsi positivi da software anti-virus euristica perché statisticamente un sacco di di malware utilizza anche UPX.

Risposto il 10/12/2008 a 11:04
fonte dall'utente

voti
12

Ci sono tre inconvenienti:

  1. Tutto il codice sarà completamente compresso nella memoria virtuale, mentre in un EXE o DLL regolare, solo il codice effettivamente utilizzata è caricato in memoria. Questo è particolarmente rilevante se solo una piccola porzione di codice nel tuo EXE / DLL viene utilizzato a ogni esecuzione.
  2. Se ci sono più istanze di DLL e EXE in esecuzione, il loro codice non può essere condiviso tra le istanze, in modo da userete più memoria.
  3. Se il vostro EXE / DLL è già nella cache, o su un supporto di memorizzazione molto veloce, o se la CPU si sta eseguendo in è lento, si verificherà ridotta velocità di avvio come di decompressione dovrà comunque avvenire, e non sarà beneficiare della dimensione ridotta. Ciò è particolarmente vero per un file EXE che verrà richiamato più volte ripetutamente.

Così gli inconvenienti di cui sopra sono più di un problema se il file EXE o DLL contiene un sacco di risorse, ma per il resto, non possono essere molto più di un fattore, in pratica, data la dimensione relativa di eseguibili e la memoria disponibile, a meno che non si sta parlando di DLL utilizzato da un sacco di file eseguibili (come il sistema DLL).

Per dispell alcune informazioni non corrette in altre risposte:

  • UPX non possa influenzare la capacità di girare su macchine DEP-protetti.
  • UPX non influenzerà la capacità del software principali anti-virus, in quanto sostengono eseguibili UPX-compressi (così come altri formati di compressione eseguibili).
  • UPX è stato in grado di utilizzare la compressione LZMA per qualche tempo (algoritmo di compressione di 7zip), usare l'interruttore --lzma.
Risposto il 11/12/2008 a 14:22
fonte dall'utente

voti
1

IMHO routine UPXing è inutile, ma le ragioni siano scritte sopra, per lo più, la memoria è più costoso di disco.

Erik: lo stub LZMA potrebbe essere più grande. Anche se l'algoritmo è meglio, non essere sempre un vantaggio netto.

Risposto il 25/04/2009 a 23:32
fonte dall'utente

voti
1

antivirus che cercano i virus sconosciuti '' possono bandiera UPX eseguibili compressi come avere un virus. Mi è stato detto che questo è perché molti virus usano UPX per nascondersi. Ho usato UPX sul software e McAfee contrassegnerà il file come avere un virus.

Risposto il 02/05/2009 a 01:47
fonte dall'utente

voti
1

La ragione UPX ha così tanti falsi allarmi è perché la sua licenza aperta consente autori di malware di utilizzare e modificare impunemente. Naturalmente, questo problema è inerente al settore, ma purtroppo il grande progetto UPX è afflitto da questo problema.

UPDATE: Si noti che, come il progetto taggant è completato, la capacità di utilizzare UPX (o qualsiasi altra cosa), senza causare falsi positivi sarà rafforzata, assumendo UPX lo supporta.

Risposto il 26/09/2010 a 17:34
fonte dall'utente

voti
1

Non ci sono inconvenienti.

Ma appena cronaca, c'è un equivoco molto comune per quanto riguarda UPX as--

risorse non sono solo di essere compressi

In sostanza si sta costruendo un nuovo eseguibile che ha il dovere "loader" e l'eseguibile "reale", beh, è ​​la sezione-spogliato e compressi, posta come una risorsa binaria dei dati del file eseguibile loader (indipendentemente i tipi di risorse erano in l'eseguibile originale).

Utilizzando metodi reverse-engineering e strumenti sia per fini di istruzione o altri vi mostrerà le informazioni relative al "eseguibile loader", e non informazioni variabili per quanto riguarda l'eseguibile originale.

eseguibile compresso da UPX

eseguibile compresso da UPX

Risposto il 21/10/2015 a 18:24
fonte dall'utente

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more