Introduction
On Windows Vista and above, Internet Explorer’s Temporary Internet Files are maintained in two isolated WinINET cache containers. One cache is used for sites loaded in Protected Mode (Internet Zone and Restricted Zone) and the other cache is used for sites loaded outside of Protected Mode (Trusted Sites, Local Intranet, and Local Machine).
...
Prior to IE6, Internet Explorer introduced a mechanism for viewing cached files; you can access this mechanism by clicking Tools » Internet Options » General » Browsing History » Settings. In the TIF and History Settings dialog, click the View Files button. Alternatively, you can simply type shell:cache into the Internet Explorer Address Bar or the Start » Run prompt. Doing this will open a Windows Explorer window to the C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files folder.
It is important to understand that what you see above is not exactly what is stored on disk—alert readers will observe that Explorer is showing columns, like Internet Address and Expires, that are not typically seen for other folders.
This is accomplished through the magic of a Shell Namespace Extension. As explained on MSDN:With a namespace extension, you can take any body of data and have Windows Explorer present it to the user as a virtual folder. When a user browses into this folder, your data is presented as a tree-structured hierarchy of folders and files, much like the rest of the Shell namespace.
This folder is mapped to the Namespace Extension using the desktop.ini file within the folder; it contains the following text:
| Code Block |
|---|
[.ShellClassInfo]
UICLSID={7BD29E00-76C1-11CF-9DD0-00A0C9034933} |
The CLSID listed refers to a COM object implemented in IEFrame.dll. When the Namespace Extension is invoked, it generates the “friendly” view of the non-Protected Mode cache. It generates this view by making API calls into the WinINET cache code. The COM object enumerates the cache using FindFirstUrlCacheEntry / FindNextUrlCacheEntry without passing any filter; this means that files download by XDomainRequest, files temporarily cached while InPrivate, and cached HTTP/3xx redirects, are not shown in this view.
The “Name” listed isn’t actually the name of the cache file on disk, but rather a filename simplistically parsed out of the URL. The HTTP expiration information and similar columns is retrieved from the metadata stored in the index.
Most importantly, this view does not show the Protected Mode cache; it only shows files that are downloaded outside of Protected Mode. In the screenshot, you’ll see a number of Internet-Zone URLs; these are here because Internet Explorer’s Medium Integrity “Frame Process” is downloading the FavIcons; the rest of these pages are downloaded and rendered by the Low Integrity Protected Mode “Tab Process.”
This view may even show files that do not exist; if the backing response entity file was deleted from the disk without calling DeleteUrlCacheEntry to delete the index entry, the Namesspace Extension will still show the entry. However, if WinINET ever wants to reuse the entry, it will find the file missing and will need to re-download from the server.
To see the actual files on disk, open shell:cache\Content.IE5. You’ll see the following view:
You see the index.dat database file, and four randomly named subfolders each of which, if opened, contains cached response files:
The folders are randomly named to mitigate certain types of attacks that involve placing malicious content at predictable file locations and then opening it using a url that uses the file:// protocol scheme. There are four of them to similarly aid in randomness, as well as for legacy reasons (older filesystems had a limit on the number of files contained in a single folder).
The Protected Mode cache files can be viewed in a similar way, by opening shell:cache\Low\Content.IE5 instead:
Again, you’ll see the same layout, with four more randomly named subfolders.