Registrarse

[Otros] LIPS | Tutorial | Estructura

FelixTheCat

Profesional de WaH
Hola a todos, el día de hoy vengo a explicar la estructura de los parches Lunar IPS (LIPS). Tal vez sea simple entender su estructura, pero creo que nadie lo ha explicado antes y considero que, a los nuevos, y no tan nuevos, les puede llegar a servir.
Introducción

El tutorial se basa en hexadecimal, así que vas a tener que poseer conocimientos básicos sobre él. Lo que voy a explicar esencialmente va a ser la estructura del parche, cómo está hecho. Esto te va a permitir identificar que modificaciones hace el parche y donde las hace. Lo más útil que vas a poder hacer es modificar dónde se hacen esas modificaciones, ya que muchas veces los parches modifican datos o insertan nuevos en direcciones de la ROM en las cuales nosotros, en nuestro proyecto, teníamos almacenados otros datos: esto provoca que se sobrescriban y se produzca una marea de bugs difíciles de identificar y resolver. Sin más que decir, empecemos…

Su estructura principal

Para explicar la estructura del parche, me voy a ayudar de una imagen en la cual se puede apreciar los datos hexadecimales de un parche LIPS con unas modificaciones muy simples.



Rojo: El programa LIPS utiliza estos bytes para representar la palabra PATCH (en código ASCII). De esta forma se ubica mejor a la hora de trabajar con los archivos, no lo modifiques.

Naranja: Esta es la dirección en la que va a modificar el parche, la pueden modificar si es que quieren que cambie lo bytes de otro lugar de la ROM.

Violeta: Esto es lo que determina cuantos bytes se van a modificar a partir de la dirección (naranja).

Azul: Esto indica porque se va a modificar el byte (si escribes 03, se va a modificar por 03). Tenés que fijarte bien en que posición está, si es que en “violeta” pusiste más de 01, la posición importa a la hora de reemplazar bytes. Va en orden, 1, 2, 3, etc.

Verde: El programa LIPS utiliza estos bytes para representar las iniciales EOF, que significa End Of Text (en código ASCII). De esta forma se ubica mejor a la hora de trabajar con los archivos, no lo modifiques.


Su estructura secundaria
Cuando un parche quiere hacer modificaciones repetitivas en una misma dirección (naranja) su estructura cambia ligeramente.



Rojo: El programa LIPS utiliza estos bytes para representar la palabra PATCH (en código ASCII). De esta forma se ubica mejor a la hora de trabajar con los archivos, no lo modifiques.

Naranja: Esta es la dirección en la que va a modificar el parche, la pueden modificar si es que quieren que cambie lo bytes de otro lugar de la ROM.

Amarillo: Esto es lo que utiliza el programa LIPS para identificar si se va a insertar una cadena bytes o se va a insertar un mismo byte repetidas veces. Este último caso se da si los valores de esos bytes son iguales a 00 00.

Violeta: Esto es lo que determina cuantas veces se va a insertar el byte (azul) a partir de la dirección (naranja).

Azul: Este es el byte que se va a insertar repetidas veces.


Verde: El programa LIPS utiliza estos bytes para representar las iniciales EOF, que significa End Of Text (en código ASCII). De esta forma se ubica mejor a la hora de trabajar con los archivos, no lo modifiques.

Datos varios
  • Da igual que ROM o archivo utilices, el programa LIPS siempre utiliza los bytes de "Rojo" y "Verde" para ubicarse.
  • Si quieren hacer modificaciones en varias direcciones, solo tienen que copiar los datos de naranja, violeta y azul, después de el ultimo azul. Espero haberme explicado, pero por si las dudas les dejo una imagen para que sepan guiarse mejor:



Fin.

Muchísimas gracias @Fran Agustín y @Bugrhak por interesarse y aportar datos <3

Espero que les haya servido, creo que me explique bastante bien, igualmente pueden decirme sus dudas. Sin nada mas que decir...

Arrivederci~
 
Última edición:

ANT0N9

Algun Sprite?
WoW exelente tutorial Felix, me ha gustado bastante el hecho de que te tomaras tu tiempo para hacer algo que tal vez algunos no sabíamos o ignorábamos. Sin nada mas que decir, me a gustado mucho el tuto es simple de entender, y ademas hiciste ejemplos con imágenes que mas vamos a pedir :lovelon:
 

Acosta

The Wolf~
Buen tutorial Felix, no es nada del otro mundo comprender este tutorial, y lo hiciste con imagenes lo cual lo hace mucho más fácil de comprenderlo. Pues es interesante que tomes algo de tú tiempo para traer tutoriales a WaH.

¡Saludos! ;)
 
Gracias Felix por tomarte el tiempo de explicar esto, no es difícil comprenderlo, pero de seguro muchos no entendian la estructura de dichos archivos, y este tutorial de seguro ayudara mucho para aquellos que no lo sabían.

¡Saludos!
 

Fran Agustín

