Windows 7 Corrupt Video Stream After 1 Min With A Spoofed MAC

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Using chilly willy's idstoragemanager i changed my psp's mac address to
match that of my windows 7 pc by modifying the mac key in idstorage. (This
is because windows 7 will only spoof mac's starting 12xxxxxxxx and psp's
start with 00xxxxxxxx.) 
2. Then i used the m33 psp mac spoofer to spoof the mac the psp uses to
match the idstorage.
3. Then i register the psp on the ps3 for remote play. (remote play
registered device list shows the psp with the desired nick and mac)
4. Use the export.orp keys from the psp to launch open remote play.

What is the expected output? What do you see instead?
The psp connection has timed out twice while using remote play with a
spoofed mac. Most of the time however it will work fine using my pc's mac.
After using the keys generated from the spoofed psp setup i expected the pc
to work with remote play, but it loses the video signal after about a minute.
What version of the product are you using? On what operating system?
Using psp 2001 with ta85 mobo running 5.00 m33-6. PC is windows 7 x64 intel
i7 920.

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 1 Mar 2010 at 8:42

[GoogleCodeExporter]

Here is the log file...

Original comment by [email protected] on 1 Mar 2010 at 9:19

Attachments:

• orp.log

[GoogleCodeExporter]

If you're seeing "Corrupt video stream", then that means the PS3 has detected 
the MAC
address is incorrect somehow and starts to poison the video stream.

If you are sure the MAC address is correct, then this probably means that the 
PS3 is
also checking the first three octets of the address and comparing it against a 
list
that is registered to Sony.

For example, enter the first three octets (ex: 00:01:4a) of a MAC address here:
http://www.coffer.com/mac_find/?string=00%3A01%3A4a

This is not a defect of Open Remote Play.

Original comment by [email protected] on 7 Mar 2010 at 4:11

• Changed state: WontFix
• Added labels: OpSys-All, Priority-Low, Type-Other
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Thank you for the reply.

I am confused however as to how the psp is able to use the mac address of the 
pc (a
non-Sony mac). If indeed remote play checks the first three octets, shouldn't 
the psp
using an incorrect mac receive a corrupt video stream as well?

Original comment by [email protected] on 7 Mar 2010 at 11:18

[GoogleCodeExporter]

Yes!  I didn't think of that.  If you are able to use the PSP with a spoofed 
MAC (of
your PC) and it works longer than a few minutes without errors or corrupted 
video
frames, then scrap my previous theory - obviously this fact disproves it.

Are you running a Linux gateway or are you able to run Wireshark on your 
network and
capture traffic originating or destined for your PS3?  I would be very curious 
to see
two captures.  The first being between your hacked PSP (with spoofed PC MAC) 
and your
PS3.  The second being from ORP and your PS3 - resulting in a corrupt video 
stream error.

Specifically I would like to examine the Ethernet frame headers between the 
two. 
Both sessions should have identical source/dest. MAC addresses.  If not, then 
that
would be the point to debug from.  If they are identical, then WOW - Sony must 
have
come up with some freaky way to detect ORP that we're unaware of.  However, I'm 
able
to use ORP just fine with the latest PS3 firmware, so I suspect the latter.

So at this point, I'm not sure how technical you are or even if you have the
time/interest to debug further, but the next step would be to start dumping 
network
traffic and using Wireshark to analyze the Ethernet frame headers.

Reverse-engineering is a dirty business :)

Original comment by [email protected] on 8 Mar 2010 at 4:01

[GoogleCodeExporter]

Well at the moment i don't have tons of time but spring break starts on friday 
for
me. So at that point i can dedicate a lot of time.

I got wireshark running on my pc and played around with it for a little bit. 
i've
recorded traffic from my pc to the ps3 while launching orp. I haven't quite 
figured
out how to filter out the other junk that wire shark is recording.
I don't know how to use wireshark to record the psp's network activity. It's not
showing up on the log when i run it.

I believe my router is compatible with some 3rd party firmwares like dd-wrt or
tomato. I think those are linux based but i'm not sure. This particular router 
would
only be compatible with the micro versions of those firmwares. I don't know how
helpful they would be.

Can wireshark dump network traffic or does that have to be done with the router?

Original comment by [email protected] on 8 Mar 2010 at 8:17

[GoogleCodeExporter]

I just changed the firmware on my router to dd-wrt because the stock firmware 
it came
with wouldn't show me a list of connected devices with their mac's and ip's. I 
can
now confirm that the psp is in fact using the exact same mac as my pc. The pc
receives a corrupt video stream within a minute whereas the psp will stay 
connected
without any problems.

