CAAD

Comunidad de Aventuras Conversacionales y Relatos Interactivos
Fecha actual 29 Jun 2017 11:53

Todos los horarios son UTC + 1 hora




Nuevo tema Responder al tema  [ 39 mensajes ]  Ir a página Anterior  1, 2, 3
Autor Mensaje
NotaPublicado: 16 Ene 2017 00:54 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4606
dddddd escribió:
Uto, ¿has visto realmente lo que dije hace unos mensajes? Estamos duplicando trabajo.


No, no lo he leido bien. Efectivamente estamos duplicando trabajo, y de hecho tú vas más avanzado. Lo verdaderamente preocupante es esa llamada a glk, que por lo que veo el parche aplicado simplemente manda la escritura al limbo, por lo que las pocas funciones que la leen, fallan (el caso de SAVE que has puesto).

Parchear en :nombreanterior como he dicho es necesario, pero al tiempo es muy fácil.

Parchear las llamadas a GLK no tanto, pero supongo que se generará algo como 0x130 0x?? ox?? 0x00 (siendo 0x130 el opcode de 'glk'). Parchear esas llamadas es relativamente fácil, pero además habría que detectar los casos en los cuales después hay un jz o un jnz, que no son muchos, para parchearlos también. Tampoco es que sea imposible, pero me preocupa más saber en que lugar de la RAM podría ponerse eso sin pisar nada. No me queda muy claro como trabajan los intérpretes de Glulx por lo que no me arriesgaría a buscar la ultima dirección utilizada, si es que se puede, y ponerla justo encima, porque lo mismo se hace un malloc justito y la liamos. La única solución en ese caso es machacar algo, pero la posición de todas las demás variables es variable así que creo que la mejor manera de hacerlo es machacar la primera instrucción o esa de las funciones glulx que hay justo detrás del :main, dado que incluso si le damos a "jugar otra vez" saltamos justo detŕas de eso,así que no importa machacarlo:



Código:
:main
 dc.b 0xc0 0x00 0x00
 setiosys 2 0
:jugar_otra_vez


¿Y donde está eso localizado exactamente? Pues la dirección está en la cabecera de Glulx, en el apartado "Start Func".

Es decir, si StartFunc = 0x7823 habría que cambiar todos los

0x130 ? ? 0x00

por

0x130 ? ? 0x7823

y si luego hay un jz, jnz o lo que sea, cambiar el

jz (0)

por

jz ( 0x7823)

Notese que no se como se almacena eso en memoria, obviamente en un byte no hay un 0x7823 pero no se si se graba como 0x78 0x23, 0x23 0x78, o incluso 0x00 0x00 0x78 0x23 que se trata de una máquina de 32 bits.

No se si le gustará a los interpretes que se machaque la cabecera de la funcion main (el dc.b) pero en el peor de los casos se puede machacar el setiosys, que no hace ya falta para nada, o sea (Start Func + 3)

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 16 Ene 2017 01:14 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1853
El lugar natural de destino de la falsa glkresult es la existente glk_result. Tengo un método para obtener su dirección desde el binario, a partir de una llamada correcta que existe. La encuentra en todas las aventuras.

Tengo bastante avanzado un script de parcheo, de forma que todo sea automático. Ya soluciona varios errores. Analizaré lo de nombreanterior, porque seguramente provoca el error que todavía obtengo en las obras parcheadas. Hasta ahora estaba muy centrado alrededor de glk y compañia, con buenos resultados.


Arriba
 Perfil  
 
NotaPublicado: 16 Ene 2017 01:52 
Desconectado
Implementador
Implementador

Registrado: 09 Jun 2010 14:50
Mensajes: 1575
Ubicación: Argentina
Enhorabuena, dddddd. Me alegro de que estés pudiendo avanzar aun sobre los binarios cuyos fuentes no están disponibles.
Este trabajo ameritaría un «artículo técnico» en el SPAC.


Arriba
 Perfil  
 
NotaPublicado: 16 Ene 2017 09:48 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4606
dddddd escribió:
El lugar natural de destino de la falsa glkresult es la existente glk_result. Tengo un método para obtener su dirección desde el binario, a partir de una llamada correcta que existe. La encuentra en todas las aventuras.


