Hello Reader!

Wow, it’s hard to believe I’ve made it to thirty weeks with this project.  Also a bit shocking that the year is getting closer to the end than to the beginning.

Unfortunately real life got in the way of things this week, so I have to reach back to a script I wrote a while ago.  However it’s a script I use on a regular basis.

Typically there are YouTube videos from conferences, etc that I like to watch on my tablet on trips, the train ride into work, etc.  I wanted to find a way to download the files off of YouTube and then just move them over to my device.  After a bit of Googling I found the pytube project on GitHub.  At the time I looked at this script, I didn’t have a lot of experience with Python, so I started with the author’s sample script.  Once I was able to get that working, I wanted to tweak it for something I could use whenever I wanted to.  Most of the sample script has everything hard coded, so you need to edit the script when the YouTube video changes.

I decided to have it prompt me for all the choices I wanted, and that way I would never need to edit the script.  With all that said the caveat with this weeks script is I’m using the pytube author’s license, versus what I normally use.

The script is pretty straightforward, when you run it, the first thing it does is ask you for the URL of the YouTube video you want to download.  This is what you get from the address bar or the share link.  Next, the script goes out and queries the URL, and pulls the name of the video.  I’m using this just to confirm that the video I want is correct.  Next, it queries the video and determines the possible video formats that you can save (codec and quality).  Finally it downloads the file.

Until next week!

https://github.com/CdtDelta/YOP


Hello Reader!

Well this week we’re going to change gears a bit and re-visit a script from Week 11.  You might remember that script was a brute force File Vault script I created to use with the libfvde project.  Now the one issue with that script is if you stop it and start it back up, it has no way of knowing which keys it used before.  One of the plans for the larger program was to include a database portion to track the keys so if we needed to stop and re-run the program, the script would already have a database of what keys had already been tried.

So for this week, I’m starting to write the code to do the database portion of the overall script.

For the “framework” of this script, I pulled in some of the code from Week 11.  The goal was that we could still generate the random File Vault decryption keys, but add them to a database, and if necessary check the database for keys that were already used.

The first new function is the check_key function.  Here we’re passing the key to check, and the database to check against.  Then we look up the key in the database, and if it exists, we return a False statement.  This is to tell the overall program that the key has already been used and to try a new key.  Now if the key doesn’t exist, we add it to the database and return True.  This tells the overall program the key has NOT been seen before, so we’ll check it against the file vault image and see if it unlocks it.  Now this script doesn’t do the file vault image check, that will be part of the larger script when it’s completed.

But for now, all this script does is add the random keys to the database.  If you re-run the script, it will check to see if the key was generated before.  So if you want a database of random file vault recovery keys, this script will generate it for you!

Until next week!

https://github.com/CdtDelta/YOP


Hello Reader!

Well the streak has (almost) been broken.  I must apologize to all of you for getting this out so late.  For the past week I’ve been at SANS DFIR Summit and Training in Austin, TX.  And unfortunately for me, I completely lost track of what day it was until this morning.  But the good news is I got the script done earlier this week because I knew this might happen….

So this weeks script was actually inspired by a panel discussion at the DFIR Summit this year.  I attended a panel discussion that included Dr. Sameer Bhalotra the Former Director of Cybersecurity at The White House.  He mentioned during his talk how Google includes the Safe Browsing functionality in their Chrome browser, but they also make an API available for people to use.  So I thought hey, why not make my own little script to check URL’s when I’m investigating malware.

Now there is one caveat to this script.  You must have an API from Google for it to work.  The good news is it’s free, and you can get the details here.

Once you have the API key, you can launch the script for the first time with the -c switch, along with a configuration file to store the API for future use.  The script does do a check to see if the file exists, so if it can’t find it, it’ll prompt you for the API key again.

Next it’s going to prompt you for the URL that you want to check.  After that, it queries the API and will return the results.  As a sanity check I do provide the URL that is sent to the API in case of any problems.  The results are based on HTTP return codes, and with that code I compare it to what Google uses it for (URL is malicious, safe, etc).

