Xploit en 2.71 &2.80

A ver.... no sse que es el modo vsh, supongo que sera un tipo de usuario avanzado o algo asi, pero el acceso a kernel mode en 2.60 no era el mismo que el de 2.71? Asi que si se consigue cargar el downgrade de Dark Alex con el modo VSH (supongo que sera sin gta por fin xD) funcionaria igual no? Lo que creo recordar (corregidme si me equivoco) que la 2.8 habian tapado el agujero a modo kernel???

Creo recordar que la psp tiene 3 modos.
1.- User mode: Con muchas restricciones en memoria y llamadas del sistema
2.- Kernel mode: Modo superusuario. Puedes hacer de la psp un pandero.
3.- VSH mode: No se sabia muy bien como funcionaba. Este modo es el que usa el updater de sony. Con el bug del gta consiguieron acceso a él, pero no se conocían las llamadas del sistema. Al principio se creía que no se consiguiría acceso a flash, y hubo un tiempo de investigación . De ahí que tardase varios meses el downgrade desde el acceso.

Corregidme si me equivoco, hace tiempo que leí esa información...

Saludos

Alguien me puede explicar de que va lo de la carta de SONY a booster??

oassys_2006 escribió:Alguien me puede explicar de que va lo de la carta de SONY a booster??

le digeron ke dejara de sacar el Device hook que sino le acian esto y lo otro...lo tipico de una empresa grande para meter el rabo entre las piernas aun usuario...

Es decir, segun lo que me dices del VSH mode tenemos un downgrade a la vuelta de la esquina jeje aunque... cruzemos los dedos para que no hayan cambiado algo los de sony y tengamos que esperar unos meses

Pues yo los hubiera denunciado por estorsión. Ya que lo único que hacía es crear software casero.

Evidentemente no me ha pasado a mí y no se como reaccionaría. Pero creo que no solo los denunciaría sino que además seguiría sacándolo, o como mínimo daría el código liberado de MI programa (que no es de Sony y por lo tanto no tiene Copyright) a otros programadores para que hicieran lo que quisieran con él.

En fin... el tema de la carta ya está muy discutido y yo pienso que el dev hook seguirá adelante.

Y ese donwgrade como irá...

EDITO: este post venía al tema de la carta por si alguien se pierde un poco, se me olvidó citar al anterior eoliano.

kemaru escribió:Pues yo los hubiera denunciado por estorsión. Ya que lo único que hacía es crear software casero.

En realidad además de crear software casero ha distribuido ficheros con propiedad intelectual de sony, así que si alguien puede denunciar a alguien no sería Booster, sino Sony, pero vamos..

Olvidaba ese detalle... No he dicho nada... sorry

pero se ha lucrado con ello?no

WaSm escribió:le digeron ke dejara de sacar el Device hook que sino le acian esto y lo otro...lo tipico de una empresa grande para meter el rabo entre las piernas aun usuario...

Pues creo que es mentira , y el tio no ha recibido ninguna carta, l

Lo primero que una empresa , no te manda diciendote , que dejes o no de hacer ese algo , para enviarte una carta de una empresa , no coje uno cualquiera y la envia sin mas

Lo segundo que el tio ese hubiera mostrado algo de esa carta , cosa que yo de momento desconozco

Lo tercero , que tambien se puede haber tirado el farol para decir que trabaja tanto en esos proyectos o simplemente necesita mas tiempo , vamos que algo por el estilo ,

Esto es lo que creo , pero que alguno de vosotros que este informado del tema , me haga corregir , Saludos

Yo creo, que esta trabajando para cambiarse de Nick, el cambiar de nombre al DevHook (Alomejor se llamara HookDev ) y no esta sacando ninguna version nueva, por que esta trabajando en la definitiva, con Nand Driver Emulation y todo eso, asi sacando el definitivo, le puede dar otro toque $ony, pero ya tendremos lo que queriamos
En fin, esto quedara en el aire, ya veremos lo que nos prepara la scene pesepera
Saludos!

También puede ser que el tio tenga vida privada y no se pase el día programando para nosotros... Pero bueno, sería una noticia estupenda tener la emulacion de la nand...

