Announcement

Collapse
No announcement yet.

Daemon Tools rootkit?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally Posted by dino00
    You ask what would happen if a user decided to disable such a feature (and a wise decision that is)? As a matter of fact the rootkit would eventually be installed just the same. You see, in order for the cd to be played on a PC, you have to install the software that comes along with the given cd (that means you also install the rootkit).
    Sorry to drift the thread even further, but I'd like to correct this: if autorun is disabled, the rootkit would not install and the user has no DRM at that point - he can rip the tracks with no trouble (unless the DRM software's installer gets run some other way).

    Alex and I are working on an academic paper, “Lessons from the Sony CD DRM Episode”, which will analyze several not-yet-discussed aspects of the XCP and MediaMax CD copy protection technologies, and will try to put the Sony CD episode in context and draw lessons for the future. We’ll post the complete paper here later in the week. Until then, we’ll post drafts of a few sections here. We have two reasons for this: we hope the postings will be interesting in themselves, and we hope your comments will help us improve the paper. Today’s section is part of the technical core of the paper. Please note that this is a draft and should not be formally quoted or cited. The final version of our entire paper will be posted here when it is ready Attacks on Installation Active protection measures cannot begin to operate until the DRM software is installed on the user's system. In this section we consider attacks that either prevent installation of the DRM software, or try to capture music files from the disc in the interval after the disc has been inserted but before the DRM software is installed on the computer. Autorun Both XCP and MediaMax relies on the autorun feature of Windows. Whenever removable media, such as a floppy disc or CD, is inserted into a Windows PC (and autorun is enabled), Windows looks on the disc for a file called autorun.ini; if a file with that name is found, Windows executes commands found in it. Autorun allows a disc to pop up a splash screen or simple menu, for example to offer to install software found on the disc. However, the autorun mechanism will run any program that the disc specifies. Other popular operating systems, including MacOS and Linux, do not have an autorun feature, so this mechanism does not work on these other systems. XCP ships only Windows code and so has no effect on other operating systems. MediaMax ships with both Windows and MacOS code on the CD, but only the Windows code can autorun. The MacOS code relies on the user to double-click an installer on the CD, which few users will do. Current versions of Windows ship with autorun enabled by default, but the user can choose to disable it. Many security experts advise users to disable autorun, to protect against disc-borne malware. If autorun is disabled, the XCP or MediaMax active protection software will not load or run. Even if autorun is enabled, the user can block autorun for a particular disc by holding down the Shift key while inserting the disc. This will prevent the active protection software from running. Even without disabling autorun, a user can prevent the active protection software from loading by covering up the portion of the disc on which it is stored. Both XCP and MediaMax discs contain two sessions, with the first session containing the music files and the second session containing DRM content, including the active protection software and the autorun command file. The first session begins at the center of the disc and extends outward; the second session is near the outer edge of the disc. By covering the outer edge of the disc, the user can cover up the second session's files, effectively converting the disc back to an ordinary single-session disc. The edge of the disc can be covered with nontransparent material such as masking tape, or by writing over it with a felt-tip marker. Exactly how much of the disc to cover can be determined by iteratively covering more and more until the disc's behavior changes, or by visually inspecting the disc to look for a difference in appearance of the disc's surface which is often visible at the boundary between the two sessions. Temporary Protection Even if the copy protection software is allowed to autorun, there is a period of time, between when a protected disc is inserted and when the active protection software is installed, when the music is vulnerable to copying. It would be possible to have the discs immediately and automatically install the active protection software, minimizing this window of vulnerability, but legal and ethical requirements should preclude this option. Installing software without first obtaining the user's consent appears to be illegal in the U.S. under the Computer Fraud and Abuse Act (CFAA) as well as various state anti-spyware laws . Software vendors conventionally obtain the user's consent to installation of their software by displaying an End User License Agreement (EULA) and asking the user to agree to it. Only after the user agrees to the EULA is the software installed. The EULA informs the user, in theory at least, of the general scope and purpose of the software being installed, and the user has the option to withhold consent by declining the EULA, in which case no software is installed. As we will see below, the DRM vendors do not always follow this procedure. If the discs didn't use any other protection measures, the music would be vulnerable to copying while the installer waited for the user to accept or reject the EULA. Users could just ignore the installer's EULA window and switch tasks to a CD ripping or copying application. Both XCP and MediaMax employ temporary protection mechanisms to protect the music during this time. XCP Temporary Protection The first time an XCP-protected disc is inserted into a Windows machine, the Windows autorun feature launches the XCP installer, the file go.exe located in the contents folder on the CD. The installer displays a license agreement and prompts the user to accept or decline it. If the user accepts the agreement, the installer installs the XCP active protection software onto the machine; if the user declines, the installer ejects the CD and exits. While the EULA is being displayed, the XCP installer continuously monitors the list of processes running on the system. It compares the image name of each process to a blacklist of nearly 200 ripping and copying applications hard coded into the go.exe program. If one or more blacklisted applications are running, the installer replaces the EULA display with a warning (shown at right ) indicating that the applications need to be closed in order for the installation to continue. It also initiates a 30-second countdown timer; if the any of the applications are still running when the countdown reaches zero, the installer ejects the CD and quits. ] This technique might prevent some unsophisticated users from copying the disc while the installer is running, but it can be bypassed with a number of widely known techniques. For instance, users might kill the installer process (using the Windows Task Manager) before it could eject the CD, or they might use a ripping or copying application that locks the CD tray, preventing the installer from ejecting the disc. The greatest limitation of the XCP temporary protection system is the blacklist. Users might find ripping or copying applications that are not on the list, or they might use a blacklisted application but rename its executable file to prevent the installer from recognizing it. Since there is no mechanism for updating the blacklist on existing CDs, they will gradually become easier to rip and copy as new applications not on the blacklist come into widespread use. Application developers may also adapt their software to the blacklisting technique by randomizing their process image names or taking other measures to avoid detection. MediaMax Temporary Protection The MediaMax system employs a different—and highly controversial, if not illegal—temporary protection measure. It defends the music while the installer is running by installing, and at least temporarily activating, the active protection software before displaying the EULA. The software is installed without obtaining consent, and it remains installed (and in some cases, permanently active) even if the user explicitly denies consent by declining the license agreement. This practice is uncomfortably close to the behavior of spyware and may be illegal. Prior to license acceptance, both MediaMax version 3 and version 5 discs install the active protection driver. (At this writing, version 5 is the current version. To our knowledge, there was no version 4.) The driver file sbcphid.sys is copied to the Windows drivers directory, configured as a service in the registry, and launched. Initially, the driver's startup type is set to "Manual,'' so it will not re-launch the next time the computer boots; however, it remains running until the computer is shut down and remains installed permanently. Albums that use MediaMax version 5 additionally install components of the MediaMax player software before displaying a license agreement—almost 12 megabytes of programs and data that are stored in %programfiles%Common FilesSunnComm Shared. These files are not removed if the EULA is declined. Even more troublingly, under some common circumstances the MediaMax installer will permanently activate the active protection software (by setting its startup type to "Auto,'' which causes it to be launched every time the computer boots). This behavior is related to a mechanism in the installer apparently intended to upgrade the active protection software if an older version is already installed. Under the following scenarios, it is triggered even if the user previously declined the EULA: The user inserted a CD-3 (older version of MediaMax) album, then sometime later inserts an MM-5 (current version of MediaMax at this writing) album. The user inserted an MM-5 album, then sometime later inserts a CD-3 album. The user inserted an MM-5 album, reboots, then sometime later inserts the same album or another MM-5 album. These steps do not have to take place in a single session. They can happen over a period of weeks or months, as users purchase new albums. We can think of two possible explanations for this behavior. Perhaps the vendor, SunnComm, did not test these scenarios to determine what their software did, and so did not realize that they were activating the software without consent. Or perhaps they did know what would happen in these cases and deliberately chose these behaviors. Either possibility is troubling, indicating either a badly deficient design and testing procedure or a deliberate decision to install software after the user denied permission to do so. Even if poor testing is the explanation for activating the software without consent, it is clear that SunnComm deliberately chose to install the MediaMax software code on the user's system even if the user did not consent. These decisions are difficult to reconcile with the ethical and legal requirements on software companies. But they are easy to reconcile with the vendor's platform building strategy, which rewards the vendor for placing its software on as many computers as possible. Even the activation of temporary protection software before the user consents to anything raises troubling ethical questions. It is hard to argue that the user has consented to loading and running software merely by the act of inserting the disc. Most users do not expect the insertion of a compact disc to load software, and although many (but not all) of the affected discs did contain a statement about protection software being on the discs, the statements generally were confusingly worded, were written in tiny print, and did not say explicitly that software would install or run immediately upon insertion of the disc. Some in the record industry argue that the industry's need to block potential infringement justifies the short-term execution of the temporary protection software on every user's computer. We think this issue deserves more ethical and legal debate. Passive Protection Another way to prevent copying before active protection software is installed is to use passive protection measures. Passive protection exploits subtle differences between the way computers read CDs and the way ordinary CD players do. By changing the layout of data on the CD, it is sometimes possible to confuse computers without affecting ordinary players. In practice, the distinction between computers and CD players is less precise. Older generations of CD copy protection, which relied entirely on passive protection, proved easy to copy in some computers and impossible to play on some CD players . Furthermore, computer hardware and software has tended to get better at reading the passive protected CDs over time as it became more robust to all manner of damaged or poorly formatted discs. For these reasons, more recent CD DRM schemes rely mainly on active protection. XCP uses a mild variety of passive protection as an added layer of security against ripping and copying. This form of passive protection exploits a quirk in the way Windows handle multisession CDs. When CD burners came to market in the early 1990s, the multisession CD format was introduced to allow data to be appended to partially recorded discs. (This was especially desirable at a time when recordable CD media cost tens of dollars per disc.) Each time data is added to the disc, it is written as an independent series of tracks called a session. Multi-session compatible CD drives see all the sessions, but ordinary CD players, which generally do not support the multisession format, recognize only the first session. Some commercial discs use a variant of the multisession format to combine CD audio and computer accessible on a single CD. These discs adhere to the Blue Book or "stamped multisession'' format. According to the Blue Book specification, stamped multisession discs must contain two sessions: a first session with 1–99 CD audio tracks, and a second session with one data track. The Windows CD audio driver contains special support for Blue Book discs. It presents the CD to playing and ripping applications as if it was a normal audio CD. Windows treats other multisession discs as data-only CDs. XCP discs deviate from the Blue Book format by adding a second data track in the second session. This causes Windows to treat the disc as a regular multisession data CD, so the primary data track is mounted as a file system, but the audio tracks are invisible to player and ripper applications that use the Windows audio CD driver. This includes Windows Media Player, iTunes, and most other widely used applications. Using a specialized procedure, it is possible to create discs with this flavor of passive protection with standard CD burning hardware and software . Limitations This variety of passive protection provides only limited resistance to ripping and copying. There are a number of well-known methods for defeating it. Advanced ripping and copying applications avoid the Windows CD audio driver altogether and issue MMC commands directly to the drive. This allows programs such as Nero and Exact Audio Copy to recognize and read all the audio tracks. Non-Windows platforms, including Mac and Linux systems, read multisession CD more robustly and don't suffer from the limitation that causes ripping problems on Windows. The felt-tip marker trick can also defeat this kind of passive protection, as noted above.

    Comment


    • #17
      Funny that Mr. R. doesn't mention any thing about a possible security risk caused by DT, which would be the only thing a DT user would be concerned about, but goes on to find it unethical...
      As for the way DT works i think all users are actually ok with it, unlike Sony's XCP..

      Comment


      • #18
        One thing that the DT team might consider is an option to install in 'stealth mode' or not.

        For people (like me) who are not gamers, the anti-blacklisting capabilties of DT are not the top consideration.

        So, like the option of whether or not to install the adware in the free version, maybe give an option to not install the hiding technology.

        Comment


        • #19
          I state officially that "DAEMON Tools contains NO rootkits".
          This article looks like a "piece of incompetent rubbish from a competent guy". Maybe some people, includung Mark Russinovich, have biased understanding of what rootkit is. Yes, our software contains registry hooking mechanisms in order to protect own registry from alteration by malicios software - but this is just technology only used not only by rootkits but also by antivirus and other applications,
          including Mark's own Regmon. If he claims it is a rootkit - we claim back Regmon is rootkit too.
          We have right to decide ourselves what technology to use in our software and what cares us in the least is the opinion of Mr. Russinovich about it. As said - it is just his opinion only.
          If he has too much free time and is willing to go into flames about ethics then he definitely chose wrong piece of software.

          Comment


          • #20
            regmon doesnt hide keys though, it just reports registry access, daemon tools DOES hide keys, so the comparison doesnt quite fit, as for having the right to use whatever technology you want in your own code, sure thats fine, however hiding it from the user is the issue, not the fact that it is done.
            my views are 100% personal views..

            Comment


            • #21
              I don't think we hide Deamon Tools from the user(s) - if Daemon Tools is installed on your system, you've installed it all by yourself, thus you know it is on your system.
              Everybody be cool! You, be cool!
              They'll keep fighting! And they'll win!

              Comment


              • #22
                Who cares what Regmon does then - it uses "unethical" technology no matter what for.

                Comment


                • #23
                  So what's the big deal about hiding keys? Microsoft hides all kinds of stuff on us.

                  How about MS's hiding known file extensions as the default in a new install of XP? This has allowed lots of malicious emails with attachments to take advantage of this. You know, a malicious program file called 'report.doc.exe' displays as attachment 'report.doc' in Outlook. The user thinks it's a Word document, opens it and WHAMO! MS still makes hidden the default even though they know of this problem.

                  AFAIK hiding Registry keys is a feature of the OS. If it's so bad for the user than why hasn't MS issued a security hotfix to plug it?

                  Now if a software package uses any Registry key to perform malicious acts then that's something that should be reported.

                  My 2 cents.

                  Comment


                  • #24
                    to whom it will concer:

                    the "registry-hiding" technology from DaemonTools is based
                    on my design, so if you want to bash someone for that reason,
                    you now whom to write!

                    It was my decision and to tell the truth: it was for sure not
                    in my mind to hide it from the user!! People who claim that
                    just simply don't know what they're talking about!

                    My goodness, it is to protect OUR software. We do NOT fool
                    the users NOR does we NEED to hide something from them!

                    Especially since we contain adware we were ALWAYS as "open"
                    to our users as possible, don't you think we use that "root-
                    kit" for "better" purposes then? NO! It is only to defend our-
                    selfes from malicious software. If THAT is unethical to some
                    users, I think you better deinstall DAEMON-Tools!

                    Apart from that is Mr. Russinovichs opinion in fact biased,
                    for me it looks even as if he knows the development behind
                    StarForce (at least he "checked" their technology and found
                    no rootkits ) - with that in mind, and the fact that he later
                    checked us, go figure! To me it is clear who sits on which
                    site of the table, check also this link: now you can see the
                    "timeline" I mentioned above:
                    http://www.star-force.com/protection.phtml?c=83&id=766

                    Especially the "he woked up famous the next morning" shed
                    some other light to the whole issues (again, in MY opinion)

                    Apart from that, we do not go on the same level like others,
                    I will not bash against Mr. Russinovich nor does I bash against
                    StarForce. At least they will not receive help from me to get
                    more attention, if I wouldn't know better, I could think that
                    all this is a very very clever "campaign" from some people
                    to get more fame. And does it worked? Yes, it does!! But we
                    are not so dumb and blind and do not notice the real reasons
                    behind all this.

                    But that is only my opinion.

                    More and more I got the idea that here people work together
                    to bring us down. That show me at least one thing: it points
                    out that we must do something right.

                    Comment


                    • #25
                      Originally Posted by LocutusofBorg
                      to whom it will concer:

                      the "registry-hiding" technology from DaemonTools is based
                      on my design, so if you want to bash someone for that reason,
                      you now whom to write!

                      It was my decision and to tell the truth: it was for sure not
                      in my mind to hide it from the user!! People who claim that
                      just simply don't know what they're talking about!

                      My goodness, it is to protect OUR software. We do NOT fool
                      the users NOR does we NEED to hide something from them!

                      Especially since we contain adware we were ALWAYS as "open"
                      to our users as possible, don't you think we use that "root-
                      kit" for "better" purposes then? NO! It is only to defend our-
                      selfes from malicious software. If THAT is unethical to some
                      users, I think you better deinstall DAEMON-Tools!

                      Apart from that is Mr. Russinovichs opinion in fact biased,
                      for me it looks even as if he knows the development behind
                      StarForce (at least he "checked" their technology and found
                      no rootkits ) - with that in mind, and the fact that he later
                      checked us, go figure! To me it is clear who sits on which
                      site of the table, check also this link: now you can see the
                      "timeline" I mentioned above:
                      http://www.star-force.com/protection.phtml?c=83&id=766

                      Especially the "he woked up famous the next morning" shed
                      some other light to the whole issues (again, in MY opinion)

                      Apart from that, we do not go on the same level like others,
                      I will not bash against Mr. Russinovich nor does I bash against
                      StarForce. At least they will not receive help from me to get
                      more attention, if I wouldn't know better, I could think that
                      all this is a very very clever "campaign" from some people
                      to get more fame. And does it worked? Yes, it does!! But we
                      are not so dumb and blind and do not notice the real reasons
                      behind all this.

                      But that is only my opinion.

                      More and more I got the idea that here people work together
                      to bring us down. That show me at least one thing: it points
                      out that we must do something right.
                      D-tools doesn't fit in the pattern of the industry, so they recrute idiots to bash here. Call me paranoid, thats MY opinion.
                      And M.R. tells very much to form himself.
                      Last edited by vatras90; 11.02.2006, 19:23.
                      My system
                      Boycott Starforce!
                      Wiederstand ist zwecklos! Ihr Assis werdet miliert!

                      Comment


                      • #26
                        i think the issue really is that people are getting scared now about rootkits, about drivers hooking KeServiceDescriptorTable entries and so on, and using this to reroute process api's, registry api's etc... true, anti virus program do this etc.. but thats really expected, after all anti virus programs monitor process execution, so a hook is expected. I agree the guy in the article is jumping to conclusions, but i think the people are interested in the reasons for these hooks in daemon tools etc, which you have explained and thats all that was required.. as for hiding it from the user, well thats your choice

                        as for starforce being rootkit free, the older versions were definately rootable and there were a few exploits for it, mostly escilating user priveledges..
                        my views are 100% personal views..

                        Comment


                        • #27
                          LocutusofBorg,

                          Correct me if I'm wrong, but what Mark Russinovich says is that hooking system calls should be avoided at all costs.

                          And there are many people who use Daemon Tools but don't play any games, so they would be much happier to have a version of Daemon Tools that doesn't use those "potentially dangerous" hooks.

                          So my proposal is this: during the installation of Daemon Tools, offer the user the choice of disabling those hooks, and of course warn them that some games will no longer work so that they can make an informed decision.

                          That way, "anally retentive" people that are concerned about the possible system instability that those hooks could produce, will be able to sleep easily.

                          And the rest of us will keep using the hooks because we want to play our legally made backups and exercise our Fair Use rights.

                          Could that be the best of both worlds?

                          Comment


                          • #28
                            This Marks is so clever, he is only concerned by our security!
                            So concern that he should tell to the world, he 's find a rootkit in alcohol and DT and blame them !!!
                            Funny that he knows since months that Symantec has implement feature to hide folders similar to those of sony...

                            "I learned of the cloaking several months again when users of our RootkitRevealer rootkit detection tool sent us log files asking whether their was evidence of malware (others have posted logs in the Sysinternals forums). A little research showed that it was generally known that SystemWorks creates NPROTECT directories that show up as false-positives in RootkitRevealer scans."

                            But for symantec, this is "false-positives", "rootkit-like"
                            Even if:
                            "I confirmed that a security vulnerability similar to Sonys exists in the cloaking by copying files into the directory "

                            But despite knowing that and being very concern by our security, does he tell anything about that? No he wait the symantec declaration...

                            Strange no?

                            As I have start about security concern. We should speak about a huge security concern. (not as the rootkit of dt who could be use perhaps by a genious hacker), I have find that a guy sell a real rootkit! This rootkit allow a five years old Kid to access my computer, allow somebody to alter my files, desactivate my antivirus, implemante a keylogger and steal documents and credit card number... What was the name of this soft ... Ah this is NTFS2DOS which allow full access to a ntfs partition just booting on dos bootdisks...
                            This kind of guy should be in jail, this is propably denied by the DMCA...

                            Comment


                            • #29
                              Originally Posted by Leolo
                              LocutusofBorg,
                              Correct me if I'm wrong, but what Mark Russinovich says is that hooking system calls should be avoided at all costs.
                              And there are many people who use Daemon Tools but don't play any games, so they would be much happier to have a version of Daemon Tools that doesn't use those "potentially dangerous" hooks.
                              So my proposal is this: during the installation of Daemon Tools, offer the user the choice of disabling those hooks, and of course warn them that some games will no longer work so that they can make an informed decision.
                              That way, "anally retentive" people that are concerned about the possible system instability that those hooks could produce, will be able to sleep easily.
                              And the rest of us will keep using the hooks because we want to play our legally made backups and exercise our Fair Use rights.
                              Could that be the best of both worlds?
                              No, if you're afraid of "potentially dangerous hooks" do not install Daemon Tools, do not install certain anti-virus software, and do not install programs and games protected by certain protections.
                              It is really interesting to see that Mark just labelled Starforce completely ethical - although especially Starforce hooks a lot of system and patches kernel during cd/dvd check. Seems for Mark there're "good" and "evil" hooks?
                              Now our hooks are just to protect our software, which is really unethical (sarcasm alert). But e.g. the Starforce hooks are completely ethical, 'cause they enforce copy protection (now Professor Frink's sarcasm detector exploded again). I wonder if Starforce paid for the analysis ...
                              Everybody be cool! You, be cool!
                              They'll keep fighting! And they'll win!

                              Comment


                              • #30
                                As far as I understood, Mark said almost nothing about StarForce.

                                Somebody asked him to check StarForce, he answered
                                I've taken a look at StarForce and other than some unorthodox ways of monitoring Cd-Rom traffic and intercepting the creation of all processes and threads, there's nothing overtly unstable about its implementation.
                                And then starforce developers started to tell everyone about Mark's "examination". I doubt if he really knows about all starforce's deeds.

                                Comment

                                Working...
                                X