-windows uses "Task Scheduler Engine" schedsvc.dll (in windows\system32\)when a scheduled task is created. I ran the DLL through a disassembler and got a lot of information that I'm clueless as to what any of it means. These were all listed as imported functions:
Import Module 001: msvcrt.dll Import Module 002: ntdll.dll Import Module 003: ADVAPI32.dll Import Module 004: ole32.dll Import Module 005: NETAPI32.dll Import Module 006: Secur32.dll Import Module 007: NTDSAPI.dll Import Module 008: IMAGEHLP.dll Import Module 009: SHLWAPI.dll Import Module 010: KERNEL32.dll Import Module 011: USER32.dll Import Module 012: RPCRT4.dll Import Module 013: USERENV.dll Import Module 014: WTSAPI32.dll-the windows/Tasks folder has two hidden files, SA.DAT and desktop.ini. SA.DAT is only 6 bytes and neither file changes when new tasks are created
-when you create a scheduled task the final step asks for the account password. If you give a password not matching the windows password, a warning comes up stating that the task may not run, but the ".job" file is still created.
-tasks made with bad password don't run
-if the .job file is modified in a hex editor to attempt to run a different program (i.e. by changing the path strings, or the date) the task won't run
-a program that is set to run under a scheduled task can be replaced with a different program of the same name, the new program will be run instead
When you create a scheduled task, windows creates a ".job" file that can be opened in a hex editor and examined (I only looked at job files of the "perform only once" type) Here's what I got from looking at a few different .job files:
-there is a 16 byte hash or checksum of some kind starting with the fourth byte of the file that is unique for every .job file created. Even when you create the same task twice, both are completely different in this portion of the file. The two files will be identical in all other respects. Likewise for identical tasks created with different passwords.
-there are two seperate sets of strings, one for the location (e.g. C:\windows\system32\)of the program to be executed, and one of the full path and filename of the program (e.g. C:\windows\system32\calc.exe)
-the format for dates and times of the task's execution could be determined easily by systemtically comparing files that differ in only one aspect (like date). I haven't taken the time to do this yet.
Soooooo in conclusion...
I'm thinking that the hash thing at the beginning must contain checksum information encrypted with the windows password (does this make sense?) and so if the checksums don't match then it won't run the task, which is why the task won't run if you even modify one byte of the .job file. Maybe if you could figure out the process for the creation of this hash you could extrapolate what the "hash" for a homebrew .job file would be based on the windows password hash and the checksum of the .job file that you wished to create. I guess this could be determined through disassembly.
on taking a closer look, this "hash" is actually two parts seperated in the hex editor by a "4". The first is 14 bytes, the second is seventeen bytes.
Edited by Jberryman, 07 May 2005 - 12:54 PM.