perché è possibile rompere così tanto ransomware?
<p>il sito: <a href="https://www.nomoreransom.org/">https://www.nomoreransom.org/</a> offre molti strumenti di decodifica per i ransomware.</p><p><strong> ma perché? </strong></p><p>non dovrebbe essere così difficile utilizzare l'api crypto di windows (ad es. google "crea chiave aes in windows") per creare chiavi aes, crittografarle con una chiave rsa pubblica generata localmente e crittografare la chiave rsa privata corrispondente con una rsa pubblica chiave controllata dall'attaccante. (il metodo di wanacry.)</p><p>se la vittima paga il riscatto, deve inviare la chiave rsa privata crittografata agli aggressori e, si spera, ottenere la chiave rsa privata decodificata.</p><p>perché queste persone cercano di reinventare la ruota e nel processo commettono errori che consentono lo sviluppo di strumenti di decodifica?</p>
<p><strong>divulgazione</strong>: lavoro per uno dei fornitori che partecipano a nomoreransom.</p><p>la maggior parte dei ransomware moderni implementa effettivamente una corretta crittografia. le versioni precedenti utilizzavano <code>rand()</code> per la generazione di chiavi, seminando i generatori casuali con varianti di <code>time()</code> - ecco perché era importante che la decrittazione riuscisse a sapere quando si è verificata esattamente l'infezione; idealmente fino a pochi minuti. quelli potrebbero essere decifrati con forza bruta. ma la maggior parte dei ransomware moderni utilizza effettivamente l'api crypto di windows o le librerie crittografiche in bundle.</p><p>tuttavia, indipendentemente dalla corretta implementazione del ransomware, c'è sempre un punto debole: per facilitare la decrittazione, le chiavi devono essere archiviate da qualche parte. questo luogo potrebbe essere rintracciato dalle compagnie di sicurezza, che collaborerebbero con le forze dell'ordine per prenderne il controllo. l'accesso al server offre alla società di sicurezza la possibilità di decrittografare i file delle vittime del ransomware. questo è ad esempio il caso del ransomware gangcrab.</p>
se il tuo hard disk è recente dovrebbe offrire la possibilità di criptare i dati contenuti in un'apposita cartella, lasciando eventualmente "in chiaro" (e disponibili alla consultazione) i file memorizzati all'esterno della cartella protetta.
se così non è, puoi utilizzare un programma come blowfish e criptare i singoli file, in modo da renderli illeggibili senza l'apposito programma e, ovviamente, la password.

^ ^ ^ ^ ^ ^ 

per fare quello che dici hai bisogno di un software e le strade sono 2, o utilizzi quello interno all'hard disk (se presente) o utilizzi un software esterno (come blowfish). non puoi mettere una password per opera dello spirito divino..."qualcosa" che gestisca la password ci deve essere.
e lascia perdere il sistema di winrar, le sue password si "rompono" molto facilmente mentre i programmi come blowfish hanno una chiave di codifica aes a 256 bit estremamente più sicura.

