XP and Viste SRP tests and ideas

There are a few threads floating around regarding SRP. I want to keep the testing, no matter what the test is for, in one spot so everything is easy to fine. Right now here are the primary SRP threads that I know of
the future of SRP - AppLocker

Maximising Windows XP security with LUA and SRP
Maximising Windows VISTA security with LUA and SRP (even without ultimate)
efficient usb Virus Prevention, using Software Restriction Policies

Now, this first post will be in reference to Hany's mention of using SRP to defeat USB autorun infections. I have made a tool, located here (please forgive the ads, it is free file storage and lets me track how many downloads have been made)
A very simple test
it is a few files. I made a program called setup.exe and have autorun.inf to start it. It reads,writes and deletes sample registry values, tells you what autorun state is for the one Rmus/Lucy mentioned. It tries to copy files to root. It does nothing really other than verify if your autorun protection is working.

I have a heavily tweaked XP Pro system. Been tweaking it for years now. One of my tweaks (reg import on install probably) keeps usb sticks from starting the autorun during install. The autorun can be triggered by viewing my computer single pane, and double clicking the usb drive. However, even turning off all options I know of both from GUI and in registry, or turning them on, does not allow autorun to start when inserting usb stix. Autoplay DOES work though. I have no idea what setting it is that I have in place, but it is mute because it still only stops autorun on insertion, not at all levels.

So, for my first testbed I am using XP Home, a fresh install, all default with no tweaks etc. Upon insertion of USB stick, the autorun happens. Setup.exe is spawned. Registry is read,written to and deleted from. Files are copied to root c: . Double clicking the usb drive while using single pane my computer also triggers the autorun, and the whole thing repeats itself.

Now, part of this test is to copy the autorun.inf, the icon and the setup.exe to the root of c: . If this happens, then things get interesting. There are commands in autorun that will now, in my testing anyway, cause double clicking the c: drive in single pane my computer to actually perform the autorun. Very intersting indeed.

Moving on then, crating manually in xp home a rule that is: path | deny | e:\autorun*
A reload of the registry, and still, double clicking on the usb drive from single pane my computer allows the autorun. That test was with no dll's included. Performing the same test with dll's included in the SRP rule proved no different.

Next a rule was made: Path | Deny | e:\ . This rule does stop execution of .bat or .exe or other monitored extensions. Even excluding dll's. However, it locks down the entire drive from actually bieng able to execute anything. Not really a good solution IMO considering portable applications that you may wish to use. If a blankent level of security is needed, it does seem to work.

So where does that leave us? Next we should test having the directory Autorun.inf existing on c: root. Testing shows that if autorun works, the file creation of icon and setup.exe to c: occurs. Also, it is showing in my setup.exe that the creation of file autorun.inf is also happening. Now technically, I have copied setup.exe to root and renamed to infection.exe. And I copy autorunX.inf from USB to root as autorun.inf. However if the directory Autorun.inf exists, the file copy for autorunx.inf to c:\autorun.inf does not fail, but interestingly what does happen is that the file autorunX.inf IS copied into the directory c:\Autorun.inf, but it is not renamed, it stays as autorunX.inf. Effectively stopping the deployment of autorun.inf to the c: root. We know this can be bypassed, but it seems a simple resolution.

Now that we know that autorun will work on default xp home system, and that a blanket SRP rule is the only way to use SRP to stop autorun, what next. We could state that by including a directory Autorun.inf on every drive might stop many takeovers of the USB/HDD to begin with. But in interest of having a USB stick that can actually run programs, like portable apps, we still need to find a way to stop autoruns on USB but also allow executables.

We will turn to turning off Autoplay and Autorun features. First, we will start with a very simple solution. We will right click on the USB drive and choose properites. Then under the autoplay tab we will choose the action 'take no action'. If we double click the USB drive in single pane my computer, the autorun still happens. So this does not work per say. But, let us now choose the action to be 'open folder view to view files' instead of 'take no action'. Now double clicking the drive in single pane my computer also does nothing, the autorun starts setup.exe. So we move on to next method. At this point I set the autoplay properties back to 'prompt'.

So next we will navigate to this registry key
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
and we will make this value
"NoDriveTypeAutoRun"=dword:0x000000FF
This value says to stop autorun on ALL drives. There are different bitsets to play with, for cd's, fixed, network drives, etc. A great source is right here
MSFN source

