Alternative Solution

Aug 3, 2009 at 9:55 AM

As there has been little progress in this project for the past year, I have thought about an alternative:

Mediacenter Extenders communicate through a protocol that is a mix of RDP (for the menu overlays) and video data. I am running Windows 7, and the RDP protocol has been greatly enhanced there. It can stream any video I play from mediaplayer over RDP in excellent quality, since DirectX over RDP is now supported. So I was thinking, why not use the new RDP protocol for SoftSled.

When I launch Mediacenter over RDP it displays the following message:

Video Not Supported
Video cannot be viewed in media center from a remote desktop connection.

But when I launch mediaplayer over RDP, it works beauityfully now, so maybe the solution to SoftSled is this:

  -  Find out (using a debugger) how Mediacenter checks if it is running from a RDP connecction, and disable the check (or change the data used for the check).

It sounds like a lot less work, and would allow two Windows 7 pc's to stream mediacenter just like an extender does. Any thoughts?



Aug 3, 2009 at 11:36 AM
Edited Aug 5, 2009 at 5:44 PM


Unfortunately this idea has already been tabled during the long and unsuccessful length of this project's duration. This was discussed in a private thread. I looked into this new innovation and came to some conclusions: to remote DirectX you need to opt-in and specifically use DirectX 10 API (MC uses DX 9), additionally to remote video you need to opt-in and build a graph which uses the RDP DirectX Video Filter to remote video along the RDP channel. 

The following are a list of approaches I've looked into:

* Implement a proper third party extender which MC sees and uses natively. 
Too bloody hard to implement the crypto.

