need software plssss

[yorkeiser]

Originariamente inviato da Nazzyyy

e infatti
qua non è solo da scoprire l'algoritmo??
le key sono giuste e valide..


vedete ke non è impossibile ;DD



(è improbabile xd)

Suppongo l'algortimo venga scoperto disassemblando l'eseguibile, dubito che ci si riesca "a mente".

[gugoXX]

Originariamente inviato da yorkeiser

Suppongo l'algortimo venga scoperto disassemblando l'eseguibile, dubito che ci si riesca "a mente".

Esatto.
Tant'e' che se l'algoritmo e' remoto, allora c'e' ben poco da fare.

[tomminno]

Originariamente inviato da Nazzyyy

e infatti
qua non è solo da scoprire l'algoritmo??
le key sono giuste e valide..


vedete ke non è impossibile ;DD



(è improbabile xd)

Non le chiavi che vedi te (che è il codice fornito dal programma), ma le chiavi dell'algoritmo di cifratura! Quelle dell'AES,3DES ecc...

Se prendi un debugger avanzato, ti attacchi in debug al software di tuo interesse e capisci (ben più di) qualcosa di assembly x86 potresti anche riuscire a ottenere qualcosa...

Se il software usa le funzioni di cifratura delle API di windows potrebbe essere più semplice perchè ti basta installare un hook di sistema e sostituirti alle chiamate SystemFunction040 e similari, sarà il programma a darti tutti i dati che ti servono, credendo di darle al sistema operativo...

[tomminno]

Originariamente inviato da yorkeiser

Suppongo l'algortimo venga scoperto disassemblando l'eseguibile, dubito che ci si riesca "a mente".

Se il software usa le api di cifratura di windows non c'è bisogno nemmeno di disassemblare niente, basta uno dei tanti software che installano hook sulle chiamate di sistema e vedrai magicamente passare tutti i dati che ti servono...

Motivo principale per non usare mai le API di windows quando si parla di sicurezza.

[tomminno]

Originariamente inviato da gugoXX

Esatto.
Tant'e' che se l'algoritmo e' remoto, allora c'e' ben poco da fare.

Anche se l'algoritmo è remoto il software deve implementare comunque la decodifica, altrimenti come fa a riconoscerne la validità?
E se ti affidi esclusivamente a comunicazioni remote chi ti dice che l'utente non simuli le stesse chiamate che esegui te, facendosi ritornare sempre qualcosa di valido?
Alla fine basta sniffare tutte le comunicazioni via socket del programma e analizzare i dati che passano.

[yorkeiser]

Originariamente inviato da tomminno

Se il software usa le api di cifratura di windows non c'è bisogno nemmeno di disassemblare niente, basta uno dei tanti software che installano hook sulle chiamate di sistema e vedrai magicamente passare tutti i dati che ti servono...

Motivo principale per non usare mai le API di windows quando si parla di sicurezza.

Beh oddio, considerando che la maggior parte dei software commerciali vengono venduti nelle varie versioni win/linux/mac/macchina da cucire, dubito che in questi casi un programmatore intelligente usi le vespe di winnezza per proteggere una versione e poi riscriva un codice totalmente diverso per un'altra... comunque, di certo negli altri casi può verificarsi lo scenario da te proposto.

[gugoXX]

Originariamente inviato da tomminno

Anche se l'algoritmo è remoto il software deve implementare comunque la decodifica, altrimenti come fa a riconoscerne la validità?
E se ti affidi esclusivamente a comunicazioni remote chi ti dice che l'utente non simuli le stesse chiamate che esegui te, facendosi ritornare sempre qualcosa di valido?
Alla fine basta sniffare tutte le comunicazioni via socket del programma e analizzare i dati che passano.

Immagina che il servizio cui vorresti fruire tramite il tuo client, sia un servizio offerto da un server remoto.
Autenticazione e utilita' del tutto stanno li' sul server, il tuo client e' solo un'interfaccia.
In questo caso, pur conoscendo N password, sara' difficile se non impossibile indovinarne una N+1esima accettabile dal server.

[tomminno]

Originariamente inviato da gugoXX

Immagina che il servizio cui vorresti fruire tramite il tuo client, sia un servizio offerto da un server remoto.
Autenticazione e utilita' del tutto stanno li' sul server, il tuo client e' solo un'interfaccia.
In questo caso, pur conoscendo N password, sara' difficile se non impossibile indovinarne una N+1esima accettabile dal server.

Si, ma il caso più diffuso è indubbiamente quello della protezione di software che girano esclusivamente sulla macchina dell'utente.

[gugoXX]

Originariamente inviato da tomminno