(Ese paisanooo) Eso de la emulacion de la NAND seria poder emular el modo actualizacion?¿

Yo no entiendo que significa emulación de la Nand me podeis explicar que es ?

La nand es la flash no ?

Toda actualizacion, va dirigida hacia la nand, el devhook, al no poder emular la nand, al iniciar el actualizador, te dara error, el dia en el cual se emule la nand, al iniciar una actualizacion de un firmware superior, ira hacia la nand emulada, asi tendriamos todos los firmwares emulados, y desencriptados
En fin, ya llegara
Saludos!

aun na de na,no se a dicho como va la cosa no de momento seguimos igual?

ná de ná. Espero que no haya habido alguna complicación.

me imajino que no por que de ser asi seguramente supiesemos algo bueno eso creo

vais a estar un mes asi???? o lo que tarde??? de verdad????

hay rumores de ke esto no va a servir pa na

Tranquilidad, y paciencia... No creo que exista el "Firmware Perfecto", hay que darles tiempo a aquellos que investigan el bug, eso no es "Un bug!!! mañana downgrader..." eso lleva su tiempo
Saludos!

E no he dicho k esto no valla a servir de nada sino k puede caber la remota idea de que se retrase un poco por una remota complicación ademas dice que ya se puede usar el VSH mode.

Noticias(creo )
Originally Posted by Fanjita
In layman's terms, here's how buffer overflows work, from the basics.

In coding, it's common to organise your program into functions. A function is just a set of instructions for doing some task, e.g. to print something to the screen. Because a function can be called from anywhere in your program, there needs to be a way of remembering where the program was before it called the function, so it can return there once the function is finished. The way this is done varies, but typically (and on the PSP) it's done by recording the current program position in a part of memory called the stack, then calling the function, then retrieving that position and going back there once the function is done.

It also happens that a lot of code uses memory space on the stack to store working variables and other temporary data.

What normally happens with image-viewing code is that the flow of the program is tightly defined - it opens the image, decompresses it, and displays it, then exits. All of this time it is running code, but it is running code written by Sony. What we want to do is to somehow intercept the program, and make it run our code instead.

Image exploits do this by giving the image viewer code a 'broken' image to view. The way in which it is 'broken' is chosen carefully, by understanding the behaviour of the image viewer code that we're targetting. What we aim to do is to get the image viewer to unpack bits of the image into its data space (the 'buffer') on the stack, in such a way that it unpacks more data than can fit in the space that has been set aside for it.

The trick that makes all this work, is that the place in memory where it recorded where to return after the function, is often close to the place where the buffer is located. Therefore, we can get the program to overwrite its own record of where to go back to. By very careful design of the data that we're stuffing into the buffer, we can fool the program into thinking that the return location is actually somewhere completely different, which just so happens to be a place where we've loaded our own code. So, when it finishes the function and tries to return from it, it actually jumps into our code, and BINGO! we're running our code.

This is a slightly simplified description of how all this works, and obviously there's a lot more detail in the actual process of designing an exploit like this. The art of it lies in several areas:

* Working out which code might be vulnerable in the first place
* Working out how it might be vulnerable
* Figuring out exactly where the different parts of memory that are involved are.
* Designing input data that overflows the correct data into the correct locations in memory
* Getting code loaded into some known place in memory so that you can actually call it
* Dealing with many quirks in the hardware, such as caching, and also restrictions of your exploit (sometimes the data you provide gets changed during the copying process, so you need to adapt to that)
* Working out how to get your code to get a sufficient foothold on the system that it can actually start to do some stuff - that gets increasingly harder on the later firmwares.


It's a really tricky process, and requires a lot of ingenuity, hard work and testing to get to the point of running something useful, especially because Sony keeps inventing new countermeasures to make the whole process harder. Some of the tricks in 2.5 are just evil... But it's also tremendous fun, which is why we do it

jeje q cachondo, dice "esto es tremendamente divertido, y es por lo que lo hacemos"

lo que pone es como se ralizan los exploits que explotan los overflows, en que consiste y como se realizan basicamente.

Dios por favor que alguien lo traduzca al español y que despues lo escriba de forma k todos los mortales k no entendemos de aspectos tecnicos lo entienda.

