I need to be able edit the content of index.dat file programmatically (C:\Documents and Settings\Username\Cookies\index.dat). More precisely I need to modify it in order that index.dat for one user can be used for a different user name. Is there any documentation out there for this kind of binary file?
Pasco (http://www.foundstone.com/us/resources/proddesc/pasco.htm) is a free index.dat parser that comes with the source code.
Docs will be hard to come by - Microsoft has never publicly documented the structure of the the structure of this file. That said, you can find docs on the web such as the one mentioned above.
However, note that IE keeps close tabs on this file. The file is locked while IE is running (meaning, you can open/read it in some modes but not in others) and you can certainly not write to it.
One method that might still work is to boot-up in safe mode and then assign yourself administrator rights and then see if you can find the files to delete them.
The method I now use is to create a batch file to rename the subfolder below the folder containing the index.bat files and to then only copy the folders back to the original location that don't contain these files but the resultant batch files needs to be run from a separate windows account that has full administrator permissions.
The freeware code editor PSPad will allow you to view and to edit the contents of all of the index.dat files on your computer in hexadecimal form. This is done by replacing all of the digits in the first eight columns with zeros. This removes all of the information contained in the files.
It's a tedious process, requiring holding down the "0" (zero numeric key) as all of the edits are made, but anyone then accessing any of the index.dat files will get no information.
IE must be closed when doing this or you may receive an error message when attempting to save the modified file(s).
Related
One of my programs stores some information in a .CONFIG file.
I want to change those information for my purposes, but after changing it with an editor, the software does not use this file. Therefore i think i need to keep the meta data of this file in order to be successful.
The evidence, that the software does not use this modified file:
After changing this file (located in program folder) and uninstalling the software, the modified .CONFIG file is not removed.
Maybe i have to say: The .config file is protected. If i want to change it, windows blocks with "access denied". So i have to save it somewhere else, remove the original and copy it to the folder (without success as i already said).
So how to keep those meta information? is there a software which allows to modify it but keeps those information?
Thanks in advance
I'm trying to write a script that removes all files from a given directory, however I don't want to remove files that are currently in use (being viewed, edited, etc.). What I'm finding is that for some file types (.docx, .xlsx, etc.), this works just fine and the .ps1 script fails as expected and moves on. However, some files (.bmp, .txt) can be open and get deleted as well. It looks like certain files are not locked when in-use. I guess my question is a few smaller questions:
Is there a way to tell if files are in-use (other than seeing if it's locked)?
Is there any definitive way to tell which file types are locked when in-use?
Is there a better cmdlet than Remove-Item to use for what I am trying to achieve?
Thanks in advance!
Some applications like Word locks the file wile reading them to avoid it being modified while it's open (usualy in case you want to modify it in ex. Word). Other applications, like notepad, doesn't.
This is not specific to a filetype (which is just a GUI attribute that has nothing to do with the data inside). It's the application that decides if it wants to lock a file or not. Ex:
Open a docx file in Word: Access denied (file in use)
Open a docx file in Wordpad: Success (no lock)
AFAIK it's impossible to detect 100% files being in use by ex. notepad which doesn't lock files.
There are many ways to delete files, but Remove-Item is as good as any of them.
Adding to Frode's point, nothing wrong with remove-item. Normal directory doesn't offer you much. Files hosted via windows file server provides session information might help you identify if a file is being used. If possible, you may implement a smart logic that excludes the files are in use.
In general, I'd recommend a work around that your powershell script check file's LastAccessTime, say, delete everything that hasn't been accessed for 24 hours
Get-ChildItem -path c:\ps | Where-Object {$_.LastAccessTime -lt (get-date).addDays(-1)}
The extreme way of protecting files, is using SCM and don't delete anything checked out. However this is not a friendly solution to average users.
I have a small application that displays the contents of a log file, somewhat transmogrified for readability. As the log file gets rewritten occasionally and Windows file system semantics prohibit deletion of open files, I create a hardlink to the file.
Obviously, this needs to happen on the same file system as the original file -- at present, I create the harddisk in the same directory, which I believe can be reasonably assumed to fulfill this requirement; the result is that a temporary file shows up in the directory listing where the user just clicked to open the file, which is ugly.
Is there a way to create a hardlink so that it does not show up (the customer where the program is used has several junctions in their directory tree, so it cannot be assumed that a specific directory is on the same filesystem), or is there a better method to read a file that another process may want to delete and rewrite (e.g. by catching their access and closing the file before letting the other process's access go through), so the program can be used on archived (readonly) log files without modification?
No
It won't help if you could. Sharing spans links.
Use the solution posed by Hans Passant as a comment.
Currently, I'm developing a system which will extract some files from an SFX archive (files that will be used for another app). I want to make the extracted files hidden, so the person which has find the location of the exe couldn't get the files which will be in same directory with the exe. I know i can apply attrib +h to the files but if the user turns on "show hidden and system files" option in Windows, the files will be visible.
Isn't there any method to overcome this? Any suggestion is welcomed.
Thanks.
If you're writing to the disk, a user can find and read your file. There's no way around that, one could monitor what happens when your application is run, find what files it's writing to, or just intercept while it's being written. Consider why you don't want the user to find your files.
Is it because there's sensitive data, or things you'd rather they didn't change? Consider encrypting it, or verifying it's integrity with a checksum or hash.
Guess you could play around with user rights. However, you'd need to ask an administrator right at install then to make it hidden from the given user who is an admin on the PC.
My windows co-workers were asking me if I could modify my non-windows binary files such that when their "Properties" are examined under Windows, they could see a "Version" tab like that which would show for a Visual Studio compiled exe.
Specifically, I have some gzipped binary files and was wondering if I could modify them to satisfy this demand. If there's a better way, that would be fine, too.
Is there a way I could make my binaries appear to be exe files?
I tried simply appending the VS_VERSION_INFO block from notepad.exe to the end of one of my binaries in the hope that Windows scans for the block, but it didn't work.
I tried editing the other information regarding Author, Subject, Revision, etc. That doesn't modify the file, it just creates another data fork(what's the windows term?) for the file in NTFS.
It is not supported by windows, since each file type has their own file format. But that doesn't mean you can't accomplish it. The resources stored inside dlls and exes are part of the file format.
Display to the user:
If you wanted this information to be displayed to the user, this would probably be best accomplished with using a property page shell extension. You would create a similar looking page, but it wouldn't be using the exact same page. There is a really good multi part tutorial on shell extensions, including property pages starting with that link.
Where to actually store the resource:
Instead of appending a block to the file, you could store the resource into a separate alternate data stream on the same file. This would leave the original file stream non corrupted on disk and not cause its primary file size to change.
Alternate data streams allow more than one data stream to be associated with a filename. Each stream is identified by a colon : at the end of the filename and an identifier.
You can create them for example by doing:
notepad test.txt:adsname1
notepad test.txt:adsname2
notepad test.txt
Getting the normal Win32 APIs working:
If you wanted the normal API to work, you'd have to intercept the Win32 APIs: LoadLibraryEx, FindResource, LoadResource and LockResource. This is probably not worth the trouble though since you are already creating your own property page.
Can't think of any way to do this short of a shell extension. The approach I've taken in the past is a separate "census" program that knows how to read version information from any kind of file.
Zip files can be converted into exe files by using a program that turns a zip file into a self-extracting zip (I know that WinZip does this, there are most likely free utilities for this also; here's one that came up on a search but I haven't actually tried it). Once you've got an exe, you should be able to use a tool like Resource Hacker to change the version information.
It won't work. Either Windows would have to know every file format or no file format would be disturbed if version information were appended to it.
No, resource section is only expected inside PE (portable executable; exe, dll, sys).
It is more then just putting the data inside the file, you have a table that points to the data in the file header.
What you can do if you have NTFS drive, is to use NTFS stream to store custom properties this way the contact of the binary file will remain the same, but you will need to use a custom shell extension to show the content of the stream.