Top Level Drive Emulation

[aspireit]

Hey Everyone

This might not be a good idea and may sound stupid to some. But I have been administering virtual servers for quite some time now. With all the recent advances in cd rom security and blacklisitng software and the steady stream of anti blacklisting software, I started thinking about how DT could be hidden from the rest of the system.

When I use VMWare and GSX Server, they virtually create CD drives, hard drives and floppy drives all the time. But what I have yet to test is how Copy protection software would react to these physical, yet virtual drives. As far as the operating system knows, this is all physical hardware, when in fact it is being emulated by a piece of software. Although this sounds alot like what Daemon Tools does now, it is not entirely the same.

My understanding of Daemon tools is that when you install it, installs a SCSI adapter (and the SPTD driver) which in itself sets off some alarms as far as copy protection goes. I assume that the SCSI adapter is there because we can only have 2 IDE channels with 2 drives in each. Then we come to all the anti-blacklisting software such as CureROM, Securom Loader etc. which attempt to hide these cirtual drivers. Please correct me if I am wrong in any of this.

The difference between DT and VMWare is in what layer the software is running. VMWare has something that Daemon tools does not, complete supervisor control over the entire system. Essentially, the operating system is run within a container that is completely open for VMWare to monitor and control.

For example, I have created a virtual machine with 1 cd rom drive and one hard drive. Of course, since it is a virtual machine, the two devices obviously virtual as well. But not to the operating system (Windows XP). The advantage here is that no matter what technique the operating system uses to identify the drives, they will always appear to be physical. Since I know very little about the inner workings of copy protection, would this actually solve some issues?

Basically, my idea is this. Create a program that essentially does what DT does now, but has the ability to install itself as a supervisor/hypervisor (for those who know what I'm talking about). If Daemon tools installed itself as either of these, then it would be capable of watching every aspect of the operating system. As in, it would have control over every command and every result. Ie, if you typed in IPCONFIG and your ip was 192.168.0.1, a supervisor program could be configured to intercept this command and force it to return say 123.123.123.123. Could this concept be applied to CD/DVD emulation? When the protection system scans memory/hardware for virtual software, the supervisor could intercept this and return values required to pass the test.

Its just an idea.

[Copytrooper]

You don't need tools like CureROM etc. to "hide" Daemon Tools' drivers. These tools are required to solve the general SCSI blacklist, i.e. even real SCSI controllers/devices are blacklisted if any ATAPI device is found in system. So your approach wouldn't help here.

[aspireit]

Although all SCSI ATAPI drives would be blacklisted, physical or not, the supervisor approach would have other applications. Since the SCSI drivers themselves would come under scrutiny from the protection software, while the program is operating in supervisor mode, it would be able to intercept all attempts to scan the systems hardware. This would allow it to return values that are not nessecarily true.

For example, say that Securom wants to check up of drive F: which is a virtual drive from DT. Securom would have to use a method of checking whether or not it is a drive connected on IDE (which would be valid) or SCSI (virtual DT, sets of alarms etc.). What the supervisor program could do is intercept this method and regardless of whether or not it is virtual, it could return IDE.

This is the idea behind my approach.

This would however leave the issue with authenticating the actual cd. But the supervisor would also be able to play a part and return all the acceptable values for the security software. For those who know what it is, this concept follows the same system as a rootkit. Although this would require people to place an immense amount of trust in Daemon tools, it would also provide DT with the ability to fool all methods of protection by returning set/acceptable values. Rootkits are dug in so deep, that even attempts to scan for them can be defeated by simply intercepting the scan and altering the result. The only drawback of a rootkit is that it slows down the CPU slightly and extends the time it takes to return a result since it is being altered. Exploiting this is the only way to detect a rootkit, but detection can not be done inside the system. Basically, you have to sit there with a stopwatch and time how many commands have been processed and compare that with how many SHOULD have been processed.

[Skirv]

wouldn't that just increase the rate of escalation, in cd protection/cd emulation, I mean, if DT did that, then the cd protection company's would just do something similar to thwart us. I trust DT to not harm my system, but there are many cd "protection" company's I don't.

[aspireit]

The CD protection companies could do exactly what I have been talking about quite easily. In fact, they could be doing it right now and you wouldnt even know about it . But if the game protection companies tried to do this, then it would end up becoming useless. To put it simply, the main purpose of this is to modify the system and the results that it returns, and to not be detected.

For the CD protection companies, they would have to have their root kit as something undetectable, otherwise people would remove it, control it, or even monitor it using their firewall software. Basically it would just become another process like explorer.exe. Now, if they were to make it detectable, a root kit form DT that wasnt detectable would still be able to see its commands going through the system, intercept and change the result.

If it were hidden on the other hand, then both of the root kits would technically be isolated form each other. However, if one was executing a command, say a Securom rootkit probing a cd drive, then that command would still be visible to the DT rootkit, and the same editing could take place. A valid result could still be returned. Theoretically, a DT rootkit could still alter commands without being detected. If it attempted to execute code however, the protection software could go nuts. But if it is simply waiting for an event, then it should remain undetectable. If it doesnt however, then the whole idea is screwed since the protection rootkit could simply force it to return false for when the specified code is being executed. (I hope that made sense. Im going in fairly deep)

I have not done any programming on rootkits, but I know of someone who spoke at the Blackbox security conference about this exact thing. A root kit that could hide itself from the rest of the system, actively altering the results of commands.

[LocutusofBorg]

....A root kit that could hide itself from the rest of the system, actively altering the results of commands.

That is what a rootkit is for, isn't it?

For the rest of your posting: In general, the idea is indeed
interesting, but it seems to me you where somewhere else
the last year. That was when the rootkit-diskussion about
DT took place on several locations. We got alot of trouble
for only use some rootkit-like!! technology. Even for this methods -
who are 110% not dangerous to users systems - we received
alot of emails about concerned users. Your suggestion would
mean a method far beyond our old methods.

No, this is a too much
invasive method for alot of users. Although many users trust
us, it seemed to us that most of our users do not want that
we go that far. The same is true for any protection. I see
no reason to throw the first stone. For the SCSI-blacklist there
are enough good tools out there.

For your thoughts about rootkits I can assure you that your
assumptions are false or too "naive" (no offense - from a
technical side of view). Or to make a long story short:
there is no such "endgame" method. EVERYTHING can be
counter-acted, everything. So what would we win? Exact -
nothing.

EDIT: I just read further and more accurate through your posting and (again - no offense!)
I have now the assumption that you're not a coder at all. (This is not meaned as some-
thing negative but explains why you "simplified" some of the processes that are necessary -
like e.g. "...compare it to how many commands SHOULD have been executed".

Alot of your text makes no sense
(technicalwise). Some of your explanations are simply impossible to implement or only if we
release next version 2018

[LocutusofBorg]

Additional, you should in general not use the term
"Rootkit" in this context. What you want is btw. nothing else
than an emulator, and that is exactly what DaemonTools already
is

What you describe is more or less how emulators work. The
only usefull thing here would be to "fool" the system so that
it "converts" scsi to ide. But then I must tell you: We already
created something (imho) better: Why instead of fooling all
simply create a REAL virtual IDE-drive ? This vIDE is included
in the DaemonTools-Pro edition which we release hopefully
soon.