Google traducción, menos da una piedra xD

En los términos del laico, aquí es cómo los desbordamientos del almacenador intermediario trabajan, de los fundamentos. En la codificación, es común organizar tu programa en funciones. Una función es justa un sistema de las instrucciones para hacer una cierta tarea, e.g. de imprimir algo a la pantalla. Porque una función se puede llamar dondequiera adentro de tu programa, necesita ser una manera de recordar donde estaba el programa antes de que llamara la función, así que puede volver allí una vez que se acabe la función. La manera que se hace esto varía, pero (y en el PSP) ha hecho típicamente registrando la posición del programa actual en una parte de la memoria llamada el apilado, después llamando la función, después recuperando esa posición y yendo detrás allí una vez que se haga la función. También sucede que los muchos del código utilizan la memoria en el apilado para almacenar variables de trabajo y otros datos temporales.
Qué sucede normalmente con código de la imagen-visión es que el flujo del programa está definido firmemente - abre la imagen, la descomprime, y la exhibe, entonces salidas. Todo este tiempo es código corriente, pero es código corriente escrito por Sony. Qué deseamos hacer es interceptar de alguna manera el programa, y hace que funciona nuestro código en lugar de otro.
Las hazañas de la imagen hacen esto dando al código del espectador de la imagen una imagen “rota” a la visión. La manera la cual “está adaptada” es elegida cuidadosamente, entendiendo el comportamiento del código del espectador de la imagen que targetting. Qué apuntamos hacer debemos conseguir al espectador de la imagen desempaquetar los pedacitos de la imagen en su espacio de los datos (el “almacenador intermediario”) en el apilado, de una manera tal que desempaquete más datos que puede caber en el espacio que se ha puesto a un lado para él.
El truco que hace todo este trabajo, es que el lugar en memoria en donde registró adonde volver después de la función, es a menudo cerca del lugar en donde se localiza el almacenador intermediario. Por lo tanto, podemos conseguir el programa para sobreescribir su propio expediente de adonde ir de nuevo a. Por el diseño muy cuidadoso de los datos que estamos rellenando en el almacenador intermediario, podemos engañar el programa en el pensamiento de que la localización de vuelta es realmente en alguna parte totalmente diferente, que apenas sucede tan ser un lugar en donde hemos cargado nuestro propio código.
¡Así pues, cuando acaba la función e intenta volver de él, salta realmente en nuestro código, y BINGO! estamos funcionando nuestro código. Ésta es una descripción levemente simplificada de cómo todo el ésta trabaja, y obviamente hay mucho más detalle en el proceso real de diseñar una hazaña como esto. El arte de él miente en varias áreas:
* Resolviendo qué código pudo ser vulnerable en el primer place
* Resolviendo cómo puede ser que sea vulnerable
* Calculando hacia fuera exactamente donde las diversas partes de la memoria que están implicadas are.
* Diseñando los datos de entrada que desbordan los datos correctos en las localizaciones correctas en el memory
* que conseguía código cargaron en un cierto lugar conocido en memoria de modo que puedas llamar realmente el it
* que se ocupa de muchos caprichos en el hardware, tal como depositar, y también restricciones de tu hazaña (a veces los datos que proporcionas consiguen cambiados durante el proceso de copiado, así que necesitas adaptarse a el)
* resolviéndose cómo conseguir tu código para conseguir un suficiente equilibrio en el sistema que puede comenzar realmente para hacer alguno materia que consigue cada vez más más duro en los firmwares más últimos.

Es un proceso realmente difícil, y requiere muchos de ingeniosidad, de trabajo duro y de prueba para conseguir al punto de funcionar algo útil, especialmente porque Sony guarda el inventar de nuevas contramedidas para hacer el más duro de proceso entero. Algunos de los trucos en 2.5 son mal justo… Pero es también la enorme diversión, que es porqué la hacemos

muy bien yo de ai saco que ya saben como tienen que acer el downgrade y solo queda programarlo(que creo que es lo mas facil del progreso), si me equivoco que me corrijan, por k tampoco es que me aya enterado muy bien.

yo por no leerlo kreo lo k dices tio jajaj

lo mismo de antes pero ordenado...