Now, we should state that there has been issues with a registry setting called MountPoints2 in HKCU. It appears that often this key will 'remember' what was opened and what happened. I ran autoruns from USB and HDD at this point, and then applied the NoDriveTypeAutoRun setting above. After a registry reload when double clicking on USB stick or psuedo-infected HDD, the autorun stopped and the action was to open the drive in folder view. Now remember, IF there is something in MountPoints2, it is already known. I have not removed anything. But just for testing to see, I went ahead and deleted it. Reloaded the registry and MountPoints2 was there again. Interesting that it contained all the items I had previously mounted, but gone were he values inside which were preferences for the autoplay menu, and also some shellexecute stuff. While the CLSID's of different drives or drive types remain, I don't know what impact those might have.

Moving on, this default XP Home machine has the owner or admin accoutn, and my test account, which is admin. On my xp pro machine, when playing with MountPoints2, I delete it, it comes back. I pilfer through all the SID's and remove every instance of MountPoints2, to try and keep propogating from happening. Many times remember there can be other copies of your registry. You have often seen in safe mode the option to 'use last known good configuration' ? This is actually a copy of your registry values. XP keeps 2 copies. When you boot successfully, it makes copy1. when you boot successfully again it makes copy2. When something changes in the registry, it makes copy 1. When you boot again with those changes, it makes copy2. Etc Etc. The point is, there are places in your registry that if you delete a value, will be recreated the same as it was before because of this other copy. By deleting all found instances of MountPoints2, it made now difference. It is hard coded somewhere. But the interesting thing is that a hard code in my XP machine gave me only a few drives. hdd's and opticals. No USB CLSID's were presetn. Yet in this XP Home fresh OS, all of my USB ports and the USB sticks I am testing with showed back up, but with no values. I am not at all certain why the discrepancy, but it is interesting.

So, now this registry value NoDriveTypeAutoRun seems to be blocking autoruns. And in this test, there seems to be no regard to what MountPoints2 is doing. But we must also regard what Rmus has stated to me, that he sees great variation from machine to machine in this matter. Perhaps others can test this as well and post results back.

Where do we stand now? From the stand point of keeping our USB sticks and HDD's from being compromised, it would seem that a simple solution would be to make a directory on the root of each, named Autorun.inf. For blanket protection of a drive, creating an SRP rule with simply the drive letter (ie. d:\ ) stops all executables in thier tracks. For a solution where you can turn off autorun completely, you can try Rmus/Lucy solution. To disable all autorun, use this

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

To change this to allow autorun again, use this

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

And finally, you can try the NoDriveTypeAutoRun and see how it works in regards to the MountPoints2 key values.

I am most interested in seeing others results.

One last note on SRP. I was playing with hierarchy of it. If you make a rule
?:\ as a deny rule, and then make a rule
c:\ as an allow rule, and have the option on to apply to all users even admins (because you are testing as an admin), you will be locked out. lol. You can go into safemode and remove this. I had hoped that SRP would first deny all, then check for exceptions and allow what was there, but this is apparently not the case.

Sul.

 

I've been using the above reg hack for years with success. In my tests (old and recent), I've found that SRP is not a panacea; it wasn't designed for malware, but still works very well and I believe is in the over 90% catagory of protection. I've learned there are some files that SRP will not block from running, it's the way it's designed I guess. In regard to autorun, the above reg script plus TweakUI has saved me over and over and didn't cost a dime.

By the way, if you want to re-enable autorun again through the registry, the correct reg script is:

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]

 

Yes, thank you I know of adding the - to delete registry keys/values. Have you ever tried that other reg tweak the one I mentioned?

On to other things now. Let someone else who might know system wide ramifications better than I look into this one. I have taken default XP Pro sp3 install now, on vmWare, and playing with more SRP. As an admin, with the setting Basic User, rules apply to all files including dlls and apply to all users including admin. Here is the path rule, with the restriction level set to Basic User

%systemdrive%\documents and settings

Oh? lol. Yes, maybe others have tried it but it seems so simple. It restricts a lot to basic user. I have been originally trying it with %userprofile%. It worked on a lot, but missing. Next I used %allusersprofile%. More was caught, but still one could not be sure of other profiles. This catches many though. So next I just include the whole docs & settings directory. I have no environment variable for this, so systemdrive works unless there is a customized profile directory.

