Por lo que estoy viendo quiere que hagamos esto:
Una vez que hayamos abierto el 010 Editor, abrimos PS3_Memory_Dump.bin y PS3MemDump_hv_call_table.bt.
Se muestra la ventana siguiente y pulsamos RUN.
jajajaja, a su salida me da error, no me sale, pero el código es este.//-----------------------------------
//--- For 010 Editor v3.x Binary Template
//
// File: PS3MemDump_hv_call_table.bt
// Author: TitanMKD
// Revision: 0.1
// Purpose: Search syscall table in a PS3 memory dump.
//-------------------------------------------------------------
typedef struct {
uint64 hv_func_addr;
} hv_call_entry <read=ReadFUNCADDR>;
string ReadFUNCADDR( hv_call_entry &f )
{
string s;
SPrintf(s, "HV_Func_Addr=0x%08X", f.hv_func_addr);
return s;
}
//--------------------------------------------
// Define the file
BigEndian();
// Search syscall table, based on xorloser code:
// "This bit was added by xorloser to find the address of the syscall table
// instead of using a version specific harcoded address.
//
// This first looks for the lv1_invalid_hvcall handler function,
// then finds references to this handler which should be entries
// in the syscall table. It then gets the start of this table to
// use as the syscall table address."
local uint64 offset, invalid_call_addr, hv_call_table_addr;
local uint64 code_val1;
local uint64 code_val2;
local uint64 addr64_val1;
local uint64 addr64_val2;
local uint64 addr64_val3;
local uint64 addr64_val4;
local uint64 addr64_val5;
local uint64 addr64_val6;
local uint64 addr64_val7;
local uint64 addr64_val8;
local uint64 lv1_invalid_hvcall_code_1;
local uint64 lv1_invalid_hvcall_code_2;
local uint32 index;
/* Correspond to lv1_invalid_hvcall code:
38600000 li r3, 0
6463FFFF oris r3, r3, 0xFFFF
6063FFEC ori r3, r3, 0xFFEC
# r3 = 0xFFFFFFEC = -20 = LV1_NOT_IMPLEMENTED error code => http://wiki.ps2dev.org/ps3:hypervisor:hypervisor_function_return_status
4E800020 blr
*/
lv1_invalid_hvcall_code_1 = 0x386000006463FFFF;
lv1_invalid_hvcall_code_2 = 0x6063FFEC4E800020;
Printf("searching for syscall table\n");
hv_call_table_addr = 0;
for(offset=0; offset<4*1024*1024 - 16; offset+=4)
{
FSeek(offset);
/* Search for lv1_invalid_hvcall code */
code_val1 = ReadUInt64(FTell());
code_val2 = ReadUInt64(FTell()+8);
if( code_val1 == lv1_invalid_hvcall_code_1 &&
code_val2 == lv1_invalid_hvcall_code_2 )
{
invalid_call_addr = offset;
Printf("found lv1_invalid_hvcall at 0x%08X\n", invalid_call_addr);
/* Now search the address of the lv1_invalid_hvcall (should be referenced only by hypervisor call table) */
for(offset=0; offset<4*1024*1024 - 16; offset+=8)
{
FSeek(offset);
index = 0;
addr64_val1 = ReadUInt64(FTell());
index+=8;
addr64_val2 = ReadUInt64(FTell()+index);
index+=8;
addr64_val3 = ReadUInt64(FTell()+index);
index+=8;
addr64_val4 = ReadUInt64(FTell()+index);
index+=8;
addr64_val5 = ReadUInt64(FTell()+index);
index+=8;
addr64_val6 = ReadUInt64(FTell()+index);
index+=8;
addr64_val7 = ReadUInt64(FTell()+index);
index+=8;
addr64_val8 = ReadUInt64(FTell()+index);
// Search for "signature" of 8 successive invalid_call_addr
if( addr64_val1 == invalid_call_addr &&
addr64_val2 == invalid_call_addr &&
addr64_val3 == invalid_call_addr &&
addr64_val4 == invalid_call_addr &&
addr64_val5 == invalid_call_addr &&
addr64_val6 == invalid_call_addr &&
addr64_val7 == invalid_call_addr &&
addr64_val8 == invalid_call_addr
)
{
hv_call_table_addr = offset - (32*8);
Printf("found syscall table at 0x%08X\n", hv_call_table_addr);
break;
}
}
break;
}
}
Printf("syscall table search completed\n");
/* Go to start of the hv_call_table */
FSeek(hv_call_table_addr);
hv_call_entry hv_call_table[256];
![[+furioso]](/images/smilies/nuevos/furioso.gif "muy furioso")
![[boing]](/images/smilies/nuevos/pelota_ani1.gif "pelota")
![[mad]](/images/smilies/nuevos/miedo.gif "loco")
ssssO escribió:me paree rarisimo que no use el exploit
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
hardcore087 escribió:ssssO escribió:me paree rarisimo que no use el exploit
A qué te refieres con eso? Creo que no me estoy enterando del último avance
Forkre escribió:Estoy dudando que se pueda desbloquear la consola
T.T... años y nada... y seguira asi T.T
) que encuentren pronto la key que buscan y desarrollen algo para la negrita. Koolk escribió:Forkre escribió:Estoy dudando que se pueda desbloquear la consola
T.T... años y nada... y seguira asi T.T
Opino igual.
Albertoamo escribió:pues que yo sepa, geohotz aun no ha publicado nada en su blog.
http://geohotps3.blogspot.com/ , sigue con las spus que son desde el 13 de febrero
[spoiler]Ese "extraño" mensaje: La memoria no se puede "read"
Uno de los problemas que más recibo y que pienso que más despista a la gente es un error del tipo "La instrucción en "0xnúmero_hexadecimal" hace referencia a la memoria en "0xnúmero_hexadecimal". La memoria no se puede "written"/"read". Observe la siguiente imagen que ilustra el error:
Leer más...
http://rinconwindows.blogspot.com/2007/ ... no-se.html
Para entretenerse un rato:
Introducción a los volcados de memoria en Windows
Un volcado de memoria, o memory dump en inglés, es una instantánea del estado interno de un programa, ya sea una aplicación en modo usuario o el núcleo del sistema operativo. En otros sistemas se emplea más el término core dump con un significado similar o equivalente. El estado interno comprende, entre otros, los valores de los registros "visibles" del procesador y porciones significativas del espacio de direcciones de memoria que incluyen código, datos y pila.
Los volcados de memoria se pueden clasificar atendiendo al tipo de información capturada o a su extensión (nivel de detalle). Así podemos tener volcados de memoria de una aplicación o del sistema, y volcados pequeños, completos o solamente del núcleo del sistema operativo.
Nota: lo siguiente se aplica a la familia Windows NT, especialmente a Windows 2000 y sus sucesores. Quedan excluidos Windows 95, Windows 98 y Windows Millennium: estos sistemas incluyen una herramienta de diagnóstico de errores de aplicación denominada Dr. Watson que no tiene nada que ver con la de los sistemas Windows NT. Véanse KB185837 y KB275481 para obtener más información.
Volcados de memoria de aplicación
La familia Windows NT incorpora el programa Dr. Watson, un tipo de herramienta que se conoce como depurador Just-In-Time (JIT) o post-mortem. Dr. Watson entra en acción cuando una aplicación encuentra un error, típicamente una infracción de acceso a memoria, para el que no tiene previsto un gestor de excepciones. Dr. Watson crea un archivo en el que registra diversa información técnica sobre el error y captura el estado interno de la aplicación en un volcado de memoria (archivo User.dmp) para un análisis posterior.
Se puede encontrar más información sobre Dr. Watson en KB103861, KB308538, El Just-In-Time Debugger... (por Rodrigo Corral), Ese "extraño" mensaje: La memoria no se puede "read" (por Daniel Martín) y otros muchos sitios, incluyendo la propia ayuda de Windows.
Microsoft también proporciona herramientas más avanzadas, como User Mode Process Dump o ADPlus (véase KB286350), que permiten generar volcados de memoria de aplicaciones, verdaderas instantáneas de ejecución, de forma automatizada o interactiva (por línea de comandos). Esto puede ser útil para diagnosticar bloqueos y otras situaciones anómalas sin tener que interrumpir bruscamente dichas aplicaciones.
Volcados de memoria del sistema
Los sistemas operativos más comunes, con ayuda de la plataforma hardware subyacente, contemplan al menos dos modos de ejecución fundamentales: modo núcleo (o kernel) y modo usuario. El núcleo del sistema y los controladores de dispositivo se ejecutan en modo núcleo, por lo que tienen acceso total a los recursos del equipo. Sin embargo, las aplicaciones se ejecutan en modo usuario, más restringido. El sistema operativo les expone un conjunto de interfaces de programación como único medio de interacción con él, impidiéndoles el acceso directo al hardware. En general el sistema no se viene abajo ante un fallo en modo usuario, sino que cesa su ejecución solamente la aplicación afectada.
Como ya hemos comentado, el modo núcleo carece de restricciones, por tanto cualquier fallo o descuido es potencialmente catastrófico. Si Windows detecta o es informado de una anomalía que no puede ignorar ni gestionar de ningún modo razonable, entonces muestra la temida pantalla azul de la muerte y se detiene. En otros sistemas operativos esta circunstancia recibe el nombre de kernel panic.
Windows puede generar tres tipos de volcados de memoria del sistema: pequeño (minidump), del núcleo o completo. La única opción antes de Windows 2000 era el volcado completo.
* El volcado pequeño es un archivo de 64 kilobytes en sistemas de 32 bits, o de 128 KB en sistemas de 64 bits. Contiene información muy básica sobre el problema sucedido y el estado del sistema, por lo que sólo aguanta análisis muy superficiales.
* El volcado del núcleo contiene las porciones del núcleo y los controladores que están presentes en la memoria física. Su tamaño es variable.
* El volcado completo recoge una instantánea de toda la memoria física. Esta opción no está disponible en sistemas de 32 bits que disponen de más de 2 GB de memoria física.
Se necesita disponer de un archivo de paginación en el volumen en que está instalado Windows y, además, proporcionarle un tamaño mínimo que sea suficiente para alojar un volcado del tipo configurado. La ubicación definitiva del volcado también deberá tener espacio libre de sobra.
De acuerdo con el artículo KB254649, los sistemas Windows clientes (Windows 2000 Professional y todas las ediciones Windows XP) vienen configurados para generar un volcado pequeño, mientras que los sistemas servidores (Windows Server 2003 y ediciones Server de Windows 2000) generan volcados completos de forma predeterminada. En sistemas de escritorio sugiero la configuración de volcado de memoria del núcleo sin reinicio automático: más detallado que el volcado pequeño, más reducido que el volcado completo, y con opción a leer el texto de la pantalla azul.
Ventana de inicio y recuperación de Windows XP
Una configuración sensata del volcado de memoria permitirá investigar y analizar STOPs, ya que es prácticamente imposible determinar la causa real mediante la simple observación de los datos técnicos de la pantalla azul y las circunstancias en que se produjo. Dichos análisis se llevarán a cabo con las herramientas del paquete Microsoft Debugging Tools for Windows, y en especial WinDBG.
Fuente:
http://geeks.ms/blogs/rsola/archive/200 ... ndows.aspx
Koolk escribió:Ya me di cuenta.
Sólo curiosos[spoiler]Ese "extraño" mensaje: La memoria no se puede "read"
Uno de los problemas que más recibo y que pienso que más despista a la gente es un error del tipo "La instrucción en "0xnúmero_hexadecimal" hace referencia a la memoria en "0xnúmero_hexadecimal". La memoria no se puede "written"/"read". Observe la siguiente imagen que ilustra el error:
Leer más...
http://rinconwindows.blogspot.com/2007/ ... no-se.htmlPara entretenerse un rato:
Introducción a los volcados de memoria en Windows
Un volcado de memoria, o memory dump en inglés, es una instantánea del estado interno de un programa, ya sea una aplicación en modo usuario o el núcleo del sistema operativo. En otros sistemas se emplea más el término core dump con un significado similar o equivalente. El estado interno comprende, entre otros, los valores de los registros "visibles" del procesador y porciones significativas del espacio de direcciones de memoria que incluyen código, datos y pila.
Los volcados de memoria se pueden clasificar atendiendo al tipo de información capturada o a su extensión (nivel de detalle). Así podemos tener volcados de memoria de una aplicación o del sistema, y volcados pequeños, completos o solamente del núcleo del sistema operativo.
Nota: lo siguiente se aplica a la familia Windows NT, especialmente a Windows 2000 y sus sucesores. Quedan excluidos Windows 95, Windows 98 y Windows Millennium: estos sistemas incluyen una herramienta de diagnóstico de errores de aplicación denominada Dr. Watson que no tiene nada que ver con la de los sistemas Windows NT. Véanse KB185837 y KB275481 para obtener más información.
Volcados de memoria de aplicación
La familia Windows NT incorpora el programa Dr. Watson, un tipo de herramienta que se conoce como depurador Just-In-Time (JIT) o post-mortem. Dr. Watson entra en acción cuando una aplicación encuentra un error, típicamente una infracción de acceso a memoria, para el que no tiene previsto un gestor de excepciones. Dr. Watson crea un archivo en el que registra diversa información técnica sobre el error y captura el estado interno de la aplicación en un volcado de memoria (archivo User.dmp) para un análisis posterior.
Se puede encontrar más información sobre Dr. Watson en KB103861, KB308538, El Just-In-Time Debugger... (por Rodrigo Corral), Ese "extraño" mensaje: La memoria no se puede "read" (por Daniel Martín) y otros muchos sitios, incluyendo la propia ayuda de Windows.
Microsoft también proporciona herramientas más avanzadas, como User Mode Process Dump o ADPlus (véase KB286350), que permiten generar volcados de memoria de aplicaciones, verdaderas instantáneas de ejecución, de forma automatizada o interactiva (por línea de comandos). Esto puede ser útil para diagnosticar bloqueos y otras situaciones anómalas sin tener que interrumpir bruscamente dichas aplicaciones.
Volcados de memoria del sistema
Los sistemas operativos más comunes, con ayuda de la plataforma hardware subyacente, contemplan al menos dos modos de ejecución fundamentales: modo núcleo (o kernel) y modo usuario. El núcleo del sistema y los controladores de dispositivo se ejecutan en modo núcleo, por lo que tienen acceso total a los recursos del equipo. Sin embargo, las aplicaciones se ejecutan en modo usuario, más restringido. El sistema operativo les expone un conjunto de interfaces de programación como único medio de interacción con él, impidiéndoles el acceso directo al hardware. En general el sistema no se viene abajo ante un fallo en modo usuario, sino que cesa su ejecución solamente la aplicación afectada.
Como ya hemos comentado, el modo núcleo carece de restricciones, por tanto cualquier fallo o descuido es potencialmente catastrófico. Si Windows detecta o es informado de una anomalía que no puede ignorar ni gestionar de ningún modo razonable, entonces muestra la temida pantalla azul de la muerte y se detiene. En otros sistemas operativos esta circunstancia recibe el nombre de kernel panic.
Windows puede generar tres tipos de volcados de memoria del sistema: pequeño (minidump), del núcleo o completo. La única opción antes de Windows 2000 era el volcado completo.
* El volcado pequeño es un archivo de 64 kilobytes en sistemas de 32 bits, o de 128 KB en sistemas de 64 bits. Contiene información muy básica sobre el problema sucedido y el estado del sistema, por lo que sólo aguanta análisis muy superficiales.
* El volcado del núcleo contiene las porciones del núcleo y los controladores que están presentes en la memoria física. Su tamaño es variable.
* El volcado completo recoge una instantánea de toda la memoria física. Esta opción no está disponible en sistemas de 32 bits que disponen de más de 2 GB de memoria física.
Se necesita disponer de un archivo de paginación en el volumen en que está instalado Windows y, además, proporcionarle un tamaño mínimo que sea suficiente para alojar un volcado del tipo configurado. La ubicación definitiva del volcado también deberá tener espacio libre de sobra.
De acuerdo con el artículo KB254649, los sistemas Windows clientes (Windows 2000 Professional y todas las ediciones Windows XP) vienen configurados para generar un volcado pequeño, mientras que los sistemas servidores (Windows Server 2003 y ediciones Server de Windows 2000) generan volcados completos de forma predeterminada. En sistemas de escritorio sugiero la configuración de volcado de memoria del núcleo sin reinicio automático: más detallado que el volcado pequeño, más reducido que el volcado completo, y con opción a leer el texto de la pantalla azul.
Ventana de inicio y recuperación de Windows XP
Una configuración sensata del volcado de memoria permitirá investigar y analizar STOPs, ya que es prácticamente imposible determinar la causa real mediante la simple observación de los datos técnicos de la pantalla azul y las circunstancias en que se produjo. Dichos análisis se llevarán a cabo con las herramientas del paquete Microsoft Debugging Tools for Windows, y en especial WinDBG.
Fuente:
http://geeks.ms/blogs/rsola/archive/200 ... ndows.aspx
Por aquí parece que han perdido la esperanza.
http://ps3hvdoc.wikispaces.com/page/his ... ervisor+RE
Saludo.
Koolk escribió:XD
No he preguntado el level 1. (se lo que es como tu, no internamente las instrucciones o direcciones que muestran, ya lo miraré mejor).
La frase que he puesto significa hablando en sarcasmo. Que el enlace que puso es un coñazo de entender.
No nos queda nada, estaba mirando algo por el aire y que complicado. Eso que es el lv1. ¿Y cuántos level hay?
Todo significa: No entiendo ni papa, y los que nos queda por ententer solo con el lv 1.
La parte de: ¿Y cuántos level hay?
Otro sarcasmo o indirecta. Si nos cuesta el lv1, imagínate los demás.
¿Lo pillas?
A la próxima tendré que escribir algo así:
He estado mirando el enlace sobre el lv1 y me parece muy complicado de entender, me imagino el resto de lv.
Esta vez no hablé técnico pero si indirectas. Mejor no hablo o mejor hablo directamente.