Al principio Fijado por Fanjita
En los términos(las condiciones) del profano, aquí está como el parachoques se desborda el trabajo, del básico.

En la codificación, es común organizar su programa en funciones. Una función es solamente(justo) un juego de instrucciones para hacer alguna tarea, por ejemplo imprimir algo a la pantalla. Como pueden llamar una función de todas partes en su programa, tiene que haber un modo de recordar donde el programa era antes de que esto llamara la función, entonces esto puede volver allí una vez que la función es terminada. De camino esto es hecho varía, pero típicamente (y sobre el PSP) es hecho por registrando la posición de programa corriente en una parte de memoria llamó el montón, luego llamando a la función, luego recuperando aquella posición y volviendo allí una vez que la función es hecha.

También resulta que mucho código usa el espacio de memoria sobre el montón para almacenar variables trabajadores y otros datos temporales.

Que normalmente pasa con el código que ve imagen es que el flujo del programa fuerte es definido - esto abre la imagen, lo somete a descompresión, y lo muestra, luego sale. Todo este tiempo esto controla el código, pero ello controla el código escrito por Sony. Lo que queremos hacer debe de algún modo interceptar el programa, y hacerlo controlar nuestro código en cambio.

Las proezas de imagen hacen esto por dando al espectador de imagen cifra una imagen 'rota' para ver. El camino del cual es 'roto' es escogido con cuidado, por entendiendo el comportamiento del código de espectador de imagen que somos targetting. Lo que apuntamos para hacer debe conseguir al espectador de imagen para desempaquetar los añicos de la imagen en su espacio de datos ('el parachoques') sobre el montón, de tal modo que esto desempaqueta más datos que puede caber en el espacio que ha sido dejado de lado para ello.

El truco que hace todo este trabajo, es que el lugar en la memoria donde esto registró donde volver después de la función, es a menudo cerca del lugar donde el parachoques es localizado. Por lo tanto, podemos conseguir el programa para superponer su propio registro de donde volver a. Según el diseño muy cuidadoso de los datos que llenamos en el parachoques, podemos engañar el programa en el pensamiento que la posición de vuelta está en realidad en algún sitio completamente diferente, que solamente(justo) tan resulta ser un lugar donde hemos cargado nuestro propio código. ¡Tan, cuándo esto termina la función y trata de volver de ello, esto en realidad brinca en nuestro código, y el BINGO! controlamos nuestro código.

Esto es una descripción ligeramente simplificada de como todos estos trabajos, y obviamente hay mucho más detalle en el proceso real de diseñar una proeza como esto. El arte de ello miente(está) en varias áreas:

* La resolución cual código podría ser vulnerable en primer lugar
* la Resolución como podría ser vulnerable
* el Entendimiento exactamente donde las partes diferentes de memoria que está implicada son.
* El diseño de los datos de entrada que se desbordan los datos correctos en las posiciones correctas en la memoria
* La adquisición del código cargado en algún lugar sabido(conocido) en la memoria de modo que usted en realidad pueda llamarlo
* Tratando con muchos caprichos en el hardware, como caching, y también las restricciones de su proeza (a veces los datos usted provee es cambiado durante el proceso de copiar, entonces usted tiene que adaptarse a lo que)
* la Resolución como conseguir su código para conseguir un equilibrio suficiente sobre el sistema que esto en realidad puede comenzar a hacer alguna materia - que se hace cada vez más más difícil sobre los programas fijos posteriores.

Esto es un proceso realmente difícil, y requiere mucho ingenio, brega y probando para ponerse al punto de carrera de algo útil, sobre todo porque Sony sigue inventando nuevas contramedidas para hacer el proceso entero más difícil. Algunos trucos en 2.5 son solamente(justo) malos... Pero esto es también la diversión enorme, que es por qué lo hacemos

practicamente nada nuevo

queroantonio escribió:jeje q cachondo, dice "esto es tremendamente divertido, y es por lo que lo hacemos"

Tu has programado alguna vez en logo aunque sea?
Tu no veas lo que mola ver que una cosa te sale, ademas de ser un gran reto personal y una enorme satisfaccion si te sale, significa ganar muchisimo respeto como ha conseguido por ejemplo dark_alex ahora nadie duda de el, todo lo que dice el va a misa (y no es para menos), en pocas palabras que si nos dice que probemos esto lo probamos porque nos fiamos bastante (para mi dark_alex es el mejor scener del momento).

