Jump to content

- - - - -

Issues running program during boot but before login?

  • Please log in to reply
4 replies to this topic

#1 AnonVendetta


    Silver Member

  • Advanced user
  • 788 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 29 June 2018 - 06:05 PM

I have a need to run an exe during boot but before login, it is basically a batch script converted to exe (the exe is self-encrypting and obfuscated but requires no password to run it). The purpose of this is to instruct VeraCrypt, an encryption software, to mount several non-critical data volumes before any user logs in, so that they will be available by the time the desktop appears.


So far I've tried running this exe via Task Scheduler, trying as both the System and my admin account. Task Scheduler reports that it has ran successfully, but the volumes aren't mounted regardless. VeraCrypt accepts command line input and both my plain bat and converted exe mount the volumes in question when I run it manually. But via Task Scheduler, no go. The point is to have these volumes become available while the system is booting, even if booting takes a bit longer.


I have also tried installing the exe as a service, with RunAsService. The service does run, and under the System account, but again, the volumes are not mounted.


No errors are reported either way.


I have also checked to see if VeraCrypt can be ran as the System user, by launching it with Process Hacker. VeraCrypt reports being ran as admin, but Task Manager shows that it is running as System. I just had to see if the mount failures were due to VeraCrypt possibly not being able to run as the System user.


I also tried running a CMD prompt as the System user, via PsTools. CMD does launch as System, but running the commands in the batch (not the batch itself) don't make the volumes mount either. If I run the same command in a regular admin CMD prompt, the volumes mount fine.


And as long as you specify a few extra switches, the command in the bat will mount the volumes in the background, with no GUI shown or input required from the user. Which, to me, it seems that the mounting bit should be suitable to run as a background service. Even though VeraCrypt's GUI is designed to allow the user to interact and therefore not suitable to run it as a service.


I'm out of ideas, these 2 are the only things I can think of try.

#2 cdob


    Gold Member

  • Expert
  • 1463 posts

Posted 30 June 2018 - 08:01 AM

Try a mount.cmd first.
Create a file C:\WINDOWS\System32\GroupPolicy\Machine\Scripts\Startup\mount.cmd

echo mount image.vc %date% %time% >> c:\data\mount.log
"%ProgramFiles%\veracrypt\veracrypt.exe" /v c:\data\image.vc /l x /a /p MyPassword /q /s
run gpedit.msc,
set the startup script mount.cmd
Computer Configuration -> Administrative Templates -> System -> Group Policy -> Configure Login Script Delay = set it to disabled

Try the batch script converted to exe next.

#3 AnonVendetta


    Silver Member

  • Advanced user
  • 788 posts
  • Location:A new beginning.....
  • Interests:Self-development, computing

Posted 30 June 2018 - 08:09 AM

@cdob: I'm working with encrypted *PARTITIONS*, not images such as the *.vc you're using as an example. I'm also using only keyfiles for these partitions, not passwords. A keyfile alone isn't very secure, but those keyfiles are scattered around in various subdirectories in C:\Windows, with legit sounding names and extensions like exe, dll, txt, mui, etc. And they are of varying sizes. Some even have digital signatures. These files aren't Windows system files, I won't specify any default file in C:\Windows\* as a keyfile. So I can be sure that Windows and other programs probably wont try to make use of them. To an attacker they might be mistaken for something else, and therefore overlooked. And my C drive is encrypted with BestCrypt Volume Encryption anyway (instead of VC, for reasons I won't go into here). I think that specifying a password in a bat/cmd is more dangerous than specifying the names and locations of the keyfiles, since an attacker would still need to obtain all those files first. Which is easier said than done. But I'll look into everything else you mentioned as well.

#4 v77


    Silver Member

  • Team Reboot
  • 590 posts

Posted 30 June 2018 - 09:48 AM

I am sure that your volumes are mounted.
I had the same issue with ImDisk Toolkit, and it took me a lot of time to understand what was wrong.

If something runs under the "System" account (typically a service), it belongs to the "session 0". It is like another user.
If a process, under this session, tries to mount a volume, the volume will be mounted, but the shell will not be notified. For security reasons, no notification can be sent from this session to the user session.

It is possible that you see your drive letter : if the user session is started after the volume is mounted, the volume will be identified like all the others.

For now, try to restart Explorer. If this is not enough, it might require to run something in the user session to send the notifications. I can easily write the tool if you want.

#5 v77


    Silver Member

  • Team Reboot
  • 590 posts

Posted 30 June 2018 - 04:36 PM

Here it is:
SHA-1: 556D935A47D5D2E675254ABA44FB08CA9ED3AB1F
SHA-256: F6484EF7388A3382819FE34C145C2AA5CFA9D47EE2457992BBAD52DDFB329958

This tool sends notifications about a new (or removed) drive to all applications of the current session.

notify.exe R X Z
This will send notifications for the arrival of the R, X and Z drives.

notify.exe -Z
This will send notifications about a removed Z: drive.

You can use uppercase or lowercase. An invalide letter stop the program. No need to add ':' .

The executable is 64-bit, but I can provide 32-bit.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users