Since the SAFER values exist in HKLM, using this profile wide SRP rule should affect much. For example, all shortcuts from start menu or desktop are now started as a User instead of admin. Let us go one further then, open control panel. Many items you can start from the start menu is now run as User.

There are some holes though. For instance, the icons for my computer and others like it, are not 'technically' shortcuts. If you double click my computer, it starts as admin. It is explorer. It is the shell. It has no restrictions, even if you make a shortcut to a folder, it still has no restrictions imposed. Neither does the run box. Nor does the items listed in the start menu, the items that change depending on how much you use them. Going into all programs or control panel everything seems to take the restrictions there.

So how wide reaching is this? What are it's pro's and con's. I don't know. Perhaps this is a light version of what AppGuard does, where much of UserSpace can be restricted. One thing is for sure, as rule in SRP it is simple. Perhaps some others who know more than I can inform us of possible downfalls of this. Still, it is fun to poke around a bit.

Sul.

 

Whew! Lots of tests, Sul! But necessary if you are going to verify for reliability.

Just to clarify: I was recommending TweakUI for XP which configures the NoDriveAutoRun key which is supposed to prevent Windows from reading the contents of the Autorun.inf file, thus prevent writing to the Registry (MountPoints2 Key). I encountered two instances where this failed - enough to make me stop recommending it.

The Registry tweak you posted is supposed to be foolproof (see first Reference below). I have not found it to fail but I've tested just three systems. However, from the description of how it works, I think it is based on sound theory.

Since you ask for tests, let's see how this Registry tweak works.

I put this autorun.inf file and a small program, astroexp.exe on a USB drive. Autorun is enabled.

Code:

[autorun]
shellexecute=astroexp.exe

Upon connecting the drive, I notice the autorun.inf file information is written to the Registry with the command to execute astroexp.exe:



and astroexp.exe starts:



Now I merge the Registry file you posted, but I'm leaving the MountPoints2 key as above. Upon connecting the device, the Autorun.inf file does not execute, but I can click on the drive icon in My Computer or click on OPEN from the context menu, and it executes. Why? Because the Shell/Command to execute astroexp.exe is still active.

Now, I reboot. On my systems, the MountPoints2 key is removed. On some, it is not, as I learned in another forum. Users need to verify on their own systems.

I connect the USB drive and notice the Registry entry:



Note that AutoPlay is recognized, but no AutoRun entries. No Shell/Command. Therefore, no execution.
When I d-click on the drive icon in My Computer, the contents of the drive display:



DISCLAIMER: The tests above have returned the same results many times on my Win2K and WinXP systems. This is no guarantee that they will do so on other systems, and each user needs to verify in order to feel secure with this method. There are just too many possibilities for something going wrong: unknown configurations that might cause conflicts, user error, etc.

By the way: on my systems, if I disable Autorun with this Registry tweak and then re-enable it, I have to reboot before the change takes place.

A bit of reminiscing: a friend who passed away a couple of years ago would be quite amused at all of the hoopla about autorun these days, for its dangers are certainly nothing new, as the same situations existed back in the days of the floppy disk.

I learned much from him, the most important being that much of computer security can be handled by well-thoughtout user policies and procedures.

At the college where we taught, we and our colleagues regularly received assignments from students on removable media. Now, students wouldn't knowingly set up one to execute malware, but disks/drives get passed around among students, used on other computers, etc. Unwittingly, their drive may have become infected and if the default configuration not to show hidden files is present, they may not see a hidden autorun.inf file.

Our procedure was to hold down the Shift Key when connecting the device. This suppresses execution of the autorun.inf file if present. Next, view the contents of the device in Windows Explorer - the two-pane view of My Computer, where nothing can execute. Files/directories with the Hidden attribute display because my Options are to show all file types:



This remains my procedure today, as I choose to keep autorun enabled. It's a great feature, allowing for customizing the Context Menu for specific tasks when I use my external USB hard drive. I just refuse to be intimidated by the malware thugs who find ways to take advantage of useful features.

FWIW...

----
rich


REFERENCES

1) Memory stick worms
http://nick.brown.free.fr/blog/2007/10/memory-stick-worms

2) Conficker's autorun and social engineering
http://isc.sans.org/diary.html?storyid=5695

