AIM toolkit

Imdisk Toolkit is now AIM Toolkit.

https://sourceforge.net/projects/aim-toolkit/

 

Thanks for the news! IMDIsk Toolkit still seems to be available and was updated 4 days ago though.

 

AIM Toolkit uses the Arsenal Image Mounter driver, and that's not what we need, with it you see each mounted image as a harddisk in the drive management.
When on has multiple confidential boxes that's not great.

 

Seems that Imdisk (Toolkit) is not working anymore with Windows 11 24h2. Read: https://sourceforge.net/p/imdisk-toolkit/discussion/general/thread/041e10fe01/

 

Working fine for me on Win11 24H2 26120.3291

 

That's interesting. As author of AIM Toolkit, but also ProxyCrypt, could you tell more about this security issue?

ImDisk Toolkit will remain available but will no longer be developed.

(I feel I am out of place on this forum...)

 

@v77 its not a security issue as such, but it complicates things and it clutters the disk management.

If you have a virtual hard disk as Arsenal Image Mounter creates and you want to guard access to the plaintext data, you need to guard more items then when you only have one filesystem device.

With a virtual hard disk you need to guard the block device and the partition, as reading booth gives you access to plaintext data. Also you need to think what if someone would delete the main Partition and create a new one, you eider have to prevent this or ensure you guard any partitions created even later on after the mount.
It complicates things as simple as that.

ProxyCrypt to my understanding does not guard the plaintext data, once an encrypted volume is mounted any process on the system can read the plaintext volume and get all the data in an unencrypted form.

The aim of Sandboxie's confidential boxes, and also of MajorPrivacy's Protected encrypted volumes is to allow only selected applications access to the plaintext data.

So I don't think its a problem for you at all, for me its a solvable problem which I don't have when i stick to the simple ImDisk driver.

 

But if ImDisk will no longer be developed, surely it will be best to change to the AIM Toolkit going forward. Bit like when you changed to SB+

 

Why?
First of all ImDisk will remain functional for the time being, and if MSFT would break something or a security vulnerability would be discovered; its open source I'll fork it and fix it.
I don't want/need the additional complexity in emulating a full disk with partitions and what not, we only need a single volume that's all.

 

Then that's different.

 

AAMOI why are you switching to AIM and no longer developing ImDisk?

As author of ImDisk, my thanks for proving such useful and reliable software. I was using it long before Sandboxie included it as a feature.

 

@henryg1
There was a link above: https://sourceforge.net/p/imdisk-toolkit/discussion/general/thread/041e10fe01/

This is a major incompatibility, Microsoft will never fix it, and the author of the ImDisk driver has stopped the development since several years.
Besides all the complaints about the issues with a lot of installers and Windows Update...

I am aware that ImDisk is more simple to handle for a lot of applications (including my ProxyCrypt), and so I understand the arguments of DavidXanatos.

But I cannot say to my users to stay on an old version of Windows and therefore depriving them of a good hardware support.
The purpose of ImDisk Toolkit was to help as many people as possible to use the ImDisk driver. And with all these issues, a lot of users started to seek after another solution. This is where AIM Toolkit comes.

 

@v77 I was not aware of that incompatibility, that's of cause a problem, do you know roughly what aspect of ImDisk is causing the issue?
Do VeraCrypt and other non full disk emulation based volume mounters have this issue as well? (I know I could test but asking is faster lol)

 

hmm... VC works fine, so its something specific to ImDisk, will need to debug that.

 

Soooo see the below code:

Code:

#include <windows.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
    // File path to open
    LPCWSTR filePath = L"R:\\Temp_123\\TaskExplorer-v1.6.1.exe";

    // Open the file
    HANDLE hFile = CreateFileW(
        filePath,
        GENERIC_READ,
        FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
        NULL,
        OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL,
        NULL
    );

    if (hFile == INVALID_HANDLE_VALUE) {
        wprintf(L"Failed to open file. Error: %lu\n", GetLastError());
        return 1;
    }

    // Get the required size for the final path
    DWORD requiredSize = GetFinalPathNameByHandleW(hFile, NULL, 0, FILE_NAME_OPENED); // <- BUG BUG on ImDisk volume this returns 0
    if (requiredSize == 0) {
        wprintf(L"Failed to get required size. Error: %lu\n", GetLastError()); // this returns ERROR_INVALID_FUNCTION
        CloseHandle(hFile);
        return 1;
    }

    // Allocate buffer dynamically
    WCHAR *finalPath = (WCHAR *)malloc(requiredSize * sizeof(WCHAR));
    if (!finalPath) {
        wprintf(L"Memory allocation failed\n");
        CloseHandle(hFile);
        return 1;
    }

    // Retrieve the final path
    DWORD result = GetFinalPathNameByHandleW(hFile, finalPath, requiredSize, FILE_NAME_OPENED);
    if (result == 0 || result >= requiredSize) {
        wprintf(L"Failed to get final path. Error: %lu\n", GetLastError());
        free(finalPath);
        CloseHandle(hFile);
        return 1;
    }

    wprintf(L"Final path: %s\n", finalPath);

    // Clean up
    free(finalPath);
    CloseHandle(hFile);

    return 0;
}

And that's why the appinfo service which handles the RPC call to do the ShellExecute "runas" command fails, it wants to use this API call in later windows versions and this API call is broken.
It is also broken on windows 10, but there the appinfo service does not use this API.

I'll try to debug this further to find whats failing there on ImDisk volumes.

Funny enough for sandboxie this does not mater as all UAC requests are redirected to start.exe which then subsequently calls the right application and it does not care if it lays on an imdisk volume where this API is broken. LOL

But it will be an issue for Major Privacy which has a ProxyCrypt like functionality and users may expect to be able to run processes as admin from such a secure protected volume.

See also:

Code:

ImDisk: Entering ImDiskDispatchCreateClose.
ImDisk: Successfully created/closed a handle for device 0.
ImDisk: Device 0 received IOCTL 0x4d0008 IRP FFFFE18BD3FFE3E0.
ImDisk: Unknown IOCTL 0x4d0008.
ImDisk: Entering ImDiskDispatchCreateClose.
ImDisk: Successfully created/closed a handle for device 0.

Unknown IOCTL 0x4d0008.

I'm pretty sure i just need to implement this IOCTL in the imdisk driver and voila it should be find again, lets hope.
But that's something for tomorrow, now its late and I'm tired.

 

The Github-Page of imdisk by LTRData.

https://github.com/LTRData/ImDisk

 

fixed: https://github.com/DavidXanatos/ImDisk
signing a release will take a bit more work need to set up CI and stuff,
but you can for testing built it and run it with testsignign enabled.

 

Thanks a lot David.

 

Update: https://github.com/LTRData/ImDisk/issues/27#issuecomment-2689339768
Will set up CI and signing on the weekend or so, was hoping the original author may do that but no.

Shell we rename the fork a bit like ImDiskNG, NG standing for Next Generation, or something?

 

ImdiskDX (Imdisk David Xanatos).

 

David, will you have a Windows exe toolkit version as currently available for ImDisk?

 

Well ImDiskTK is made by @v77 I would appreciate it very much it he/she could keep maintaining it, that as now ImDisk itself is no longer abandoned.

 

Signed: https://github.com/DavidXanatos/ImDisk/releases/tag/v3.0.0

 

@DavidXanatos Thanks. deviodrv.sys not signed?

 

It wasn't signed in the last imdisk release eider.