* Hack MC to use a different video renderer i.e. not the enhanced video renderer. 
I don't know where MC constructs its graph. It may be possible to hack MC to think it's rendering to DirectX (by modifying the program's checking logic) 
rather than GDI and subsequently hijack the Graph using graphedit and reconnect a network video renderer. 

The second option is probably the most likely achievable path, though it would involve hacking MC heavily and probably intercepting calls to ehui.dll (native library which MC uses to check renderer device capabilites - would need to tell MC to use DirectX even if in an RDP session). If MC tries to build an EVR (enhanced video renderer - DirectX) graph, which we would subsequently hijack and disconnect, are we sure this wouldn't error in a terminal session? i.e. you can construct an EVR session in a terminal session, albeit for probably only a couple of (milli)seconds?

Aug 3, 2009 at 11:41 AM
Edited Aug 3, 2009 at 11:45 AM

Just had a little thought:

On Windows 7 you are able to open with Media Player a recording program without any locking issue. Has anyone tried playing a recording file from within a terminal session, hence getting the DirectX Video remoting?



Would probably be better to play over a file share if possibe.

Aug 3, 2009 at 12:15 PM

I haven't tried Webguide yet, but they claim they stream mediacenters livetv over the internet. I think im gonna download it, and see which method they are using. I think they just stream whatever is in the playback buffer on harddisc for timeshifting?

Aug 3, 2009 at 12:27 PM

Yeah, basically. Webguides tells MC to start recording a program and webguide opens the recording file using the Stream Buffer Engine and transcodes the MPEG stream to WMV. (I think).

Aug 5, 2009 at 5:19 PM

OK.. Another idea: There are many extenders out there.. Aren't they just plain linux boxes just like wifi routers are? It would be incredible simple to dump the firmware. Or maybe there are dumped firmwares of xbox 360's on the internet (although that would be a lot harder to accomplish). Then you could extract the keyfile from the dump (the private key needed for encrypted communication, were current development halted). We could even pay microsoft to give us a key (pretending were a start up thats wants to produce an extender for example :p) All the info you need is in the filesystem of the extenders, and that filesystem is not encrypted. Maybe you could even FTP to the box to download the keyfile :D I will investigate in this..

Aug 5, 2009 at 5:34 PM

Actually you can download the firmware from linksys's website.  I could figure out how to access the file system as I am not familiar with firmwares and getting at them.  I think that would be a great place to start if you can get to them.  It would also help in seeing how they do it in order to figure out some of the stuff out.  Good luck and let me know if you need anything from me.

Aug 5, 2009 at 5:42 PM

Hi Drazix

That sounds good, as mentioned jlambert had some degree of success accessing the firmware image. That was discussed in a private thread; I tried adding you as a contributor there but codeplex gave me an unhandled error! (Microsoft's influence at work!)

Aug 5, 2009 at 6:32 PM

Looks like you should be in there as a contributor now.  Should be able to access the private threads.

Aug 5, 2009 at 8:43 PM

Thanks for adding me! I download an ISO which containts the linksys firmware. When I extract the iso it contains another container called: ROOTFS_R.FW

When I examine this file using a hex editor, i see the first four bytes are: LFUF (I think it stands for Logitech Firmware Update File). A couple of lines below I see a mention of 'zImage.bin'. I think the FLUF file is just a container (like uncrompessed zip) for the bin file. It should be very straightforward process to mount the filesystem that is in the bin-file, because every TFTP client can do it, but I did not succeed yet.

It would be very cool if we (once we extracted the linux filesystem) could boot the dma's OS in VMWare :p But if we not, i'm almost certain we can find the certificate file somewhere, or disassemble the binaries that are talking to mediacenter.



Aug 5, 2009 at 8:51 PM

This does look promising! I wonder what architecture the Linksys box is though, if they are not X86 (could more likely be ARM) we would not be able to boot it up in vmware. Nevertheless being able to have a look at the actual binaries would be brilliant, i'm sure there is an ARM virtual machine about which we could use to debug the binaries while they are loading!

Keep going!

Aug 5, 2009 at 9:15 PM

I think you're right, it may be PowerPC or ARM. I have a HTC phone, and I flashed Android to it. The image that contained Android was also called 'zImage.bin'. And my phone (touch diamond) also has an ARM processor. I asked the creator if the android image, if he could tell me how I can extract the contents, so I am waiting on his email. On my phone I have an application called 'Haret.exe' which shuts down WM, and launch the android image. This application must contain the code to read the contents of binary vram images.

Aug 5, 2009 at 10:25 PM

Already you are farther than I got in the week or so that i looked into this.  Nice work.

Aug 10, 2009 at 5:59 PM

Any updates on this? Has that developer responded to your question of how Haret extracts the file system image?

Aug 21, 2009 at 5:17 AM

Yeah, I would be interested in hearing any updates on this as well.  I think this has potential.

Aug 21, 2009 at 10:00 PM

Here is the board that companies used to test their stuff on...


Aug 26, 2009 at 3:19 PM

Figuring that the board is ARM9, what about using something like qemu to do the emulation.  Supposedly you can emulate ARM on a x86.  I tried something like...

qemu-system-arm.exe -M versatilepb -kernel linksys_dma2100.bin -append root="0800"

But this didn't work.  Here is a link to an article about doing arm9 stuff with qemu...

Aug 26, 2009 at 3:46 PM

Here is a link to hacking a device that has the sigma design 8622 chip on it...

Aug 29, 2009 at 6:44 AM

Ok, I decided to open up my 2200 to see what was inside.  There were a couple of things inside that might be useful.  One is a 10 pin connector labeled J17.  I took a multimeter to it and pin 1 had 5v on it and pin 6 had 3.3v on it.  pin 10 had a box around it.  There was also a 6 pin connector to it.  some of the pins had 3.3V on them.  and one of the pins had a box around it.  I was hoping that one of them would be a serial port that we could connect to but pretty sure not.  Anybody got any ideas on what these might be?

Aug 31, 2009 at 4:04 AM
Edited Sep 9, 2009 at 3:55 PM

Apparently I am just talking to myself at this point.  Since the code to run the linksys boxes is based on linux, I asked linksys if I could have their source code under the GPL license.  I got this response from them...

Hi Jason,
I have contacted our Engineering department and you do appear to be correct. There is a copy 
of this code available but unfortunately due to legal reasons we must run it through our Quality Control Testing 
before we can provide it since it had not been posted to the web yet. I appologize for any inconvenience this delay 
may cause. I will get back to you when I have an ETA on the availability. 

Thank you and have a great day.

Kind Regards,
GPL Manager

I am not sure that they will actually give it to me or not but hopefully they do.  I know it won't probably have any of the microsoft stuff but at least it would give us a starting spot.  I wasn't able to make anymore headway with the connectors on the 2200.  I think the 10 pin might be a JTAG connector.  Not sure on that though.  I will post if I hear anything more from Linksys. 

Anybody have anything else?

Aug 31, 2009 at 11:17 AM

This look interesting. As you say all the Pika extender stuff will be stripped out but the linker tools should perhaps allow us the ability to peek into existing firmware images.

Sep 8, 2009 at 11:54 PM

Very nice work jlambert!! I received a reply about the extraction of the dma2100 firmware image:

Hi, it seems it is "packed" with romfs. Just mount it the way it is
described over here :

"Once decoded, you should search for the string -rom1fs- using a hex
editor. It was at offset 0x0144AA4 in my case. Snip everything from
there, and mount it using mount -o loop -t romfs
13.img.xSYS.kernel.bunzipped.romfs /mnt/romfs."

Especially have a look at the -rom1fs- :D

Didn't try it, but it should work for sure. If not, then tell me and I'll find a way.

I will try this tomorrow, if it fails, I will contact him again..







Sep 9, 2009 at 3:54 PM

I guess I should have mentioned that I was able to open up that file using the method you discribed.  But all that is in there is a .bin file called image.bin or something like that which i believe is the firmware.  I think if we could figure out the kernel.bin file on the 2200 iso that might help us in figuring out how the firmware is loaded.  Anyways, let me know if you figure anything else out.

Sep 30, 2009 at 1:07 PM

Hey, i'm going to have a go at this tonight, I have just setup my development environment so be good to have a update to where your running in to problems.


Oct 2, 2009 at 2:31 AM

Sorry about not getting back to you on this before now.  Depends on which one you are looking at.  As far as the linksys firmware extraction goes I was able to get a .bin file out of the linksys firmware downloaded from their website.  But that is all the farther I got.  I know that the linksys is an ARM9 processor so you would need that architecture to do anything with it.  I was never able to figure out how to do anything with that though.  I thought if we could get the kernel.bin loaded from the 2200 ISO download that we might be able to figure out how the firmware is loaded and reverse it that way.  We are also looking at the XEX file that is on windows that gets loaded on to the 360 and trying to figure out how to decipher that.  Not much farther there although I did get it to decompile some but the functions it produces are giberish and in no way decipherable.  That is about all I know for now.  Not sure if anyone else has anything to add.

Oct 2, 2009 at 12:28 PM

Have you tried getting hold of a ARM9 emulator for windows and running it on there?

Oct 2, 2009 at 12:47 PM

Check out this PDF, just some info on reverse engineering, ARM and decompiling :)

Oct 2, 2009 at 1:04 PM

I have actually tried to get it running in an ARM9 emulator.  but you need to know specifics about the firmware in order to do it and you probably need to know more than I know about firmwares in general.  I come from a web development background so I don't have a lot of experience in low level development.  Have you had any success with getting it loaded in an emulator or decompiling it?

Oct 2, 2009 at 2:44 PM

Tonight i'm going to run the emulator to launch debian and decompile using dcc, this should give us the assembler and C code.

If I can get the C code with assembler using dcc can someone help us from there? probably be easier to reference this code throught visual studio in windows at this point. Can you drop me the bin file?


Oct 2, 2009 at 7:03 PM

Here is a link to the D-Link DSM-750 source code...

Oct 2, 2009 at 7:05 PM

Silly question, but obviously all the copyrighted proprietary PIKA code is absent?

Oct 2, 2009 at 7:09 PM

I assume so, but don't know.  Still downloading it.  I will let you know if I can figure it out at all.

Oct 2, 2009 at 7:11 PM

I'm downloading right now as well.... Any news back from the Linksys people? Still going through their "quality control" department I imagine?

Oct 2, 2009 at 7:25 PM

Nope, no PIKA stuff.  Not surprising there.  But it does have some stuff about the config of the DSM-750 as far as what options are set for running on the ARM processor.  Might be useful to get the real firmware up and running on a VM.

Oct 2, 2009 at 7:27 PM

Unfortunate, but expected. Is the Dlink firmware binary available?

Oct 4, 2009 at 2:33 AM

Yep.  You can download it at the link below.


Oct 12, 2009 at 4:54 PM

Here is the latest response from linksys on getting their sourcecode.  Don't think it matters at this point because it is not going to have any of the pika stuff in it.

The legal and engineering teams are still going in circles in regards to this particular software. I am 
still trying to get an offical date out of them but it has been a slow process as this product model has 
since been discontinued. I will again notify them that there are customers waiting for this software and 
it is very important we make this available as soon as possible. I can only appologize for any inconvience 
this has caused.

Oct 21, 2009 at 2:17 PM

Another response from the linksys open source team...

Hi Jason,
I'm very sorry about the delay on this, but I finally do have an official date for you. The expected post date for this product on the external website is 11/9. I have provided your name/contact information to our engineers but I am unsure if they will contact you directly or not. We will keep this case open until after the GPL files are offically posted on the site. Again thank you for your patience.

Kind Regards,
GPL Manager

Nov 7, 2009 at 4:35 AM

You could always just use the ARM emulator Microsoft wrote... ;-)

