Domanda [HELP] AutoPatcher e avviare gioco

Stato
Discussione chiusa ad ulteriori risposte.

Laiton

Utente Silver
21 Marzo 2009
115
9
46
96
salve,
volevo solo un'informazione. Ho un autopatcher che fa il suo dovere e cliccando sul tasto apposito mi avvia il metin2.exe.
Come faccio a far avviare il metin2.exe SOLO tramite l'autopatcher?
grazie
 
Devi inserire l'argument :D
Ah ps.
l'autopatcher oltre a fare "avvia metin2.exe" aggiorna i file del client..
 
Nessuno sa aiutarmi?
mi basta sapere anche solo la logico, al resto penso io :D
La risposta corretta: è impossibile.
Se un programma è eseguibile - allora è eseguibile da chiunque abbia i permessi di farlo. Togliere all'utente i permessi di farlo, impedisce che anche il tuo software (autopatcher) possa avviare il programma. Per cui il problema non ha soluzione.
 
@SpeedJack mi sa che tu hai inteso male...
Vuole far avviare il metin2.exe solo da autopatcher. Se apri metin2.exe dovrebbe darti un errore.
Si chiama argument..
 
  • Mi piace
Reazioni: Laiton
Devi inserire l'argument :D
Ah ps.
l'autopatcher oltre a fare "avvia metin2.exe" aggiorna i file del client..
Ok, non ho mai sentito di questa cosa, ma mi informo subito.
Si si so cosa fa un autopatcher xD

@SpeedJack mi sa che tu hai inteso male...
Vuole far avviare il metin2.exe solo da autopatcher. Se apri metin2.exe dovrebbe darti un errore.
Si chiama argument..
Si perfettamente quello che voglio fare :)

Grazie a tutti per la risposta ;) ora vedo se riesco a cavarmela da solo xD
 