Alguien me puede explicar porque no me gusta leer estas cosas en español? quiero decir el comunicado de fanjita.

En terminos que entendamos todos así es como funciona un buffer overflows, de forma sencilla.

Para codificar, se suele organizar un programa en funciones. Una función con un sistema de instrucciones para realizar alguna tarea, por ejemplo imprimir algo a la pantalla. A una función se le puede llamar desde cualquier lado del programa, se necesita una forma de recordar donde estaba esa función en el programa antes de llamarla, para así poder volver al programa una vez que acabe la función. La manera de hacerlo en la PSP varía, se ha hecho siempre registrando la posición del programa actual en una parte de la memoria llamada stack, después se llama a la función, después se recupera esa posición y cuando acaba la función se va a esa posición.

También ocurre que muchos códigos utilizan la memoria en el stack para almacenar variables de trabajo y otros datos temporales.

Lo que ocurre con el visualizador de imagenes es que el flujo del programa está muy definido- abre la imagen, la descomprime, y la visualiza. Todo este tiempo es código normal, pero es código normal escrito por Sony. Lo que queremos es coger el programa de alguna forma, y hacer que funcione nuestro código en lugar del otro.

Los exploits de imágenes hacen esto, cuando el visualizador de imagenes ofrece una imagen "rota". La manera la cual “está adaptada” es puesta cuidadosamente, entendiendo el comportamiento del código del visualizador de imágenes. Lo que intentamos es que el visualizador de imágenes pueda desempaquetar los pedacitos de la imagen en su espacio de datos (el “buffer”) en el stack, de tal manera desempaquete más datos de los que puedan caber en ese espacio que se ha reservado para el.

El truco que hace todo esto, es que el lugar en memoria donde se registró es donde debe volver después de la función, que es a menudo cerca de donde se localiza el buffer. Por lo tanto, podemos conseguir el programa para sobreescribir esa parte para ir hacia atras también. Por el diseño muy cuidado de los datos estamos rellenando el buffer, podemos engañar el programa para que piense que la lozalización de los datos que pide sea en otra parte totalmente diferente, en la que hemos cargado nuestro propio código. ¡Entonces, cuando acaba la función e intenta volver hacía el final, salta hacia nuestro código, y BINGO! estamos haciendo funcionar nuestro código.

Ésta es una descripción algo simplificada de como se trabaja, y obviamente todo esto tiene mucho más detalle en el proceso real de diseñar un exploit. Este detalle está en varias sitios:
· Resolviéndo qué código pudo ser vulnerable en primer lugar.
· Resolviéndo cómo puede ser vulnerable.
· Calculando donde están las zonas de la memoria que estarán implicadas.
· Diseñando los datos de entrada que desbordan los datos correctos en las zonas de memoria correctas.
· Conseguir cargar código en un lugar conocido en memoria para luego poder llamarlo.
· Tener en cuenta las especificaciones del hardware, donde dejarlo todo, y también restricciones del xploit (a veces los datos que proporcionas se cambian dutante la copia, así que hay que adaptarse a eso)
· Resolviéndo cómo conseguir tu código para conseguir un suficiente equilibrio en el sistema para pode comenzar a trabajar. Yque en los últimos firmwares es cada vez más complicado.

Es un proceso realmente difícil, y requiere bastante ingenio, trabajo duro y pruebas para conseguir que funcione algo util, especialmente porque Sony iventa nuevas contramedidas para hacermás duro todo este proceso. Algunos de los trucos en 2.5 nos dan decepciones… Pero también es mucha la diversión, que es por lo que lo hacemos.

traduccion decente mejor q la del google por parte d zerox de todopsp
salu2

alexfd escribió:
Tu has programado alguna vez en logo aunque sea?
Tu no veas lo que mola ver que una cosa te sale, ademas de ser un gran reto personal y una enorme satisfaccion si te sale, significa ganar muchisimo respeto como ha conseguido por ejemplo dark_alex ahora nadie duda de el, todo lo que dice el va a misa (y no es para menos), en pocas palabras que si nos dice que probemos esto lo probamos porque nos fiamos bastante (para mi dark_alex es el mejor scener del momento).