3) Adventures at altitude
http://www.viruslist.com/en/weblog?discuss=208187471&return=1

4) Social Engineering, the USB Way
http://www.darkreading.com/security/perimeter/showArticle.jhtml?articleID=208803634

 

What a wonderful post Rmus. And thank you for the reminder of the Shift key technique. I always tell this to the users I work with as a quick, free method to bypass execution of the autorun.inf file.

 

Wow. This MountPoints2 key will be a godsend. Often, since USB came to computers, it has been a mystery why you plug something into port 0, it works, then for some reason later it is no longer recognizable on port 0 and you must use it on port 1. You even have to install it actually on new ports. Used to be, when I got my first USB scanner, I think 96 or 97, this problem occured a lot. It still happens, but unknown why. It would appear that deleting the MountPoints2 key, or at least particular ones, makes windows forget about it so you can reinstall it.

It is interesting that when you plug usb stick into computer, a CLSID is created in MP2. By default, you have A,B,C etc etc that represend drive letters. You also have CLSID for your optical drives it would appear. There is also a value called CPC, which houses it seems removable media. The optical CLSID's are in there all the time.

When you insert media, cd or usb, subitems are created. Autorun/Autoplay within those are shell and open items. If you insert xp cd, the CLSID for the cdrom will have in it the value for autorun d:\setup.exe. This stays until you insert a different cd with autorun.inf, then it changes. While it is in place, the CPC/CLSID key also has that value.

Now, inserting USB does almost the same. It puts info in there from the autorun.inf. And it also puts same information in CPC/CLSID as well. When you unplug the USB, the data from CPC is removed. I found then what the 'safely eject hardware' does. It removes from CPC the value for you, to ensure it is gone. It looks like it is possible for those values to stay in CPC for the drive if you just pull it. They seem to be gone by themselves, but may not I guess. If the value is 'stuck' in CPC, it seems that the drive will not be recongnized next time. But there is also discrepancy in the CLSID values not under CPC.

For example, on my XP Pro system I use most of the time for coding/gaming, I have a reg val (I assume) somewhere that does not allow autorun.inf of USB drives. It does allow autoplay. I have watched MP2 on XP Home and my XP Pro from same USB stick. XP Home, upon insertion, stores the values in MP2. ShellExecute or Open commands from Autorun.inf are stored there even after removal. However, my XP Pro machine, they show up for about 30 seconds. The autorun does not actually work though, only autoplay. Watching the registry then, the shell values exist in both CLSID and CPC/CLSID, but after 30 seconds approx, they are gone from both places. Leaving my system upon next insertion to prompt me (as I like it to) on what to autplay, but never autorun.

I have examined all spots that I know of for disabling autorun, and nothing exists. I have no idea what it is, but I cannot get it to autorun now to save my life. There is one thing strange about my xp install. When I insert USB drives, they are found. But the 30 seconds I talk about, not only do the registry values in question go away, but also if you are in folder view looking at the drive, it basically takes the drive letter away and what you were looking at is gone, normally for me replaced by the drive below it, which is actually control panel. Then a few seconds and the drive is assigned a letter again. You can view it forever without the same issue. If you plug the drive it before powering comptuer back on, it does not exhibit this issue at all. And all of this with none of the disabling autorun methods I have seen here or elsewhere. But I have looked through my reg file, and I don't see anything that would affect this. It is also interesting that every computer I have ever installed with my customized dvd, this is true on. I use RyanVM's update packs and some add-ons. I also use Bashrat's Driver Packs. One of those could also be causing this I suppose.

And finally, rather than use an HKCU reg edit, I now am using this as HKLM

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoDriveTypeAutoRun"=dword:000000ff

This appears to be all that is needed for all accounts.

More to come.

Sul.

 

Oh, it just gets better and better. This whole issue with MountPoints2 is an excellent adventure into the registry. Follow me here.

You have HKCU. There is also an identical registry set HKU-S-x-xxxx.... This is your SID. So your values exist in 2 places when you are currently logged in. I won't even start into why this is, it just is.

I have freshly installed default XP Home SP2. Nothing special, except turned of unneeded services. I am using InstallRite now to catch the changes. Here is what happens.