chi spollicia in giù non capisce proprio un tubo di sicurezza informatica. <p>innanzitutto ciò dipende interamente dalla crittografia utilizzata dal punto di accesso. esistono diversi tipi di crittografia possibile. principalmente sui punti di accesso wireless di consumo si tratta di:</p><ul> <li>wep</li> <li>wpa</li> <li>wpa2</li> <li>wps</li> </ul><h2>wep</h2><p>immergiamoci prima in wep. wep è stato il primo algoritmo utilizzato per proteggere i punti di accesso wireless. sfortunatamente è stato scoperto che wep presentava alcuni gravi difetti. nel 2001, 3 ricercatori che lavoravano a berkeley hanno prodotto un documento chiamato " <a href="http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html">(in) security of the wep algoritmo</a> ". hanno riscontrato i seguenti difetti in wep:</p><ul> <li>attacchi passivi per decrittografare il traffico sulla base di analisi statistiche.</li> <li>attacco attivo per iniettare nuovo traffico da stazioni mobili non autorizzate, basato su testo in chiaro noto.</li> <li> <p>attacchi attivi per decrittografare il traffico, basati sull'inganno del punto di accesso.</p> </li> <li> <p>attacco da dizionario che, dopo aver analizzato il traffico di circa un giorno, consente la decrittazione automatizzata in tempo reale di tutto il traffico.</p> </li> </ul><p>un estratto dal loro articolo sui problemi tecnici con wep:</p><blockquote> <p>wep utilizza l'algoritmo di crittografia rc4, noto come crittografia di flusso. un codice di flusso funziona espandendo una chiave breve in un flusso di chiavi pseudo-casuale infinito. il mittente xor esegue il flusso chiave con il testo in chiaro per produrre testo cifrato. il destinatario ha una copia della stessa chiave e la utilizza per generare un flusso di chiavi identico. xoring il flusso di chiavi con il testo cifrato produce il testo in chiaro originale.</p> <p>questa modalità operativa rende le cifrature di flusso vulnerabili a numerosi attacchi. se un utente malintenzionato lancia un bit nel testo cifrato, quindi al momento della decrittazione, il bit corrispondente nel testo in chiaro verrà capovolto. inoltre, se un intercettatore intercetta due crittografati crittografati con lo stesso flusso di chiavi, è possibile ottenere il xor dei due testi semplici. conoscenza di questo xor può abilitare gli attacchi statistici per recuperare i testi in chiaro. gli attacchi statistici diventano sempre più pratici man mano che vengono conosciuti più testi cifrati che usano lo stesso flusso chiave. una volta che uno dei testi in chiaro viene conosciuto, è banale recuperare tutti gli altri.</p> <p>wep ha difese contro entrambi questi attacchi. per assicurarsi che un pacchetto non sia stato modificato durante il trasporto, utilizza un campo integrity check (ic) nel pacchetto. per evitare la crittografia di due cifratix con lo stesso flusso di chiavi, viene utilizzato un vettore di inizializzazione (iv) per aumentare la chiave segreta condivisa e produrre una chiave rc4 diversa per ciascun pacchetto. il iv è anche incluso nel pacchetto. tuttavia, entrambe queste misure sono implementate in modo errato, con conseguente scarsa sicurezza.</p> <p>il campo di controllo dell'integrità è implementato come checksum crc-32, che fa parte del payload crittografato del pacchetto. tuttavia, crc-32 è lineare, il che significa che è possibile calcolare la differenza di bit di due crc in base alla differenza di bit dei messaggi su cui vengono rilevati. in altre parole, capovolgendo il bit n nel messaggio si ottiene un insieme deterministico di bit nel crc che deve essere capovolto per produrre un checksum corretto sul messaggio modificato. poiché il lancio di bit viene eseguito dopo una decrittografia rc4, ciò consente all'attaccante di invertire i bit arbitrari in un messaggio crittografato e regolare correttamente il checksum in modo che il messaggio risultante appaia valido.</p> <p>il vettore di inizializzazione in wep è un campo a 24 bit, che viene inviato nella parte in chiaro di un messaggio. un così piccolo spazio di vettori di inizializzazione garantisce il riutilizzo dello stesso flusso di chiavi. un punto di accesso occupato, che invia costantemente pacchetti di 1500 byte a 11 mbps, esaurirà lo spazio di iv dopo 1500 * 8/(11 * 10 ^ 6) * 2 ^ 24 = ~ 18000 secondi, o 5 ore. (la quantità di tempo può essere anche inferiore, poiché molti pacchetti sono inferiori a 1500 byte.) ciò consente a un utente malintenzionato di raccogliere due cifrati crittografati con lo stesso flusso di chiavi ed eseguire attacchi statistici per recuperare il testo in chiaro. peggio ancora, quando la stessa chiave viene utilizzata da tutte le stazioni mobili, ci sono ancora più possibilità di collisione iv. ad esempio, una comune scheda wireless di lucent reimposta il valore iv su 0 ogni volta che una scheda viene inizializzata e incrementa il valore iv di 1 con ciascun pacchetto. ciò significa che due carte inserite all'incirca nello stesso momento forniranno un'abbondanza di collisioni iv per un attaccante. (peggio ancora, lo standard 802.11 specifica che cambiare il iv con ogni pacchetto è opzionale!)</p> </blockquote><p>qualche altro materiale di lettura interessante può essere trovato su <a href="http://dl.aircrack-ng.org/breakingwepandwpa.pdf">aircrack-ng.org</a> .</p><h2>wpa</h2><p>il secondo è wpa. wpa originariamente era inteso come un wrapper per wep che affronta le insicurezze causate da wep. in realtà non è mai stato inteso come standard di sicurezza ma solo come soluzione rapida fino a quando wpa2 non è diventato disponibile.</p><p>esistono due modalità in cui può operare:</p><ul> <li>wpa-psk: chiave già condivisa (password)</li> <li>wpa-enterprise: richiede un radius e può essere combinato con un <a href="http://en.wikipedia.org/wiki/extensible\_authentication\_protocol">extensible authentication protocol</a> (eap).</li> </ul><p>wpa utilizza generalmente il protocollo tkip (temporal key integrity protocol). tkip è stato progettato dal gruppo di attività ieee 802.11i e wi-fi alliance come soluzione per sostituire wep senza richiedere la sostituzione di hardware legacy. ciò era necessario perché la rottura di wep aveva lasciato le reti wifi senza una valida sicurezza a livello di collegamento ed era necessaria una soluzione per l'hardware già distribuito. tkip non è <strong> non </strong> un algoritmo di crittografia, ma viene utilizzato per assicurarsi che ogni pacchetto di dati venga inviato con una chiave di crittografia univoca.</p><p>da <a href="http://dl.aircrack-ng.org/breakingwepandwpa.pdf">il documento aircrack-ng.org</a> </p><blockquote> <p>tkip implementa una funzione di miscelazione delle chiavi più sofisticata per mescolare una chiave di sessione con un vettore di inizializzazione per ciascun pacchetto. ciò impedisce tutti gli attacchi di chiave correlati attualmente noti poiché ogni byte della chiave per pacchetto dipende da ogni byte della chiave di sessione e dal vettore di inizializzazione. inoltre, in ogni pacchetto è incluso un message integrity check (mic) a 64 bit chiamato michael per prevenire attacchi al meccanismo di protezione dell'integrità crc32 debole noto da wep. per prevenire semplici attacchi di replay, viene utilizzato un contatore di sequenza (tsc) che consente ai pacchetti di arrivare solo al destinatario.</p> </blockquote><p>esistono due attacchi noti contro tkip:</p><ul> <li>attacco di beck-tews</li> <li>attacco di ohigashi-morii (che è un miglioramento dell'attacco di beck-tews)</li> </ul><p>tuttavia, entrambi questi attacchi possono solo decrittografare piccole porzioni di dati, compromettendo la riservatezza. ciò che non possono darti è l'accesso alla rete. per darti un'idea di quanti dati possono essere recuperati, un singolo frame arp impiegherebbe circa 14-17 minuti per ottenere il testo in chiaro.</p><p>l'unico attacco noto, oltre a difetti nel firmware di alcuni router, è la forzatura del wpa. generalmente la chiave viene generata come segue:</p><pre><code>key = pbkdf2(hmac−sha1,passphrase, ssid, 4096, 256) </code></pre><p>considerando che questo algoritmo ha lo scopo di prevenire la violazione delle password con hash, può richiedere molto tempo. l'unico attacco ragionevole sarebbe usare un attacco con dizionario (quindi è importante usare password lunghe contenenti caratteri, numeri e lettere).</p><p>si noti inoltre che è necessario modificare il proprio ssid in qualcosa di molto casuale. le tabelle rainbow sono state generate per <a href="http://rainbowtables.shmoo.com/">i primi 1000 ssid utilizzati</a> .</p><p>wpa supporta anche aes (che può essere utilizzato al posto di rc4). ciò implicherebbe comunque l'utilizzo di tkip-mic.</p><h2>wpa2</h2><p>wpa2 supporta le stesse modalità di wpa, tranne per il fatto che non utilizza tkip ma ccmp per l'incapsulamento crittografico.</p><p>ccmp è un meccanismo avanzato di incapsulamento crittografico dei dati progettato per la riservatezza dei dati e basato sulla modalità counter con cbc-mac (ccm) dello standard aes. questo è usato per sostituire tkip per la riservatezza dei messaggi.</p><p>tuttavia, alcuni punti di accesso possono ancora essere configurati per utilizzare sia tkip che ccmp. ciò è stato fatto perché altrimenti le persone dovevano aggiornare il proprio hardware.</p><h2>estensioni</h2><h3>wps</h3><p>wi-fi protected setup (wps; originariamente wi-fi simple config) è uno standard di elaborazione che tenta di consentire una facile creazione di una rete domestica wireless sicura. consentiva una facile sicurezza per gli utenti domestici ma utilizzava ancora il più sicuro wpa anziché wep. wps non dovrebbe mai <strong> mai </strong> essere usato in quanto presenta un grande difetto di progettazione. wps genera "tramite il pulsante push di un pulsante" a pin che può essere inserito dall'utente. l'idea alla base di ciò era di aumentare l'usabilità. pone un problema: la quantità di possibilità è ridotta a 10.000.000 che qualsiasi computer può sgridare abbastanza rapidamente, anche quando si utilizza pbkdf2.</p><h3>eap</h3><p>eap è utilizzato per wpa (2) -enterprise ed è un framework di autenticazione, non un meccanismo di autenticazione specifico. fornisce alcune funzioni comuni e la negoziazione di metodi di autenticazione chiamati metodi eap. attualmente ci sono circa 40 diversi metodi definiti. alcuni hanno i loro difetti, tuttavia, considerando la grande quantità di possibilità che suggerisco di cercarli da soli.</p> trucchi come ad esempio scrivere codici mentre giochi non ce ne sono ma se vai su questo sito:

http://nfscheats.net/

trovi dei programmi di hacks che ti permettono di prendere molti boost,soldi e powerup....

ps:io ho provato da buon truccatore ma a me nn vanno...non so se è per il mio pc pieno zeppo di virus o se proprio non va il programma. <p>keepass utilizza un processo di derivazione della password personalizzato che include più iterazioni di crittografia simmetrica con una chiave casuale (che quindi funge da salt), come spiegato <a href="http://keepass.info/help/base/security.html#secdictprotect">lì</a> . il numero predefinito di iterazioni è 6000, quindi sono 12000 invocazioni aes per l'elaborazione di una password (la crittografia viene eseguita su un valore a 256 bit, aes utilizza blocchi a 128 bit, quindi devono essere presenti almeno due invocazioni aes per ogni round). con un pc quad-core <em> recente </em> (quelli con lo spiffy <a href="http://en.wikipedia.org/wiki/aes\_instruction\_set">istruzioni aes</a> ), dovresti essere in grado di testare circa 32000 potenziali password al secondo.</p><p>con dieci personaggi casuali scelti in modo uniforme tra i centinaia di caratteri che possono essere digitati su una tastiera, ce ne sono 10<sup>20</sup> password potenziali e forza bruta, in media, proveranno la metà di esse. sei dentro per 10<sup>20</sup>* 0,5/32000 secondi, noto anche come 50 milioni di anni. ma con <em> due </em> pc che sono solo 25 milioni di anni.</p><p>ciò presuppone che il processo di derivazione della password non sia in qualche modo imperfetto. nel "processo di derivazione della password personalizzata", la "personalizzazione" è una parola spaventosa. inoltre, il numero di iterazioni è configurabile (6000 è solo il valore predefinito).</p> cerca un programma di riconiscimento testo ocr ... molti scanner hanno questa funzione già integrata nel software in dotazione, comunque se googli un po' trovi tanti software di questo tipo. <p>mi sembra rischioso. la compressione http va bene per le risorse statiche, ma per alcune risorse dinamiche servite su ssl, sembra che la compressione http possa essere pericolosa. mi sembra che la compressione http possa, in alcune circostanze, consentire attacchi di tipo crime.</p><p>si consideri un'applicazione web che ha una pagina dinamica con le seguenti caratteristiche:</p><ol> <li> <p>viene servito su https.</p> </li> <li> <p>la compressione http è supportata dal server (questa pagina verrà inviata al browser in forma compressa, se il browser supporta la compressione http).</p> </li> <li> <p>la pagina ha un token csrf su di essa da qualche parte. il token csrf è stato risolto per la durata della sessione (diciamo). questo è il segreto che l'attacco proverà ad imparare.</p> </li> <li> <p>la pagina contiene alcuni contenuti dinamici che possono essere specificati dall'utente. per semplicità, supponiamo che ci sia qualche parametro url che viene ripetuto direttamente nella pagina (forse con un po 'di escape html applicato per impedire xss, ma va bene e non scoraggerà l'attacco descritto).</p> </li> </ol><p>quindi penso che gli attacchi in stile crime potrebbero consentire a un utente malintenzionato di apprendere il token csrf e montare attacchi csrf sul sito web.</p><p>lasciami fare un esempio. supponiamo che l'applicazione web di destinazione sia un sito web bancario su <code>www.bank.com</code> e la pagina vulnerabile è <code>https://www.bank.com/buggypage.html</code>. supponiamo che la banca assicuri che le attività bancarie siano accessibili solo tramite ssl (https). e supponiamo che se il browser visita <code>https://www.bank.com/buggypage.html?name=d.w.</code>, quindi il server risponderà con un documento html simile a qualcosa di vagamente simile a questo:</p><pre><code>&lt;html&gt;...&lt;body&gt; hi, d.w.! pleasure to see you again. some actions you can take: &lt;a href="/closeacct&amp;csrftoken=29238091"&gt;close my account&lt;/a&gt;, &lt;a href="/viewbalance&amp;csrftoken=..."&gt;view my balance&lt;/a&gt;, ... &lt;/body&gt;&lt;/html&gt; </code></pre><p>supponiamo che tu stia navigando sul web tramite una connessione wifi aperta, in modo che un utente malintenzionato possa intercettare tutto il traffico di rete. supponiamo che tu sia attualmente connesso alla tua banca, quindi il tuo browser ha una sessione aperta con il sito web della tua banca, ma in realtà non stai effettuando alcuna attività bancaria tramite la connessione wifi aperta. supponiamo inoltre che l'attaccante possa attirarti a visitare il sito web dell'attaccante <code>http://www.evil.com/</code> (ad esempio, magari facendo un attacco man-in-the-middle su di te e reindirizzandoti quando provi a visitare qualche altro sito http).</p><p>quindi, quando il browser visita <code>http://www.evil.com/</code>, quella pagina può attivare richieste tra domini al sito web della tua banca, nel tentativo di apprendere il token csrf segreto. si noti che javascript è autorizzato a effettuare richieste tra domini. la politica della stessa origine impedisce che venga visualizzata la risposta a una richiesta tra domini. tuttavia, poiché l'aggressore può intercettare il traffico di rete, l'attaccante può osservare la lunghezza di tutti i pacchetti crittografati e quindi dedurre qualcosa sulla lunghezza delle risorse che vengono scaricate tramite la connessione ssl alla tua banca.</p><p>in particolare, il maligno <code>http://www.evil.com/</code> page può attivare una richiesta a <code>https://www.bank.com/buggypage.html?name=closeacct&amp;csrftoken=1</code> e guarda come si comprime bene la pagina html risultante (intercettando i pacchetti e osservando la lunghezza del pacchetto ssl dalla banca). successivamente, può attivare una richiesta a <code>https://www.bank.com/buggypage.html?name=closeacct&amp;csrftoken=2</code> e vedi quanto comprime bene la risposta. e così via, per ogni possibilità per la prima cifra del token csrf. uno di questi dovrebbe comprimersi un po 'meglio degli altri: quello in cui la cifra nel parametro url corrisponde al token csrf nella pagina. ciò consente all'attaccante di apprendere la prima cifra del token csrf.</p><p>in questo modo, sembra che l'attaccante possa apprendere ogni cifra del token csrf, recuperandole cifra per cifra, fino a quando l'attaccante apprende l'intero token csrf. quindi, una volta che l'utente malintenzionato conosce il token csrf, può avere la sua pagina dannosa su <code>www.evil.com</code> attiva una richiesta tra domini che contiene il token csrf appropriato, annullando correttamente le protezioni csrf della banca.</p><p>sembra che ciò possa consentire a un utente malintenzionato di montare un attacco csrf riuscito su applicazioni web, quando si applicano le condizioni sopra, se la compressione http è abilitata. l'attacco è possibile perché stiamo mescolando segreti con dati controllati dall'aggressore nello stesso payload, quindi comprimendo e crittografando tale payload.</p><p>se ci sono altri segreti che sono memorizzati in html dinamico, potrei immaginare che attacchi simili potrebbero diventare possibili per imparare quei segreti. questo è solo un esempio del tipo di attacco a cui sto pensando. quindi, mi sembra che l'uso della compressione http su pagine dinamiche a cui si accede tramite https sia un po 'rischioso. potrebbero esserci buoni motivi per disabilitare la compressione http su tutte le risorse offerte su https, ad eccezione di pagine/risorse statiche (ad es. css, javascript).</p> ma li e facile basta impegnarsi io lo ripetuto circa 10 volte ma allla fini ci sono riuscito quindi cerca di impegnarti oppure cerca i trucchi e te lo sblocchi allora 1) obfuscator.xz usa una interazione per il bypass delle firme digitali che è la styessa usata per le alcune crack... quindi di solito è un falso positivo.
obfuscator.xz in realtà non è un virus ma un vettore che "installa" quello che gli viene assegnato quindi gli effetti non sono prevedibili anticipatamente...
si è un tojan ma spesso viene dotato di malware tipo rat o backdoor per connessioni di shell ( spesso con privilegi system)
scusate ora mi spiego questo virus può essere rilevato in modo errato nelle crack
il vero virus nasce solo per installare un altro virus e poi obfuscator.xz rimane latente fino a che vede il processo del virus istallato attivo mentre 
spesso il virus iniettato ha il compito di camuffarsi all'interno di un processo di windows e usarei i privilegi di questo processo per 
1) diventare da utente normale a utente system (qualcosa di molto simile all'amministratore)
2) far aprire una connessione verso l'esterno per fare upload e download di dati o ricevere comandi
2b) oppure per fare un upload automatico dei dati interessanti ogni x tempo magari dati collezionati dallo stesso virus iniettato che ha funzioni anche di key logger o session hijaker

in sostanza non si può dire cosa sia successo al tuo disco rigido ma sicuramente nulla è cancellato, i dati sono recuperabili con una probabilità del 99% ora resta da capire cosa sia successo e come rimediare ma da qui è parecchi difficile normalmente, se aquisti uno scanner il software ocr ce accanto dello scanner.
se no scarica un software ocr (riconoscimento testo) :
http://softi-freeocr.softonic.it/
ciao <p>ho usato <a href="http://home.snafu.de/tilman/xenulink.html">xenu's link sleuth</a> . funziona abbastanza bene, assicurati di non dos!</p>