Ah genial, en ese caso desde luego es el mejor sitio :-)

dddddd escribió:
Tengo bastante avanzado un script de parcheo, de forma que todo sea automático. Ya soluciona varios errores. Analizaré lo de nombreanterior, porque seguramente provoca el error que todavía obtengo en las obras parcheadas. Hasta ahora estaba muy centrado alrededor de glk y compañia, con buenos resultados.


Sin duda, corresponde al opcode copy que han parcheado recientemente Zarf y Kinder. Lo bueno es que ese debe ser fácil de localizar por el contexto.

El de canal_sonido que debería ser canal_efectos puede que lo puedas parchear también porque la llamada a glk es única, y poco antes de esa llamada tienes la de :canal_musica, que por suerte es la variable anterior a canal_efectos. Este caso de todos modos no es peligroso en cuanto a que dé error el interprete, pero ya que estás...

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 18 Ene 2017 00:17 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1853
Superglus beta 2 (24apr2004) localizada en:

ftp://ftp.funet.fi:21/pub/mirrors/ftp.i ... superglus/


Arriba
 Perfil  
 
NotaPublicado: 18 Ene 2017 10:10 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4606
dddddd escribió:
Superglus beta 2 (24apr2004) localizada en:

ftp://ftp.funet.fi:21/pub/mirrors/ftp.i ... superglus/



Me la guardo, aunque sea porque esa tendrá además el asunto de los opcodes.

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 24 Ene 2017 15:20 
Desconectado
Implementador
Implementador

Registrado: 13 Feb 2005 18:57
Mensajes: 1853
Uto escribió:
me preocupa más saber en que lugar de la RAM podría ponerse eso sin pisar nada [...] [quizá] machacar la primera instrucción o esa de las funciones glulx que hay justo detrás del :main, dado que incluso si le damos a "jugar otra vez" saltamos justo detŕas de eso,así que no importa machacarlo

Las instrucciones del juego se consideran --si entiendo bien-- ROM, así que esta opción no sería válida. Aunque ya encontramos alternativa, saco el tema de nuevo porque...

En World of Witchcraft hay un problema extra, ya que parece que el autor utiliza algún truco de reescribir su propio código en tiempo de ejecución, o de utilizar un espacio que ha se dejado entre instrucciones para almacenar algún dato (quizá alguna creación dinámica de objetos). No tengo muy claro lo que pretende, pero debido a ello me parece que el parcheo de esta obra no va a ser posible en primera instancia, puede que nunca. Necesitará un intérprete que no compruebe ninguna escritura en ROM.

Código:
Glulxe fatal error: Memory write to read-only address (37A10)


Uto escribió:
supongo que se generará algo como 0x130 0x?? ox?? 0x00 (siendo 0x130 el opcode de 'glk')

Es un poco más complicado que directamente el número de opcode. Hay unas reglas que indican cómo se codifican. En concreto, se representa como 0x81 0x30.

http://eblong.com/zarf/glulx/glulx-spec_1.html#s.5
1.5 Instruction format.

Uto escribió:
"glkresult" se usa en muchísimos sitios, pero en realidad está definida como "glk_result", esta es muy chunga porque es usada como tercer parámetro de todas las llamadas a glk para retornar un valor. La verdad es que es muy sorprendente que esta función no cause la alerta en glulxe si no está específicamente parcheada. Solo se me ocurre pensar que la escritura en ROM en este caso no la hace exactamente glulxe, sino la librería Glk.

El opcode glk es la primero que parcheó zarf (envío al limbo) en glulxe, antes del añadido de DavidK. Commit 2e182f091461.

Uto escribió:
"nombreanterior" creo que es la que se ha detectado ahora, la variable realmente se llama nombre1anterior y solo aparece en un sitio: copy 255.l (:nombreanterior).l . Probablemente modificar ese 255 y poner otro valores puede dar una idea de como encontrarlo en un binario para parchearlo y hacer que en lugar de copy 255.l (0) use una variable en RAM. Otra cosa es que no entiendo muy bien es que ese supone que eso limpia el nombre de frases anteriores, no recuerdo muy bien por qué, y si lo está grabando en 0 en lugar de donde esté :nombre1anterior pues no lo limpia, lo cual es lo correcto y de hecho en los fuentes actuales la linea está corregida con la variable correcta pero también está comentada (;copy 255.l (:nombre1anterior).l). Quizá lo ideal sería simplemente cambiar ese copy 255.l (0) por nops