It's primarily used to load Windows CE based images, but I would see no reason why it couldn't attempt to load the kernel...provided there's a proper bootloader.  I'm going to warn you will probably fail with a kernel panic.  I'm sure that kernel is compiled with modules specific to the Linksys or D-Link device.

Also, do you have a place where I can acquire the image.bin file?  That is the file system the kernel mounts after initialization.

Nov 7, 2009 at 4:51 AM

BTW...I'm loading openSuSE on Virtualbox right now and have the DLink firmware downloaded so I can see if I can mount the filesystem.  I'll let you know what I find out.


Nov 12, 2009 at 12:10 AM

Any luck with this?

Jan 17, 2010 at 7:25 AM

I'm having a problem extracting the firmware, the script on that website is not working for me... I've also tried to do it manually and I've only gotten as far as stripping before BZh out, bunzip2 fails on the file... can someone just send me the extracted files so I can take a look at it? Or post it in the download links, or provide instructions for properly extracting...


Jan 17, 2010 at 11:05 AM

Are you a coder by any chance?

Jan 17, 2010 at 8:45 PM

Yes, I also wanted to send over to a friend of mine that I'm sure can figure out the key exchange... I just gotta get him to put in little bit of time... It would be best to be able to load this linux image file to reverse the existing code.

Jan 17, 2010 at 8:50 PM

