forums.ps2dev.org

tmbinc · Joined: 30 May 2005 Posts: 6

Hi,

I noticed the following ways to crash the wipeout browser:

1.) "<div>" * (large number, > ~500). you can use every other tag as well.

The html parser seems to be recursive. At least this slows down the parsing process until it finally crashes.

No big deal, i think, i don't think it can be exploited (but hey, people always told this and a month later, machines get rooted.)

2.) <a href="proc://buttons/http://bla?bla">CRASH ME</a
3.) <a href="proc://exists/http://bla?bla">CRASH ME</a
4.) <a href="proc://sound/http://bla?bla">CRASH ME</a

Looks just like some stupid *strchr(buffer, '<any-nonexisting-char>') =0; (which is damn stupid, yes, but doesn't look too exploitable, too.)

5.) "<" + '(any char)' * 1024

This looks more interesting. The crash boundary is exactly 1024 characters, which makes me feel that the developers of the wipeout browser are indeed damn stupid.

and finally my favourite one:
6.) "<a href="proc://upload/profile:http://?" + 'a' * ~980 + "">CRASH ME</a>"

this one seems to be related with the "%s&upload=profile&value=all&uid=%s" format string. No, they didn't used snprintf. How stupid.

Anyway, i tried something like "http://?" + "\xfc\x23\x91\x88" * (256+16) which should end up at 089123fc, which should be a "jr $ra" (can somebody please check this? i was told that game load to 08900000, and as \x08 seems to cause problems while parsing, i set the MSB. Is this valid for code like for data addresses, too?), and it didn't worked as expected (expected behaviour: "sounds continues, browser hangs", experienced behaviour: "like any other crash - sound hangs, browser hangs"). I don't have a bright idea anymore.

I've spent some disassembling the corresponding functions, but i couldn't find something i'm doing wrong. The buffer in question should be 0x400 bytes, plus 0x20 bytes of variables which are only touched after the sprintf(), and then the return address. So sending 0x420 bytes junk and the the return address should do it. Well, it doesn't.

KiWi · Joined: 10 Mar 2005 Posts: 13

Yo tmbinc !

Nice to see you joining from Gamecube development to PSP development ...

Finding overflows in the Wipeout browser is not the time worth for doing research. I personally think it's easier to find an overflow in the build in media player routines (jpeg viewer, mp3 player, mp4 player etc.)

It would also be more comfortable to turn on the psp and starting code over the build in viewers than booting wipeout from umd and typing hundreds of chars into the url line ...
_________________
Regards,

KiWi

Germany's largest Console Community : www.gamefreax-forum.de

placasoft · Joined: 28 Mar 2005 Posts: 53

What does ""proc://exists/" do?

tomt · Joined: 23 May 2005 Posts: 12

sounds very promising for a buffer overflow :)

i have a few questions:

if the wipeout code is encrypted how do you decompile it?

and more generally when doing buffer overflows on console games, i was just thinking.. you must have to unregister all the callbacks the game has to be properly in control of the system right? is that what you meant by the sound continuing?

also surely its better to have a buffer overflow in a game that sony cant easily patch, rather than the firmware which most likely wont work anymore once it is updated, i think this direction is a very good idea.

tmbinc · Joined: 30 May 2005 Posts: 6

KiWi: i choosed the first thing which i had some binaries for, and that was wipeout. exploiting something without having binaries sounds nearly impossible for me, at least when doing stack-based overflows where you have to know the return-addr.

Sure an exploit in something else would be better, but at least i don't have any access to the binaries of the loader.

placasoft: Honestly, i don't know. I grepped through the binary, and found it.

tomt: The available rip contains EBOOT.BIN which is encrypted and BOOT.BIN which is unencrypted. I don't know for sure if this executable matches the one on my wipeout disc, but especially the 6.) behaves like i expected that from the code.

About the "sound-or-not":

The sound is played in one thread, the browser works in another thread.
Now, if a thread crashes, the whole game crashes. The exception handler probably halts the whole system (?). If some thread, however, would loop infinite, the other threads should continue. Thus, the sound should continue, while the browser hangs (but not crashes).

As said, it didn't worked. Maybe because i have to jump to 08xxxxxx and can't set any other bits? Sorry i'm not too familiar with this kseg-stuff. Can anybody enlighten me?

Or the binary is just a little bit different than the one on my disc (japanese vs. US?)

Does anybody know how to place something in the memory at a known location?

placasoft · Joined: 28 Mar 2005 Posts: 53

tomt · Joined: 23 May 2005 Posts: 12

thanks for the info :)

i have the us wipeout, i'll test it if you like (if i get time)

GeKKo · Joined: 16 May 2005 Posts: 9

The 1. Way doesn't work for me : /.

Hey placa man sieht dich so selten auf pg.de :|

djhuevo · Joined: 10 Mar 2005 Posts: 47

placasoft · Joined: 28 Mar 2005 Posts: 53

Erant · Joined: 13 May 2005 Posts: 33

tmbinc · Joined: 30 May 2005 Posts: 6

With help of #pspdev i was able to continously call "sceKernelSleepThread", so sound continued but browser crashed. yay.

The binary is in fact loaded to 08900000. That location seems to be "static", it isn't randomized or so.

Next big task is to place some more interesting code somewhere where we know the memory address of. I haven't succeeded here for now.

Damn, i wish i had a ramdump of the running game...

0xdeadface · Joined: 31 May 2005 Posts: 62