You insert USB or CD. Values are made in MountPoints2. Enums are made in many areas. usbstor.sys is installed. Lot's of things to get initial USB drive to work. Autorun.inf exists so it autoruns, does it's thing. This autorun has open,shell/open/command and shellexecute in it. So you can watch that in both HKCU and HKU these preferences are written around. However, if you pull the drive, some of those are removed. Yes, gone. But not always. They might be on a timeout or a trigger. Looking at my different registry captures, sometimes they are deleted when you reinsert them. Sometimes they are just gone.

Either way, it appears that from default values those MP2 values, along with many others are actually removed rather than stored. Why does it not always work. Why some machines it does, others not? I have not found out.. yet. lol. It is always a pleasure to dig down into this crap. You always walk away with something. Besides, with the current popularity of USB drives and also the ways people are trying to exploit them, this is a great time to learn more.

Sul.

 

You are welcome.

For those that use this method, I encourage them to remember that the drive must be accessed in the two-pane view of My Computer to prevent accidental executing of an unwanted autorun.inf file.

I've often set up a shortcut for people that will open the USB drive directly in that view.

First you create a shortcut to the USB drive letter assigned in My Computer and give it a recognizable name. You see that it uses the My Computer Icon

Next, in the Properties of the shortcut icon, put this syntax in the Target box, using your own Drive Letter:

%windir%\explorer.exe /e, H:\



The /e, switch forces the Explorer two-pane view. Now the icon changes to the Windows Explorer Icon:



And the USB drive will display the contents with no chance of accidental execution of an autorun.inf file:

​

----
rich

 

Using the "Hold Shift Key" method works for those who are aware of the potential danger of accidently running the autorun.inf file either by clicking on the drive letter in My Computer, or opening from the r-click context menu.

For that reason, in family situations with several users, I prefer using TweakUI-XP to disable drives other than CDROM from executing Autorun.inf. The appropriate value for NoDriveAutorun is automatically entered in the Registry.

​

DISCLAIMER: I use TweakUI-XP only on systems where I can verfiy that it works.

Another consideration: USB like a browser is a potential entry point for malware. I never depend on configurations and settings at these points as the final hurdle for malware to overcome. Some type of protection against unauthorized executables must be in place to guard against a potential breach in the above safeguards.

Here is an early Pen Drive exploit using this autorun.inf file:

Code:

[autorun]
open=kwjkpww.exe
shell\open=Open
shell\open\Command=kwjkpww.exe
shell\open\Default=1
shell\explore=Explore
shell\explore\Command=kwjkpww.exe

This trick modifies the Open and Explore Commands on the r-click Context Menu:

So that using any of these commands would execute the Autorun.inf file unless something blocks:

​

Finally, it should be reviewed how Pen Drive infections work. There are two types of Pen Drives: the U3 type, where an autorun.inf file will execute, and those that do not.

I always suggest in families that to avoid the U3 type and use those that just store data. Windows reacts differently to each.

I'm using my Win2K workstation; you can see the difference in the Mountpoint key entries.

My USB external HD, drive H, does execute Autorun.inf and you can see the Shell command.

On my Pen Drive, Drive I, there is also an autorun.inf file but Windows does not recognize the drive type, so there is no Shell command to execute anything:

​

For technical information about U3 vs non-U3, search for articles.

The implication is obvious: avoid using a U3 type, then in case your Pen Drive becomes infected when used in some other computer, there is no chance that it can accidentaly do damage on yours.


CONCLUSION

There are many ways of dealing with autorun.inf. The IniFileMapping Registry tweak is the most secure, but effectively cripples all Autorun functions on the computer.

Less drastic measures can provide effective protection when thought-out in context of user policies and procedures.

----
rich

 

Another way of dealing with USB flash drive infections is the drive itself. I have a 16GB drive that has the capability of switching to a read-only status. It's a bit of a throw-back to the days of the floppy disk.

 

The only weakness I can see here is if you connect your flash drive to another computer to copy some files. You have to let them write to your drive. At that point, if the other computer has a USB virus it can successfully write the infected files to your drive.

----
rich

 

This Key stores information about any device that is mounted. Unmount (remove) the device and this value goes away.

If so, why did this situation recently appear on my XP laptop?

I have just two partitions, C and D (CDROM)

I connect my USB external drive and it takes the next letter, E. Then I connect my Pen Drive, it takes F.

