Hearts reversing

From UIC

Hearts revesing

Hearts reversing
Author:	SepticConvulsion
Email:	septicconvulsion@gmail.com
Website:
Date:	06/12/2008 (dd/mm/yyyy)
Level:
Language:	Italian
Comments:	Vediamo le carte degli altri giocatori

Introduzione

Visto che ero stufo di continuare a perdere costantemente contro "giovanna", ho deciso che avrei utilizzato le mie neonate conoscenze di reversing per barare.
Questo e' il mio primo reversing e... come dire... state attenti che potrei aver scritto delle cretinate! :)

Notizie sul Programma

Il target e' Rete di Windows Hearts 5.1 distribuito con Windows XP Home ed. Credo che le altre versioni non si discostino molto da quella reversata qui.

Essay

Come prima cosa ho messo un bp sulla funzione "rand" e "srand": a priori prevedevo che queste due funzioni sarebbero state usate per generare la distribuzione casuale delle carte. Altra regola generale è stato evitare di seguire tutte le chiamate esterne al modulo principale del programma (ovvero quelle fuori da "mshearts").

La prima chiamata di "srand" non ci dice niente di interessante sulle carte. Il gioco chiede quindi di inserire il nome del giocatore e subito dopo brekka su una chiamata a "rand". A occhio la sezione di codice non sembrava di nuovo quella cercata: la funzione rand veniva chiamata una sola volta, mentre per distribuire le carte (52 carte), era presumibile che rand si trovasse all'interno di un ciclo. In pratica qualcosa di simile a:

Per sicurezza mi sono messo cmq a steppare in di tutte le funzioni interne al modulo principale che seguivano. Non è servito a molto fino a che non sono entrato in 01007F89.

Questa sembra finalmente la parte cercata: contiene una bella chiamata a rand all'interno di un ciclo! Bene! Ora analizziamo la prima parte del codice.

ECX contiene il numero di carte contenute nel mazzo (52d = 42h) e viene passato come parametro dalla funzione chiamante.

Qui abbiamo un ciclo for che inserisce tutti i numeri da 0 a 52 nell'array posizionato all'indirizzo EBP+EAX*4-110. Chiameremo questo array "carte". Se non siete famigliari a come si accede a un array (non che io sia esperto, eh!) l'indirizzamento funziona cosi: EBP-110 è fisso per questo ciclo, e in pratica indica da dove inizia l'array "carte". EAX varia nel loop ed è indice che scorre l'array. Notare che è moltiplicato per 4 perchè si stanno scrivendo DWORD nell'array: quindi tra un entry è l'altra devono esserci 4 byte! Riassumendo in C sarebbe:

Tornando al listato assembler abbiamo:

Queste istruzioni servono esattamente a settare a 0 la variabile n_carte_date (il numero di carte distribuite dal mazzo) all' indirizzo EBP-14. In EBP-18 vengono salvate il numero di carte ancora da distribuire (in questo caso ancora 52), che ora chiamiamo n_carte_disponibili.

Analizziamo quindi il mega ciclo che inizia in 01007FB6 e finisce in 01008013.

Le condizioni per continuare a ciclare sono che n_carte_date sia < 52 (34h). In C:

Andando avanti col disassembato troviamo:

Rand ci sbatte valori random in EAX e ECX. CDQ non è che abbia gran utilita' qui (correggetemi se sbaglio). Quindi IDIV mette EAX = EAX / n_carte_disponibili e in EDX il resto di tale divisione. Dato che EDX puo' assumere valori compresi tra 0 e 52 questo fa presurre che EDX rappresenti appunto la carta che è stata estratta!

EAX assume n_carte_date, EDI e EBX prendono i valori di "max_carte_per_giocatore" (numero di carte da dare a ogni giocatore) e EBX il numero di giocatori; entrambe sono passati come paramentri dalla funzione chiamante.

Ancora IDIV: con due semplici calcoli si capisce che EAX indica ora a quale giocatore stiamo ora distribunedo le carte mentre EDX indica quante carte abbiamo gia' distribuito al giocatore corrente. Esempio: n_carte_date = 22 -> 22 / 13 = 1 resto 9 -> stiamo dando le carte al giocatore 2 (ricordate che EAX è un indice e quindi parte da 0) e ha gia 9 carte in mano (gli sitiamo dando la decima).