Original comment by [email protected] on 8 Mar 2010 at 9:26

[GoogleCodeExporter]

I am unable to install tcpdump or any packages on my router due to hardware
limitations. Sorry. Is there another way to obtain dumps of my network? Perhaps 
some
sort of virtual router running on my pc where i could possible connect the psp 
to my
pc via an adhoc network?

Original comment by [email protected] on 9 Mar 2010 at 7:08

[GoogleCodeExporter]

here are the two captures :)

Original comment by [email protected] on 21 Mar 2010 at 9:30

Attachments:

• orp.pcap
• psp.pcap

[GoogleCodeExporter]

Thanks for the captures!  They are truncated so I can not examine the TCP 
payload,
but from what I can see, the only difference is that Windows 7 is not using TCP
timestamps.  The PSP does.  Perhaps the PS3 is expecting the TCP options to be
present and if not, poisons the video stream.  Check if TCP timestamps are 
enabled:

>: netsh interface tcp show global

Enable timestamps:

>: netsh interface tcp set global timestamps=enabled

NOTE:  I don't know the exact syntax, I guessed "timestamps=enabled", you can
probably run netsh /? to get the proper name if that doesn't work.

If that goes well, you can verify that TCP timestamps are present by dumping the
traffic of an ORP session and checking the TCP header for the options field.  
Should
contain a NOP, NOP, then 12-bytes of timestamp.

If you would like me to compare the two sessions further, you can email me two 
*full*
captures (don't truncate).  Do not post the captures here as they contain 
sensitive
information that you don't want to publicly share.

Original comment by [email protected] on 21 Mar 2010 at 1:32

• Changed state: Started

[GoogleCodeExporter]

Just a testing follow-up:

I've done the same as you, spoofed the PSP's MAC as my laptop's WLAN MAC using
idstorage manager and macspoofer.  This works GREAT by the way!  I've haven't 
tried
it before... and it works!  So now I don't have to use a tunnel to spoof my PC 
as my
PSP.  Anyway, I've been connected for about 2 hours now without any video stream
corruption problems using the latest SVN build:

http://code.google.com/p/open-rp/wiki/Downloads?tm=2

So, I can verify that yes you can use your PC's MAC and the PS3 has no clue.  
So in
your case the difference between our two configurations is that I'm using Linux 
(with
TCP timestamps enabled by default), and you're using Windows 7 (with TCP 
timestamps
disabled).  It would seem like the PS3 actually looks at the timestamp options 
field
of the TCP headers and if it's not present, poisons the video stream.

Original comment by [email protected] on 21 Mar 2010 at 3:04

[GoogleCodeExporter]

ok.. i sent the two captures and i did see the timestamp (nop, nop, and 12 
bytes of
timestamp) in the orp capture. So what else does linux do by default that 
windows 7
doesn't? I'm still getting corrupt video stream.

Original comment by [email protected] on 21 Mar 2010 at 4:15

[GoogleCodeExporter]

"and i did see the timestamp"

So you see the timestamp now that's you've enabled it using netsh?

I haven't received any email yet... which address did you send it to
([email protected])?

Original comment by [email protected] on 21 Mar 2010 at 4:27

[GoogleCodeExporter]

no i replied to the email i got from open-rp that notified me of the new 
comment.. i
just sent it to your email though.

Original comment by [email protected] on 21 Mar 2010 at 4:30

[GoogleCodeExporter]

Did you get the email? I do have timestamps enabled and I believe that they are
showing up on the capture. I still get the corrupt video stream.

Can you confirm from the captures i sent as to whether or not the timestamps are
enabled? If they are I guess I leave the dirty work to you to figure out what 
else
might be going on. Let me know how I can help. Now that i have all the dumping 
pretty
much figured out I can probably be of more help.

Original comment by [email protected] on 21 Mar 2010 at 5:33

[GoogleCodeExporter]

Yes!  Got the email with attached captures.  Studying them I can't see any
significant differences between ORP and the PSP session.  I can verify that you 
have
indeed enabled TCP timestamps.  Since that made no difference, that theory is 
out.

So I decided to try the same version you've been testing, ORP v1.3 325 SVN, on 
my
WinXP virtual machine.  Normally I would use a tunnel set to spoof the PSP's MAC
address, but this time, I tried using your method - spoofing my PC MAC address 
on the
PSP (which works awesome under ORP for Linux).

