Activity for ProxyCrypt
-
Guillaume modified a comment on discussion General Discussion
An alternative would be to do something similar to VDI/VHD/VMDK image files: something that grows regularly but not shrinks. But this is doing half the work. And it's still a lot of work. Yeah, and that would be pretty much like a sparse file anyway, so supporting the creation of an image files as sparse file would do exactly that, apart from the fact that moving it would require creating a new image file at the destination and then moving the data. Shrinking files would cause it more to be like...
-
An alternative would be to do something similar to VDI/VHD/VMDK image files: something that grows regularly but not shrinks. But this is doing half the work. And it's still a lot of work. Yeah, and that would be pretty much like a sparse file anyway, so supporting the creation of an image files as sparse file would do exactly that, apart from the fact that moving it would require creating a new image file at the destination and then moving the data. Shrinking files would cause it more to be like...
-
v77 posted a comment on discussion General Discussion
Yes, this has nothing to do with the file system. But at the end, the same issues than a file system would appear: empty blocks in the middle, and how to remove them. It's not impossible, but this is far too much work for this kind of tool. An alternative would be to do something similar to VDI/VHD/VMDK image files: something that grows regularly but not shrinks. But this is doing half the work. And it's still a lot of work.
-
Ah wait, do you perhaps mean here not that fragmentation of the file system per se is a problem, but that it makes the allocation, or rather mapping of image file to volume an issue? Like, for instance, some old implementations of GRUB handling booting from ISO images required the .iso file to be written 100% contiguously on disk?
-
Yep, I thought as much, but I was wondering how deep the "proxy" aspect was and whether the compression would be possible beforehand. That being said, I guess NTFS compression is somewhat capable to do the same.
-
That may be true, but fragmentation is but a small issue by now with everyone using SSDs. The only "problems" left with fragmentation I can think of is that it may leave a bit more parts of sectors unused and that the file table of whatever file system you use will somewhat increase in size.
-
That may be true, but fragmentation is but a small issue by now with everyone using SSDs. The only "problems" left with fragmentation is that it may leave a bit more parts of sectors unused and that the file table of whatever file system you use will somewhat increase in size.
-
That may be true, but fragmentation is but a small issue by now with everyone using SSDs. The only "problem" left with fragmentation is that it leaves more parts of sectors unused and that the file table of whatever file system you use will somewhat increase in size.
-
If we compress an encrypted image file, the compression rate would be almost null. It would be best to compress data before the encryption. To achieve that, the best is probably to use the NTFS compression.
-
There would be a big difference with dynamic ramdisks: we don't have to handle the location of a memory block. We only have to allocate it. With an image file, we would end up with the good old issue of fragmentation.
-
I was wondering if you'd be interested into adding compression support for the image files, e.g. 7z or zstd, if possible. It could significantly decrease file sizes. I'm trying to get rid of a few Pismo Private Folder files, which do have these advantages.
-
I was wondering whether it'd be possible to allow the creation of an encrypted image without specifying the volume size beforehand. The file would grow dynamically and empty blocks would be "reclaimed" by shrinking the file size. Alternatively a very big volume size could by defined, but its image files size would still grow and shrink according to the allocated data inside it. This is the main issue I have with e.g. VeraCrypt: while you can create a sparse volume, empty space cannot be reclaimed...
-
I was wondering whether it'd be possible to allow the creation of an encrypted image without specifying the volume size beforehand. The file would grow dynamically and empty blocks would be "reclaimed" by shrinking the file size. Alternatively a very big volume size could by defined, but its image files size would still grow and shrink according to the allocated data inside it. This is the main issue I have with e.g. VeraCrypt: while you can create a sparse volume, empty space cannot be reclaimed...
-
Mario Pilesi modified a comment on discussion General Discussion
Maybe because you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? I get a similar behavior when I use API before turning off: - ImDiskSetAPIFlags(3) hang shutdown - ImDiskSetAPIFlags(2) fine shutdown It seems related to the 5 second limit for the shutdown. It seems related to this and this.
-
Maybe because you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? I get a similar behavior when I use API before turning off: - ImDiskSetAPIFlags(3) hang shutdown - ImDiskSetAPIFlags(2) fine shutdown It seems related to the 5 second limit for the shutdown.
-
See down.
-
See down.
-
Maybe because you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? I get a similar behavior when I use API before turning off: - ImDiskSetAPIFlags(3) hang shutdown - ImDiskSetAPIFlags(2) fine shutdown Do you can to try to remove it or add a command line switch inProxyCript and RamDyn? static LRESULT __stdcall WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { if (Msg == WM_ENDSESSION || (Msg == WM_POWERBROADCAST && wParam == PBT_APMSUSPEND...
-
Maybe because you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? I get a similar behavior when I use API before turning off: - ImDiskSetAPIFlags(3) hang shutdown - ImDiskSetAPIFlags(2) fine shutdown Do you can to try to remove it or add a command line switch inProxyCript and RamDyn? static LRESULT __stdcall WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { if (Msg == WM_ENDSESSION || (Msg == WM_POWERBROADCAST && wParam == PBT_APMSUSPEND...
-
Maybe because you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? I get a similar behavior when I use bees before turning off: - ImDiskSetAPIFlags(3) hang shutdown - ImDiskSetAPIFlags(2) fine shutdown Do you can to try to remove it or add a command line switch inProxyCript and RamDyn? static LRESULT __stdcall WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { if (Msg == WM_ENDSESSION || (Msg == WM_POWERBROADCAST && wParam == PBT_APMSUSPEND...
-
Maybe because you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? I get a similar behavior when I use bees before turning off: - ImDiskSetAPIFlags=3 hang shutdown - ImDiskSetAPIFlags=2 fine shutdown Do you can to try to remove it or add a command line switch inProxyCript and RamDyn? static LRESULT __stdcall WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { if (Msg == WM_ENDSESSION || (Msg == WM_POWERBROADCAST && wParam == PBT_APMSUSPEND...
-
Maybe because you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? I get a similar behavior when I use bees before turning off: - ImDiskSetAPIFlags=3 hang shutdown - ImDiskSetAPIFlags=1 fine shutdown Do you can to try to remove it or add a command line switch inProxyCript and RamDyn? static LRESULT __stdcall WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { if (Msg == WM_ENDSESSION || (Msg == WM_POWERBROADCAST && wParam == PBT_APMSUSPEND...
-
Maybe because you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? I get a similar behavior when I use bees before turning off: * ImDiskSetAPIFlags=3 hang shutdown * ImDiskSetAPIFlags=1 fine shutdown Do you can to try to remove it or add a command line switch inProxyCript and RamDyn? static LRESULT __stdcall WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { if (Msg == WM_ENDSESSION || (Msg == WM_POWERBROADCAST && wParam == PBT_APMSUSPEND...
-
Maybe because you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? I get a similar behavior when I use bees before turning off: * ImDiskSetAPIFlags=3 hang shutdown * ImDiskSetAPIFlags=1 fine shutdown Do you can to try to remove it or add a command line switch inProxyCript and RamDyn? static LRESULT __stdcall WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { if (Msg == WM_ENDSESSION || (Msg == WM_POWERBROADCAST && wParam == PBT_APMSUSPEND...
-
Maybe you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? Do you can to try to remove it or add a command line switch inProxyCript and RamDyn? static LRESULT __stdcall WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { if (Msg == WM_ENDSESSION || (Msg == WM_POWERBROADCAST && wParam == PBT_APMSUSPEND && suspend_close)) { device_dismount((void*)(IMDISK_API_FORCE_DISMOUNT | IMDISK_API_NO_BROADCAST_NOTIFY)); return 0; } else return DefWindowProc(hWnd,...
-
Maybe you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle? Do you can to try to remove it inProxyCript and RamDyn? static LRESULT __stdcall WndProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { if (Msg == WM_ENDSESSION || (Msg == WM_POWERBROADCAST && wParam == PBT_APMSUSPEND && suspend_close)) { device_dismount((void*)(IMDISK_API_FORCE_DISMOUNT | IMDISK_API_NO_BROADCAST_NOTIFY)); return 0; } else return DefWindowProc(hWnd, Msg, wParam, lParam);...
-
Maybe you use the flag IMDISK_API_NO_BROADCAST_NOTIFY that does not give time to completely close the handle?
-
I found some ideas. I have a encrypted volume that open with ProxyCrypt64avx.exe in X: In X: I have RamDyn.exe I create a volume Y: with X:RamDyn.exe Before shutdown I use imdisk -D -m Y: imdisk -D -m X: RamDyn.exe close and shutdown work If I not force unmount the shutdown hang and sometimes but not always i get "Task Host Window" warning. I have tested: If I move RamDyn.exe from X:encrypted to C:phisical Shutdown sometimes it works and others are not (timeout?).
-
You should avoid to put an ImDisk utility inside an ImDisk volume. This case requires to unmount each volume in the correct order, and it's currently impossible to do that programmatically. Besides, I don't see the point to keep RamDyn in an encrypted volume. RamDyn is a legitimate software that writes nothing on the hard drive. If the system still hangs with RamDyn on C:, then there is another issue. As I said, I will check a few things but it does not mean I will be able to do something. Microsoft...
-
I found some ideas. I have a encrypted volume that open with ProxyCrypt64avx.exe in X: In X: I have RamDyn.exe I create a volume Y: with X:RamDyn.exe Before shutdown I use imdisk -D -m Y: imdisk -D -m X: RamDyn.exe close and shutdown work If I not force unmount the shutdown hang and sometimes but not always i get "Task Host Window" warning. Instead if I unmount with API ImDiskRemoveMountPoint the volume is unmounted but the RamDyn.exe, also if located in a phisical volume, remain and shutdown hang...
-
I found some ideas. I have a encrypted volume that open with ProxyCrypt64avx.exe in X: In X: I have RamDyn.exe I create a volume Y: with X:RamDyn.exe Before shutdown I use imdisk -D -m Y: imdisk -D -m X: RamDyn.exe close and shutdown work If I not force unmount the shutdown hang sometimes but not always i get "Task Host Window" warning. Instead if I unmount with API ImDiskRemoveMountPoint the volume is unmounted but the RamDyn.exe, also if located in a phisical volume, remain and shutdown hang the...
-
I found some ideas. I have a encrypted volume that open with ProxyCrypt64avx.exe in X: In X: I have RamDyn.exe I create a volume Y: with X:RamDyn.exe Before shutdown I use imdisk -D -m Y: imdisk -D -m X: RamDyn.exe close and shutdown work If I not force unmount the shutdown hang sometimes but not always i get "Task Host Window" warning. Instead if I unmount with API ImDiskRemoveMountPoint the volume is unmounted but the RamDyn.exe, also if located in a phisical volume, remain and shutdown hang the...
-
ty, please try to mount a ntfs crypted volume, and copy and execute files. After close, see if have opened transactional ntfs files and shutdown without expliti unmount.
-
ProxyCrypt always dismounts the volume at shutdown. This is required because if the system kills the process with the volume open, Windows could try to send requests to the volume, and these requests would not be processed, which leads to a system freeze. The technique used is very common and reliable (processing WM_ENDSESSION in an invisible window). For now, it perfectly works for me on my Windows 11. But of course, there could still be a bug somewhere. I will check that again.
-
Auto-Dismount when system enters a Suspended state. Do it is possible to add a option to Auto-Dismount when system enters a shutdown state to try if it solve the problem? I think that with the latest versions of Windows, ImDisk cannot normally unmount the driver due to the transactional ntfs that leaves open handle. But it affect crypted driver and not uncrypted driver. It happens in two different computers with the same last OS.
-
Auto-Dismount when system enters a Suspended state. Do it is possible to add a option to Auto-Dismount when system enters a shutdown state to try if it solve the problem? I think that with the latest versions of Windows, ImDisk cannot normally unmount the driver due to the transactional ntfs that leaves open handle. But it affect crypted driver and not uncrypted driver. It happens if two different computers with the same last OS.
-
Auto-Dismount when system enters a Suspended state. Do it is possible to add a option to Auto-Dismount when system enters a shutdown state to try if it solve the problem? I think that with the latest versions of Windows, ImDisk cannot normally unmount the driver due to the transactional ntfs that leaves open handle. But it affect crypted driver and not uncrypted driver.
-
Home
-
Syntax
-
I not have a virus. The problem persist also changing antivirus. My esperience with Nvidia problem, Intel Graphics problem. Also you has the same problem with same solution? Then problem can to be imdisk?
-
I just checked in a virtual machine and I saw no issue. However, since some times, I too have difficulties with the shutdown of Win 10. But even by uninstalling ImDisk (so no ProxyCrypt nor ramdisk), the issue remains. So, even if it seems to work for you by unmounting the ImDisk volumes, I think we likely have the same bug. Perhaps the Nvidia graphic driver (if you have a Nvidia card)? Or a virus?
-
I often have a problem of missing full shutdown in Win 10 on a computer but not in other. I noticied that it solve if I before manually unmont a ImDisk unit and a ProxyCypt unit. Do it is a bug?
-
The full package now embeds the imdisk driver 2.1.1. This driver is only signed by a SHA-256 certificate. Windows Vista 64-bit and unpatched Windows 7 64-bit require digitally signed drivers but are not able to load drivers that are signed this way. In these cases, the driver will not load, and ProxyCrypt will display an error message with a link to download the driver 2.0.10. Note that there is no update for Vista 64-bit to fix this issue. On this system, you have to retrieve the driver 2.0.10 (with...
-
The full package now embeds the imdisk driver 2.1.1. This driver is only signed by a SHA-256 certificate. Windows Vista 64-bit and unpatched Windows 7 64-bit require digitally signed drivers but are not able to load drivers that are signed this way. In these cases, the driver will not load, and ProxyCrypt will display an error message with a link to download the driver 2.0.10. Note that there is no update for Vista 64-bit to fix this issue. On this system, you have to retrieve the driver 2.0.10 (with...
-
Hash
-
ProxyCrypt updated /readme_changelog.txt
-
-
-
ProxyCrypt_full-2.6.2.zip official release remain with ProxyCrypt32*.exe are encrypted.
-
Hash
-
-
-
-
-
-
-
ok ty.
-
https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences
-
There is an issue with your software. With 7-Zip, you can see and extract the files of this folder without password (empty or not).
-
When I try, I get 260 errors and 89 warning.
-
I not find it in source doc: puts(" Error. Please retry.\a");
-
To be precise: The files in "Source" but "source" itself are encrypted. However I imagined that it is an automatism and I thought of warning you.
-
To be precise: The files in "Source" but "source" itself are not encrypted. However I imagined that it is an automatism and I thought of warning you.
-
I just checked and there is no password at all for this folder. Only ProxyCrypt32*.exe are encrypted. I use a script to create the releases so there should be no mistake.
-
Never tried. There is currently no asm, so it should be possible. More importantly, you will very likely get less performances. Everything is optimized for GCC, which nowadays produces a code almost as fast than the Intel compiler. On this kind of software, you can easily get huge differences on this point.
-
"source" folder in ProxyCrypt.zip have a empty password to decompress.
-
Do it is possible to compile in Visual Studio?
-
As said, it's not ProxyCrypt that produces the sound but the console (conhost.exe). So you can open the volume mixer, then open a console and make a sound with the console by using either ProxyCrypt (with a password error) or the Ctrl-G trick. Then you should see a volume control for the console.
-
Maybe it may be a lacks discretion missing option f.e. if you use the tool in a non-private own computer. It should be Default and sound by Option. The best would be also a sound with system sound off. When I use ProxyCrypt In mixer volume I can to set volume for "Acoustic signals System". I don't know if it is also possible to have a mixer volume specific for ProxyCrypt instead of signals System.
-
Maybe it may be a lacks discretion missing option f.e. if you use the tool in a non-private own computer. It should be Default and sound by Option. The best would be also a sound with system sound off.
-
Maybe it may be a lacks discretion missing option f.e. if you use the tool in a non-private own computer. It should be Default and sound by Option. The best would be a sound also with system sound off.
-
Maybe it may be a lacks discretion missing option f.e. if you use the tool in a non-private own computer. It should be Default and Sound by Option.
-
Maybe it may be a lacks discretion missing option f.e. if you use the tool in a non-private own computer.
-
Maybe it may be a lacks discretion missing option f.e. if you use the tool in a non-private computer.
-
It works like this. Ty.
-
Can you try this? The sound produced by the "bell character" depends on the Windows version and the "sound scheme". According to my tests: - Windows XP and Vista do nothing (but who cares? :)) - Windows 7 produces a small and typical sound, no matter the sound scheme - Windows 8 and 10 produce a sound depending on the sound scheme So it seems to me good enough and will not bother the users who have selected "No Sound" in their sound scheme (except for Windows 7 users), so it removes the need for...
-
Ctrl-G work in dos but I not see how implement in proxycrypt. When password is wrong PC loop inadee. It should produce a sound directly from itself.
-
I just remembered something: playing a sound registers the volume for the program and its name/location in the registry. I don't like that, it terribly lacks discretion for a tool like that. A workaround could be to use one of the oldest ways to play a sound: using the "bell" character (because it is played by the console). You can check whether your console will play this sound by typing Ctrl-G and then Enter. But on Windows 10, if you have disabled the system sounds, you may get nothing.
-
When I wake up in the morning, I turn on the computer with my eyes closed and I insert the password. I would like to hear a beep to understand that you have to re-enter it. :-) I usually keep the disabled system sounds and I have not tried if PC from DOS produces a sound when the password is wrong. I would also like if you could set the volume and, if the beep is used, the frequency. Ty.
-
It's very easy to do (provided that the system is configured to play a sound for error events). But could you explain why you need that? When we type the password, we are supposed to watch what is going on... :)
-
Do it is possible to add a command line switch to play a beep or a sound when password is wrong?
-
Hash
-
-
-
-
It work fine, ty.
-
I just added the -font switch. As said in the syntax help, first use this command: ProxyCrypt -font d
-
Mingw: as getting updates for a complete, compiled and ready-to-use toolchain becomes difficult (no new release since more than 2 years on SourceForge), I was looking for an alternative. So I recently found out the releases of "LH_Mouse", a contributor of the project who has his own website: https://gcc-mcf.lhmouse.com/ The version change of GCC involved various small changes in both the source and the compilation script, but now everything works fine. Another important change is that the critical...
-
Hash
-
-
-
-
Hash
-
-
-
-
No problem for me, ty.
1 >