Cláusula de confidencialidad y de creación de esta Referencia.
Este hilo-referencia ha sido creado por Alek para ElOtroLado debido a la gran cantidad de dudas y equivocaciones que había respecto al IdStorage.
El deseo fundamental de este hilo por parte del autor y los que han colaborado es que estas dudas cesen y que, en el futuro, sea más simple comprender qué papel juega.
Existe una cierta confidencialidad de este hilo para EOL, mas si quereis copiarlo para otra web, por favor mandarme un MP y lo comentaremos :) No es por nada, pero es necesario que se tenga en cuenta a la gran cantidad de personas que han trabajado en la desvelación de secretos que guardaba el propio IdStorage.
Está creado a fecha 05 de Septiembre del 2007, y fue actualizado por última vez el 6/09.
Sobre los colaboradores y que han hondado profundamente en esta materia, directos o indirectos, es necesario mencionar a (no necesariamente por el orden que dispongo aquí y ahora) adrahil, Chilly Willy, FreePlay, harleyg, jas0nuk, l_oliveira, Mathieulh, Dark_AleX, Silverspring, Squirrel, spectroplasm, Nem, y tantos otros que puede que me deje por el camino.
Definiciones Iniciales
Antes de emprendernos en pensar o saber sobre un tema en cuestión, es necesario ante todo el aventurarnos en una serie de términos que usaremos contínuamente y que son extremadamente necesarios de su perfecta comprensión.
> NAND (nand-flash) > La podremos considerar como una, de forma genérica, memoria flash; habitualmente encontrada en células de memoria y serial, de una composición más simple que las memorias NOR. También es entendida en algunos aspectos como una serie de operaciones booleanas, pero este no es nuestro caso *exacto*, ya que hay bastantes puntos en desacuerdo.
En la PSP, se divide en tres partes distintas:
- El IPL (ver más abajo)
- Sistemas Fat flash0 y flash1 (entre otros, ver más abajo)
- IdStorage (ver más abajo)
Una jerarquía podría ser, por ejemplo, NAND - IPL - FAT - IdStorage
Hay una serie de llamadas o NIDS interesantes para comentarlos, como es el conocido..
int sceNandEraseAllBlock (void); <- Que crea un brick instantáneo
que no es, obviamente, aconsejable usarlo... Originariamente, en el fw 1.50, el driver que controlaba estas nids externamente, estaba en el archivo emc_sm.prx, mas ahora se encuentra en el psar.
Hay una serie de formas de controladores dentro de la propia NAND para las distintas tareas de las que se encarga; y de leer las nand-flash en su competitud desde el PC con un programador y adaptador como este (home made, claro está), pero eso si es necesario, lo comentaremos en otra ocasión.
> IPL > Término acuñado por los sistemas base de IBM, el IPL o Initial Program Load es una función del hardware, y NO un programa localmente ejecutado.
El proceso es el siguiente: Inicio >> Se escoge un canal I/O y se inicia >> Carga de un programa X
Un programa X que en el caso de la PSP es el propio vshmain o el XMB (y las funciones derivadas de éste), sin necesidad de tener ninguna rutina de bootstrap.
En la PSP, se encuentra en los primeros 48 bloques de la NAND, y existe un canal llamado "IPL:/" que se puede acceder mediante subrutinas de sceNand (y sólo mediante estas, de ahi que esté (más o menos) protegido de bricks, sin embargo no comentaremos más allá de esta definición. Hay una serie de direcciones y bloques que explican gran parte del funcionamiento base de la PSP, y como nota curiosa, destacar que en 1.50, el IPL no estaba encriptado... mas en 2.0 ya lo estaba.
De igual manera, el propio IPL se utilizó para el downdate de 1.50-1.00 (mediante el ipl_update.bin, y otras llamadas..) pero como comento, es entrar en otro tema distinto. Por su lado, el EBOOT update de 1.50 (en 2.0 y siguientes este update al ipl está en el psar) tenía ya de por sí un iplupdate.prx, que contiene las siguientes llamadas:
int sceIplUpdateSetIpl (void); <- que escribe el IPL de 1.50 que está en este propio prx
int sceIplUpdateClearIpl (void); <- que elimina los 48 primeros bloques de la NAND, y con ello el propio IPL.
int sceIplUpdateUpdateIpl (void); <- que parece ser un simple verificador, pero que no escribe en la flash.
Hace relativamente poco, Moonlight sacó esta aplicación que creaba una IPL modificada, que extiende la original de 1.50 y que, por razones que comentaremos más adelante, no tiene problemas con las placas (82,86) que no soportaban este kernel.
Este propio IPL, se puede desencriptar con una serie de código que pasa bloque por bloque, pero como comento, será para otra ocasión.
Si es necesario, más adelante haré otra referencia en la cual se explique desde los chips flash que usa la propia PSP (Samsung K5E5658HCM) y que lee esta IPL desde el cool boot al iniciar la PSP desde el switch de encendido; hasta el mapeo que podríamos hacer de sus blockes.
Sin embargo, esta referencia es sobre el IdStorage, así que sigamos.
> Flash > Las habitualmente llamadas flash o "flashes" (anglicismo incorrecto, por cierto), y más específicamente las memorias computerizadas no volátiles-flash, son memorias independientes pero a la vez unidas por el mismo hecho de que está todo bajo la misma NAND-flash.
Tienen su propio EEPROM (o memoria de sólo lectura programable y de borrado eléctrico que es un chip de almacenamiento no volatil) y, en el caso de la PSP, se dividen en cuatro:
- flash0 (~23mb) <- Acceso FAT que es un volumen de almacenamiento de archivos, entre los que se incluye las carpetas data (con los archivos de certificado), dic (con los diccionarios de pruebas y de uso), font (con las fuentes utilizadas), kd y kn (en su caso) (con los principales archivos de carga), y vsh (con la carga directa en boot, siempre considerable)
- flash1 (~4mb) <- Acceso FAT como volumen de almacenamiento de archivos temporales de configuración con carpetas como anteriormente como dic (datos de diccionarios), vsh (datos del tema usado), dh, gps, net (datos del navegador y caché) y registry (registro de operaciones) por defecto; aunque esto puede variar.
- flash2 (944kb) <- Acceso FAT como volumen de almacenamiento, en el que residen datos de configuración no residentes.
- flash3 (800kb) <- Acceso FAT como volumen de almacenamiento, en el que residen datos de configuración no residentes.
Toda esta serie de almacenamiento es usada y borrada y testeada con regularidad.
> IdStorage > Al fin, el meollo de la cuestión.
El Idstorage es, como hemos comentado, parte de la NAND. Más específicamente, es una serie de módulos que empiezan en la dirección 0xc0000, y, si queremos explicarlo gráficamente, se encontraría en la parte más posterior del IPL.
Su uso es casi exclusivo para el almacenamiento de datos de bajo nivel, como es el caso del serial, de datos del UMD, de la dirección MAC, etcétera.
Se divide en "keys" o pares de datos, de 512bytes (más 16 de intercambio)indexados en la propia NAND. Sin embargo, estas propias keys son en su esencia, enteros de 16 bytes.
Programando el IdStorage
En este apartado, comentaremos cómo se utiliza el idstorage a la hora de programar en C-PSP.
En primer lugar, en el header, habríamos de añadir, como mínimo:
#include <pspkernel.h>
#include <pspdebug.h>
#include <pspsdk.h>
// #include <pspiofilemgr.h> No en principio necesario
#include <pspidstorage.h>
#include "pspidstor.h"
Siendo el pspidstorage la libería por defecto del PSPSDK de ps2dev, y "pspidstor.h" una libreria .h que crearemos nosotros mismos y que incluirá los ints, voids y demás que usemos.
El porqué de añadir dos librerías es, básicamente, porque la del PSPSDK está anticuada para las nuevas funciones que aquí explicaremos (Obviamente, tiene algunas, pero ni un 1/4 del total si no recuerdo mal)
A continuación, en la zona del módulo, es imperativo trabajar en kernel:
PSP_MODULE_INFO("Test",0x1000,1,0);
PSP_MAIN_THREAD_ATTR(0x0000);
PSP_MAIN_THREAD_STACK_SIZE_KB(32);
Viendo el último una simple comprobación de stack para las transacciones que nunca viene mal.
Ahora bien, estudiemos las distintas funciones que se pueden utilizar, una por una.
// Idstorage.h
#ifndef IDSTORAGE_H
#define IDSTORAGE_H
#ifdef __cplusplus
extern "C" {
#endif
// Inicia la transaccion con el IdStorage.
int sceIdStorageInit(void);
// Finaliza la transaccion con el IdStorage. Flush y Ram
int sceIdStorageEnd(void);
// Lee una hoja o key predeterminada.
/// key == key
/// buf == puntero al buffer de la key
int sceIdStorageReadLeaf(u16 key, void *buf);
// Escribe una hoja o key predeterminada.
/// key == key
/// buf == puntero al buffer de la key
int sceIdStorageWriteLeaf(u16 key, void *buf);
// Crea/Escribe una key en la selección
/// key == key
int sceIdStorageCreateLeaf(u16 key);
// Elimina la key seleccionada.
/// key == key
int sceIdStorageDeleteLeaf(u16 key);
// Devuelve el total de las keys sin uso
int sceIdStorageGetFreeLeaves(void);
// Devuelve el tamaño de hoja (512bytes)
int sceIdStorageGetLeafSize(void);
// Devuelve el tamaño de la key especificada
/// key == key
/// offset == salida de 512
/// buf == puntero al buffer de la key
/// len == longitud de los datos a devolver (max 512)
int sceIdStorageLookup(u16 key, u32 offset, void *buf, u32 len);
// Actualiza el mapeo.
int sceIdStorageUpdate(void);
// Formatea el IdStorage.
int sceIdStorageFormat(void);
// sceNandEraseAllBlock desde 0xc0000
int sceIdStorageUnformat(void);
// Checkea si ha sido formateado con anterioridad
int sceIdStorageIsFormatted(void);
// Usa un iterador como index desde un descriptor en el int para ver los elementos del mapeo.
/// iterador = iterador
/// arg == descriptor
void iterador(int id, int page, int arg);
int sceIdStorageEnumId(void *(iterador), int arg);
// Comprueba si el IdStorage tiene daños superficiales.
int sceIdStorageIsDirty(void);
// Suspende el proceso. Flush y devuelve 0
int sceIdStorageSuspend(void);
// Reanuda el proceso
int sceIdStorageResume(void);
// Comprueba si es de sólo lectura
int sceIdStorageIsReadOnly(void);
// Finaliza la escritura
int sceIdStorageFlush(void);
// Creación de multiples keys ¿?
extern int sceIdStorage_driver_99ACCB71();
#ifdef __cplusplus
}
#endif
#endif // IDSTORAGE_H
// Nand.h
#ifndef NAND_H
#define NAND_H
#ifdef __cplusplus
extern "C" {
#endif
// Inicia el modulo NAND
int sceNandInit();
// Finaliza el modulo NAND
int sceNandEnd(void);
// Suspende el proceso NAND (NOP)
int sceNandSuspend(void);
// Reinicia el proceso NAND
int sceNandResume(void);
// Habilita o deshabilita la protección contra escritura de la NAND
/// protect == FALSE : permite la escritura en NAND
/// protect == TRUE : deniega la escritura, protección contra ella.
int sceNandSetWriteProtect(bool_t protect);
// Proporciona acceso exclusivo a la NAND
/// write == TRUE : habilita la escritura en la NAND
int sceNandLock(bool_t write);
// Finaliza el acceso exclusivo a la NAND
int sceNandUnlock(void);
// Manda un STATUS y devuelve el resultado
int sceNandReadStatus(void);
// Manda un RESET a la NAND
/// buf == buffer que devuelve el STATUS o NULO
int sceNandReset(u8 *buf);
// Manda un ID a la NAND
/// id == buffer que almacena los codigos de id
/// len == tamaño del buffer id
int sceNandReadId(u8 *id, s32 len);
// Lee las páginas de usuario y compartidas con un ECC automatico
/// ppn == número físico de paginas
/// user == buffer para las paginas de usuario o NULO
/// spare == buffer para las paginas compartidas (12bytes, sin ECC en alojamiento)
/// len == numero de paginas a leer, max. 32
int sceNandReadPages(u32 ppn, u8 *user, u8 *spare, u32 len);
// Escribe paginas de usuario y compartidas con un ECC automatico
/// ppn == número físico de paginas
/// user == buffer para las paginas de usuario o NULO
/// spare == buffer para las paginas compartidas (12bytes, sin ECC en alojamiento)
/// len == numero de paginas a escribir, max. 32
int sceNandWritePages(u32 ppn, u8 *user, u8 *spare, u32 len);
// Lee las páginas de usuario y compartidas con un ECC automatico sin entrada al ECC desde NAND
/// ppn == número físico de paginas
/// user == buffer para las paginas de usuario o NULO
/// spare == buffer para las paginas compartidas (12bytes, sin ECC en alojamiento)
/// len == numero de paginas a leer, max. 32
int sceNandReadPagesRawExtra(u32 ppn, u8 *user, u8 *spare, u32 len);
// Escribe paginas de usuario y compartidas con un ECC automatico sin entrada al ECC desde NAND
/// ppn == número físico de paginas
/// user == buffer para las paginas de usuario o NULO
/// spare == buffer para las paginas compartidas (12bytes, sin ECC en alojamiento)
/// len == numero de paginas a escribir, max. 32
int sceNandWritePagesRawExtra(u32 ppn, u8 *user, u8 *spare, u32 len);
// Lee las páginas de usuario y compartidas sin un ECC automatico
/// ppn == número físico de paginas
/// user == buffer para las paginas de usuario
/// spare == buffer para las paginas compartidas (12bytes, sin ECC en alojamiento)
/// len == numero de paginas a leer, max. 32
int sceNandReadPagesRawAll(u32 ppn, u8 *user, u8 *spare, u32 len);
// Escribe paginas de usuario y compartidas sin un ECC automatico
/// ppn == número físico de paginas
/// user == buffer para las paginas de usuario
/// spare == buffer para las paginas compartidas (12bytes, sin ECC en alojamiento)
/// len == numero de paginas a escribir, max. 32
int sceNandWritePagesRawAll(u32 ppn, u8 *user, u8 *spare, u32 len);
// Lee las páginas fisicamente de la NAND
/// ppn == número físico de paginas
/// user == buffer para las paginas de usuario o NULO
/// spare == buffer para las paginas compartidas o NULO
/// len == numero de paginas a leer, max. 32
/// mode == como habria de ser manejado el ECC segun el buffer de pagina
int sceNandReadAccess(u32 ppn, u8 *user, u8 *spare, u32 len, SceNandEccMode_t mode);
// Escribe las páginas fisicamente de la NAND
/// ppn == número físico de paginas
/// user == buffer para las paginas de usuario o NULO
/// spare == buffer para las paginas compartidas o NULO
/// len == numero de paginas a escribir, max. 32
/// mode == como habria de ser manejado el ECC segun el buffer de pagina
int sceNandWriteAccess(u32 ppn, u8 *user, u8 *spare, u32 len, SceNandEccMode_t mode);
// Manda un ERASEBLOCK a la NAND
/// ppn == numero de paginas fisicas
int sceNandEraseBlock(u32 ppn);
// Lee las paginas compartidas con ECC automatico desde la NAND con la interfaz serial.
/// ppn == numero fisico de paginas
/// spare == buffer para las paginas fisicas (16bytes por pagina, ECC alojado)
/// len == numero de paginas compartidas a leer, max 32
int sceNandReadExtraOnly(u32 ppn, u8 *spare, u32 len);
// Calcula y devuelve un valor de 12bits para el ECC que sirva en la region compartida
/// buf == buffer de 8bytes de datos a calcular
int sceNandCalcEcc(u8 *buf);
// Calcula y compara valores de 12bits para el ECC, devolviendo el resultado.
/// buf == buffer de 8bytes de datos a calcular
/// ecc == valor de ECC de 12bits para la comparacion
/// @ return 0 - Valor de ECC correcto
/// @ return -1 - Valor de ECC incorrecto : Error de unico bit (corregible)
/// @ return -2 - Valor de ECC incorrecto : Error multiple de bits en ECC
/// @ return -3 - Valor de ECC incorrecto : Error multiple de bits
int sceNandVerifyEcc(u8 *buf, u16 ecc);
// Calcula y compara valores de 12bits para el ECC, corrige si puede y devuelve el status.
/// buf == buffer de 8bytes de datos a calcular
/// ecc == valor de ECC de 12bits para la comparacion
/// @ return 0 - Valor de ECC correcto
/// @ return -1 - Valor de ECC incorrecto : Error de unico bit (corregible)
/// @ return -2 - Valor de ECC incorrecto : Error multiple de bits en ECC
/// @ return -3 - Valor de ECC incorrecto : Error multiple de bit
/// Funcion en desarrollo, no se ha comprobado su funcionamiento
int sceNandCollectEcc(u8 *buf, u16 ecc);
// o bien
int sceNandCorrectEcc(u8 *buf, u16 ecc);
// Lee el dispositivo y el codigo del productor, asi como las propiedades de la NAND
int sceNandDetectChip();
// Devuelve el tamaño de pagina de la NAND
int sceNandGetPageSize(void);
// Devuelve el numero de paginas por bloque en la NAND
int sceNandGetPagesPerBlock(void);
// Devuelve el total de bloques en la NAND
int sceNandGetTotalBlocks(void);
// Borra el bloque seleccionado y escribe en NAND con ECC automatico
/// ppn == numero fisico de paginas
/// user == buffer para los bloques de usuario
/// spare == buffer para los bloques compartidos (12bytes por pagina, sin ECC)
int sceNandWriteBlock(u32 ppn, u8 *user, u8 *spare);
// Borra el bloque, escribe con ECC automatico, verifica la escritura hasta cuatro veces
/// ppn == numero fisico de paginas
/// user == buffer para los bloques de usuario
/// spare == buffer para los bloques compartidos (12bytes por pagina, sin ECC)
int sceNandWriteBlockWithVerify(u32 ppn, u8 *user, u8 *spare);
// Lee el bloque, verifica la lectura hasta cuatro veces
/// ppn == numero fisico de paginas
/// user == buffer para los bloques de usuario
/// spare == buffer para los bloques compartidos (12bytes por pagina, sin ECC)
int sceNandReadBlockWithRetry(u32 ppn, u8 *user, u8 *spare);
// Verifica el bloque
/// ppn == numero fisico de paginas
/// user == buffer para los bloques de usuario
/// spare == buffer para los bloques compartidos (12bytes por pagina, sin ECC)
int sceNandVerifyBlockWithRetry(u32 ppn, u8 *user, u8 *spare);
// Elimina el bloque, verifica la escritura hasta cuatro veces
/// ppn == numero fisico de paginas
int sceNandEraseBlockWithRetry(u32 ppn);
// Comprueba si el bloque está dañado.
/// ppn == numero fisico de pagina(s)
int sceNandIsBadBlock(u32 ppn);
// Marca el bloque como dañado
/// ppn == numero fisico de pagina(s)
int sceNandDoMarkAsBadBlock(u32 ppn);
// Hace un check de la NAND para bloques dañados, y un NandTestBlock en los no dañados.
int sceNandDumpWearBBMSize(void);
// Llama a sceNandDetectChipMakersBBM para todos los bloques en la NAND y devuelve los dañados
int sceNandCountChipMakersBBM(void);
// Igual que en sceNandIsBadBlock, pero aumentado de capacidad; devuelve 0 si el bloque no es marcado como dañado
int sceNandDetectChipMakersBBM(void);
// Elimina todos los bloques.
int sceNandEraseAllBlock(void);
// Realiza un testeo en los bloques seleccionados (borra, hace test, comprueba) Si es dañado, se marca como dañado con domarkasbadblock
/// ppn == numero fisico de pagina(s)
int sceNandTestBlock(u32 ppn);
#ifdef __cplusplus
}
#endif
#endif // NAND_H
Y estas son todas las llamadas o NIDS de las que disponemos, explicadas para que sepais de su uso.
En el makefile, por su parte, habríamos de añadir lo siguiente:
LIBS = -lpspnand_driver
que nos añadiría directamente el driver de sceNand que hemos comentado anteriormente para el uso del propio IdStorage. (Claro que, para eso añadimos un .h con las funciones que queríamos usar con predilección antes)
El eterno dilema: 1.50 IPL y las "placas malditas"
Como todos sabreis de sobra, hay una serie de placas (series 82 y 86) que se han ganado el apodo de "malditas" por el hecho de que no eran "compatibles" con el IPL ni el kernel de 1.50.
Pues bien, esta "no-compatibilidad", explicada más a fondo, es un problema, como es de imaginar, de hardware. Al ser la IPL no un proceso que se cargue manualmente sino automáticamente como hemos explicado en las definiciones, esta misma IPL se desarrolla en el mismo proceso de creación del hardware.
Pues bien, a la hora de la creación de estas placas, el propio proceso de mejora de los componentes (junto con el uso de otros nuevos que no viene a cuento) hizo una serie de incompatibilidades que se denotaron a nivel bajo de i/o. Es decir, en el IdStorage.
Tras mucho tiempo de desarrollo, se llegó a la conclusión de que esto podría ser reversible, y así lo fue en cuanto se empezó a indagar un poco más. Pues bien, el proceso de cambio, aunque seguramente alguno de vosotros lo sabreis, es este...
Copiar 0x0042 a 0x0043 (usb)
Copiar 0x0041 a 0x0042 (refresco)
Copiar 0x0006 a 0x0041
Copiar 0x0005 a 0x0006 (refresco)
Copiar 0x0004 a 0x0005 <-- Esencial
Copiar 0x0046 a 0x0004 (refresco)
Copiar 0x0045 a 0x0046
Copiar 0x0045 a 0x0009 (Byte 0)
Copiar 0x0045 a 0x0047
, una serie de pares que podeis ver su significado más adelante en la referencia de pares.
Referencia de pares del IdStorage
Desde hace un tiempo, se han estado analizando cada par de keys del idstorage, con resultados futuros muy fructíferos, y ahora mismo se sigue desarrollando una investigación al respecto, y con el deseo futuro de poder recuperar la idstorage al completo.
En ese proyecto, yo ayudo en lo que puedo, pero he pensado que mi aportación sería más valiosa aquí y haciéndoos saber de cómo va, y proporcionándoos las claves para usarlo (en base al programa ejemplo de más adelante.
La siguiente es una referencia de pares comentada en el hilo linkeado anteriormente, que he podido comprobar por mi parte. (más allá de la encriptación KIRK, estoy estudiando eso)
-
-
-
0x0004 <- Niveles de bateria para funciones del power.prx posiblemente.
0x0005 <- Reloj, i2c, el que previene el kernel 150 en 082/086
0x0006 <- Tiempos de RAM y DDR
0x0007 <- Llamado por el IPL (main.bin)
0x0008 <- Circuitos de brillo para la TA-086 (si no es localizada, la placa actúa como 79, de ahi los fallos en la pantalla de brillo.)
-
0x0010 <- Usado para MagicGate
0x0011 <- Usado para MagicGate
0x0012 <- Usado para MagicGate
0x0013 <- Usado para MagicGate
-
...
-
0x0040 <- Usado para MagicGate
0x0041 <- USB
-
0x0043 <- USB
0x0044 <- Dirección MAC
0x0045 <- Región WLAN
-
0x0047 <- Vacio tras 0x09
-
-
0x0050 <- Serial (sin uso desde 82)
0x0051 <- Firmware original en venta (desde 86)
0x0052 <- Nuevo en Slim
-
0x0054 <- Nuevo en Slim
-
...
-
0x0100 <- DNAS, VSH/INET/ADHOC Region <- Si es ausente, da el error 0x80000025
0x0101 <- OpenPSID
0x0102 <- Usado para el UMD
0x0103 <- Usado para el UMD
0x0104 <- Usado para el UMD
0x0105 <- Usado para el UMD
0x0106 <- Usado para el UMD
-
...
-
0x0120 <- Backup de 100
0x0121 <- Backup de 101
0x0122 <- Backup de 102
0x0123 <- Backup de 103
0x0124 <- Backup de 104
0x0125 <- Backup de 105
0x0126 <- Backup de 106
-
...
-
0x0140 <- Kirk??
(En proceso)
--Programa ejemplo
En proceso una nueva versión mejorada.
4.0 <- Restauracion del idstorage, ipl y nand al completo.
5.0 <- 4.0 + Restauracion de keys conflictivas (usb, umd, region, mac, etc)
--AlekEsto es todo.
En el futuro, a medida que se investigue más, iré añadiendo, en la misma referencia de pares, ejemplos para su manipulación, siempre que se confirme su funcionamiento.
Alek escribió:Actualizado el programa de ejemplo a la versión 2.0
Ahora muestra en pantalla:
- MAC
- Región de WLAN
- Serial de hardware (algo en desuso, pero en un 80% de los casos es cierta para diferenciar placas)
- Región de Compra
Y, además, puedes:
- Dumpear el idstorage en un único .bin
- Dumpear el idstorage key a key en una carpeta en la raiz de la MS.
Junto con otras chorradillas, como ponerle icon0 y pic1, y arreglar ciertos detalles que se mostraban en pantalla.
Sources y binarios subidos y actualizados en el post principal.
Si, así como para las conexiones USB y demás..torrentex escribió:Has encontrado ya algo para reparar el umd?
Si, en teoría una vez que esté terminado podrá parchear cada key de por sí, con una diferenciación seguramente por placas, y quizá habría de ser manual para la manutención de ciertos detalles como el USB o la MAC.Manumtz escribió:[mad] tio alek ya que estas con esto azlo;hay mucha gente con estpos problemas y si lo haces las psps tochas no tendran problemas si ay brick? pandora si esta estropeado el idstorage pos usamos el programa de alek.
la slim puede esperar...
P.D Haber si algun mod pone esto en pos it please.....
No te preocupes xD ya idearé alguna manera xD aunque sea desde el vshmain.Manumtz escribió:joder si vivieras aqui donde yo o yo donde tu te dejaria una de las dos mias que es ta 86 para testear.
Cuando puedas te estaremos esperando colega;
ojala sea pronto, ah y gracias por interesarte e intentar ayudarnos ^.^
Bueno, de cualquier manera los sources están posteados a continuación, solo es compilarlosPaketostio escribió:Alek, no va el enlace para el programa de ejemplo, dice que no existe el fichero
Por lo demás, uno de los mejores tutoriales que he visto con respecto a estos temas, sigue asi!
Alek escribió:Bueno, de cualquier manera los sources están posteados a continuación, solo es compilarlos
Ya tengo una nueva versión (4.0) preparada, que restaura idstorage, ipl y la nand completa, la postearé más adelante; y tengo otra version (5.0) en beta que restaura ciertas keys como las del usb, display, umd y demás (esta última aún la estoy probando, ya que tengo que hacer ingeniera inversa para sacar la encriptación kirk que reside individualmente)
Al menos los errores más frecuentes.Manumtz escribió:y con la 5 ya estara todo al completo arreglado al usarla?
Nop, la 4 restaurará y creará dumps (creados con anterioridad para las restauraciones, obviamente) de IdStorage, IPL y NAND.Manumtz escribió:haber que me aclare con la version 4.0;
si tengo una psp con todo el idstorage corructo y uso la version 4 se arregla entero no?
entonces la version 5 que hace si hace lo mismo k la 4 no?
Si, supongo. ¿Alguna idea?Manumtz escribió:y despues de la 5 abra otra no? que aga mas cosas no?
Alek escribió:Nop, la 4 restaurará y creará dumps (creados con anterioridad para las restauraciones, obviamente) de IdStorage, IPL y NAND.
La 5 además de esto anterior, se centrará en problemas específicos de corrupcion como el UMD, Region, etc.
pindout escribió:me parece que te han jodido el proyecto los de maxconsole
pero bueno asi ya se pueden revivir las slim con brick UP NandRestore 64