I was very surprised to see the same results you've been experiencing... video 
stream
corruption after about a minute.  So...  I have much more testing to do but 
this is
very interesting.  ORP v1.3 325 Linux works, ORP v1.3 325 Win32 fails.  From the
packet captures I can not see any differences - but there MUST be something 
there
that the PS3 "sees" which is causing it to counter.  I'll keep comparing and 
see what
I find...  Thanks for the captures!

There definitely is something that Windows does differently (networking-wise) 
that
the PS3 is looking for.

Original comment by [email protected] on 21 Mar 2010 at 10:01

[GoogleCodeExporter]

I've noticed that the length of the orp session, before the video stream is
corrupted, usually depends on what is being done during the session. For 
example if i
watch a movie saved on the ps3 the corrupt video stream will occur much sooner. 
If i
just leave the ps3 on the xmb for the entire orp session it will last a bit 
longer.
I'm not sure if that might be a lead to go off of. Could just be coincidental. 

I also notice a difference when I watch orp in full screen mode by pressing f11.
Although I would think this has nothing to do with the problem at hand, i have
noticed full screen mode lengthens the time of the orp session. Also the corrupt
video stream message does not show in full screen mode, it just freezes on the 
last
frame of the session.

Original comment by [email protected] on 22 Mar 2010 at 12:06

[GoogleCodeExporter]

It shouldn't matter what you're doing with ORP.  Unless watching a video 
generates
more key-frames.  Key-frames are the only frames that the PS3 encrypts.  If it
detects a non-licensed client (ORP), it will encrypt key-frames and then 
randomly
change one (or more?) bytes before sending it.  This results in a corrupted 
key-frame
when decrypted.

Fullscreen mode does nothing different.  Errors are supposed to toggle out of
full-screen mode, returning to windowed mode at 480x272.  But I guess that's not
working properly under Windows... though I have noticed that malformed 
key-frames can
sometimes crash the libavcodec that ORP uses to decoded audio/video.  Maybe 
that's
why it just crashes.

Regardless, I'm really puzzled by how the PS3 can detect a difference (or
differences) between an ORP session in Linux versus an ORP session in Windows
(XP/Vista/7).  I look forward to solving this...  but at this point, I have no 
theories.

Original comment by [email protected] on 22 Mar 2010 at 1:45

[GoogleCodeExporter]

A key-frame would be one where the data contains something like this?

"GET /sce/premo/session/ ctrl HTTP/1.1  User-Agent:..." and so on.

Original comment by [email protected] on 22 Mar 2010 at 2:34

[GoogleCodeExporter]

Nevermind... I think that would be orp telling the ps3 it is a psp.. right?

Original comment by [email protected] on 22 Mar 2010 at 2:38

[GoogleCodeExporter]

On frame 8088 of the orp capture i sent you.. orp sends its user-agent info. 
Then two
frames later is when the ps3 closes the connection.

So I compared orp user-agent data string with the user-agent data string from 
the psp
capture and they are different. Is that normal?

Original comment by [email protected] on 22 Mar 2010 at 2:48

Attachments:

• [orp user-agent.txt](https://storage.googleapis.com/google-code-attachments/open-rp/issue-27/comment-20/orp user-agent.txt)
• [psp user-agent.txt](https://storage.googleapis.com/google-code-attachments/open-rp/issue-27/comment-20/psp user-agent.txt)

[GoogleCodeExporter]

The request you are seeing in the ORP captures (@ frame 8088) is sent to the PS3
*after* the corrupted video stream was detected.  The URL as you can see in the 
image
linked below is for /sce/premo/session/ctrl and the mode is "session-term".  
This is
simply how a remote play session is terminated.

The request you are comparing to is for /sce/premo/session, which is opened at 
the
beginning of *both* sessions (ORP and native PSP).  Look closer toward the top 
of the
ORP capture and you'll see that it does the same thing the PSP does.

Basically, these two requests are different because they are requests for two
different resources.

http://orp.ps3-hacks.com/images/user-agent.png

Original comment by [email protected] on 22 Mar 2010 at 8:08

[GoogleCodeExporter]

Ok. Does the psp terminate a session differently from orp?

Is there a way to make orp clone a psp session? (i mean make the exact same 
requests
in the same order?) I think it would be a nice debugging feature no?

Original comment by [email protected] on 29 Mar 2010 at 8:06

[GoogleCodeExporter]

any developments/progress?

Original comment by [email protected] on 27 May 2010 at 8:06