Alguien me puede explicar porque no me gusta leer estas cosas en español? quiero decir el comunicado de fanjita.

Pues como cualquier cosa en la vida, no solo en el ambito de la informatica. No confundas velocidad con tocino y no interpretes mis palabras como quieres por que lo he dicho para bien y no para mal.

donde esta el canal de fanjita?'

en noobz.eu

alexfd escribió:Alguien me puede explicar porque no me gusta leer estas cosas en español? quiero decir el comunicado de fanjita.

porke en español no tienen sentido......mas o menos

pos la verdad que si, yo no entiendo a la gente que sabiendo ingles quiere las traducciones en español de gugle. yo no se ingles pero si que me gusta porque algo entiendo, a nivel de 3º (ESO). Bueno algo mas porque me pateo alguna vez los foros guiris.

aquí dejo el link del famoso overflow, para que los sceners hispanos investigen tambien, porque si tenemos que esperar a que saken algo los ingleses..........

ya de paso, probar en las psp's, para ver si se os cuelgan (evidentemente seguro, pero probar ya de paso)

http://fragment.lan.st/nop/proof.tif

pero este bug esta tambien en la 2.0 pa lante?

alexfd escribió:pero este bug esta tambien en la 2.0 pa lante?

segun los inlgeses se a provado en 2.0/2.01/2.5/2.6 y en mayores no seguro (se cuelga, pero no an probado ha hacer un hello world o algo por el estilo para confirmarlo)

si esto fructifica el GTA se desvalorizara...

hombre si ya no es o fuese necesario pues es normal. y por otra parte tambien tienes que pensar que para la gente que no lo tiene o el que tiene no es el del bug pues estambien es un incordio.

ya se que hace tiempo se comento en este foro lo del posible downgradeo de psp via *.swf (juego flash) , el caso es que hace una semana probe en una psp 2.71 (original) unos juegos flash, el caso es que nunca consegui iniciarlos, metia en el navegador File:/Juegos/xxx.swf y nunca consegui cargar ningun juego flash, total apague la pesepe, y al dia siguiente de aquello, volvi a encender la psp, aparecia el sony ent.system , todo bien, y en la siguiente pantalla, la ya famosa pantalla azul con todos los idiomas " pulse O para reparar el sistema", el caso es que no le di importancia al tema... y hoy me a dado por hacer la misma rutina en la 2.71(original) y vuelve a aparecer lo mismo.
No se si esto se abra comentado y si se le podra sacar algun provecho

a mi tambien me paso lo mismo, y creo que se debe, cuando accede a la flash1, a mirar si esta activo el flash (DNAS), lo deja abierto en el buffer, y se cuelga produciendo un error en la flash1, pero nada mas... U.U

tengo una 2.70 ( k la actualicé un dia antes de k saliera el downgrade, i tenia la 2.01, sere melón!! todo por el mierda flash en el navegar k no carga una mierda pq le falta memoria!! mierda flash!!) i he cargao el tiff i se keda colgao.
Spero k para antes de invierno lo saken, ya k viene Metal Gear Portable Oops! jejejeje moola, hoy ha salio el segundo trailer, k visto lo visto kreo k es lo k todos hemos visto, algo es algo...

POR DIOS!! DALE CAÑA A MI 2.70!!

alexfd escribió:si esto fructifica el GTA se desvalorizara...

El GTA ya esta desvalorizado por 2 causas:

Por el tiempo q lleva fuera ya
Y por q todas las remisas q vengan ya vendran correjidos

/Offtopic

pues precisamente por todas las remesas que ya vienen corregidos los antiguos se revalorizaran...

Vamos que te has colao...

estoy dsd el navegador de la psp...x dios necesitamos mas informacion...estoy desesperado,no solo yo,tambien medio mundo...

Todos esperamos ansiosos la gran noticia ^^!

PD: esperemos k no tarden mucho, q ya han hecho todo el trabajo estresante y mas chungo nO ?

pD2: Gracias a todos los grandes sceners