Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix

Echostar DishPVR 721 GPL Software Released 109

Posted by Hemos from the make-it-open dept.
Faw writes "It was mentioned before that Echostar was releasing a Linux based PVR. It has been out for a month now, and the modifications to the kernel and other software are here. The cool thing is the site is running on the same receiver. Someone is already hacking it. Wonder how long until the receiver get slashdotted."
This discussion has been archived. No new comments can be posted.

Echostar DishPVR 721 GPL Software Released More

Echostar DishPVR 721 GPL Software Released

Comments Filter:
  • Wonder how long until the receiver get slashdotted.

    Honey, while you're getting me that beer, can you wiggle those rabbit ears a little? The cables gone out again.

    *scratch*scratch*
  • * Run a firewall on it, nobody on earth is gonna think my Hi-Fi firewall runs on that :) * Is it downstream only ? if not we can broadcast useful stuff... Any other ideas, am racking my brains... :)

  • New FCC Regulations (Score:2, Offtopic)

    by Hornsby ( 63501 )
    For those wondering, PVR stands for personal video recorder. It's like a VCR, but it's digital. Now on to my question.

    How will the new FCC copy-protection regulations being passed effect TiVo and other PVR devices? Are they going to be rendered completely useless, or is there going to be some loophole?
    • Grandfather clause

      OTOH, if they can't interface with the new formats, they will be as useless as your dad's collection of Slim Whitman 8-tracks.
    • The proposed BPDG [eff.org] regulations (which the FCC is considering adopting) say that you can build an HD PVR as long as it uses a CPRM hard disk and there's no way to get digital video out of the PVR in the clear.
    • There are already programs out there for copying video off a 501 and Dishplayer. That being said we at DBSTalk.COM have been staying away from that kind of talk because the MPAA and NAB folks have been keeping an eye on this, we dont want a lawsuit so we have been not allowing talk about this topic on our board. That being said the 721 is a different bird, from what I know the videos on the hard drive are encripted, to break the encription basicly means you hack the box completely. We are not a pirate site and do not support pirating of satellite signals so again these issues are not being discussed there. I think soon you will need permission from the NAB and MPAA to go to the bathroom. The entertainment industry has gone nuts. I am sure you heard that one of the Senior VP's of AOL has called PVR owners theives because many are using their PVR to skip commercials.

  • PVR?!? When do we get PAL/Ethernet converters? (Score:3, Interesting)

    by dybdahl ( 80720 ) <infoNO@SPAMdybdahl.dk> on Saturday August 24, 2002 @11:18AM (#4133105) Homepage Journal
    A lot of people focus on Personal Video Recording, but what we really lack is the possibility to transmit video via ethernet cable (TCP/IP), so that we can have 10-20 televisions without having tons of coax cable around.

    It's very simple: One box located at the satellite dish (or TV-cable where it enters the building) receives the TV-signal and provides it via ethernet in full quality, and another box at the TV receives that signal and provides the ability to remote control the receiver via a remote control and ethernet.

    But I guess this violates the DMCA?

    Dybdahl.

    • Easily done. (Score:3, Interesting)

      by FreeLinux ( 555387 )
      This is easily done, and no, it does not violate the DMCA.

      The TV signal is first encoded using an MPEG or similar format. This encoded signal is then streamed on the network via multicast. There are plenty of these systems out there, most are rather expensive but, they do exist and it can be done with Linux. The trick is to have a powerful enough box to do the realtime MPEG encoding.

      Commercial versions of this are used for desktop video conferencing, distance learning and even entertainment transmission. Nothing sells highend networking equipment better than a demo with a Top Gun DVD broadcasting to a dozen PCs and TVs around the room.

      • Re:Easily done. (Score:3, Insightful)

        by dzeuthen ( 246536 )
        This is unfortunatly not going to happen anytime soon.

        Since Echostar is a DVB [dvb.org]-compliant satellite network the different channels are encoded as MPEG2 a/v streams are put in number of multiplexes of about 30 Mbps (this gives 5-10 services per multiplex depending on quality).
        Using error-reducing codes, each multiplex is coded onto an analog transponder which is about 33Mhz wide. Remember that one transponder can carry one analog tv service.

        Thus, the set-top box would (in the worst case) require one tuner per endpoint in your ethernet network.

        There is a host of other problems I dont want to mention here including the scrambling systems, smart cards and digital rights management.

    • Umm. www.videolan.org?
    • I'm interested in doing something very similar for my new home, but I would like to have HD capability right off the bat. There are already many satellite stations broadcasting HD material, and I'd like to make use of that... especially since most of my monitors support HD resolutions. Aside from my Sony Wega in the living room, every other display is on a Mac or PC. I already have Cat5e to most rooms and have a nice managed 3com switch bringing it all together.
  • Ok, any idea what arch the processor is? Wasn't mentioned as far as I could see. Also, now all someone has to do is make a web interface so that we can pick what programs we want to record over the net, ala Tivo.

    SealBeater

  • File Format... (Score:4, Interesting)

    by SealBeater ( 143912 ) on Saturday August 24, 2002 @11:22AM (#4133125) Homepage
    Almost forgot, what's the file format for the archived video? Is it straight MPEG or something propriatary? Can I install NFS or somesuch on it? Sorry, it's just a day for questions apparently.

    SealBeater
    • If it's anything like the DishPVR501, it copies the satellite data stream as-is, for completely lossless recording. This means that you would have the same trouble decrypting it as you would stealing satellite service normally.

    • Re:File Format... (Score:3, Informative)

      by Kagato ( 116051 )
      The 721 uses stock PVR functionality built into a broadcom chipset (interestingly enough the chipset supports both HD and SD). The broadcom chipset provides hardware DES3 encryption for PVR archive functions. It's likely dish enabled the encryption because at a hardware level they don't lose much as far as clock cycles go.

  • GPL violation? (Score:4, Interesting)

    by ortholattice ( 175065 ) on Saturday August 24, 2002 @11:23AM (#4133127)
    From the "DishPVR 721 Source Code" page: "Do not replace or add any software to the DishPVR 721 with items compiled from these source trees. Doing so will void all warranties and cause the unit to fail."

    Well, if replacing a piece of software recompiled from the source tree causes the unit to fail, that means the binary must not correspond to the source. Thus the GPL'ed source must have had further, secret modifications that are not being released. Isn't that a violation of the GPL?

    • Not if the pieces aren't compiled into the kernel.
    • I used to work for those fuckers. Incompetant management et al but I guess they finally got the thing out, albiet a year or two late. I left them pretty early in the project, so I don't know a whole lot about the security bits of the system.

      I can think of several ways to pull this off; the sytem has a smart card and reader. I can see having the hardware check to make sure the software corresponds to a certain signature before allowing anything to happen. There may also be a few kernel modules and things where they could do secret stuff (IIRC the smart card software and the tuner software were both modules.)

      I am kind of curious to know if they went with GNU's gettext for translation in their UI. They were looking at it at one point. It'd be interesting if someone could find out. They may not have realized that gettext is GPLed (Not LGPLed.) It'd be fun to see how much of the UI code they kept from when I was working on it. It was a hideous mess back then; they essentially developed a C++ screen library on top of GDK and the programmer who was working on it when I got there was in the "Oooh! Lets inherit everything!" phase of learning C++. Everything was done with pixmaps and hotspots and given a choice I'd sooner program in MFC (and I don't do windows!)

      • They may not have realized that gettext is GPLed (Not LGPLed.)

        I believe the latest release is LGPLed. In any case, there are LGPLed copies of gettext about - libc has a copy (so nothing for Linux that uses gettext need be GPLed) and KDE has a copy that was taked from libc.

        (For those reading at zero, the AC is me; I just forgot to log in first.)

    • Re:GPL violation? (Score:4, Informative)

      by Jade E. 2 ( 313290 ) <slashdot@perlstor[ ]et ['m.n' in gap]> on Saturday August 24, 2002 @02:49PM (#4133790) Homepage
      You're missing the point. The restrictions you're talking about only apply when you're using someone else's GPLed code. In this case, since it's their own code, they can do it however they like, including releasing 2 versions, a non-GPLed binary version including the proprietary bits (inside the boxes) and a GPLed source of the non-proprietary bits. If they had taken someone elses GPLed code and used it, then they would have to release the whole thing or nor use that code, but since they own the code they can do with it what they like.

  • GPL? Um, nope... (Score:5, Informative)

    by haukex ( 229058 ) on Saturday August 24, 2002 @11:30AM (#4133150)
    Please note that the DishPVR 721 software also includes some proprietary elements that are not subject to the GPL. You cannot perform a working DishPVR 721 software build without the additional proprietary code.

    This discussion was held before [slashdot.org] but here goes:

    Combining two pieces of software more than just calling each other through the shell constitutes them being one program, especially in this case where the software won't even *compile* without the missing (proprietary) code. This is not allowed under the GPL - either the entire software is released under the GPL or you can't release it under the GPL at all. (see here [gnu.org])

    Admittedly, it's nice of them to release the code and make it avaliable to the public, I'm sure it'll be interesting for everyone - but once again, the GPL is beaten.

    • Re:GPL? Um, nope... (Score:3, Insightful)

      by darkwiz ( 114416 )
      Notably missing from the posted code is anything capable of recording. It may be that the recorder is a key element missing.

      You may be able to compile it, but you won't end up with a PVR.

      It looks to me, superficially, as if they are doing *exactly* what is required and nothing more. You can't fault them for that, their value add is the recording facility. If they give that away, there is little for them to build a business model on other than a Tivo'esque subscription.

      Of course, as these make it into geek hands, and they are opened up and inspected, we will get a better idea as to whether they are being as compliant as they appear.
      • You can't fault them for that, their value add is the recording facility

        They wouldn't lose too much by releasing the recording facility, it seems the way it works is just capturing the encrypted data stream verbatim from the satellite signal.

        I could understand them not wanting to open up the part that actually reads the smart card and decrypts the stream though, that could give the people that think satellite service should be free (cost) a big leg up.

    • Re:GPL? Um, nope... (Score:2, Interesting)

      by sfennell90 ( 562864 )
      I would suspect that EchoStar is probably licensing an MPEG decoder. Not to mention the code to run TIVO. So there's no way they could release this as completely GPL since they don't own it all to begin with.
      • You are right of course cannot break the licence on any code they use.

        However, the GNU GPL'd code requires that other code mixed with it is released as GPL.

        If the other code has a licence preventing this then that means the two licences are incompatible and they cannot distribute the binaries at all.

        Breaking one license (the GNU GPL) in order not to break another is not legal. They must conform to both licences or not distribute the code at all.

        • However, the GNU GPL'd code requires that other code mixed with it is released as GPL.

          So release it as LGPL. If, as your parent post believes, Echostar owns the GPLed code, they can do as they like. They can even release an arbitrary part of the code as GPL, while retaining the remainder internally. Of course, the GPLed stuff won't compile, but they can do that.

          It occurs to me that if the internal situation at Echostar is as bad as others have implied, they might be releasing the code because doing so gives them better version control than what they already have.

        • However, the GNU GPL'd code requires that other code mixed with it is released as GPL.

          So what? A contract restriction is civil law, not criminal law. The courts are not going to do anything unless someone brings an enforcement action.

          It is far from clear who if anyone has standing to bring an enforcement action besides the original contributors to the code. And if people did start to bring that type of action on a regular basis the commercial users of Linux would quickly move to BSD. It does not matter whether you are right or wrong, if someone brings a lawsuit against you it will cost a lot of money.

          It is somewhat noticeable that the GPL enforcement freaks are most often the first to explain why Napster was not abetting theft and music copyrights should not apply on the net. Henceforth the only copyright license that will count is the GPL...

          Like the recording industry the legal technicalities may be on the side of folk who want to read the source. However just like in the case of the recording industry the best way to achieve the desired outcome is probably not to start threatening people that to paraphrase Pulp Fiction, you intend to get medi-legal on their ass.

    • Re:GPL? Um, nope... (Score:3, Informative)

      by mikec ( 7785 )
      You're oversimplifying. Actually, it is extremely unclear what constitutes being "one program". The GPL FAQ says it's ultimately up to a judge, and goes on to speculate in an extremely vague fashion about what may and may not constitute combining two parts into one program. There has only been one court case (Nintendo vs. Goloob Games) and the ruling was not definitive.

      Even the question of whether dynamic linking is covered is somewhat questionable. To quote RMS,

      "I think we have a pretty good argument that nontrivial dynamic linking creates a combined (i.e. derivative) work. I have an idea for how to change the GPL to make it clearer and more certain, but I need to see if we can work out the details in a way that our lawyer believes will really work."

      Even assuming that the FSF prevails in this argument, it is far from clear that programs connected by pipes, shared memory, CORBA, or SOAP would be considered "one program." In fact, the GPL is so weak in this area that it's one of the main reasons for GPL version 3.
  • Wonder how long until the receiver get slashdotted

    Somehow I thought /. is having a story regarding that famous .cx site.. *phew* ..

    It's still early.. -_-

  • Starband (Score:5, Interesting)

    by GigsVT ( 208848 ) on Saturday August 24, 2002 @11:42AM (#4133190) Journal
    Echostar/Starband still will not release client specs to allow Linux computers to directly connect to starband satellite modems with normal speeds.

    You can connect the Linux box to the satellite modem, but it operates at around 64kbits up/down, with the windows client installed, it gets more like 768 down 64 up. Many people have requested the specs to write a driver for Linux, but they were told that the specs would not be given out to support the development of any sort of open source driver.

    Don't get the idea that Echostar is Linux friendly. Starband proves that.
    • Starband and Echostar are not only not related, they are now pretty much competitors. Echostar was one of the original funders of Starband. After the annoucement of the pending merger between Echostar and Hughes (DirecTV, DirecPC), Echostar severed their Starband ties. This left Starband without a way to bill, and forced them into Chapter 11. Legal stuff ensued.

      I don't believe that Starband and Echostar R&D were related. Starband's technology comes from Gilat.
      • Oh yeah, I forgot to mention the other funder besides Echostar and Gilat was, drumroll please...

        Yeah, Microsoft. That might relate to some of the linux stuf :-) I think there are performance hoggability reasons why they might not want an open source driver too.
      • Echostar still sends me the bills for Starband, I don't think you can say they are competitors.
    • At one point, I was approached to write something similar for a FreeBSD based devices, but at the time I had too much on my plate to accept the contract.

      The protocol stack modifications allow for more data in the pipeline without an acknowledgement on a long delay link (e.g. a satellite link).

      The basic problem with satellite links is that the latency increases the amount of data that must remain in the sender's buffer without acknowledgement, so the unacknowledged data times the number of active clients becomes the limiting factor. There are several approaches to dealing with this, but all of them require adulterating the protocol stack to the point that what you are running is not really TCP over IP, it's something else.

      The problem is that you simply *can't* crank the TCP window size large enough to cover the latency, without reducing the number of clients that the server can support. Maybe this will change when 64 bit systems with 128G of RAM become available, but I rather expect that the extra memory will be used for supporting a larger number of simultaneous subscribers, rather than better supporting existing subscribers without using their proprietary protocol.

      The reason the data rate goes down is that there is not an implementation of this stack for Linux (there is one for FreeBSD, but it's not published, to my knowledge), and there's also an implementation for Windows (not published).

      Just because the call something a "driver" in the Windows world doesn'yt actually mean that it's really a "driver", and not something else.

      In any case, it works at all because, in the face of the lack of a driver, the connection falls back to simple TCP/IP. *That* works, because the assumption is that the data will be mostly unidirectional, out to the remote site.

      There's actually a lot of information available on the concept (but nearly none on the implementation, and I couldn't disclose anything anyway) if you dig around the various web sites.

      -- Terry
      • Well I figured as much, but it still comes down to Starband irrationally protecting specs that could be released. I don't see that they would lose as much as they would gain from linux support.
        • It's not "irrational"...

          What do they have to lose by publishing the protocol specifications?

          A heck of a lot, actually. They open the market to competitors who would otherwise have an R&D barrier to entry.

          By doing that, they compress the amount of time they have available to amortize their R&D costs, before someone else enters the market and puts a downward price pressure on the service, as it becomes commoditized.

          As a result, the price to consumers between the time of disclosure and the time that the price pressure actually starts, must be higher, which reduced the market further, so the price must be even higher... until it finds an equalibria point for the reduced amortization period.

          This is true, even if there ends up being a small additional Linux developer market on top of the consumer market (if you can see more than that in what "they would gain from linux support", then you need to make a business case to that effect).

          The net result is a higher cost to consumers, and a lower overall availability of the service.

          It's not always a black-and-white, positive thing to have all information disclosed, no matter what.

          -- Terry
          • How do you get from "downward price pressure" to "higher cost to consumers"?
            • "How do you get from "downward price pressure" to "higher cost to consumers"?"

              People with an incomplete understanding of market economies always ignore fixed initial costs, for some reason, when trying to promote the idea of "free" software.

              Please read this part again:

              | By doing that, they compress the amount of
              | time they have available to amortize their
              | R&D costs, before someone else enters the
              | market and puts a downward price pressure
              | on the service, as it becomes commoditized. ...I get there by noting that R&D costs to be recovered remain a fixed constant, and the time available for recovery of those costs is reduced.

              Then I divide the R&D costs by the time available, and spread that cost across the total number of users.

              For people who can't do "story problems", here is the math:

              R := Recovery time, in years
              N := Number of users
              C := R&D costs
              ? := Cost per consumer per year

              C / N / R = ?

              Say our R&D costs were $10,000. Say the number of users was 1000. And say we had 5 years to recover our costs, because that's how long it would take someone to duplicate our work, without access to our source code. So:

              $10,000 / 1000 / 5 = $2/year cost per user for R&D

              Now, let's give away our source code. Now it takes our competitor a year to productize it and get their business processes in place so they can compete equally:

              $10,000 / 1000 / 1 = $10/year cost per user for R&D

              Now, say only 3/4 the users are willing to pay the inflated costs, and the rest say "screw you, you greedy capitalist bastards, we will do without":

              $10,000 / 750 / 1 = $13.33/year cost per user for R&D

              Do you "get it" now??? *Eventually*, the cost will go down... but *ONLY* after the R&D costs have been amortized out by *someone* - a customer - paying for them. The money "Joe The Programmer" was paid to write the code in the first place had to come from *somewhere*.

              -- Terry
              • You are arguing this as if it is a commodity software product. You seem to forget that this is more like a device driver than commodity software. Without the Gilat modem and whatever runs on the server side, this is useless. They stand to lose nothing by providing a driver for hardware and a service that they control.
                • I will point out the obvious, yet again...

                  This is *NOT* a driver for a particular piece of hardware, it is a *protocol stack*, which could care less who you buy your hardware or satellite service from.

                  "Without the Gilat modem and whatever runs on the server side, this is useless. They stand to lose nothing by providing a driver for hardware and a service that they control."

                  This is wrong. Control is *precisely* what they give up, as soon as they document/publish their protocol, unless they have a patent on it (they don't, according to my search of the patent database).

                  As you pointed out: it works at the high data rate with Windows (where they have implemented their stack) but not with Linux (where they have not). Thus the issue is software,l not hardware dependent.

                  This is *exactly* what Real, Inc. does, by documenting their protcols well enough to permit implementation of a proxy server over a NAT or firewall, but *NOT* well enough for you to implement a Real Audio server (no QOS encapsulated protocol documentation, for the protocol between the client and the server, which is tunneled through the proxy connection without being interpreted by it). By *NOT* documenting their protocol, they keep control of the server side of the market.

                  Let me put it this way: if *I* had source code to a Real Audio player that implemented the client side of the QOS protocol, I *could easily* implement the server side. As it is, you have to spend a lot of money reverse engineering the QOS protocol (Network Appliance did exactly this, in order to implement their streaming media caching server -- cached content needs the same QOS moderation in the stream the server sends to the client).

                  -- Terry

  • Easy, there. (Score:2, Interesting)

    by Anonymous Coward
    It could be something fairly innocuous.

    From the hack-site linked in the original story,

    "And any attempt to edit post-startup scripts or executable binaries (e.g. the lbreakout game) resulted in that executable failing to run.

    I don't yet know how it works, but it appears that the 721 features a built- in mechanism to prevent changes to core files, guaranteeing their integrity. I suspect a SHA1-based message digest is stored (somewhere) for each protected file, and checked at run-time. It's possible the XFS filesystem's extended attributes contain the file checksum data."

    This could be the mechanism for discouraging changes, I dunno. I also have not thought about any GPL implications, but it doesn't sound like a violation to me.

    But hey, it runs XFS! Ain't that cool! :)
  • Interesting note: the results from Netcraft about the specific DB721 box that is running on 204.45.37.181 is that it is running micro_httpd. Though it doesn't have a specific Linux distribution... hmm... maybe I should nmap it and try to get a finger print off of it. :-)

  • As some others have pointed out, Echostar is doing precisely what the GPL requires of them and nothing more. (they released the kernel code and some common shell utils, the PVR-specific stuff is still secret)

    This is like making a Slashdot headline for a company that buys a license for each copy of Windows and Office it is using. Why are we so excited they just obeyed the license?
  • Who would have thought the day would come when I could run a web server on my VCR^H^H^HPVR?

  • Here's the HOWTO (Score:2, Informative)

    by Anonymous Coward
    HOWTO_Dish721WebSvr

    HOWTO: Install a Web Server on Your Dish Network PVR-721
    August 2002

    INTRODUCTION

    Ever wanted to run a Web server on your Dish Network PVR-721? This document describes one method of doing so. If you have physical access to a PVR-721, a Linux-based PC, and a USB-to-Ethernet adapter, you can make your PVR-721 serve up HTML while you watch your favorite shows. The technique described in this document is pretty safe. It doesn't require permanent physical changes to the PVR-721, nor does it require you to break any "warranty stickers" on your PVR-721.

    REQUIREMENTS

    You'll need a few things before you get started.

    1. Dish Network PVR-721 with system software revision 102 or earlier
    2. Spare Linux desktop PC with:
    a. Kernel 2.4.x
    b. XFS support - Highly recommend SGI XFS Installer paired with RedHat 7.3
    c. Available IDE connection (master or slave, primary or secondary)
    3. Rough working knowledge of Linux administration from the command line
    4. USB-to-Ethernet adapter
    5. Secure Local Area Network (firewalled at minimum)
    6. Separate PC with telnet client and Web browser

    If you don't meet all the requirements, you'll need to get creative. Creativity is beyond the scope of this document.

    SWAP THE DRIVE OVER

    First you'll need to attach the PVR-721's hard drive to a Linux PC so you can copy files to it. Since you won't want to break the "warranty sticker" preventing you from removing the PVR-721's hard drive, you'll want to put the PVR-721 very close to the Linux PC. Here are step-by-step instructions:

    1. Power down the Linux PC, remove its cover, and locate the IDE cable and an extra hard drive power cable
    2. Power down the PVR-721 (pull power plug), remove its cover, place it near the Linux PC, and locate the hard drive
    3. Warning: be very careful not to touch the power supply which is located opposite the hard drive; it is not enclosed, and might shock you
    4. Remove the IDE cable and power cable from the PVR-721's hard drive
    5. Attach the Linux PC's IDE cable and power cable to the PVR-721's hard drive

    Now you can access the PVR-721's hard drive from the Linux PC. It sounds kinda scary, but it's not that bad.
    Troubleshooting: If your system can't find the 721's drive, try isolating it as the master drive on the secondary IDE channel. That would make it /dev/hdc in Linux.

    MOUNT THE XFS FILESYSTEMS

    Create the mount points first.
    mkdir /mnt/video; mkdir /mnt/root; mkdir /mnt/next_root; mkdir /mnt/download

    I added these lines to /etc/fstab, but you can mount them manually if you want.
    /dev/hdc1 /mnt/download xfs defaults,noatime,nodiratime 0 0
    /dev/hdc5 /mnt/root xfs defaults,noatime,nodiratime 1 1
    /dev/hdc6 /mnt/next_root xfs defaults,noatime,nodiratime 0 0
    /dev/hdc8 /mnt/video xfs defaults,noatime,nodiratime 0 0
    Once added to fstab, use "mount -a" to auto mount everything.

    Bear in mind that hdc5 and hdc6 are interchangeable. The PVR-721 is using one as the root device now, and the other one will be used for the next software update. So you may have to look at the /Download.Version text file to see which partition is running the latest version. Mount that one in the /mnt/root directory.

    INSTALL THE WEB SERVER

    Next you'll edit some configuration files on the PVR-721, enabling you to start the Web server.

    Edit the /mnt/root/etc/crontab file, and add these lines. They refer to some scripts that you'll have to put in place in a later step.
    0-59/10 * * * * root /bin/echo 1 > /dev/connectled
    5-55/10 * * * * root /bin/echo 0 > /dev/connectled
    1,31 * * * * root /sbin/syslogd >> /mnt/video/syslogd-out 2>&1
    2,32 * * * * root /sbin/klogd >> /mnt/video/syslogd-out 2>&1
    0-50/10 * * * * root /sbin/ifconfig eth0 192.168.1.99 netmask 255.255.255.0 broadcast 192.168.1.255 >> /mnt/video/ifconfig-out 2>&1
    1-51/10 * * * * root (cd /; /usr/bin/python /mnt/video/python-bash.py >> /mnt/video/python-bash.log 2>&1 )
    2-52/10 * * * * root (cd /; /usr/bin/python /mnt/video/telnetd-wrapper.py >> /mnt/video/telnetd-wrapper.log 2>&1 )
    3-53/10 * * * * root (cd /; /usr/bin/python /mnt/video/pythonshell.py >> /mnt/video/pythonshell.log 2>&1 )
    4-54/10 * * * * root (cd /; /usr/bin/python /usr/lib/python1.5/CGIHTTPServer.py >> /mnt/video/http.log 2>&1 )
    Notes on crontab:

    1. Replace the ifconfig line with the static IP address that you'd like the PVR-721 to use.
    2. We send all output to debug log files on the data partition. Either send it to log files or send to /dev/null, so it doesn't fill up root's mail file.
    3. We start syslogd and klogd for fun. These are optional. The PVR-721's startup scripts start them and then kill those processes because they apparently caused some issues. We like to see the debug info.
    4. The echo lines will blink the Message LED every 5 minutes, to indicate CRON is still working.
    5. The PVR-721's system clock is in GMT, so scheduling events to run at certain hours of the day takes some math. /mnt/root/var/cron/log helps debug time problems.

    Now place the files python-bash.py, telnetd-wrapper.py, and pythonshell.py in the /mnt/video directory. These files have been included at the end of this document. [NOTE: These files have been omitted from this post due to potential copyright problems. You can download the original script source from http://itamarst.org/software/. Look for backdoor.py. Sorry for the inconvenience.]

    pythonshell.py: This listens on port 8023. If you telnet to it, it will open up a Python interpreter shell. Quite handy.
    telnetd-wrapper.py: This listens on port 23. This is the middle-man between your telnet client and a bash shell. It's really ugly. Basically it reconnects you to 8024, which has python-bash.py running on it. But the middle man strips out carriage returns. It's ugly, but it's the best we've got so far. We're looking for help here getting Twisted's Python Telnet Daemon or SSH daemon working. Their Telnetd opens a python shell, but it could be hacked to give us bash instead.
    python-bash.py: This listens on port 8024, it only helps telnetd-wrapper.py. Also note that these two processes quit after you exit from the telnet session. But cron starts them again within 10 minutes.

    Place the index.html from below into the /mnt/root directory.

    Edit the /mnt/root /usr/DP721/system/Hannibal.ini file. Find the stanza about BreakOut Game, and make it look like this:
    #### BreakOut Game
    [BreakOut]
    uid = 0
    gid = 0
    exe = /usr/sbin/cron
    foreign = 1
    start_delay = -1
    restart = 0
    Why launch cron from the LBreakout game? Annoyingly, the DishLinux crond startup script sleeps for 4 hours before cron is started up.

    At this point you may wish to nose around. Feel free. You may look, but don't touch. Any changes you make to startup scripts or binary executables will be detected by the PVR-721 the next time it boots. It will display a "bad hard drive" error message, and reinstall itself, wiping the slate clean (so to speak). Not only will you lose your changes, you'll lose any previously recorded programs. On the bright side, you don't have to worry about permanently damaging the PVR-721 - if you mess it up, it automagically heals itself. A nifty feature, huh?

    SWAP THE DRIVE BACK

    When you're through nosing around, unmount the PVR-721's boot partition and shutdown the Linux PC. Power it down, and swap the hard drive back. Step-by-step:

    1. Shut down the Linux PC with "/sbin/shutdown -hf now"
    2. Make sure the Linux PC is powered off
    3. Unplug the Linux PC's IDE cable and hard drive cable from the PVR-721
    4. Plug the PVR-721's IDE cable and hard drive cable into the PVR-721's hard drive
    5. Plug in the USB-to-Ethernet adaptor and network cable.
    6. Boot the PVR-721

    Your PVR-721 should boot normally; you won't be able to see anything different, except that the link light on your USB-to-Ethernet adapter will illuminate.

    START THE WEB SERVER

    Now you'll want to start the Web server by playing the LBreakout game on the PVR-721. No, that's no joke. We've secretly replaced the LBreakout game with the cron daemon, which launches the Web server. Sneaky, huh? You'll know it's worked when the "Online" LED on the PVR-721's front panel illuminates. Here are step-by-step instructions:

    1. Access the main menu of the PVR-721's user interface
    2. Navigate to the "Games" menu
    3. Press "Select" to start the LBreakout game
    4. Notice that the game doesn't actually start; instead, the cron daemon starts up.
    5. Within 10 minutes, the "Online" LED will illuminate on the front panel.
    6. Now turn to a computer with a Web browser (any computer on the LAN will do)
    7. Point the Web browser at the PVR-721's new home page:
    a. http://ipaddress:8000/index.html
    8. Verify that you can access the PVR-721's filesystem via the Web server
    a. Click the "Echostar" link under the "Proc Filesystem" heading

    Congratulations, you did it. You're running a Web server on your Dish Network PVR-721. What's next? It's up to you.

    If you're feeling adventurous, try connecting to the telnet server on port 23. It's not a real telnet server, so it won't work exactly like you'd expect, but it provides some functionality.

    A WORD OF CAUTION

    The PVR-721's filesystem is protected by two security mechanisms, the boot-time "auto-reinstall" mechanism mentioned above, and a "secure loader."

    At boot time, the auto-install mechanism checks the disk for validity. It examines each executable (binary or shell script) required for startup. If it finds any changes to those files, it assumes the disk is invalid and reinstalls the operating system from a standby boot partition.

    At run time, the secure loader examines executables as they are loaded. If it detects any changes to the executable, it refuses to load it. It's safe to change configuration files (e.g. crontab), and to run the executables that shipped with DishLinux, but "foreign" executables aren't permitted to run. Fortunately DishLinux ships with Python 1.5 support. Python scripts aren't subject to the secure loader.

    For details of our research into PVR-721 security and speculation on the implementation details of these security mechanisms, check out our paper on the subject.
  • The front page story links through this address:

    http://www.dbstalk.com/showthread.php?s=8a085317 ee eeb9082bd8763f6759d0d3&threadid=6558

    The link at the top of the "Read More..." page links direct at:

    http://www.dbstalk.com/showthread.php?s=8a085317 ee eeb9082bd8763f6759d0d3&threadid=6558

    Is this part of Slashcode or a goof or what? Just found it curious considering the generally negative /. stories concerning DoubleClick.


  • When are we Europeans going to get a service like this ?? If it runs linux and is hackable I'l sign up on the spot !

  • Greetings, thanks for the article guys! It was great having everyone from Slashdot visit us at DBSTalk.COM today! I am hoping the Internet Access on the 721 can be Slashdotted! Before the 721 it was announced that when Internet access is available on the 721 that you will be able to use ANY broadband service you want. However on the last tech chat it was announced that they changed their minds and that Internet access will be available only to those who subscribe to one of their partners DSL service. I feel like I have been lied to and I am mad as hell about this, this is the reason I purchased a 721, if I just wanted a Dual Channel PVR I would have cenceled Dish Network and picked up a DirecTivo for $19 at Circuit City. I invite all the code hacker to work on this and post their finding at DBSTalk.COM we have a large group of 721 users owners and hackers there. Thanks!

Slashdot Top Deals

We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan

Close