The OLD, which stands for Object-Level Deceiving/Detouring, is a way of detouring by sending faked kernel objects to the system. This kind of technique represents light granularity of deceiving ratter than hooking technique.
Now let's take a look at a classical example -- Force File Deletion.
Generally, there are 2 things which are in the way of file deleting. One is the share access. If the file is not opened with FILE_SHARE_DELETE, nt!IoCheckShareAccess fails when invoking *CreateFile.
Actually, this is not a problem 'cause openning an existing file with FILE_READ_ATTRIBUTE will always be successful. After you get the file object, the file is all yours. On getting rid of the shared access, MmFlushImageSection is a problem we have to face. M$ tells us: 'The MmFlushImageSection routine flushes the image section for a file that is no longer in use.'. Before you read this article, hooking is your first and maybe only choice. But now, you have a better way of kicking it -- the OLD.
The OLD has it's superiority:
1. It is object-level and light in granulary.
2. You do not have to take the risk of hooking the kernel with a badly written hooklet.
3. ...
When a file is asked to be deleted, the filesystem will invoke MmFlushImageSection to flush the image. If the function failed, the deletion procedure fails. After I reverse engineered the filesystem driver, I found out that the filesystem passes FILE_OBJECT->SectionObjectPointer to MmFlushImageSection to flush the image. So if I fake the SectionObjectPointer field of the file object before passing the irp to the filesystem, the OS will be fooled.
Here's the pseudo code:
void force_delete( ... )
{
...
struct _SECTION_OBJECT_POINTERS sop = { 0 }
fileobject->SectionObjectPointer = &sop;
do_delete( fileobject );
...
/* something have to be done here, find it out my dear reader :> */
...
}
Well, that's the main idea.
Before trying to use the OLD, find out how the OS played with the object. And remember, the OLD is not only a method for force deletion. It's a way of thinking.