If you managed to call the KernelSleepThread, how did you achieve that?
If you'd like to share please do :) but if not - Wouldn't it simply be possible to place your own code in the data you pass (except you'll have a pain to code it in such a way that it only uses allowed bytes)? That's at a known address (program counter - xx) which you can stuff in ra and jump to?

0xdf

Shine · Joined: 03 Dec 2004 Posts: 728 Location: Germany

tmbinc · Joined: 30 May 2005 Posts: 6

0xdeadface:

I overwrote the return address with the address of the sceKernelSleepThread function (or better, the wrapper).

Yes, i could pass my own code, but the problem is finding it in memory. I don't know where the stack is located nor any other place where i can upload code to. The only thing i know is that the binary itself is loaded to 08900000.

Basically only .data or .bss are fixed in memory, and i wasn't able to find anything useful which i could do to have specific data loaded there.

Making some "shellcode" which only contains allowed bytes is probably difficult but not impossible. so far i wrote some "put-something-to-vram" which doesn't have any nullbytes - but still, i don't know where i have to jump to.

@shine:

IDA Pro, as always. I'm a lucky employee who could convince his company that this piece of software is "absolutely required for my work". And well, it is. :)

Finding the stuff is easy. Just search for some sprintf()-like format strings, and look how they are used.

Or search for stack frames in the range of ~1kb or so (just search for the "addiu $sp, -0x400...0x500" or whatever - some binary wildcarding does it fine). That gives you a lot of interesting functions.

0xdeadface · Joined: 31 May 2005 Posts: 62

"deleted....forgot to think*

0xdf

chaos · Joined: 10 Apr 2005 Posts: 135

is the location random? or would it be the same place every time?

if it was fixed, and you could put enough nops in front of it, it would be possible to generate a batch of say 1000 possible locations..

i'm sure we could find enough volunteers to try them fairly quickly..
_________________
Chaosmachine Studios: High Quality Homebrew.

LiquidIce · Joined: 04 Apr 2005 Posts: 55

Yes, you have one volunteer here with his PSP booted into the Wipeout browser, ready to test. Let me know what I need to do, and it shall be done.

Sounds like you guys might be on to something here.

Shine · Joined: 03 Dec 2004 Posts: 728 Location: Germany

0xdeadface · Joined: 31 May 2005 Posts: 62

tmbinc,
While I assume you already have done this, have you checked where with your own (meaning any homebrew) app the stack lies?
It'd be kinda safe to assume that the stack at that moment of crashing can't be *that* far away from that address. Surely it'll be a tad deeper, but most likely in the order of bytes, not Kb's.

If you have determined how long the string is you can pass (both before the jump address and after it you should be able to inject different fragments of code to and some cleverly guessed jump addresses to figure out where your stack lies exactly at that moment in time?

This is, by the way, assuming that the crash happens in usermode code. I don't know whether kernel code uses it's own stackspace.

Unfortunately I have no WipeOut....might want to get that :)

0xdf
(edited to make one thing a bit more readable'

Shine · Joined: 03 Dec 2004 Posts: 728 Location: Germany

tmbinc · Joined: 30 May 2005 Posts: 6

You need to put the address of sceKernelSleepThread, not the ID. the address would be 0x08a39360. otherwise it would work, though i didn't tried with javascript. i had to use 0x48a39360 because 0x08 wouldn't be parsed, but maybe you have more luck with javascript!

i used Wipeout-USA (is there another version?)

0xdeadface: the problem is that each thread allocates a new stack, most threads have stack sized of ~64k. this gives a rather large space to search :/

0xdeadface · Joined: 31 May 2005 Posts: 62

tmbinc,

Have you already determined the correct position in the string where the return address should be placed?

I wonder how many bytes you can get stuffed behind it...it would, in case of a bruteforce search, at least limit the search space

I know it´d be a ridiculous venture but......if all else fails.....

0xdf

tmbinc · Joined: 30 May 2005 Posts: 6

Shine: i'm sorry, i wasn't able to get this to work with javascript. try a static file.

anyway, i think call= "\x60\x93\xa3\x48"; should do it (or does it produce unicode crap?), but it doesn't. or should unescape() work around something?

Galfpart · Joined: 01 Jun 2005 Posts: 9

tmbinc, nice work so far.

tmbinc:
have you tried looking for a byte sequence in the wipeout
binary which will form an opcode to copy the current stack pointer
into the Program counter/ Instruction Pointer ?

something like

MOV PC, SP (ARM equivalent)

or

PUSH ESP (IA32 equivalent)
RET

From there you can continue your experiments ;-)

This might work, depending on the layout of the stack.

i'd love to try it out myself but i don't have a psp ;-)
any sponsors around ? ;-)

cheers

tomt · Joined: 23 May 2005 Posts: 12

i was thinking about this the other day but i didnt post it because i thought it was too dumb

but if you have a vague idea where the stack is you could just put it the return address, and then a huge list of no ops (like several K), followed by your code.

that way as long as the return address is within the list of no ops, it should just run all the way down them to your code, so you dont have to hit the first instruction spot on.

if you cant encode the no op instuction (does mips even have one?) you could always just put a huge list of adds that wont have any effect other than adding lots to a register

pixel · Joined: 30 Jan 2004 Posts: 791

Galfpart · Joined: 01 Jun 2005 Posts: 9

pixel, what'd be the opcode sequence of that instruction ?

thanks in advance

pixel · Joined: 30 Jan 2004 Posts: 791

http://wiki.nobis-crew.org/PlayStation/r3000

There's all the ressources you need to encode the instruction yourself, and even more of them. jr $sp would be 0x03a00008
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

Galfpart · Joined: 01 Jun 2005 Posts: 9

Thanks!

the bad news:

Searching down CASE-INSENSITIVELY for binary string 08 00 a0 03...
Search failed.
Command "AskBinaryText" failed

Gotta have a deeper look...

edit:

as MIPS processors have a lot of registers, there may be more
than just one register pointing to the stack. maybe someone is lucky
and can find any register pointing into his "shellcode". what does
the psp do when it crashes?
i want a coredump ;-)