Topic
  • 4 replies
  • Latest Post - ‏2009-12-28T18:50:21Z by gjeremia91
gjeremia91
gjeremia91
31 Posts

Pinned topic Parsing Windows Scheduled Tasks (.job files)

‏2009-12-22T21:31:26Z |
I had a requirement to know if a user was running a specific job/scheduled task. I couldn't rely on the name of the task, instead I had to base this on the command being run in the scheduled task.

To the best of my knowledge:
1. BigFix do not provide an inspector for scheduled tasks (nudge nudge)
2. Typically handled with 2 fixlets/tasks
- i. run schtasks and output data to file
- ii. parse output

I needed this to all be done in relevance so, I decided to parse the .job file:

The following relevance appears to give me the command being run (not the params):


concatenation of characters ( bytes (( 72 + (it * 2) ) of ( positions  whose (it < ((

byte (

byte 20 of it) of files 
"<filename>.JOB" of folder 
"tasks" of windows folder)) - 1 ) of ( 
"..............................................................." & 
"................................................................" & 
"................................................................" & 
"................................................................" ) ) ) of files 
"<filename>.JOB" of folder 
"tasks" of windows folder)

Not claiming it's the most optimized bit of relevance I've ever written (in fact, the performance is terrible, about 200 ms), but it does the job.

All those "."s are there to create an array of integers 0-255. I use that to provide an integer array/list to "bytes", thereby obtaining a series of bytes from the file.

I used bytes because treating the file as lines of strings is not the right thing to do. There could be many %0d/%0a line terminators in the file, so how many lines would we need to look at and which line is our data on? If we chose to look at all, then the file could become too large to be held in a string.

byte 20 holds the offset value for the application name length and the application name starts at byte 72. So in essence we are saying:

read from byte 72, for the number of bytes specified in byte 20, skipping every other byte (it * 2, because each character is null terminated). now convert all of those to characters and concatenate them into a string.
  • NoahSalzman
    NoahSalzman
    676 Posts

    Re: Parsing Windows Scheduled Tasks (.job files)

    ‏2009-12-23T02:27:33Z  
    Not sure if the value 69 is just luckily close to "byte 72" for this particular file... but will something like this work?

    q: concatenation of substrings separated by "%00" of first (byte 20 of file "<filename>.job" - 1) of (following texts of first 69 of concatenation of lines of file "<filename>.job")
    A: C:\windows\system32\msfeedssync.exe
    T: 0.657 ms
    I: singular string
  • BenKus
    BenKus
    1408 Posts

    Re: Parsing Windows Scheduled Tasks (.job files)

    ‏2009-12-23T07:15:22Z  
    We have already implemented the new scheduled task inspectors and they are scheduled for release with the next major version...

    Ben
  • gjeremia91
    gjeremia91
    31 Posts

    Re: Parsing Windows Scheduled Tasks (.job files)

    ‏2009-12-23T19:30:42Z  
    Noah,

    as I mentioned in my post, you can't guarantee that "lines of file" won't run over the max size of a string.

    noah
    Not sure if the value 69 is just luckily close to "byte 72" for this particular file... but will something like this work?

    q: concatenation of substrings separated by "%00" of first (byte 20 of file "<filename>.job" - 1) of (following texts of first 69 of concatenation of lines of file "<filename>.job")
    A: C:\windows\system32\msfeedssync.exe
    T: 0.657 ms
    I: singular string
  • gjeremia91
    gjeremia91
    31 Posts

    Re: Parsing Windows Scheduled Tasks (.job files)

    ‏2009-12-28T18:50:21Z  
    Lol, that's wicked !!!

    Good to hear that inspector will be there. Will there be a direct inspector for network routes too ?
    Ben Kus
    We have already implemented the new scheduled task inspectors and they are scheduled for release with the next major version...

    Ben