Sí, este opcode copy es el que parcheó DavidK y efectivamente es el culpable del error en tiempo de ejecución tras introducir un comando en el juego.

Superglús 1.0 tiene el cambio que mencionas:
Código:
- copy 255.l (:nombreanterior).l
+ ;copy 255.l (:nombre1anterior).l

Así que parece razonable (y ha funcionado bien) parchear con NOPs.

Uto escribió:
"canal_sonido" solo se utiliza una vez, en un sitio donde debería poner "canal_efectos", pero como es de lectura no veo demasiado problema. [...] la llamada a glk es única [...] Este caso de todos modos no es peligroso en cuanto a que dé error el interprete, pero ya que estás...

Como bien decías, es relativamente fácil encontrar la dirección buena. Esto también lo parcheo y mejor reaccionará a la creación del canal.

Entre hoy y mañana te paso una primera versión del script, por si ves algo raro. Por cierto, ya tenemos nombre adecuado para las circunstancias, gracias a la genialidad de Al-K:

Arreglús


Arriba
 Perfil  
 
NotaPublicado: 25 Ene 2017 00:55 
Desconectado
Momio
Momio
Avatar de Usuario

Registrado: 09 Mar 2004 16:14
Mensajes: 4606
Fantástico trabajo el de Arreglús :-)

Lo del Witchcraft me suena un poco raro: Superglús no tiene de por sí posibilidad de meter cosas entre condactos, por lo que cualquier cosa que pueda haber metida por medio de algo ha tenido que ser un retoque de las librerías, lo cual no considero imposible dado que el autor tiene una maña bien conocida, pero sinceramente mi impresión es que ya no es que no pudiera, sino que en la época que creó esto no estaba en esa fase de tocarlo todo, y especialmente teniendo en cuenta que hablamos del puñetero assembler de Glulx. Quizá me equivoque, lo mismo él mismo puede decirnos algo si nos lee.

En cualquier caso, si me puedes dar más detalles al respecto de ese punto quizá se me ocurra algo.

_________________
Sígueme en twitter: @uto_dev
http://www.ngpaws.com


Arriba
 Perfil  
 
NotaPublicado: 27 Ene 2017 02:03 
Desconectado
Implementador
Implementador

Registrado: 09 Jun 2010 14:50
Mensajes: 1575
Ubicación: Argentina
En cuanto al Witchcraft, por suerte el hecho de que el autor haya sacado Héroes de la mazmorra en 2010, época en que Superglús ya no generaba estos binarios que escribían en la ROM, importa que de no ser posible el parcheado en primera instancia junto con las demás obras éste pueda esperar. Y es que en definitiva Héroes de la mazmorra tiene el mismo contenido que Witchcraft y más: jugar con múltiples razas con algunos quests distintos según la elegida, multimedia, hechizos adicionales, guardado y cargado en y desde memoria además del clásico en disco, y alguna cosa más.
No digo que existiendo la primera encarnación de lo que años después sería Héroes de la mazmorra haya que coartar la libertad del usuario de jugar si quiere a esa primera encarnación —adecuada para dispositivos como celulares o tabletas en que por espacio de almacenamiento o uso de otros recursos se prefiera jugar sin multimedia—, pero sí que, existiendo una obra sucedánea que aparte es del mismo autor, afortunadamente se puede esperar para el parcheo mientras se estudia la especial composición de su binario.


Arriba
 Perfil  
 
Mostrar mensajes previos:  Ordenar por  
Nuevo tema Responder al tema  [ 39 mensajes ]  Ir a página Anterior  1, 2, 3

Todos los horarios son UTC + 1 hora


¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado


No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro

Buscar:
Saltar a:  
cron
Desarrollado por phpBB® Forum Software © phpBB Group
Traducción al español por Huan Manwë para phpBB-Es.COM