Si el sol besa tus ojos, ni cuenta te das.
Miembro insignia
Hola Feli. Veo que no había comentado tu tutorial en su momento, aunque estoy seguro de que te lo dije por discord o algo.

Los parches son una de las herramientas más útiles y aún así menos usadas en el rh binario. En gran medida eso se debe a la cantidad de novatos que buscan parches y los aplican sin entender cómo funcionan. En algunos casos, los propios parches tienen bugs y en otros sobreescriben data pues quien lo aplica ya había usado ese espacio que en una ROM limpia estaba vacío.
En fin, no recuerdo haber leído nunca un tutorial que explicara la estructura interna de un parche en detalle, podría haber sido muy útil, incluso para la época en que lo escribiste. Actualmente, sin embargo, creo que es mejor usar decomp y ya. Los parches son un equivalente más rudimentario pero igualmente útil de los commits de git.

Bueno, sin más dilación, venía para aclarar lo que te comenté ayer: el byte que has marcado en amarillo no se trata de un padding (es decir, no es un byte vacío que separa dos valores). En realidad junto con el violeta marcan la cantidad de bytes a modificar, formando una única entidad de 2 bytes. Espero si tienes tiempo lo corrijas en el post principal.


Probé con varias ROMs, para ver si el código se modificaba dependiendo de en cual te basaras, pero no es así (al menos que yo sepa).
Ah y sobre esto: confirmo, no depende en absoluto de la ROM. De hecho, ni siquiera importa que sea una ROM de Pokémon ni siquiera que sea un juego de GBA, Lips sirve para crear parches sobre cualquier archivo (obviamente teniendo en cuenta sus limitaciones).

¡Un saludo!

EDIT: El Pipe se puso la 10 y editó el post corrigiendo estos detallitos. ¡Qué grande el Pipe! Ya puedes leerlo y estar seguro sin depender de estos comentarios.
 
Última edición:

Bugrhak

A long time ago I used to call myself "Subzero".
Verde: Repito, no se como funciona el programa, ergo, supongo que determina el final de los datos del parche.
Quizas lo que voy a decir puede no ser del todo acertado, pero creo que tengo una forma de comprobar si esa es la verdadera función del verde.

1) Utilizando la nueva información que aportó @Fran Agustín, te sugiero que cambies la cantidad de bytes que modifica el parche, para que dicha cantidad sea mayor.
2) Ahora, naturalmente, corresponde añadir más bytes, para que se correspondan con la nueva cantidad que has establecido luego del paso uno.

3) Aplica el parche. Si estoy en lo correcto, cuando apliques el parche, todo lo que has hecho va a estar ahi.

No obstante, también se me ocurre otra cosa, prueba a borrar los bytes en verde y luego intenta usar el parche.
Supongo que el programa detectará la falta de esos bytes y no aplicará el parche, y en caso de que lo aplique, puede que salga algún mensaje, no sé. Es cuestión de ir probando.

Otra cosa que puedes hacer es fijarte si otro parche tiene los mismos bytes al final.

Por cierto, no se si lo has pillado, pero los bytes que marcaste en rojo corresponden a la palabra "PATCH" (también tiene un € que no sé que pueda significar para el programa, quizas es un indicativo de que debe parcheara continuación de ese byte).
 

Fran Agustín

Si el sol besa tus ojos, ni cuenta te das.
Miembro insignia
Quizas lo que voy a decir puede no ser del todo acertado, pero creo que tengo una forma de comprobar si esa es la verdadera función del verde.
Ah sí, sobre eso. Efectivamente son bytes que el programa usa para reconocer sus archivos y ubicarse mejor. No son más que las palabras PATCH y EOF escritas letra a letra con cada byte representando su código ASCII.
  • Los bytes marcados en rojo corresponden al código ASCII para los caracteres: P, A, T, C y H respectivamente, formando la palabra PATCH.
  • Los bytes marcados en verde corresponden al código ASCII para los caracteres: E, O y F, formando: EOF que es el acrónimo para End Of File.

Desconozco si es una convención que utilizan otros formatos para sus parches (UPS por ejemplo).
 

Bugrhak

A long time ago I used to call myself "Subzero".
Ah sí, sobre eso. Efectivamente son bytes que el programa usa para reconocer sus archivos y ubicarse mejor. No son más que las palabras PATCH y EOF escritas letra a letra con cada byte representando su código ASCII.
  • Los bytes marcados en rojo corresponden al código ASCII para los caracteres: P, A, T, C y H respectivamente, formando la palabra PATCH.
  • Los bytes marcados en verde corresponden al código ASCII para los caracteres: E, O y F, formando: EOF que es el acrónimo para End Of File.

Desconozco si es una convención que utilizan otros formatos para sus parches (UPS por ejemplo).
Ya me parecía si, aunque reconozco que cuando comenté, no le presté mucha atención a las palabras.

Sobre lo último, pues... Como tu bien has dicho, en algunos parcheadores UPS, lo usan pero no en todos.
Me puse a chequear los parcheadores que hay psra android y algunos no ponen nada ni al inico, ni al final del archivo.
 
Arriba