PSP & desarrollo ASM, comienzo imposible!?

[Darthvader38]

*haya<--que pena tío...

Vamos, que por adelantado, empece a leer (en lo que encontraba SPIM,ahora Mars)
el capitulo 4 de "Introduccion a la Arquitectura de PSP" hecho por M0skit0, y
casualmente ese es el apartado donde se explica la situacion de los "nop" posterior
a los "jal", vaya coincidencia digo ... lo que no estaba seguro completamente que se referia a
eso, cuando codestation los llamó "delay slot".

En par de horas esoty cacharreando MARS...y me bajo el Tuto ese del link que aprendiste...

M0skit0 si no sabes donde dejaste esos
tutos tuyos ade+ de que "no te importa", pues en el fondo de my hard_drive estan,
ahora no me los pidas de vuelta!
Salu2 y no peleis por quien me ayuda +

[m0skit0]

Vale Codestation, pero los delay slot no se dejan en cualquier tutorial decente de MIPS porque es algo muy particular de MIPS (yo no lo he visto en ninguna otra arquitectura).

@Darthvader38: olvida los tutoriales de arquitectura de PSP, primero aprende ensamblador MIPS con el enlace que te he mandado y MARS. En el enlace hay ejercicios, hazlos en el MARS. Si quieres más ejercicios, no dudes en pedirlos, te pongo más. Una vez controles MIPS bien, vuelve a los tutos de arquitectura de PSP, ya verás cómo te enteras mucho mejor. También ten en cuenta que esos los escribí cuando aún no tenía mucha idea, así que posiblemente contengan errores. Los tutoriales del HBL (y el código) valen mucho más para aprender cómo funciona la PSP (por lo menos en modo usuario).

Weno un abrazo a los dos

[Darthvader38]

Umm, HBL, de verdad que no imaginé que terminaria viendo
su codigo...
Bueno, x ahora me concentro en Mars (tio,un asunto a la vez).
Despues, con dudas, estoy de vuelta (seguro no demoro ).

Larga vida a la scene!

[m0skit0]

Claro, es lo que te he dicho Primero el tuto de MIPS con MARS. Luego ya veremos por dónde quieres tirar.

[m0skit0]

Darthvader38 ¿no has muerto en el intento, verdad?

[Darthvader38]

En el intento?!, esto lo comienzo y lo TERMINO!!! , voy por la PART 4, vamos que estoy
cojo con el ingles y eso me atrasa,
no paso pagina sin entenderlo todo, ademas, el tuto esta EXELENTE!, da gusto leerlo,
a esta velocidad, antes de noviembre deberia terminarlo.
No queria aparecer x aqui sin acabar el tuto MIPS...(vamos, q quiero
ser una parte "activa" en el debate)
Gente, os lo recomiendo .

