Da qualche tempo mi stanno arrivando delle notizie riguardo a preoccupazioni circa l'uso del client di SimRacingTools. le preoccupazioni riguardano la sicurezza del proprio pc, dei dati contenuti e delle potenziali azioni che il client potrebbe fare.
Ci tengo a sottolineare che le preoccupazioni possono essere comprensibili, si tratta di un client a cui vengono dati permessi di amministratore e che nulla si sa su cosa fa e dove lo fa, se l'azione si limita al controllo per il quale viene dichiarato o se va oltre. In poche parole se può svolgere azioni malevoli.
Ebbene, scopo di questo post non è quello di convincere chi in animo non vuole credere ma chiarire sul perchè di alcune scelte tecniche e come queste sono ritenute da me utili ai fini dello scopo prefissato.
Premessa, lunga ma importante.
Senza addentrarmi eccessivamente in disquisizioni filosofiche faccio notare come i requisiti di privacy e di protezione dei dati, anche sensibili, sono sempre stati in antitesi con quelli di sicurezza e controllo. Lo vediamo nella vita reale con l'attualità dei nostri giorni ed è facile immaginarlo anche in un piccolo ambito come quello del cheating.
Io ritengo che il miglior modo, forse l'unico, per individuare l'utente che fa uso di cheat sia quello di individuare l'utente che materialmente usa il cheat. Ogni analisi eseguita a valle è intrinsecamente debole. Mi spiego meglio: individuare i cheat basandosi sull'effetto che i cheat producono è certamente una strada valida ma poco efficace e con molti limiti. Gli effetti analizzabili sono consultabili sulla telemetria ovvero, visto che i cheat consentono l'alterazione delle prestazioni del veicolo (parlando di simracing) e visto che molti simulatori (non tutti però) consentono l'export della telemetria, allora in linea teorica sarebbe possibile individuare l'uso del cheat confrontando le telemetrie ovvero verificando quale di queste mostrano valori diversi dalle altre o, meglio sarebbe ancora, diversi da quanto atteso. Chi ha un minimo di esperienza nell'ambito del simracing o anche in generale nell'ambito dell'online gaming sa bene che trane casi sporadici e solo nei casi più eclatanti questo tipo di controllo può essere valido.
Se ad esempio un utente usa un cheat che blocca il consumo del carburante allora il semplice controllo della telemetria può essere più che sufficiente per individuare non il cheat ma l'effetto del cheat. Cosa succede però se l'utente più malizioso non blocca il consumo ma semplicemente lo riduce quanto basta per rientrare nei margini del tenicamente possibile? Quale amministratore di lega può, senza ogni ragionevole dubbio, dichiarare che quell'utente ha fatto uso di cheat scartando l'ipotesi che si tratti invece di un setup e di una capacità di guida migliore delle altre? Identico discorso si può fare per le temperature dei pneumatici o del drag o di ogni altro parametro della fisica che, se migliorato anche solo di poco, può portare sensibili benefici e decidere l'esito della competizione.
Per questa ragione SRT, nello svolgimento del suo compito, non lavora usando i dati prodotti a valle ma individua i cheat in funzione o installati a prescindere se questi stanno producendo effetti.
SRT individua i cheat usando 3 diversi metodi:
1) scan dei processi
2) scan dei filesystem
3) analisi della telemetria (solo per rFacttor2 e, prossimamente, anche per rFactor)
Sia per lo scan dei processi e sia per lo scan dei filesystem viene usato il database dei cheat ovvero una lista di cheat, continuamente arricchita.
Per entrambi i casi l'approccio è quello euristico per individuare i possibili match seguito da un approfondimento più preciso.
Lo scan dei processi viene eseguito dal client mentra l'analisi viene poi svolta dal server. Per quanto riguarda il filesystem tutto il lavoro viene svolto dal client il quale riceve la lista dei cheat da individuare.
Il traffico dati da e verso il client è composto principalmente da due componenti:
1) i report che il client produce contenente i processi attivi da inviare per l'analisi lato server. In questi report sono contenuti anche gli estremi delle connessioni di rete a carico degli exe di gioco (processo che ha eseguito la connessione, ip e porta verso cui è stabilita la connessione).
2) sincronizzazione del client nei confronti del server ovvero un azione che il client svolge periodicamente per fasarsi con il server e ricevere i dati parametri necessari per il suo funzionamento. I paramentri consentono di variare il modo di operare del client, ogni quanto eseguire una operazione, con che priorità, la lista dei cheat etc.
Veniamo ora ai punti caldi ovvero a quelle azioni che il client fa o farebbe è che destano preoccupazioni.
1) diritti di amministratore. Questi privilegi sono necessari non tanto per l'esecuzione degli scan quanto per permettere l'installazione autonoma dei plugin di estrazione telemetria e dei suo file di configurazione. Questi plugin consentono di estrarre la telemetria dai simulatori ISI e permettono la terza fase di analisi quella appunto sulla telemetria.
Senza i diritti di amministratore un processo di windows non può creare un file su una cartella diversa dalla sua installazione e quindi verrebbe meno parte dell'automatismo che contraddistingue il client SRT che è poi necessaria per rendere l'uso facile a tutti gli utenti. Avere un applicazione che svolge autonomanente tutte le operazioni necessarie al fine del suo lavoro è fondamentale affinchè ogni utente, anche poco esperto, sia in grado di usarlo senza diventare fonte di ulteriore preoccupazione e difficoltà.
2) traffico dati da e verso il server e controllo remoto. Come gia spiegato il traffico dati contiene unicamente i risultati parziali dell'analisi ed i parametri utili al funzionamento del client. In nessun modo vengono inviati al client parti di codice che poi possono essere eseguiti. Tutto il codice è gia all'interno del client. La comunucazione client server avviene tramite il protocollo HTTP dove è il client a invocare il server e mai il contrario.
Nessuna delle informazioni da me date può fugare tutti i dubbi, non era questa l'intenzione. L'intenzione è spiegare le ragioni di certe scelte tecniche ed il modo in cui queste vengono eseguite. Chi ha fiducia nel funzionamento di SRT e chi crede che SRT si limiti a svolgere il lavoro che dichiara e unicamente questo sicuramente non aveva bisogno di leggere quanto sopra per tranquillizzarsi. Chi invece ritieneva (e continua a ritenere) che in qualche modo SRT vada oltre il compito dichiarato allora nessuna spiegazioneo divulgazione di dettaglio tecnico sarà mai sufficiente.
Chi vi scrive lavora nell'IT da oltre 20 anni e tenta di mettere a frutto la sua esperienza al servizio della sua passione tentando nella difficilissima opera di coniugare entrambi, è inoltre da 13 anni amministratore e creatore di una importante comunità di simracing italiana (
www.gtitalia.org).
Questo è tutto
Mauro Musella
Show Posts
) one of most seroius the caused the interruption of real monitor.