La SUB di solito non fa nulla perchè il secondo operando è (solo nel mio caso?) sempre 0. Poi segue l'operazione matematica EAX = (EAX + 4) / 4 = EAX / 4 + 1 e mette il resto in EDX (valore tra 0 e 3). Onestamente penso che la ADD non sia molto utile in quanto il resto della divisione non cambia e il quoziente non viene piu' considerato nel resto del ciclo. Inoltre EDX rappresenta sempre a quale giocatore stiamo distribuendo le carte, esattamente come EAX dopo 01007FCC.

EAX ora punta all' array "carte" (in EBP-110), entry data da ECX. In EBX finisce il la vera e propria carta, o meglio il "codice carta" che rappresenta la carta (in questo caso rappresentata da un numero intero).

SHL moltiplica EDI = EDI*16. ECX punta a un entry di un array di indirizzi, "mano_giocatore" (indirizzo in ESI+130) dove EDX appunto indica il giocatore corrente. EDX assume quindi il valore di un secondo array dove sono contenute le carte assegnate al giocatore corrente ("slot_carte"). L'ultimo MOV serve a immettere la carta scelta a caso nella mano del giocatore nell'entry segnalata da EDI*16 (ci sono 3 DWORD non scritte tra una volta e la seguente). In pratica: mano_giocatore(giocatore_corrente)->slot_carte(carte_giocatore_corrente) = carta(resto1)

Beh, ora il gioco è fatto! Abbiamo l'indirizzo in cui trovare le carte di ogni giocatore: tutti gli indirizzi contenuti nei 4 array "slot_carte". Per trovarli in memoria basta guardare i 4 indirizzi scritti in "mano_giocatore". Se facciamo un bel "follow in dump" del primo indirizzo (occhio che non è sempre lo stesso) si ha la figura seguente.

Il riquadro rosso rappresenta appunto "slot_carte": ke righe di "FF" sono entry a cui non e' ancora stata assegnata nessuna carta. Il riquadro verde sara' spiegato in seguito.

ECX punta direttamente a slot_carte del giocatore corrente e EBX viene azzerato con la XOR. Quindi le due variabili n_carte_disponibili e n_carte_date vengono aggiornate. Il CMP serve a controllare se si deve ancora ricominciare il ciclo o meno.

Entra in gioco un nuovo array in posizione "ECX+28" che si accede 4 byte si 4 no tramite EDI. Si puo' notare che questo array è il "complementare" di "slot_carte".

01008007 e 0100800A servono a fare in modo che ECX contenga il valore della carta con entry piu' alto all'interno di "carte" (non è detto che sia la carta di valore piu' alto!). La MOV successiva sposta tale carta nel posto di quella appena distribuita: EAX punta ancora all'entry della carta estratta da 01007FDC. Si nota che la lunghezza dell'array "carte" è uguale a n_carte_disponbili. Queste operazioni servono quindi a fare in modo che "carte(0 a n_carte_disponibili)" contenga solo carte non ancora distribuite. JL finale fa ricominciare se il CMP di 01007FFF ha dato esito positivo o no.

Il problema si sposta quindi nell'associare il numero che rappresenta ogni carta con l'effettiva carta giocata e a chi corrisponde ogni mano puntata in "mano_giocatore". Io ho usato un trucchetto: ho semplicemente modificato "slot_carte" appena terminata la distribuzione delle carte mettendo carte ripetute in mano. Sappiamo che tutte le carte sono uniche in hearts: si modifica la memoria di slot_carte (indirizzo dato da mano_giocatore(0)) mettendo due volte uno stesso codice carta (per esempio "00"). Facendo ripartire l'esecuzione, il gioco mostrera' che nella mia mano ci sono due carte uguali. Quindi si puo' associare il codice carta 00 all'asso di fiori. Si puo' estendere il ragionamento a forzare in mano anche 3 codici uguali, 4 codici ugali e 5 carte uguali, ogni volta scelgiendo un codice carta diverso. Facendo ripartire il gioco ritroveremo quindi gli abbinamenti codice carta <-> carta effettiva

Note Finali

L'obbiettivo è stato raggiunto. Basandomi sul tute di AlexMark sul Memory Patching and DMA Defeating, ora sto scrivendo un programmino per leggere direttamente la memoria del gioco durante l'esecuzione e outputtare le carte di tutte le mani. Devo solo capire un attimo quali sono gli indirizzi che variano ogni riavvio del gioco.

Scusatemi ancora per le eventuali cazzate che ho scritto e per la mia pessima conoscenza della programmazione (sono arrugginito e pigro). Consigli, commenti e correzioni sono MOLTO benvenuti.

Disclaimer