I added you as a developer, have a look in the discussion board, there's been some other alternate progress.


Reverse engineering an actual image may be the cleaner way of doing it, but potentially more difficult. 

Feb 11, 2010 at 2:21 AM
Edited Feb 11, 2010 at 2:23 AM

My post was pointless, nevermind..  ;-)

May 7, 2010 at 5:11 AM

I have a few dma2200's that I am not using so i tore one down today to play with it. Given that we know they are running some linux flavor on this thing I'm suprised nobody has just tried putting a mini-pci serial card in place of the wi-fi mini-pci card.


There are lots of them out there (e.g. ) and then unless there were no build in drivers for it you have serial access to it, no?

If Im' off base let me know otherwise I'll be happy to order one up.

I think the best solution possible here would really be to get in on a console and from there you can do things like mount an ide hard drive instead of the dvd-rom they provide and burn an iso which you can then use to boot up in a vm or on another hardware that might support it.

May 7, 2010 at 9:02 PM
Edited May 8, 2010 at 3:00 AM


Sounds like a good idea, I don't think anyone has suggested using the wifi mini-pci slot with a serial card to gain access.

Currently, the project is halted on sorting out the video signalling between MC and the extender. A lot of the project members have disappeared and I don't have any ideas how to proceed. We've sorted the crypto pairing and the signalling to create a UI session.

Any advantage on working out how the extender system should be encouraged! 



$113 is quite an investment for a hobby project, you sure we'd get out-of-the-box compatability with BusyBox Linux?

How's your COM debugging skills? :P