M0skit0, aun no hablamos,
termino el Tuto, y volvemos a la bestia (PSP, prx's, syscalls y +).
Salu2!

[m0skit0]

[m0skit0]

Ah y sólo por información: saber MIPS no sólo sirve para la PSP

http://www.devttys0.com/2013/10/from-china-with-love/

[Darthvader38]

Mejor tarde que nunca...he terminado el curso hace unos minutos !!!
Una experiencia necesaria, al menos para mi.
En los ultimos dias he ido preparando un Desafio DaxHordes V4,
ahora, no considero que es la mejor manera de hacer esto...
Me vale + ir paso a paso.
M0skti0, donde estas?!
Decir "antes" de noviembre fue MUCHO optimismo ...

Cargando argumentos $a0-3...,
guardando $s0-7 en el stack,
dejamos $ra intacto puesto que...ESTO VA A SER UN SALTO SIN RETORNO!!!
Jal Iniciando_Debate_sobre_la_Bestia!!!
nop


Mi primera pregunta:
=============

Digamos que desee patchear un modulo,
y que parte de mi codigo, el que deseo incrustar utiliza la funcion
sceIoOpen, pero el modulo donde voy a patchear no tiene incluida
en su compilacion esa funcion o la llamada a esa funcion
(esto tiene otra manera de decirse, creo que es: no tiene el
import, stub o algo asi...)
el asunto es:
Como areglárselas para entonces usar la funcion sceIoOpen desde mi codigo incrustado?!
Es decir, no puedo usar Jal, porque no se donde esta la funcion sceIoOpen!
Supongo que el sistema le "coloca" la direccion de sceIoOpen al modulo, pero
como este "originalmente" (u otra manera de decirlo, en su compilacion) no la
usa, el sistema no la especifica para este modulo...

Nota: Necesito ademas prxtool para desensamblar (porfa, cuelguen uno compilado,
nunca pude compilar el que me baje)

Salu2!!!

[codestation]

Nota: Necesito ademas prxtool para desensamblar (porfa, cuelguen uno compilado,
nunca pude compilar el que me baje)

Para linux? windows? si es lo segundo hace unas semanas compilé prxtool para alguien, aún lo conservo en el servidor: http://codestation.nekmo.com/misc/prxtool.exe

Mi primera pregunta:

Y viene bien cargada, ya es tarde para mi a estas horas (medianoche) pero por lo menos vamos a responder algo para empezar.

Digamos que desee patchear un modulo,

El modulo corre bajo modo usuario o kernel? Esto es algo que afecta el enfoque que uno toma al momento de parchear. Hago el quote por que si no se me olvida discutirlo en un futuro post. Vamos a asumir que estar parcheando un modulo en modo kernel para el resto de la pregunta.

Digamos que desee patchear un modulo,
y que parte de mi codigo, el que deseo incrustar utiliza la funcion
sceIoOpen, pero el modulo donde voy a patchear no tiene incluida
en su compilacion esa funcion o la llamada a esa funcion
(esto tiene otra manera de decirse, creo que es: no tiene el
import, stub o algo asi...)
el asunto es:
Como areglárselas para entonces usar la funcion sceIoOpen desde mi codigo incrustado?!

Pues tienes varias formas de hacerlo, ninguna es la incorrecta y seguro que hay otras formas. Por ejemplo podrías obtener la dirección de memoria donde empieza sceIoOpen y saltar a ella con un jal $registro. Generalmente si uno está bajo un HEN/CFW, la forma mas sencilla es llamar a la función sctrlHENFindFunction(char* szMod, char* szLib, u32 nid) y te devolverá esa dirección que buscas.

Vamos con los argumentos necesarios para la función:

El nombre del modulo de donde proviene sceIoOpen: sceIOFileManager (puedes obtenerlo con prxtool).

El nombre de la libreria: IoFileMgrForKernel.Esto puedes mirarlo usando prxtool en cualquier modulo que importe dicha función, por ejemplo:

Código: Seleccionar todo

.....
Import 4, Name IoFileMgrForKernel, Functions 5, Variables 0, flags 00010000
Functions:
0x810C4BC3 [0x00000EB4] - sceIoClose
0x109F50BC [0x00000EBC] - sceIoOpen
0x6A638D83 [0x00000EC4] - sceIoRead
.....

Y por último necesitas el NID: 0x109F50BC. Este valor viene a ser un identificador único que puede ser usado para encontrar el punto de entrada a una función de una librería definida en un modulo. Estos valores no cambian para funciones que pueden ser llamadas desde el modo usuario pero lamentablemente son diferentes para las funciones en modo kernel en cada revisión de firmware (antes eran fijas pero sony las hizo aleatorias por medidas de seguridad en el fw 3.11 (creo)). Esa es la razón #1 del porque cada CFW nuevo rompía la compatibilidad con la mayoria de los plugins: los programadores se veían forzado a hacer sendas tablas de traducción con el NID antiguo al 3.11 y su NID correspondiente para el FW actual (un trabajo muy tedioso y casi nunca agradecido por los usuarios de CFW).

Por supuesto no aprendes mucho si simplemente llamas a esa función por lo que te recomiendo que te leas la definición de esta función aquí: https://code.google.com/p/procfw/source/browse/SystemControl/systemctrl.c#145.

Básicamente la función lo que hace es llamar a sctrlKernelFindModuleByName para obtener una estructura de datos del modulo en cuestión. Luego se dedica a iterar la tabla de funciones del modulo buscando el nombre de libreria y cuando la encuentra pues empieza a revisar la lista de NID para dar con la dirección de la función.

La solución cutre seria tener obtener la dirección base del modulo en memoria y sumarle el offset donde se encuentra el inicio de la función que buscas. Por supuesto que funciona pero es obvio que no es portable para nada.

Se que me estoy saltando muchas cosas pero ya las aclararé yo (u otro que se pase por el hilo) cuando descanse un poco.

P.D.: se que me explico fatal, menos mal que no soy docente o el futuro de mi pais estaria en peligro