È fondamentalmente possibile verificare che una versione non modificata del client si connetta al tuo server?

È fondamentalmente impossibile convalidare un client su un sistema che non controlli.

Ciò non significa che non possa essere fatto in misura sufficiente. I lettori di e-book, ad esempio, generalmente cercano di garantire che il client sia autentico. Loro (sembrano) lo fanno in un modo sufficientemente sicuro per difendersi dalla loro minaccia. Abbastanza buono per proteggere i segreti nucleari? No. Ma abbastanza buono per il loro ambiente di minacce.

Scopri quanto è importante quel controllo per la tua applicazione e determina i controlli di compensazione che dovrai mettere in atto per limitare il danno quando qualcuno attraversa il problema di fare a pezzi e quindi imitare la tua applicazione. Non pensare in termini di bianco / nero, possibile / impossibile; pensa in termini di sicurezza accettabile e realizzabile.

Fondamentalmente impossibile per convalidare che una versione non modificata del tuo client si connette al tuo server.

... a meno che non faccia ciò che è necessario per assicurarlo. Ciò significa hardware resistente alla manomissione lato client.

Quando il codice viene eseguito sul computer del client, il proprietario del computer può eseguire un debugger e modificare il codice client in qualsiasi punto con valori arbitrari. Il "debugger" può essere una macchina virtuale in piena regola. Se vuoi evitarlo, puoi provare a impegnarti in un elaborato nascondiglio e cercare un gioco dove immagini sistemi di rilevamento extra, e gli attaccanti contrastano questi con varianti dei loro stessi strumenti. Questo è il problema delle persone che cercano di progettare soluzioni software anti-cheat (ad es. PunkBuster ); questo è anche il problema delle persone che vogliono vendere servizi Video-on-Demand impedendo ai clienti di salvare i video localmente e quindi pubblicarli su varie piattaforme di condivisione file.

Per riassumere, queste protezioni non funzionano bene, anche quando i dati da proteggere sono banali come vite extra in alcuni giochi.

Per evitare ciò, devi far funzionare il tuo codice su hardware protetto, che si difenderà da un'ispezione approfondita dal suo presunto proprietario. Questo è il modello di console di gioco, terminali di pagamento e smart card.

Un TPM è un tentativo di compromesso: un modulo antimanomissione che funziona all'interno di un normale PC; l'assunto è che un utente normale troverà troppo difficile modificare l'hardware per, ad esempio, leggere e scrivere tutta la RAM senza passare attraverso i pezzi sotto il controllo del modulo TPM (ad es. la CPU).

Senza tale hardware sul lato client, quello che stai cercando di fare non funzionerà. A meno che la modifica del codice cliente non sia così inutile di quanto nemmeno nessuno ci provi. Tutto dipende dal valore di ciò che è in gioco qui.

Potresti provare Cryptographic Obfuscation quando esiste

L'offuscamento crittografico è stato, in alcuni sensi, reso illeggibile un codice sorgente di un programma. Quello che puoi fare è inserire un codice crittografico nel programma con hardcode. Si vorrebbe anche che il server fornisca un seme casuale al programma poiché non è possibile attendersi il computer. L'unico problema con questo approccio è che l'Obfuscation crittografico è che non è stato ancora implementato, e che solo alcuni dei suoi sensi sono possibili.

Anch'io ho affrontato un problema come questo con la compagnia per cui lavoro. dopo settimane di lavoro, la risposta non è realmente possibile.

Ed ecco perché:

Stai fondamentalmente incontrando un problema "Trusted Client". Il codice client viene eseguito sul PC dell'utente e l'utente ha il pieno controllo sul PC da cui proviene. L'utente può modificare i byte del programma su disco, o anche in memoria in alcuni casi. Se dovessi provare a eseguire un hash o checksum contro il codice, potrebbe semplicemente cambiare il codice che ha effettuato tale verifica e renderlo "non modificato". È una tattica di fumo e specchi.

Potresti provare a rendere le cose un po 'più difficili a un utente malintenzionato ma non c'è un modo pratico per ottenere ciò che speri. Non senza diventare un grande mal di testa.

È possibile utilizzare HTTPS insieme all'autenticazione del certificato client. Quindi puoi assicurarti che solo i clienti con un certificato valido siano in grado di utilizzare il tuo sito.

Il certificato client sostituirà quindi la password che hai menzionato e l'utente non noterà la magia eseguita in background.

Se vuoi identificare in modo univoco l'utente , le chiavi API funzioneranno bene per te. Per utilizzare API di Facebook o Stack Exchange's API (ecc. Ecc.), Avrai bisogno di ottenere una chiave API per identificarti come un particolare utente dell'API e inviare tale chiave API ad ogni richiesta. Pertanto, ogni richiesta che colpisce l'API può essere fatta risalire a un utente originario. Ciò consente inoltre al proprietario dell'API di controllare chi accede all'API limitando a chi è consentito l'accesso a una chiave API.

Tuttavia, identificherà solo in modo univoco l'utente . Non verificherà che l'utente stia utilizzando il software originale (piuttosto che, ad esempio, un clone scritto da zero). Verificare che l'utente stia utilizzando il tuo software originale è praticamente impossibile, dal momento che si basa sul presupposto che l'utente non ha il controllo sul proprio computer e non può, ad esempio, eseguire il programma in un debugger e modificare le istruzioni del software a piacimento .