PiratePila escribió:Volviendo al tema...
¿ Se sabe algo nuevo del Xploit 2.7 & 2.8 ?
Yo aún no me enterado muy bien que és, ni para que servira pero bueno... [tomaaa] [+risas]
Saludos !
Como es un poco dificil buscar pagina tras pagina yo me las e mirado todas y e intentado recopilarlo todo por si chapan el hilo,aqui os dejo el resumen por si la persona que ha creado el post ve oportuno copiarlo y pegarlo en el post inicial:
Copio y pego mi resumen de los post anteriores:
Resumen sobre las noticias mas interesantes:
Aviso previo: No hay downgrader ni nada por ahora, es solo información.
Parece ser que unas personas llamadas Dungeon Developers han conseguido encontrar un Xploit para las versiones
v2.71 y v2.80, se trata del Xploit ya archiconocido del Tiff, pero renovado.
Parece ser que todo anda bién por el momento, así que en breve podríamos tener de nuevo homebrew en las versiones
más punteras de las PSP, aunque por el momento es tan solo una investigación.
También se dice que ya se han cargado códigos en PSP's con dichas versiones, aunque quedaría también por averiguar
como acceder al modo Kernel en la versión 2.80 que tapó la modificación que lo hacía posible, de lo contrario en
las 2.71 funciona el mismo método que para las 2.6+.
Como he dicho anteriormente es tan solo un paso más hacia el homebrew en las últimas versiones. No pregunteis por
downgraders, homebrew o cargas, ya que de momento tan solo sabemos que se ha descubierto dicho Xploit, nada más.
Este post tiene como finalidad simplemente informar a los usuarios que en poquito tiempo (o no) podremos disfrutar
de homebrew, pero de momento como ya he dicho es solo un avance.
********************************
Dark Alex dijo:
Parece que si que es un autentico buffer overflow:
En windows, en un programa que usa la libreria libtiff (ImageMagick, que se supone que deberia tener la libreria libtiff
lo mas actualizada posible): "access violation when executing [04004000]"
[04004000] -> es la direccion de memoria especificada en el tif para la direccion de retorno, o sea, que si que se
consiguio saltar a dicha direccion de memoria.
Por cierto, que para un downgrader no hace falta modo kernel. Con modo vsh como el exploit de 2.00 es más que suficiente.
***************************************
[Fanjita]
The only way to view the code in the TIFF is to use a MIPS disassembler on it.
And the only way to understand how it works is to understand how libtiff is coded, and then to figure out
what is unusual (i.e. broken) about the image.
Opening it in a viewer will not reveal anything. Most of the exploited TIFFs just show a small black square,
if anything.
weno esto es lo ke a dixo fanjita, en breve lo traducire...
###Traduccion para que lo entendamos todos:
solo explica ¡como desensamblar el TIFF para ver el código que lleva y como entenderlo para poder hacer algo.
El único modo de ver el código en el TIFF es de usar un MIPS disassembler sobre ello.
Y el único modo de entender como esto trabaja es de entender como libtiff es cifrado, y luego entender(calcular)
que es insólito (p. ej. roto) sobre la imagen.
La apertura de ello en un espectador no revelará nada. La mayor parte de las TIFF explotadas solamente(justo)
muestran un pequeño cuadrado(plaza) negro, si algo.
********************************
Fanjita dice:
Hey guys, iv been messing around with libtiff for a couple of weeks now
and I found something interesting, Im still doing debugging on it and
whatnot, but it crash's the psp and most image viewers, it may be the
begging of homebrew on 2.71 and 2.80 it may not, im not going to release
the source for it just yet, probably in a couple of days once i do
proper debugging to release a full disclosure. i will however post a
link to the image, iv made a small tiff reader program that does the
most ****tiest error checking you have ever seen but i will print a
quick backtrace
Program received signal SIGSEGV, Segmentation fault.
0xb7eae46b in TIFFFindFieldInfo () from /usr/lib/libtiff.so.3
(gdb) bt
#0 0xb7eae46b in TIFFFindFieldInfo () from /usr/lib/libtiff.so.3
#1 0xb7eace97 in _TIFFsetDoubleArray () from /usr/lib/libtiff.so.3
#2 0xb7eacf3e in TIFFVSetField () from /usr/lib/libtiff.so.3
#3 0xb7eacf27 in TIFFSetField () from /usr/lib/libtiff.so.3
#4 0xb7eafd80 in TIFFReadDirectory () from /usr/lib/libtiff.so.3
#5 0x04004000 in ?? ()
#6 0x04004000 in ?? ()
the 0x4004000 was put in by me, iv noticed it hasnt actually overwritten
the instruction pointer and crashed at that address per say, but im sure
i could maybe get something working, if not I then with help this may
become something. Im asking for volunteers, I would prefer someone from
the hitmen or ps2dev crew or SonyXTeam to help, I have recently been
banned from Toc2rta for not releasing any information and whatnot, I
would however like to come back if at all possible and there are no hard
feelings whatsoever. If anyone would like to help or is even the slight
bit interested then get up with me on yahoo my instant messenger name is
hymn_of_a_needle_freak. I am going to jump ahead of myself at the moment
and go ahead and take some inspiration for the old 2.0 exploit and do my
own variation of the framebuffer png(credit goes to skylark on the idea
and niacin for dumping the data on the original version). Im going to go
ahead and work on setting the rest of it up before i concentrate on more
work with the main part of this. Get up with me if your interested.
greetings to the whole psp homebrew team, mainly ps2dev and
sonyXteam(coldbird and the rest of the gang on their irc server) for
taking the time to listen, also groepaz and skylark for putting up with
my hours of retardedness and questions, harleyg and wakawooki for 2.80
testing(your right, the modchip is the **** ) . I would also like to
thank LC for donating me a psp. I dont know to much about the psp at the
moment as i only have 2.71 so if anyone has pointers then please feel
free to share.
thank you
###Traduccion para que lo entendamos todos:
La libreria no tiene una vulneravilidad sino que tiene 2
Al parecer funciona en 2.5 tambien.
Se piensa que cuando se sepa de que manera afecta para 2.7X si se podra hacer algo pues el bug del que se aprovecha
el downdater todavia sigue ahi.
Pero para las 2.8 todavia es pronto.
se rumorea que han cargado algo de codigo tipo HELLO WORLD pero me imagino que eso sera a nivel USER MODE.
*************************************************
fajita escribe:
No. Try reading some kmem, then you'll see that you're not in kernel mode. The Sony APIs just allow
user threads with the VSH thread attribute to do more stuff, that's all.
###Traduccion para que lo entendamos todos:
Que el modo vsh no tiene acceso a kernel pero que no ace falta tener acceso a kernel mode
para hacer un donwgrade con k tengamos modo vsh k lo tenems sirve.....el donwgrade
de 2.00 no lo tenia el acceso a kernel mode solo tenia vsh mode
*************************
Fanjita escribe:
Yes, me for one
But to be honest, it's hard to explain in a meaningful way, without going into a lot of technical detail. Suffice to see
that yes, it is capable of running code. Making that a reliable and repeatable occurrence, such that someone not well versed
in the low level PSP details would take it as fully working, is more difficult.
We're focussing more on exploring the possible scope of the exploit before attempting to convert it into an application.
We'd all much rather know whether it can work on 2.8, than to have yet another way of running eloader on v2.00.
###Traduccion para que lo entendamos todos:
Para ser honesto, es duro explicar de una manera sencilla y entendible, sin entrar en muchos detalles técnicos, la
funcionalidad. Lo que si sabemos es que el bug seria capaz de funcionar código arbitrario. Se podria cargar dicho codigo,
pero no al máximo nivel de la PSP, sino a un nivel bajo (como ya ocurrió con el primer eloader),
lo que será un trabajo duro el ponerlo a máximo rendimiento . Nos estamos centrando mas asta donde puede llegar este bug
(las posibilidades que este nos podrá ofrecer), enverde hacer un exploit para explotar dicho bug (osease un eLoader por
ejemplo). No sabemos si el exploit funcionara en 2.80 de la misma manera que funciona en 2.0
#############################
Bueno almenos nos confirma que si que funciona el bug para cargar código en 2.80, pero que falta tiempo para conseguir algo
que nos consiga rendir a máximo rendimiento (como un cargador de backups o de emuladores potentes). También nos explica que
estan trabajando, para explorar las posibilidades y el funcionamiento que el bug realiza, para mas adelante realizar un
exploit que cargue código (homebrew), (que a mi me parece bien, ya que esa es la base), y que hay bastante trabajo para
conseguir algo mas "estable".