Come documentare il codice di sicurezza / crittografia di un'applicazione

Question

Come documentare il codice di sicurezza / crittografia di un'applicazione

#1 da (5 voti)
#2 da (5 voti)

3

Sto lavorando su un'applicazione per la quale ho sviluppato un livello di sicurezza. Utilizza l'ID hardware del disco rigido, l'indirizzo MAC e un'altra chiave seriale hardware, per bloccare il software su un particolare hardware.

Mi sono imbattuto in siti online, che dicevano che dovevo usare nomi abbastanza strani per le procedure / funzioni / variabili nel livello di sicurezza. Ad esempio

function XtDmat: Boolean; 
var
  x3mat: string;
  hhiTms: Interger;
begin
  Result := False;
  x3mat := GWindosColr;  //this returns the HD ID
  hhiTms := GalilDriverID; //this gets a controller ID
  if (t5gFx=x3mat) and (hhiTms=f4teXX) then Result := True; //match IDs with those saved in the registry
end;

E per la finestra di dialogo dei messaggi:

procedure Tfrm_MainWindow.mxProtectorExpiration( Sender: TObject );
begin
  lbl_Remaining.Caption := GetClassPath('xsedfers34;;''kd'); // encrypted value  decryted and shown       '0 days remained'
  lbl_Message.Caption := GetClassPath('qwe23vftTxxx ii gtr');   //decryt and show       'This license has expired'
  btn_Go.Enabled := False;
end;

L'ho fatto perché ho utilizzato Delphi DEDE per decompilare il mio codice e trovato anche la chiave di registro "HCKU \ software \ myapplication" in bella vista.

Ora, tuttavia, è diventato difficile

spiega ai miei compagni di squadra, perché l'ho fatto (cioè i nomi),
documento in quanto i nomi non hanno senso,
debug che mi dà mal di testa

Qualcuno può suggerire un buon modo per documentare questo tipo di codice in questo tipo di situazione. Quindi il codice diventa più facile, ma è ancora difficile decompilare. In alternativa, potresti suggerire un offuscatore per Delphi.

security delphi

posta PresleyDias 09.01.2012 - 17:57

fonte

2 risposte

5

La ragione per cui hai i tre problemi descritti è che hai violato le regole fondamentali per scrivere codice mantenibile. Il codice che hai scritto è quindi in gran parte non mantenibile, e piuttosto che tentare di documentarti fuori dal problema (un compito destinato a fallire), il codice dovrebbe essere riparato.

I came across sites online, that said I should use fairly weird names for the procedures/functions/variables in the the security layer

Spero che tu non creda a tutto ciò che leggi su Internet. Leggi il lavoro di Bruce Schneier , in particolare "Segreti e bugie" prima di fare qualsiasi altra cosa che faccia affermazioni sulla sicurezza. Se il tuo modello di sicurezza si basa sull'oscurità, è fatalmente imperfetto e se non ha bisogno di oscurità per funzionare, allora perché renderlo impossibile da mantenere. Se davvero si deve avere oscurità nel codice finale spedito, utilizzare un pre-processore per modificare la fonte gestibile e creare il programma oscuro.

risposta data 09.01.2012 - 21:56

fonte

Leggi altre domande sui tag security delphi

Qual è il vantaggio di un programmatore VM oltre alla portabilità [duplicato] Termine per problemi di prestazioni dovuti al ciclo [chiuso]

score 5 · Accepted Answer

I commenti del codice non sono disponibili per qualsiasi decompilatore di cui sono a conoscenza. Questi vengono lasciati sul pavimento dal tuo preprocessore o dal tuo lexer. Il parser non vede mai commenti, per non parlare del compilatore. Se vuoi documentare costrutti di codice bizzarri, i commenti sono il posto giusto per farlo. In questo modo li vedrai in un debugger, ma non nel codice decompilato, e viaggiano con il codice.

Detto questo, la mia raccomandazione è di usare solo nomi che abbiano un senso. Le persone che vogliono sconfiggere tali misure per lo più si dividono in due gruppi: quelli che non hanno idea di dove cominciare e quelli per i quali i nomi confusi sono solo un ostacolo minore. Le persone di quest'ultimo gruppo possono rompere la maggior parte della protezione del software in un'ora o due. L'offuscamento come quello di cui parli sta per rallentarli di forse un'altra ora. Dopo tutto, il software decompilato è già ottuso.

Ti dico questo per incoraggiarti a chiedere a te stesso se tutto questo sforzo in più per la tua squadra valga la pena rallentare un cracker una volta ogni ora o due.