VB - How to use Alternate Data Stream files

[CVMichael]

Since not many people know about those files, and I see no one posted in the CodeBank about them before, I thought I'd give a small example.

First of all, Alternate Data Streams (ADS in short), work only on NTFS.
ADS files are files that "attach" to another file or directory. Those files are completely invisible files; they don't show up in Windows Explorer.

In this example it's creating the ADS file on the C:\ directory (because it's a code snippet), if you want to do it on your application, you should attach the ADS file to App.Path (or something like that).
Remember that you can attach an ADS to a file too, just do something like: "C:\myfile.txt:myADS_file.dat" (the myfile.txt file must exist of course).

Visual Basic supports reading and writing to ADS files, but you can't use functions like Dir or Kill, you have to use API for that.

I usually use ADS files to save settings which I don't want a regular user to see, like username and password (or something like that). But of course that does not mean that that's the only thing you can save in an ADS file. You can use an ADS file just the same as you use a regular file, except that the file is "invisible"

Option Explicit
 
Private Const OF_EXIST = &H4000
Private Const OFS_MAXPATHNAME = 128
 
Private Type OFSTRUCT
    cBytes As Byte
    fFixedDisk As Byte
    nErrCode As Integer
    Reserved1 As Integer
    Reserved2 As Integer
    szPathName(OFS_MAXPATHNAME) As Byte
End Type
 
Private Declare Function OpenFile Lib "kernel32" (ByVal lpFileName As String, lpReOpenBuff As OFSTRUCT, ByVal wStyle As Long) As Long
Private Declare Function DeleteFile Lib "kernel32" Alias "DeleteFileA" (ByVal lpFileName As String) As Long
 
Private Type tWindowPos
    Left As Single
    Top As Single
    Width As Single
    Height As Single
    ' put some other settings here that you want to save...
End Type
 
Private Sub cmdDeleteADSFile_Click() ' a button to click if you want to delete the ADS file
    Dim ADSFileName As String
    
    ADSFileName = "C:\:mydata.dat"
    
    If FileExists(ADSFileName) Then ' cannot check with Dir if the ADS file exists
        If DeleteFile(ADSFileName) = 0 Then ' cannot delete an ADS file with Kill
            MsgBox "No able to delete ADS file", vbExclamation
        Else
            MsgBox "ADS file deleted", vbInformation
        End If
    Else
        MsgBox "File does not exist", vbInformation
    End If
End Sub
 
Private Sub Form_Load()
    Dim MyPos As tWindowPos
    
    If FileExists("C:\:mydata.dat") Then ' cannot check with Dir if the ADS file exists
        ' Open the ADS file, and read the data
        Open "C:\:mydata.dat" For Binary Access Read As #1
            Get #1, , MyPos
        Close #1
        
        With Me
            .Left = IIf(MyPos.Left = 0, Me.Left, MyPos.Left)
            .Top = IIf(MyPos.Top = 0, Me.Top, MyPos.Top)
            .Width = IIf(MyPos.Width = 0, Me.Width, MyPos.Width)
            .Height = IIf(MyPos.Height = 0, Me.Height, MyPos.Height)
        End With
    End If
End Sub
 
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
    Dim MyPos As tWindowPos
    
    If UnloadMode > 1 Then
        GoTo SaveData ' don't prompt for saving, just save without asking if windows is closing
    Else
        If MsgBox("Save window position ?", vbYesNo + vbQuestion, "Save ?") = vbYes Then
SaveData:
            If Me.WindowState <> 0 Then
                Me.WindowState = 0
                DoEvents
            End If
            
            With MyPos
                .Left = Me.Left
                .Top = Me.Top
                .Width = Me.Width
                .Height = Me.Height
            End With
            
            ' Save the data into the ADS file
            Open "C:\:mydata.dat" For Binary Access Write As #1
                Put #1, , MyPos
            Close #1
        End If
    End If
End Sub
 
Private Function FileExists(ByVal FileName As String) As Boolean
    Dim OF As OFSTRUCT
    
    FileExists = OpenFile(FileName, OF, OF_EXIST) = 1