With those Mountpoints2 keys removed, if I plug in my Pen Drive first, it should take the drive letter E, correct? It doesn't: it takes F.

So, there has to be another Registry Key which stores this information, and I found it at

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices.

I deleted the values DosDevices\E and \F, reconnected my Pen Drive and it took the letter E. The DosDevice\E value reappeared in the above Key.

It's another indication of how the complexities of the Registry make difficult to predict from system to system what is going on, and why unexplained bypasses of Autorun.inf tweaks have happened in the past.

----
rich

 

Weakness? I don't understand. All of these drives have to be written to for storage. How can a drive that doesn't have the read-only feature be stronger?

 

I guess I misunderstand what you are getting at.

I assume you mean that a drive with Read-only enabled cannot get infected. Yet, if you copy files to your drive from another's computer, you have to disable Read-only to copy the files. If that computer is infected with a USB virus, it will transfer to your drive at that point. I and aigle demonstrated this in the early days of Conficker.B

By "weakness" I refer to the idea that Read-only is failsafe in all situations.

Please clarify if this is not correct.

----
rich

 

I think there is a misunderstanding on both sides. I don't understand your last post.

I haven't been able to infect my drive with any malware files yet.

Of course. Do you really think that someone should take that risk and copy any files from a unknown PC? I don't. Even if your flash drive has the dummy autorun.inf\con folders added with the perms stripped out does not guarantee against any malware writing to that drive. After all, the drive has write-access. All I'm saying is in this day and age of flash drive malware and I'm offered a USB flash drive that has the ability to switch to a read-only mode....I'll take it.

 

OK, I see your point. I was referring to situations where users transfer/copy files to/from friend's computers, which could be infected without their knowledge.

I do this all of the time. Flash drives are great for this, but because I don't use a U3 device, no autorun.inf file would run in any case. In several years of using flash drives in this way, I've never encountered any malware on my flash drive. Of course, back on my computer, I always check the drive's contents using my procedure above.

----
rich

 

Sul, you might check with Mrk - in a thread on Autorun earlier this year, he mentioned success with using SRP against Autorun, but I don't recall if he specified the way he set things up.

----
rich

 

K. Thanks. Will look into that.

Is it possible to assign ACL type setting to removable drive, or lock root etc, so that only a lone directory will remain available for writes? Does NTFS support that at all? Something along those lines, which I have never tried.. yet, might alleviate the threat of your flash stick getting exploited.

Sul.

 

I may be missing something from this thread.
What point is it to block autoplay, if SRP is in place? It's only important if you run as admin, or without SRP correct?

I may want to compile these tricks in a "Security Control Panel" folder!

 

The point is to block autorun with SRP. It is proving difficult withuot the method Hany3 outlines, where you block all executables from the removable drive. There are multiple places here concerning SRP, so I thought maybe it would be good to have one devoted to different polices tested and what the results were.

SRP being used in Admin mode, yes as you say it is relevant. SRP when in LUA, it would depend upon how your settings were. The original intent was for myself to allow autoplay while stoppng autorun, whether in context of LUA or Admin. It has gone into some other intersting directions since then

Sul.

 

All clear now Sully, and thank you for the reply. Please continue!

 

It would seem that I have a desire to learn ever more. Digging a little deeper in the registry can be quite revealing.

Here is a key devoted to devices by class. If you examine this key, you will find it is enumerated but still it's base appears in both xp home and xp pro. It can vary a bit depending on your hardware, but it seems very static in concept

Code:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}]

If you examine your own registry, you well see that base CLSID has many device in it, including cdroms,floppies, hdd volumes and removable media. While each 'class' of device has it's own parent key, with an enumerated portion of this

Code:

53f5630d

they are lumped into one big group.

If you examine your MountedDevices closely, you will note that the binary value points to this CLSID. The device is added when found to this class, and also created in MountedDevices.

If you delete MountPoints2, even with a heavily populate one, where you have multiple removable media both in the list as previously used, as well as currently in the USB slot, you will note it is possible without some autorun-stopping mechanism that some will have autorun/autoplay/shell values. Instigating the registry value

Code:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"

like this will certainly cause autorun to stop. It has been found that sometimes the values in MountPoint2 if they still exist, will influence what happens if you were to for example double click on the removable drive icon.

Having done many many tests now, I prefer to use this method to stop autoruns.

Code:

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoDriveTypeAutoRun"=dword:000000ff

