GDB error != runtime error

While trying to develop an exploit recently, I ran into a 'fun' issue with GDB: lies. See, while working on a ROP buffer I had been stepping through with GDB to ensure everything was lined up properly. At the very last step of the exploit, the one before actually calling my shellcode, I kept running into the same error:

(gdb) msi
0x0804a92e in <....... removed .......>
=> 0x804a92e <....... removed .......>    ret   
(gdb)
Cannot access memory at address 0x5f
(gdb)

After double-checking the exploit payload, the registers, re-adjusting values, etc I still saw the same error. Finally out of frustration, I told GDB to continue just so the application would crash. To my surprise, the crash never happened and my shellcode executed! Wait! What? I thought we had a memory access problem. Turns out, that error was from GDB trying to read the current application location by referencing EBP, which had just been trashed with the value 0x5f. Next time, need to pay attention that no SIGNAL had been received by GDB. Or, maybe GDB could have been nicer to state that why/what it was accessing 0x5f.

More than fossils in TAR

Buried deep in the GNU manual for tar are references to a prompt when changing tapes. Now, I don't know many people who actually still use tar with tapes, but let's look an interesting excerpt:

When GNU tar comes to the end of a storage media, it asks you to change the volume. The built-in prompt for POSIX locale is(23):

Prepare volume #n for `archive' and hit return:

where n is the ordinal number of the volume to be created and archive is archive file or device name.
When prompting for a new tape, tar accepts any of the following responses:

and

!

Request tar to run a subshell. This option can be disabled by giving ‘--restrict’ command line option to tar(24).

So if we can force the end of a tape prematurely, tar will allow us to drop to a prompt. Turns out a few lesser used options provide just that ability. Here's an example script that will drop to yet another shell. Check it yourself with 'ps f' afterwards.

#!/bin/sh
dd if=/dev/zero of=./filler bs=1024 count=30
echo "at the next prompt, enter '!' without the quotes and press Enter"
tar cf /tmp/tmp.tar --multi-volume --tape-length=10 ./filler

Hex-Rays + C++ = The Low Pass Filter

Recently doing some RE on a closed-source C++ library, and Ida alone wasn't cutting it as the C++ name-mangling, and operations can be quite 'noisy'. So I figured why not throw it through Hex-Rays' decompiler to get a look at just the C++ operations.

My favorite feature of Hex-Rays is being able to quickly recognize obfuscation operations. These are generally instruction intensive and if written in a high-level language, often times filled with extra mov's and unnecessary operations. This makes it more time-consuming to decipher. Hex-Rays generally chews this kind of stuff up and spits out the juicy bits.

Now, following the de-obfuscation was a series of C++ string-class operations that consisted of concatenating various pieces. To aid in deciphering which pieces were used when, I figured that Hex-Rays would be able to easily decipher this and provide me the same goodness as the de-obfuscation.

Anyone who's used Hex-Rays knows all about its ability (or IN-ability) to actually decompile some code and the feature of just omitting the code. In this case, I was hoping that it should at least pick up the C++ object operations and just display those to minimize the extraneous work. Turns out, Hex-Rays actually dropped most of the C++ operations that I was originally interested on the floor. BUT, what it did reveal was a key even better than what I was searching for. So in this case, Hex-Rays acted as low-pass filter to remove the noise that I thought was interesting data. Lesson learned? Just because it was omitted doesn't mean it wasn't useful, but it may make something else more obvious.

Red Dead while PSN is Dead, Part 3

So after one night of the script working, future tests kept turning up nil results.

Everything we tried kept showing the broadcast messages for finding a server, as well as the server response; but, the client would not connect.

Reviewing traffic over-and-over again turned up nothing new at the IP layer. Turns out, the IP address of the server is embedded in the message sent by the server. I discovered this by noticing ARP requests for my IP address on the other network. A quick fix of changing the repeater address of the "fake" server to that of a PS3-server and voila, working again.

I'll dig into the protocol to find that in the fields and release a new version of the scripts that will fix the IP on the fly. Until then, at least there is a work around.

Red Dead while PSN is Dead, Part 2

Continuing my testing, I found that upon receiving responses from the server, the client then switched to a different port for both sending and receiving, 3658. A quick fix in the script to handle this, and voila LAN game activated.

So now I present to you 2 Python script files that will bridge 2 LANs and allow for 1v1 multiplayer in Red Dead Redemption on the PS3. Currently the scripts have been tested with one Linux and one Windows machine. Turns out there are some gotcha's between the two platforms when it comes to UDP broadcast traffic. In Windows, broadcast UDP packets will be received by a socket listening on a specific IP, whereas Linux required listening on ANY. This results in a weird scenario where the Linux box could not send from the proper socket. To host the source, I created a Google Code project, GPL-v2 licensed.

This only supports one other user, there is no voice chat (as that is carried over the PSN), and has only been rudimentary tested. Hope this helps someone while the PSN is down.

Red Dead while PSN is dead

Back in college, when the network admins added rules to the routers in the dorms to drop UDP broadcasts, we wrote an application to perform re-broadcast on different leaf's to allow for our games to work. All we wanted was some Counter-Strike, and Unreal action.

So turns out that effort was not totally for naught with the recent PSN outage. Most game only have PSN support, but luckily our current game du jour, Red Dead Redemption, also still has support for LAN gamers. Alas, trying to create a VPN without heavily modifying our home networks can be quite cumbersome. So I decided to analyze the traffic for the game and write a 1-off server so my brother and I can take care of some outlaws. I mean, they're not going to kill themselves.

Analyzing the traffic, I found that when entering LAN mode the game would broadcast a series of packets to the LAN on UDP to port 11112. Whipping up a client/server to handle this was simple enough. So far the client has sent its broadcast requests to the server, and the server has responded, but the client does not seem to like the responses. So I tried to dig a little deeper and see if anything stood out in the protocol. So far, the only item of note is the first 16-bits of the UDP payload is the size of the message being sent. The contents of all the messages does not change from both the client and the server. So this leads me to believe that maybe some timing is being performed to detect if its *really* a LAN connection.

As remote protocol RE'ing can be quite difficult, I tried a scan around the Inter-tubes to see if anyone else had shed any light on this subject. All I was able to turn up was a link about smattering of ports and another broad swath of ports that includes the PSN/Voice Chat ports

Hopefully I can get 2 PS3s on my LAN to see how the traffic works out, otherwise I'm stabbing in the dark. If you have any information on this, or would like to help, drop me an e-mail.