End Function

PS
This is small tool which I found on the internet that alows you to list the ADS files on your comptuer: LADS

[Dave Sell]

They may not show in Windows Explorer, but they are available to other filesystem queries like the CMD.EXE (DIR command), etc... Even the FileSystem Object I believe.

[CVMichael]

I've been using command prompt with dir command for quite a while, and I never seen a ADS file listed by dir.

I don't have any experience with filesystem object, can you post some code that shows listing of files that includes ADS files with the filesystem object ?

[Dave Sell]

Well, not only did I fail to find it with CMD.EXE, I can't even find it with the LADS tool you linked to. I know it exists, because your code works as expected, so I guess I will retract my statements above.

[Dave Sell]

OK I found my file with the LADS tool. I found no way to view ADS information using the Filesystem object.

There are ways to view ADS information using CMD.EXE but I was unable to find a way to "browse" for ADS's using CMD.EXE.

LADS is the only way to browse for ADS "files" which is a misnomer.

This is great info, thanks for posting it - I found I learned something by this.

[Dave Sell]

P.S. I was unable to glean any ADS info using the FisleSystem Object.

[CVMichael]

...There are ways to view ADS information using CMD.EXE...

Can you show how ? cuz I have no clue...

[Dave Sell]

Yes, but it necessitates you know the name and location of the ADS before-hand. As I said browsing is not supported, as I discovered:

C:\>more < C:\:mydata.dat > file.txt

C:\>type file.txt

ÿPF

╥C
H¿E
α─D

C:\>

[Fox]

This is scary. The file is not even included in file size operations, I stored some ADS data into a new folder and it didn't grow at all. What the heck is MS thinking?

Is there really no way to have those files displayed in Explorer? I mean, this may be nice for dumb users who are not supposed to see certain files, but *I* want to know what's on my HDD. Not to think of worms and malware storing data in such a way.

[CVMichael]

I'm glad someone realized how big this is... I was thinking the same, "What was MS thinking when they made this".

But that's not all... you can EXECUTE EXEs from ADS also !
Check this thread:
http://www.vbforums.com/showthread.php?t=380326
Look at the attachent I have in post #20

You could really have a file like "Info.txt" with some text, and then attach an EXE to that file that actually executes a virus, or some kind of malware.

I wonder how many AntiVirus programs check for viruses in ADS files ?
[Edit]
Ow, and to anser your question:

Is there really no way to have those files displayed in Explorer?

I don't know of any way to show these files in Explorer... only with that tool I posted in the first post, wich I think it's using API to do that, but I don't know wich API...

[Fox]

I knew about ADS streams and the vulnerability but didn't realize it was THAT easy to handle, even in VB. Glad ADS Locator didn't find anything here (except some test ADS I just created and forgot to remove *cough*).

