E ' impossibile proteggere completamente il codice, indipendentemente da come lo si impacchetta, per poter essere eseguito deve essere accessibile e decrittografato, il che significa che la chiave deve essere memorizzata localmente.
Considerare questo scenario;
Gli autori del sistema di elettroni e il formato di file asar implementano la crittografia simile a un zip protetto da password e offrono la possibilità di specificare la password dell'archivio al momento della compilazione in modo che sia "sicuro" memorizzato all'interno dell'exe e del il file asar non può essere aperto/letto senza di esso.
Un hacker poteva ancora calcolare la chiave compilando elettroni stessi con alcune chiavi di test, ad esempio AAAA e AAAB, quindi confrontando il file binario risultante per determinare la posizione della stringa di chiavi al suo interno. Una volta che sanno come estrarre la chiave dall'exe, è finita.
Immagino che la protezione più forte che si può fare è se si modifica il codice sorgente dell'elettrone per memorizzare e recuperare la chiave, ma anche in questo caso un utente malintenzionato può decompilare il codice, confrontarlo con una versione standard decompilata di elettrone, capire in cui le modifiche al codice iniziano e eseguono il reverse engineering fino a quando non capiscono come si sta memorizzando la chiave.
Ancora una volta, nel momento in cui hanno la chiave, è game over, e per fare in modo che l'elettrone esegua qualsiasi codice deve essere in grado di leggerlo il che significa che deve avere la chiave disponibile localmente. Catch 22.
fonte
2016-09-16 19:34:53
Avresti anche bisogno di un modo per proteggere dalle chiamate a toString che potrebbero visualizzare fonti decodificate. – gaspard