Si, ma il caso più diffuso è indubbiamente quello della protezione di software che girano esclusivamente sulla macchina dell'utente.

Si', certo, l'algoritmo remoto era una ciliegina, tanto per dimostrare che con le sole chiavi in ingresso non si puo'. Qualsiasi risposta e' teoricamente plausibile.

Comunque, si', le protezioni locali sono il caso piu' diffuso. Finora...

[cionci]

Quello che vuoi fare te è praticamente impossibile.
Leggi un po' qui: http://www.oneitsecurity.it/04/09/20...crittoanalisi/
Tu sei nel secondo caso... Solo che per sfruttare quell'attacco c'è la necessità di una grossa quantità di coppie di testi cifrati e comunque alcune caratteristiche dell'algoritmo.

[Nazzyyy]

Originariamente inviato da cionci

Quello che vuoi fare te è praticamente impossibile.
Leggi un po' qui: http://www.oneitsecurity.it/04/09/20...crittoanalisi/
Tu sei nel secondo caso... Solo che per sfruttare quell'attacco c'è la necessità di una grossa quantità di coppie di testi cifrati e comunque alcune caratteristiche dell'algoritmo.

grazie x l'Aiuto

[nikel]

un programma che scopra l'algoritmo che collega 2 chiavi alfanumeriche date un numero x di chiavi valide... wow sarebbe a dir poco fantascienza!!

@ Nazzyyy il tuo secondo esempio mi ricorda molto qualcosa...

[fero86]

Originariamente inviato da tomminno

Motivo principale per non usare mai le API di windows quando si parla di sicurezza.

rettifica: quando si parla di security-by-obscurity.

[tomminno]

Originariamente inviato da fero86

rettifica: quando si parla di security-by-obscurity.

Non è questo il caso, installando l'hook sulle funzioni delle cryptoapi ti interponi tra il software e il sistema operativo per cui riesci a leggere key e iv prima che vengano utilizzati per la cifratura e recuperi anche i dati in chiaro prima che vengano cifrati.
Basta una sbirciatina con dependency walker (o reflector per programmi .net) per capire quali funzioni vengono usate.
Ad esempio SecureString del .NET è una classe totalmente inutile, ti protegge dal memdump ma non dall'hook su SystemFunction040.

[WarDuck]

Ma questi hook possono essere installati anche senza privilegi admin?

[tomminno]

Originariamente inviato da WarDuck

Ma questi hook possono essere installati anche senza privilegi admin?

Fortunatamente no.
Però per qualcuno che vuole "esaminare" nel dettaglio un software non è un problema.

[fero86]

Originariamente inviato da tomminno

Non è questo il caso,

si che lo é: se il tuo avversario é un programma malizioso che gira sulla tua stessa macchina tu per lui non stai usando l'algoritmo di cifratura X con una chiave segreta, stai usando l'algoritmo X con una chiave nascosta tramite security by obscurity (che é una cosa ben diversa) perché la chiave é "nascosta" dall'assunzione errata che il nemico non riuscirá a scovarla facendo reverse engineering sul tuo programma. di fatto non stai usando l'algoritmo X noto: ne stai usando una versione X' ignota che corrisponde ad usare X con una ben determinata chiave K. ma la versione X' é vulnerabile e non resterá ignota per molto.

parliamo invece di un altro contesto dove le CryptoAPI di Windows sono estremamente utili: le comunicazioni di rete. se é ragionevole assumere che il nemico non stia sulla tua macchina, bensi ad esempio in un router intermedio, le CryptoAPI vanno benissimo, anzi bisognerebbe usare quelle perché é inutile reinventare 6000 ruote rischiando anche di produrre risultati errati; se si usano le CryptoAPI i risultati saranno orientativamente corretti e in piu hai il vantaggio di poter scaricare su Microsoft la responsabilitá di qualunque vulnerabilitá. é stupido non usarle.

Originariamente inviato da tomminno

Fortunatamente no.

mi sa tanto di si invece

é vero che non posso accedere con pieni permessi ad alcuni processi che girano sulla macchina, ma posso sempre simulare il tutto all'interno del mio processo, sul quale posso fare quello che voglio, incluso modificare le DLL di sistema mettendoci degli hooks.

non é molto difficile far partire un programma all'interno del proprio processo: si carica il modulo eseguibile normalmente con LoadLibrary, si cerca l'indirizzo dell'entry point (il formato PE é ben documentato) e lo si invoca direttamente usando il prototipo della mainCRTStartup. prima di fare tutto ció é possibile installare quanti API hooks ti pare. una libreria molto buona per installare hooks é Microsoft Detours.