No ho capito benissimo.
"argument" non è una 'protezione' come molti qui credono - è soltanto l'inglese di "argomento". Avviando un programma è possibile passargli degli argomenti 'da linea di comando'.
Ad esempio il "ping" è un programma. Se da prompt dei comandi si da "ping google.com" quel "google.com" è un argomento inviato al programma ping.
Quello che generalmente viene applicato come 'protezione' (decisamente scarsa) è quello di modificare il programma da avviare (metin2.exe) in modo che: a) prelevi l'argomento da linea di comando; b) controlli che l'argomento sia uguale ad un certo valore scelto. Poi nel programma chiamante (l'autopatcher) viene avviato il programma da chiamare passandogli l'argomento scelto.

Questo però non impedisce all'utente di avviare il programma anche senza l'autopatcher. Infatti è sufficiente avviare il programma con "metin2.exe <argomento>" e il programma si avvia senza problemi.
Anche prendere l'argomento è banale - ci sono 3 modi, tutti semplicissimi:
1. Ottenere l'argomento dal programma da avviare tramite reversing (o debuggando il programma e ottenendolo dal risultato della chiamata di GetCommandLine oppure, senza che sia necessario un debug, prendendo quello già necessariamente salvato come costante dentro il programma);
2. Ottenere l'argomento dall'autopatcher tramite reversing (tra l'altro, dato che solitamente gli autopatcher vengono scritti in .NET, è ancora più banale);
3. Semplicemente utilizzare uno dei tanti software per Windows per vedere con quale CommandLine è stato creato un processo (roba da 5 secondi).

Impedire all'utente di avviarlo, come l'autore del topic ha chiesto, è impossibile. E questo "argument" come viene chiamato è bypassabile anche da uno scimpanzé ubriaco.
Si perfettamente quello che voglio fare
Il problema è che anche così non risolvi nulla: risolvi solo che non si avvia al doppio click, ma basta dare "metin2.exe <argomento>" e si avvia subito.
 
  • Mi piace
Reazioni: Laiton
No ho capito benissimo.
"argument" non è una 'protezione' come molti qui credono - è soltanto l'inglese di "argomento". Avviando un programma è possibile passargli degli argomenti 'da linea di comando'.
Ad esempio il "ping" è un programma. Se da prompt dei comandi si da "ping google.com" quel "google.com" è un argomento inviato al programma ping.
Quello che generalmente viene applicato come 'protezione' (decisamente scarsa) è quello di modificare il programma da avviare (metin2.exe) in modo che: a) prelevi l'argomento da linea di comando; b) controlli che l'argomento sia uguale ad un certo valore scelto. Poi nel programma chiamante (l'autopatcher) viene avviato il programma da chiamare passandogli l'argomento scelto.

Questo però non impedisce all'utente di avviare il programma anche senza l'autopatcher. Infatti è sufficiente avviare il programma con "metin2.exe <argomento>" e il programma si avvia senza problemi.
Anche prendere l'argomento è banale - ci sono 3 modi, tutti semplicissimi:
1. Ottenere l'argomento dal programma da avviare tramite reversing (o debuggando il programma e ottenendolo dal risultato della chiamata di GetCommandLine oppure, senza che sia necessario un debug, prendendo quello già necessariamente salvato come costante dentro il programma);
2. Ottenere l'argomento dall'autopatcher tramite reversing (tra l'altro, dato che solitamente gli autopatcher vengono scritti in .NET, è ancora più banale);
3. Semplicemente utilizzare uno dei tanti software per Windows per vedere con quale CommandLine è stato creato un processo (roba da 5 secondi).

Impedire all'utente di avviarlo, come l'autore del topic ha chiesto, è impossibile. E questo "argument" come viene chiamato è bypassabile anche da uno scimpanzé ubriaco.

Il problema è che anche così non risolvi nulla: risolvi solo che non si avvia al doppio click, ma basta dare "metin2.exe <argomento>" e si avvia subito.
Ti ringrazio per la spiegazione. In mancanza di una vera e propria soluzione, mi accontento di questo.
 
Ti ringrazio per la spiegazione. In mancanza di una vera e propria soluzione, mi accontento di questo.
Credo sia più una perdita di tempo che altro.
Comunque, per applicarlo, salvo che non ci sia già roba pronta sul web (probabile - ma non bazzico in metin2), basta che:
- nell'autopatcher richiami l'API CreateProcess passando l'argomento che scegli come secondo parametro (lpCommandLine) alla funzione; se lo fai in .NET invece crei un'istanza della classe ProcessStartInfo, ne riempi le proprietà Arguments e FileName e poi avvii con il metodo Start().
- nel file di gioco è più complicato: va modificato l'assembler in modo che richiami la funzione GetCommandLine (cosa che probabilmente fa già, ma il risultato viene ignorato) - prendere il puntatore che ritorna (che sarà un puntatore a stringa) e leggere la stringa a cui punta e confrontarla con la costante stringa dell'argomento che hai scelto (costante che hai inserito da qualche parte - o anche semplicemente inserisci inline nell'assembler controllando quindi a blocchi di 32 bit). Per inserire tutto questo codice avrai bisogno di inserire un JMP poco dopo l'entry-point che ti porti ad un'area vuota dove puoi scrivere - inserisci tutto il codice che ti serve (CMP ecc.) compreso anche il codice che hai dovuto cancellare per piazzare la JMP - e poi con un'altra JMP torni dove prima. Puoi usare anche CALL ovviamente.
 
  • Mi piace
Reazioni: Laiton
Ultima modifica:
Credo sia più una perdita di tempo che altro.
Comunque, per applicarlo, salvo che non ci sia già roba pronta sul web (probabile - ma non bazzico in metin2), basta che:
- nell'autopatcher richiami l'API CreateProcess passando l'argomento che scegli come secondo parametro (lpCommandLine) alla funzione; se lo fai in .NET invece crei un'istanza della classe ProcessStartInfo, ne riempi le proprietà Arguments e FileName e poi avvii con il metodo Start().
- nel file di gioco è più complicato: va modificato l'assembler in modo che richiami la funzione GetCommandLine (cosa che probabilmente fa già, ma il risultato viene ignorato) - prendere il puntatore che ritorna (che sarà un puntatore a stringa) e leggere la stringa a cui punta e confrontarla con la costante stringa dell'argomento che hai scelto (costante che hai inserito da qualche parte - o anche semplicemente inserisci inline nell'assembler controllando quindi a blocchi di 32 bit). Per inserire tutto questo codice avrai bisogno di inserire un JMP poco dopo l'entry-point che ti porti ad un'area vuota dove puoi scrivere - inserisci tutto il codice che ti serve (CMP ecc.) compreso anche il codice che hai dovuto cancellare per piazzare la JMP - e poi con un'altra JMP torni dove prima. Puoi usare anche CALL ovviamente.
ok grazie dell'aiuto. Vediamo cosa riesco a fare :D

EDIT:
allora, sto incontrando qualche problemino.
Premetto che sto usando questa guida (http://www.inforge.net/xi/threads/tut-argument-davvio-argument-davvio-con-msgbox-error.239663/) ma purtroppo non trovo la stringa "--hackshield".
Quindi sono ad un punto morto...
 
Impostando un semplice argument non otterrete nessun tipo di protezione, in quanto io posso benissimamente trovare l'argument...ma solo se quello che gli passo é una stringa fissa... e se invece l'argument fosse variabile?
Sicuramente non posso passare un numero random, allora cosa? Qual'è la cosa che può accomunare un patcher con un client? La risposta è il tempo... il patcher calcola il numero di minuti intercorsi tra una certa data (esempio anno 0) e il momento in cui l'utente preme il tasto Start e lo passa al client, il client farà lo stesso calcolo e lo confronterà con lpCmdLine (ovvero l'argument che gli è stato passato). Certo... se magari l'utente fa start a 59 secondi, può esserci la possibilità che il client starti a 00 quindi il numero di minuti sarebbe diverso e darebbe errore, ma vi basterebbe verificare che lpCmdLine sia <= del tempo ricalcolato +1 (quindi gli do uno scarto di 1 minuto).
Potranno anche trovarvi l'argument... ma questo ha una scadenza (nel nostro caso di 1 minuto)... io ho dato l'idea... adesso mettetela in pratica voi. Ah ovviamente io parlo per quelli che partono da un sorgente client, se pretendete di partire da client belli e fatti io non so che farvi ;)
 
Impostando {...} io ho dato l'idea...
Così è solo un poco più difficile. In realtà basta replicare l'algoritmo che genera l'argomento e utilizzare quello. Oppure, più banalmente, prendere il binario del gioco e togliere il controllo dell'argomento (di solito basta togliere un JMP).

Ad ogni modo se non trovi la stringa "--hackshield" è solo perché l'autore di quella guida utilizzava un binario che accettava il parametro "--hackshield" - mentre te hai un binario diverso che non accetta questo parametro.
Ad ogni modo da qualche parte c'è sicuramente la chiamata all'API GetCommandLine. Quindi: search for all intermodular calls > e cerca per "GetCommandLine".
Questa funzione prende proprio la lista di parametri e salva nel registro EAX un puntatore all'area di memoria che contiene la commandline.
Per capirci qualcosa chiaramente devi conoscere il linguaggio assembler.
 
Sto da Linux e non ho un ambiente Windows a disposizione - quindi io non posso fare nulla.
Però è possibile anche che GetCommandLine non venga proprio chiamato (anche se di solito si chiama sempre). Nel caso devi fare te la chiamata dopo l'entry-point del programma.
Ad ogni modo, inizio a pensare che stai utilizzando un binario compresso o protetto. Dovresti controllare con RDG Packer Detector.
 
Ecco il risultato.
 

Allegati

  • Immagine.png
    Immagine.png
    148.8 KB · Visualizzazioni: 56
Sì appunto - è compresso, e c'è un controllo con IsDebuggerPresent.
Per IsDebuggerPresent è sufficiente un plugin per olly in modo da nascondere il debugger all'API.
Per la compressione devi trovare l'entry-point originale del programma e poi fare un dump dalla memoria. Se però non sai niente di reversing e di assembler non puoi fare molto - e da Linux non posso farlo al posto tuo.
 
Sì appunto - è compresso, e c'è un controllo con IsDebuggerPresent.
Per IsDebuggerPresent è sufficiente un plugin per olly in modo da nascondere il debugger all'API.
Per la compressione devi trovare l'entry-point originale del programma e poi fare un dump dalla memoria. Se però non sai niente di reversing e di assembler non puoi fare molto - e da Linux non posso farlo al posto tuo.
Ti ringrazio per le spiegazioni.
 
Così è solo un poco più difficile. In realtà basta replicare l'algoritmo che genera l'argomento e utilizzare quello. Oppure, più banalmente, prendere il binario del gioco e togliere il controllo dell'argomento (di solito basta togliere un JMP).

Ad ogni modo se non trovi la stringa "--hackshield" è solo perché l'autore di quella guida utilizzava un binario che accettava il parametro "--hackshield" - mentre te hai un binario diverso che non accetta questo parametro.
Ad ogni modo da qualche parte c'è sicuramente la chiamata all'API GetCommandLine. Quindi: search for all intermodular calls > e cerca per "GetCommandLine".
Questa funzione prende proprio la lista di parametri e salva nel registro EAX un puntatore all'area di memoria che contiene la commandline.
Per capirci qualcosa chiaramente devi conoscere il linguaggio assembler.
Giusto...ma se alla fine il problema é voler creare questo tipo di...seccature (perchè protezione non si puo definire), allora é sempre meglio di far trovare la pappa pronta sul debugger...poi ovvio che se ci unisci un compressore, gli indici dei pack nel binario, e ad ogni update cambi la versione client e sul server attivi il controllo della versione client...hai praticamente azzerato la possibilitá di usare un binario/client diverso da quello prestabilito
 
  • Mi piace
Reazioni: SpeedJack
Se il problema comunque è che si vuole evitare che venga utilizzato un client diverso da quello scelto, la cosa migliore è sicuramente modificare il modo di comunicazione tra client e server: anche semplicemente aggiungere un handshake iniziale; oppure modificare il keep-alive (c'è sempre nei giochi MMO) in modo tale che sia possibile connettersi a quel server solo con quel client.
 
  • Mi piace
Reazioni: SunJoin
Se il problema comunque è che si vuole evitare che venga utilizzato un client diverso da quello scelto, la cosa migliore è sicuramente modificare il modo di comunicazione tra client e server: anche semplicemente aggiungere un handshake iniziale; oppure modificare il keep-alive (c'è sempre nei giochi MMO) in modo tale che sia possibile connettersi a quel server solo con quel client.
Ovviamente si... basta cambiare il pacchetto di login :D
 
Puoi attivare semplicemente il checkversion(pong).
Inoltre usando la source è tutto molto più semplice (se sai il linguaggio normalmente),
Bye.
 
  • Mi piace
Reazioni: Laiton
Stato
Discussione chiusa ad ulteriori risposte.