What I find happens is this. With a heavily populated MountPoints2 key (as well as MountedDevices), I apply the NoDriveTypeAutoRun reg value to HKLM, not HKCU. If I reload (logoff) the registry, those values in MountPoint2 will still be present. However, if I shut down and restart, those MountPoint2 values that refer to autorun are gone. This seems repeatable.

However, there is another registry key I found that must coincide with this method. Here it is

Code:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers\CancelAutoplay\Files]

Here is the autoplay registry values. I have played a LOT with these values. You can totally change what happens on autoplay, including what is called the 'sniffing', where windows determines what the media type is and then fills your autoplay menu with values it thinks you might need, like starting in media player.

What is important to note here is the cancel files values. These values are simple REG_SZ (string) values, with no data to the value. They look something like this by default on XP.

Code:

"*instal*.exe"=""
"*setup*.bat"=""
"*instal*.bat"=""
"*setup*.cmd"=""
"*instal*.cmd"=""
"*setup*.com"=""
"*instal*.com"=""
"Y?kle*"=""
"Felrak.exe"=""
"Imposta.exe"=""
"KUR.exe"=""
"Ayarla.exe"=""
"sfc2.ico"=""
"evanims"=""
"00000001.tmp"=""
"updmoney.exe"=""
"hs\\media\\y\\11399\\11399_cd_fp.jpg"=""
"hs\\media\\y\\9953\\9953_cd_fp.jpg"=""
"hs\\media\\y\\9951\\9951_cd_fp.jpg"=""
"hs\\media\\y\\9964\\9964_cd_fp.jpg"=""
"hs\\media\\y\\9968\\9968_cd_fp.jpg"=""

what this key does, is tells autoplay to cancel it's action of one of these exist, and instead just go ahead and perfrom what it is designed to do. For example, I believe it was mentioned that an xp cd would start it's setup.exe, and there was amention of maybe it was MS's design of the setup.exe that went around circumvention. However, I do not believe this to be the case.

For example, I have many USB devices plugged into my machine. They are designed to autorun of various sorts (imagine that lol). They are present in MountPoints2. I add the NoDriveTypeAutoRun reg value, and reboot. Now MountPoints2 is clean, and inserting USB stick or double clicking USB drive icon only opens the drive in a folder view (explorer) window. This is good. Inserting a XP install cd, does not autostart. However, if I double click the cd drive icon, the setup.exe does start. This, I think, is due to the *setup*.exe being in an autoplay 'cancel' area of the registry.

If you remove this value, then the autoplay is not cancelled. Evidentily, that NoDriveTypeAutoRun value not only affects autorun, but also autoplay. However in order for it to control autoplay, autoplay must actually execute (whatever that really is). If the file the autorun.inf is attempting to run on the cd is in the cancel list for autoplay, then autoplay never really executes, and the NoDriveTypeAutoRun does not block it successfully.

I find it interesting that if you insert the cd, nothing happens, but if you double click the drive icon, it does. This is different from the USB stick with this method, as it is completely stopped, it appears. I have no idea where the value is that dictates a removable media as CD still will autoplay on double click where removable media on USB does not.

As you can see, well, I am not sure what we see here. I do know that I got risky, removed all the registry values of 'removable media' type from DeviceClasses, MountedDevices and MountPoints2. Then rebooted. Then plugged everything back in examining as I went. If I were to ever get a USB drive that refused to be recognized properly on any USB port, at least now I know how to purge the values.

I think, that by using the NoDriveTypeAutoRun method in conjuction with removing the cancel file types, the system is locked down. The reason to do this is so that when you put your USB stick in, it does not autorun, but does pop up in explorer as folder view. Having said that, I messed with so much, I managed to kill that action too, where it did nothing on insertion.

I even, and not sure how, managed to get a box to pop up when inserting anything with autorun.inf, that asked for admin rights before installing. It was installing, it was just trying to run setup.exe. I was using an admin account, yet this box requesting admin rights popped up. If I gave false credentials or said cancel, the setup.exe would stop. If I gave it correct credentials, the setup.exe would begin. It reminded me of UAC in vista for auotrun, but in XP. I was messing heavily with putting CLSID's in areas that they did no exist, so I don't know how I managed it. But it was pretty cool.

I guess that is the end for today.

Sul.