Il programmatore associato ha usato le peggiori pratiche di programmazione

Do I look for a obfuscator library in Java and fix his old code (which might be a little touchy about remodeling his code), or do I leave it as it, as much as that irks me to no end?

No , tornare indietro a qualcuno e modificare il codice di cui sono responsabili sarebbe un reato peggiore rispetto alla scrittura del codice discutibile per cominciare.

L'hai portato con il programmatore, il tuo prossimo passo è di toglierti il naso o portarlo su con la gestione e poi toglierti il naso.

C'è stata una revisione ufficiale del codice di qualsiasi tipo - o lo scontro ha avuto una "revisione del codice" non ufficiale? Direi che dal momento che questo è un argomento delicato e importante come la sicurezza e le licenze, è necessario aumentare la catena. Hai fatto la prima parte - confrontando il programmatore. Tuttavia, ora che non sta ascoltando, puoi / dovrebbe riprenderlo. Se non lo fai, potresti essere parte del problema.

Gli direi che lo farai - questo PU change cambiare idea. In caso contrario, scrivi un'email molto politicamente corretta, ma precisa e concisa sulla situazione al tuo capo e CC il programmatore. Nell'e-mail, chiedi un incontro tra voi tre e / o qualsiasi altra parte partecipante.

Incontra sempre queste cose - ma in modo politico e amichevole.

Se riesci a trovare un offuscatore che può offuscare la firma delle classi (nomi dei metodi ecc.), bene, proponi di acquistarlo e usarlo.

Fino ad allora, potresti dover convivere con essa. Ammetto di aver fatto qualcosa di simile in un recente progetto Grails: i controlli delle licenze sono volutamente incorporati nel già grande metodo di accesso, quindi sarebbe piuttosto difficile sostituire il metodo per ignorare il controllo.

Può dimostrare che un tale hack è fattibile, o è solo uno scenario ipotetico di cui è piuttosto preoccupato? Può dare una dimostrazione dal vivo di questo lavoro? Dovrebbe provare. Sul serio. Se funziona, dovrebbe essere presentato alla direzione e quindi suggerire di ottenere un offuscatore.

Se un offuscatore non è abbastanza sicuro, hai esaminato altri modi per proteggere il JAR, forse qualcosa come crittografarlo o compilarlo nel codice nativo?

RE: rielaborazione del suo codice: si tratta solo di rinominare? Molti IDE hanno strumenti di refactoring che possono farlo abbastanza facilmente.

Indipendentemente dal valore del tuo IP, la cosa intelligente è non manipolare il tuo codice nella speranza di confondere gli hacker. A parte il fatto che sarà un incubo per mantenere il futuro, in realtà non risolve alcun problema. Rende solo più difficile ma non impossibile. Quindi non è davvero una soluzione e gli effetti collaterali sono cattivi. È come prendere medicine che non funzionano e hanno effetti collaterali negativi.

Il tuo problema è come proteggere il tuo IP. Trova una soluzione per questo: obfuscators, server licenze ecc.

Mi sono imbattuto in un problema simile quando un altro sviluppatore ha chiamato le nostre routine di codifica / decrittografia str__copy e str__delete (notare il secondo trattino basso). Era zoppo e avrebbe potuto essere fatto meglio, quindi abbiamo aspettato che ci fosse una storia in cui era necessario aggiornare le licenze. La gestione non ha avuto problemi con l'ulteriore manciata di ore perché l'abbiamo descritta come "ripulire così la prossima volta che entreremo in licenza, ci vorrà meno tempo e sarà più sicuro". Problema risolto, nessun sentimento ferito.

Il mio primo pensiero è stato il mantenimento di quel codice. Se il codice è già stato offuscato e si è trasferito, buona fortuna sta cercando di ottenere un controllo su quel codice. Sarai quindi l'hacker che sta tentando di decifrare il codice.

Invece raccomanderei di ripulire il codice e usare un obfuscator fa tutto il duro lavoro. A lungo termine avrai un codice molto gestibile e lascerai tutta la complessità folle a chiunque desideri hackerare la tua licenza.

Ricorda che nessun obfuscater è perfetto, e un hacker molto determinato può decodificare qualsiasi cosa, ma almeno sarà solo lui. Inoltre gli obfuscaters aggiungono molta più complessità di quello che probabilmente un ragazzo può.

Sono molto d'accordo con le risposte che dovresti chiedere al tuo capo in merito al problema e fare ciò che dice.

Tuttavia un addendum molto importante a queste risposte è che dovresti documentare le tue preoccupazioni in merito sia alla sicurezza che alla manutenibilità. Indipendentemente dal fatto che tu cambi il codice, è importante che le persone sappiano di cosa ti preoccupi e perché. Questo è importante sia in modo proattivo (il tuo capo non può prendere una decisione che non sa nemmeno di dover fare) e in modo difensivo (se / quando un hacker fa buchi nel sistema di licenze poco sicuro, non possono biasimarti per il loro errore.)

"Non essere il professionista più esperto di un problema".

In altre parole, dillo al tuo capo e vai da lì. Se stai zitto, e sei la cima del totum su quel segreto, quando arriva la spinta, sarai responsabile. Dì al tuo capo di passaggio e fagli decidere un modo per affrontarlo. In questo modo sei sollevato dall'onere della scelta.

Non dirlo al tuo capo, perché molti manager forse non sono così tecnici, ma fanno quello che facciamo sempre: dai al problema e alle possibili soluzioni i vantaggi / svantaggi di ciascuna di queste soluzioni. Quindi lascia che decidano e che sia approvato. Ecco perché manager / leader vengono pagati i soldi!

La semplice verità è che dato abbastanza tempo e risorse tutto può essere rotto. È una semplice funzione di quanto è popolare la tua app. Più popolare è l'hacker più abile che attira e più tempo è dedicato a romperlo. L'offuscamento del codice fornisce proprio questo - un mezzo per aumentare il tempo necessario per romperlo, simile alla crittografia. Quindi se il tuo codice è offuscato richiede che l'hacker sia abile e dedica del tempo ad esso altrimenti si disperherà e si arrenderà. Devi chiederti se la tua app vale la pena a entrambe le estremità.

In realtà è incredibile quanto possa essere difficile decifrare il codice offuscato. Puoi facilmente trasformare un semplice programma in 10 linee C in un assemblaggio di 100 linee attraverso l'offuscamento. Se provi a eseguirne il debug, salterai senza senso nel codice e potresti essere davvero frustrante nel superarlo. Alla fine si romperà ma diventerà davvero difficile e poiché nulla è davvero impossibile è questo il punto. L'offuscamento del codice riduce il numero di persone che sono in grado di romperlo.

Certo, ci sono modi migliori, come cercare di confondere il debugger e non il cracker, ma questo è economico ed efficiente. Tuttavia nominare le cose in modo imbarazzante non basta. È necessario modificare le funzioni di controllo del flusso di controllo che in realtà non fanno nulla per il codice generale, ma aumentano le dimensioni e la complessità di esso: chiamate funzioni fittizie il cui valore di ritorno non è utilizzato da nessuna parte, da funzioni interne che fanno veramente qualcosa. Puoi già vedere come questo può diventare veramente confuso.

Hai qualcosa che l'aggressore non ha. Il codice sorgente originale. Trova un modo per organizzarlo meglio per te.