Well about code execution, this is merely a way to keep being infected and not really a intrusion problem (you cannot send ADS data to another computer as it's stored in the FS directly). So in order to append the exe to any file the virus must already be running on your computer.

But still. I guess a virus could fill up your HDD and you wouldn't even notice, even Windows would swear there's plenty of free space.

[edit] interesting way to password-protect data... But I'm a little concerned about memory leaks; eg. what happens if you attach ADS data to a file and then delete the file? Will the ADS be removed?

[edit 2] Confirmed that ADS data is removed when the corresponding file is deleted.

[CVMichael]

[edit] interesting way to password-protect data... But I'm a little concerned about memory leaks; eg. what happens if you attach ADS data to a file and then delete the file? Will the ADS be removed?

As you discovered in "Edit 2", Yes, the file gets deleted.

That's why I don't usually attach ADS files to files, I attach them to directories, like "C:\" or "C:\Windows" or "C:\Windows\System32", those directories are there for a long time, and so your ADS file(s) won't get deleted.

By the way, I don't think I mentioned before...

You can attach more than one file to the same location (as long as your ADS files have diferent name of course)

[Fox]

In the meantime I did a little research on ADS. I have to correct my last statement, it looks like ADS can be copied with files to other computers.

- To check the real free disk space use 'chkdsk'
- ADS are supposed for the file properties dialog (where you can enter Title, Autor, etc.)
- Copying files from NTFS to FAT32 will strip the ADS data (o' course)
- No way to display them in Explorer because they are only attachments, not files

That's about it...

[Dave Sell]

I thought that copying a file with an ADS wipes out the ADS on the copied file?

[Fox]

Someone should test that out.. I guess this works on your local computer, eg. you can't send ADS by mail but copying from C:\ to D:\ keeps the data.

[plenderj]

oh....my....god!

[CVMichael]

oh....my....god!

Ammm... to wich part ?

[plenderj]

Em like all of it.. sorry I'd been eating pizza earlier and could only type with one hand

[Atribune]

ADS have been used by CoolWebSearch about:blank variants for well over a year, CoolWebSearch is a major browser hijacker.
About:Buster, removal tool for CWS A:B, by RubberDucky removes ADS from files he bases the ADS search on md5 I think or he did, I remeber collecting for him.

Kaspersky AntiVirus uses them as well when it scans.

We started using iStreams™ technology a couple of years ago to improve scanning performance. Basically, this means that our products use NTFS Alternate Data Streams to hold checksum data about files on the user's system. If a checksum remains unchanged from one scan to another, KAV products know the file has not been tampered with and do not, therefore, require a repeat scan.

There is a catch with Kaspersky's ADS though if Kaspersky is running no tools can see them.

Mark Russinovich, Systernals, tried to claim it was a rootkit and Kaspersky responded with this:
http://www.viruslist.com/en/weblog?weblogid=177727537

Kaspersky has also detected ADS since September of 2000

ADS Spy also finds and removes ads its available at http://www.spywareinfo.com/~merijn/downloads.html

Coded by the author of HijackThis Merijn.

Some other viruses and malware use them as well but not many yet.

Don't know if you wanted info like this but might as well share.

Atri

[CVMichael]

.....
Don't know if you wanted info like this but might as well share.

Atri

Very nice info, especially the ADS Spy tool from http://www.spywareinfo.com/~merijn/downloads.html

More info like this is welcomed...

Thanks

[Dave Sell]

Albeit old news, I made a nice VB6 Module for accessing ADS with 4 Public Functions:

Read_ADS_Info
Write_ADS_Info
Does_ADS_FileExist
Delete_ADS_File

[0xC0000022L]

A web search led me to this strange thread with strange claims about ADS. So I thought I'd better put some things straight. But since I saw Atribune posted here, I guess you already got some professional statement as he is a well-renowned security community member (of course given it is the same).

First of all, Alternate Data Streams (ADS in short), work only on NTFS.

They work on any file system that chooses to support them.

ADS files are files that "attach" to another file or directory. Those files are completely invisible files; they don't show up in Windows Explorer.

ADS are not files at all. Instead one file can have multiple streams but has at least one "main data stream".

I usually use ADS files to save settings which I don't want a regular user to see, like username and password (or something like that). But of course that does not mean that that's the only thing you can save in an ADS file. You can use an ADS file just the same as you use a regular file, except that the file is "invisible"

Invisible to what? Security through obscurity is a very bad idea.

They may not show in Windows Explorer, but they are available to other filesystem queries like the CMD.EXE (DIR command), etc... Even the FileSystem Object I believe.

Only echo and more, if I didn't miss any?!

This is scary. The file is not even included in file size operations, I stored some ADS data into a new folder and it didn't grow at all. What the heck is MS thinking?

Oh, maybe they were actually just thinking ... and looking at NTFS it is quite well-thought.

Not to think of worms and malware storing data in such a way.

They (the bad guys) are using it for several years, so we (the good guys) are detecting it already for several years. Any file system filter will see any stream getting accessed, so no need to worry about AVs and other software not detecting it ... (although some had glitches with these a while ago ... )

But that's not all... you can EXECUTE EXEs from ADS also !

Now what's so amazing with that? You can execute the main data stream so why not be able to execute any other stream as well?

I wonder how many AntiVirus programs check for viruses in ADS files ?

Approximately all and already quite some time before you started this thread.

I don't know of any way to show these files in Explorer... only with that tool I posted in the first post, wich I think it's using API to do that, but I don't know wich API...

Well, the Native API does provide ways to do this, but this will be a pain with VB ... maybe time to start real programming

I knew about ADS streams and the vulnerability but didn't realize it was THAT easy to handle, even in VB. Glad ADS Locator didn't find anything here (except some test ADS I just created and forgot to remove *cough*).

What are you all so afraid of? ... and btw: any user having XP with SP2 and using IE will have ADS because this is how IE saves the information whether the file was downloaded and whether it is allowed to run the file in the current "zone". Also other fully legit software uses this (e.g. KAV, as Atribune showed).

As you discovered in "Edit 2", Yes, the file gets deleted.

Because you delete the file with all its streams, not some ominous "ADS file" as you keep insisting.

That's why I don't usually attach ADS files to files, I attach them to directories, like "C:\" or "C:\Windows" or "C:\Windows\System32", those directories are there for a long time, and so your ADS file(s) won't get deleted.

Okay, to make it short: directories are also files to the file system, that is why directories have a file ID and streams just as any other file. There are some specialties with directories, though. If you are using the Win32 API sometimes you'll have noticed already.

- ADS are supposed for the file properties dialog (where you can enter Title, Autor, etc.)

Not quite, but they are used there (by some OLE/COM storage functions).

- No way to display them in Explorer because they are only attachments, not files

You got it: not files! ... however, you could well write a shell extension to display them from within Explorer.

I thought that copying a file with an ADS wipes out the ADS on the copied file?

Since you copy the file and not a single stream all streams will stay intact unless the target file system doesn't support them. But since Explorer does not show the other streams by default, there wouldn't be any need to inform the user of the ADS being stripped (e.g. when copying it to a non-supporting FS), right?!




Here's some much better information on ADS with explanations, tools and source code (of course not VB):
http://www.flexhex.com/docs/articles...-streams.phtml

[Dave Sell]

A web search led me to this strange thread with strange claims about ADS. So I thought I'd better put some things straight.

They work on any file system that chooses to support them.

Well, the Native API does provide ways to do this, but this will be a pain with VB ... maybe time to start real programming

How painful is it to add 1 .BAS module to a project? Once that is completed, your project can access ADS data with 1 line of code (See my above file attachment). Your statement implies you never use VB6 as a software solution, and discredits your opinion about it. Real programming happens with VB6 even today, years after it has been "discontinued", although I admit, it seems to be used primarily be cowboy (and cowgirl) programmers, developers, engineers, and architects who solve problems (as opposed to legions of java programmers solving similar problems).

[0xC0000022L]

How painful is it to add 1 .BAS module to a project?

Well, Native API is a bit different in several aspects. The structures are different and the way you step to the next structure when one function returns multiple structures in a buffer. So I know from my experience with VB that it will be a pain to use the Native API there. It would be a thousand times easier to write a simple wrapper in any other language and call it from VB with an easier function interface than the normal Native APIs. (Native API != Win32 API)

And if you refer to your BAS file: it has been quite a while since I used (read: was forced to use) VB professionally (approx. 5 years), however, in your module I cannot find any use of the Native API which would be the only way to actually enumerate the ADS of a file

Since your BAS module just treats the files using the standard Win32 APIs it is subject to the same limitations as the Win32 API.

Oh, it is not fully true that you cannot enumerate all streams in the Win32 API since some backup functions allow this, however, they also require the respective (backup/restore) privilege which would normally (i.e. using the Native API) not be necessary, thus making it practically impossible to be used by normal non-privileged users. This is why I did not mention this before, but well now you know it for the sake of completeness ...

Your statement implies you never use VB6 as a software solution, and discredits your opinion about it.

I was forced to use it in my career and I hope it will never happen again as I prefer to have either functional programming or object oriented programming or a (well-thought) mix of 100% FP and 100% OOP, but not ~50% FP and ~50% OOP as in VB ...

Real programming happens with VB6 even today, years after it has been "discontinued", although I admit, it seems to be used primarily be cowboy (and cowgirl) programmers, developers, engineers, and architects who solve problems (as opposed to legions of java programmers solving similar problems).

Ehrm, I'd argue about the terms here (e.g. "real programming" in the same sentence with "VB"), but well ... seems to be the wrong forum to argue about VB anyways ... so never mind

(No, I am not one of the Java guys either, although I am indifferent between most of the other programming languages I know.)

[Dave Sell]

Well, Native API is a bit different in several aspects. ... (Native API != Win32 API)

Since your BAS module just treats the files using the standard Win32 APIs it is subject to the same limitations as the Win32 API.

Interesting comments; what limitations do you refer to? A link or book reference will suffice to satisfy my curiosity, but your comments are welcome.

[0xC0000022L]

Hi again,

don't know whether I am allowed to post links to Amazon here, but here is the most popular book about the topic: Windows NT/2000 Native API Reference by Gary Nebbett. ISBN is 1578701996.

A comprehensive list of functions can be found here (without prototypes in the list, though). Of course not all of the functions are user mode functions, but you can see that from the color of the function name (green is user mode). More information can be found from the ReactOS project which attempts to imitate many aspects of a Windows NT system and thus re-implements the Native API.

BTW: You are looking for the following two functions NtQueryInformationFile and NtSetInformationFile (sometimes also referred to as ZwQueryInformationFile and ZwSetInformationFile, which are equal in user mode - just noting it so you don't wonder).



Oops, sorry. The limitations? Well, lack of ability to enumerate ADS would be what I'd call a major limitation ... for the exception (Win32 backup APIs) lookup the structure "WIN32_STREAM_ID" and the API function BackupRead on MSDN.

[Dave Sell]

I appreciate your response; nice links! Book linking should be OK on any forum...

If your problem (read, project) involves writing device drivers, debuggers, operating systmes, virtual machines, RDBMS's or profilers, VB6 is obviously not an appropriate medium to use to solve your problems.

I have used the gammit of languages pretty heavily from Basic to Fortran to C to C++ to java to VB6 to VB.NET (even a little C#) over the past 15 years.

I have learned to use VB6 in specific ways, mostly using VB6 classes and UserControls (OCX). On projects that range from small to medium complexity, VB6 tends to require about half the time to solve the problems I face. I mostly interface with OPC, databases, TCP/IP, GUI, and the filesystem. Most of my problems cross OS boundaries (read, distributed). I find MS's ActiveX and Win32 implementations to be extremely efficient in creating encapsulated modules (binary compiled) which lend themselves to breaking down complex problems into smaller complexity fragments.

I have never had a need to interface directly with the Native API.

I tend to get offended when VB6 amatures give up on, and criticize the VB6 environment. Minus inheritence and some minor, upper echelon features, VB6 can definately be used in a robust and OO manner (even multi-threaded benefits). It really depends on how you use it. The IDE is quite polished, and I find the installed MSDN the best help-search I have used.

Modern technologies (such as web services, hibernate) do not seem to fit well with VB6 technologies, and that is when I jump into VB.NET.

Trust me; I do not miss the complexities added by inheritence when solving problems.

[0xC0000022L]

If your problem (read, project) involves writing device drivers, debuggers, operating systmes, virtual machines, RDBMS's or profilers, VB6 is obviously not an appropriate medium to use to solve your problems.

True.

I have used the gammit of languages pretty heavily from Basic to Fortran to C to C++ to java to VB6 to VB.NET (even a little C#) over the past 15 years.

The only one out of the list that I haven't used yet is VB.NET.

I have learned to use VB6 in specific ways, mostly using VB6 classes and UserControls (OCX). On projects that range from small to medium complexity, VB6 tends to require about half the time to solve the problems I face. I mostly interface with OPC, databases, TCP/IP, GUI, and the filesystem. Most of my problems cross OS boundaries (read, distributed). I find MS's ActiveX and Win32 implementations to be extremely efficient in creating encapsulated modules (binary compiled) which lend themselves to breaking down complex problems into smaller complexity fragments.

Yap, you gotta know the tools which suit your purpose best ... btw: OPC was the reason I had to use VB back then.

I have never had a need to interface directly with the Native API.

... and you shouldn't. In all cases it is better to use the Win32 API if it provides a way to accomplish the same. However, registry key names with embedded NULL characters are one point where the Win32 API will fail (which is/was sometimes used by malware to "protect" their registry keys). There are many more. But for example the creation of hardlinks on NTFS is easily achieved (since NT4!) by using MoveFileEx with MOVEFILE_CREATE_HARDLINK. Yes, this really works since NT4 although MSDN claims it is reserved for future use. Funnily the structure used by the underlying Native API is identical for move and hardlink actions. Only the "ID" for the action differs.

I tend to get offended when VB6 amatures give up on, and criticize the VB6 environment. Minus inheritence and some minor, upper echelon features, VB6 can definately be used in a robust and OO manner (even multi-threaded benefits). It really depends on how you use it. The IDE is quite polished, and I find the installed MSDN the best help-search I have used.

Most (VB-)code of others I have ever seen tended to be "spaghetti-like" ... but I'll take your word for it. Although I wouldn't call myself a VB6 amateur, I'd not call myself a professional in that respect either, not after 5 years without VB

Modern technologies (such as web services, hibernate) do not seem to fit well with VB6 technologies, and that is when I jump into VB.NET.

Hmm, well it is just shifting the problem into another huge framework which also creates a lot of overhead.

Trust me; I do not miss the complexities added by inheritence when solving problems.

As I said, I take your word for it. However, some of my experiences with VB conflict with my understanding of OOP (not just the lack of inheritance, btw).

But all that is off-topic, so as I said: never mind

[Dave Sell]

Most (VB-)code of others I have ever seen tended to be "spaghetti-like" ... but I'll take your word for it.

90% of other people's VB6 code I have seen is that way. Remember, VB was marketed toward managers, secretaries, and students (remember, MS promised managers could fire half their programmers with VB3?)

Consider, however, one could argue that the majority of code is not of excellent quality in nearly any development language and platform.

It really takes a special curiosity, education, open-mindedness, and dedication to use VB6 in a good way. I mostly take offense to a statement that implies VB6 cannot be used in a good way, just because, in general, it is not.

[0xC0000022L]

Consider, however, one could argue that the majority of code is not of excellent quality in nearly any development language and platform.

Also true - although I'd argue whether some languages are more "supportive" of such a lax programming style. But in the end we have to admit that ~99% of the errors have their cause between chair and keyboard

It really takes a special curiosity, education, open-mindedness, and dedication to use VB6 in a good way. I mostly take offense to a statement that implies VB6 cannot be used in a good way, just because, in general, it is not.

Alright. Sorry it wasn't meant to offend anyone (and it was based on experience, not prejudice).

[bitman]

As you discovered in "Edit 2", Yes, the file gets deleted.

That's why I don't usually attach ADS files to files, I attach them to directories, like "C:\" or "C:\Windows" or "C:\Windows\System32", those directories are there for a long time, and so your ADS file(s) won't get deleted.

How do you do this in vb6 for folder as you describe?
I can't seem to make it happen off of anythy folder but c:\

Windows 7, AppFilePath is c:\ProgramData\

This does not work.

Open AppFilePath + "\BCRMultiUnit\:BCRBitBridgeHelper.dll" For Binary As 345
Put 345, 1, Somedata

This does work

''Open "c:\:BCRBitBridgeHelper.dll" For Binary As 345 Put 345, 1, Somedata

Standard file write works as one would expect.

Open AppFilePath + "\BCRMultiUnit\BCRBitBridgeHelper.dll" For Binary As 345
Put 345, 1, Somedata

Thanks in advance,

Ron