Until next week!

https://github.com/CdtDelta/YOP


Hello Reader!

This week we’re wrapping up my Windows LNK file header parsing scripts.  And it’s ending with the Hotkey value of the shortcut which is at file offset 64.

This value is somewhat unique in that it’s a two byte value, and each byte refers to one part of the hotkey combination.  The low byte value (the first byte) references the alphanumeric key in the hotkey combination.  The high byte value (the second byte) shows if you need to press the Alt, Ctrl, or Shift key (or some combination of the two) along with the alphanumeric key.

To that end, I created three functions to parse out this data.  The first function takes the file offset value and splits it into two parts, the low and high byte.  The second function parses the high byte value.  What I decided to do with this function is create a dictionary with all the combinations, and assign the corresponding key combination(s) to it.  Then it just reads the hex value of the high byte and returns what key combination it refers to.  Finally the third function parses out the low byte value.  This turned out to be relatively easy, because it uses the ASCII character set to define the key.  So you just use the built in python chr function on the hex value to find out what it is.

After all that I just changed the print statement to print out what the Hotkey is.

Until next week!

https://github.com/CdtDelta/YOP


Hello Reader!

This weeks script is a continuation of the week twenty three script that’s parsing the LNK file header.  It’s a short one this week, but we’re working on the ShowCommand portion of the header at file offset 60.  The Microsoft documentation describes this portion as:

“A 32-bit unsigned integer that specifies the expected window state of an application launched by the link.”

Now the values for this are different if you look at the Microsoft documentation versus the documentation written up by Joachim Metz.  For this part of the code I went with the official Microsoft docs, but it’s a trivial matter to modify the code to use the information from Joachim.  The overall difference is the number of identifiers this value represents.

The first part of the code is the function that parses the four bytes of data.  It compares the value with three possible outcomes.  The second part of the code replaces line 53 of the original week 23 script, which just prints out the return value from the function.

Like I said it’s a short one this week!

https://github.com/CdtDelta/YOP


Hello reader!

Today we come to part three of our Windows LNK File Header parsing script, which began with the YOP – Week 23 script.

For this weeks snippet, we’re looking at a function to parse out the attributes of the target file that the lnk file points to, and again we’ll be making use of the bitstring module to parse out the individual bit values for this section.  Now the attribute itself is four bytes in length, starting at file offset 24.

First up is the function, lnk_attrib, which creates a dictionary that refers to the different values depending on which bit flag is set.  Then, in the second part of the function, we parse out the bit values, and if we see a “1”, we print out that the corresponding bit value is set.

The second part is where we pull in the byte values, and then pull out the individual bit values of those bytes.

Finally in the third part, we pass the bit values to the lnk_attrib function, and print the results.

Overall not too different from last weeks script, we’re just looking at a different dictionary.

Until next week!

https://github.com/CdtDelta/YOP


Hello Reader!

This week we’re going to continue working on our LNK File Parser script.  We have two things we’ll be adding this week to how we are parsing the header portion of a LNK file.  If you look at last weeks post, there were some sections that we were just printing out the data to make sure it was there.

First, we need to add some additional modules to our script.  First is the UUID module so we can parse out the Link CLSID correctly.  Second is the BitArray module, which we’ll need to parse out the Link Flags and the File Attributes.

Now this week we introduce a new function, called lnk_flags, which handles the Link Flags.  What I’m doing here is taking this four byte value, and we parse out the individual bits.  Each bit refers to a flag that’s been set.  So I’m looking at which flag is set to a one, and we print out what the corresponding bit refers to.

The second item to mention is we take the 16 byte LinkCLSID value, and then pass it to the UUID module to get the correct output.

And finally we just updated our print statements to show the correct output.

Next week we’ll look at another function I created to parse out some other header data.

Until then!

https://github.com/CdtDelta/YOP




Follow

Get every new post delivered to your Inbox.