Houston Tenemos un problema (Sces_501.39)

Tras mirar un rato este sles me encontre algo confundido.... no respondia a los patrones normales...

Por lo que tras localizar la rutina de checks busque los dvd checks cuando me encontre q eran de este formato...

jal CYBBLADECHCK -> funcion de DVD checks
paddub $a0, $s0, $0 #offset 68044
jal sub_198328

haber si alguno ha trasteado con esto...
En que juego?, si se puede saber
en el WRC han posteado el sles para los dvd checks
Pos eso

Pero no estoy seguro de lo que hemos hecho (tu por un lado y yo por otro).

A ver si alguien puede probarlos (el que tenga el juego) y nos dice cual le funciona.

Es el WRC???? es bueno??? porque ya tiene que serlo
Pues a pesar de todo yo tampoco lo tengo muy claro.
La solucion que he posteado toca directamente el registro $s1 ya que es al que el scmd_prechk va a revisar una vez llamada a la funcion.

Ya no está la carga en el registro $a0 del bit que le indica si la operacion ha sido o no un exito,por lo que supongo que esa comprobacion la hace insitu dentro del propio scmd_prechk.

La funcion CYBBLADECHK que es donde se hace la modificacion del daddub debe ser así ya que es aqui donde inicializa el $a0,de tan forma que si me lo cargo y lo sustituyo por lo que se supone que debe salir al final: li $s1,1,o sea el $s1=1.

Pero ojalá alguien lo pueda probar,porque me cagonto lo que se menea 40.000.000 de veces!!!!
yo creo que hay que cambiar

paddub $a0, $s0, $0 =28260072 en hex
por
li $a0,1 =01000424 en hex

por que hablais de 01001024?

si siempre se a sustituido por el otro


venga saludos a los dos
es por el registro q vamos a cambiar... no cambiamos el $a0 sino el $s0


daddu $s0, $a0, $0 (2D 80 80 00)

con

li $s0,1 (01 00 10 24)

en vez de

li $a0, 2 (02 00 04 24)
Originalmente enviado por mellin
yo creo que hay que cambiar

paddub $a0, $s0, $0 =28260072 en hex
por
li $a0,1 =01000424 en hex

por que hablais de 01001024?

si siempre se a sustituido por el otro


venga saludos a los dos

Como te ha dicho Cybblade,no estamos tocando el registro $a0,ahora el puntero a la pila ya no nos sirve ya que lo han metido dentro de uno de los registros que no tiene acceso a la pila: $s1.
Y la sentencia es daddu dentro de la funcion del check...por qué?
Por esto:
(ojo,que no estoy sentando catedra ni nada por el estilo ;) que me ha costao un huevo entender el porque podría ser así y no estoy ni seguro de ello )

daddu $s0, $a0, $0 -->
Meto lo que hay en $a0 en $0 sin preocuparme por el overflow
Pero si lo cambio por esto:
li $s1,1 -->
modifico el s1 de tal forma que en ese registro (que parece que es donde quiere ir a buscar la info) le digo que ya está encontrado
La operacion anterior ddadu sacaba de la pila los datos para comprobar el dvdcheck y los metia en $s0 y en $0 sin preocuparle el overflow (ya que es como si lo repartiera en ambos registros) y luego,dentro de la funcion del check jugaba con el registro $s1 hasta conseguir que este fuera el que realmente viera si los datos eran correctos (se asemeja a la tipica funcion de ensamblador de cryptografia básica -espero que los que sepan ensamblador no se me echen al cuello,he dicho se asemeja y no es criptografia..).
De todas formas la pila de datos de la ps2 es la leche!!!!tiene 4 punteros (que se vean a simple vista)...donde estan el sp y el bp de nuestro querido msdos???? [mamaaaaa]
7 respuestas