Ripping VSCs – Practitioner Method
Monday, February 6, 2012
Volume shadow copies (VSCs) store a wealth of data and there are different approaches to extract that data for examination. One approach is to examine the data stored inside VSCs directly thereby skipping the need to image or copy the data. My previous post (Ripping Volume Shadow Copies – Introduction) briefly provides an overview about this approach and the two different methods to implement the approach. One method is the Practitioner Method and this post will explain it in detail.
Background
I wanted to provide a little more background about the Ripping VSCs approach and why I needed this capability. At my day job the majority of my cases are fraud related and one activity I need to do is track users’ activity so I can determine where financial data is located. As most examiners know the registry stores information about what a user was doing on a Windows computer including what files they accessed. Over time I grew accustomed to using Regripper when performing registry analysis. A cool thing about Regripper is it comes with some other useful tools and one of them is RipXP. RipXP enables you to parse a registry key from a hive on a system and then it will extract that same key from every registry hive in the system restore points. On my cases where I wanted to know what files were accessed? I would parse specific registry keys from my forensic image then parse those same keys from all system restore points. RipXP automates this process which was not only a time saver but it enabled me to get a more complete picture about a user’s activity over the course of time.
When I received my first few cases involving Windows 7 (and one Vista) systems then I lost the ability to use RipXP. The issue was that Windows 7/Vista replaced the restore points with VSCs. VSCs have a different structure than system restore points which means RipXP doesn’t work against them. I didn’t want to lose this capability when faced with Windows 7 systems so I went on a quest to figure out what my options were for ripping registry hives in VSCs. I first reviewed others’ research about VSCs and their forensic significance. I proceeded to learn and attempt the two well known approaches to VSCs examination including the robocopy method for copying data. I took what I learned and wanted to take the robocopy method to another level. My logic was if robocopy can copy data from VSCs then Regripper could parse registry hives inside VSCs. I manually ran Regripper against hives in VSCs through symbolic links showing I was on the right track. For the technique to be useful I needed automation so I could replicate how RipXP worked. I had to run the Regripper command in a loop to execute it repeatedly against registry hives in different VSCs. I was working on looping Regripper through the command-line and reached out to Harlan for some help. The end result was a command that would rip registry hives across VSCs. I saw that Harlan shows the exact command in Chapter 3 in Windows Forensic Analysis 3rd Edition.
The technique worked and replicated RipXP’s functionality. However, all you have to do with RipXP is run a script which means the technique had to be scripted. I taught myself Windows batch scripting and created a few scripts to rip registry hives in VSCs thereby getting my lost RipXP capability back. One of these initial scripts is included in the materials that accompanies WFA 3/e (I have made some significant changes too the script since it was given to Harlan). Now my logic was if Regipper can parse registry hives then any program can be automated to parse data inside VSCs. Again I was on the right track and this is how the Ripping VSCs approach came about.
Practitioner Method Overview
The Practitioner Method uses one existing tools to parse data inside a mounted volume’s VSCs by traversing through a symbolic link. I won’t rehash how to mount a volume of interest since it was discussed in the introduction. The method will be explained from the point after the volume was mounted and below illustrates the examination process.
The method can be broken done into the following three steps:
1. Accessing VSCs
2. Ripping Data
3. Removing Access to VSCs
Before breaking down the three steps I wanted to discuss one of the lost DFIR commandments: Thou Shall Not Fear the Command-line. This commandment should be kept in mind because the Practitioner Method doesn’t have a nice GUI since its command-line based. For those who don’t like to interact with the command-line should check out Girl Unllocated’s Basic Command Prompt video since it may be a helpful tutorial. With all joking aside, the method does leverage command-line tools since they can be automated in scripts. I’ve found overtime the technique is very powerful because of the sheer number of free DFIR tools that run from the command-line.
Accessing VSCs
I just started reading Harlan’s WFA 3/e Kindle version (I’m on chapter 4 at the time of this post) and chapter 3 does an outstanding job explaining the process about accessing VSCs. From explaining what VSCs are to mounting a forensic image to creating symbolic links to VSCs to various tools for examining data inside VSCs. WFA 3/e goes into more depth than this post because I’m only providing a quick overview.
Accessing a VSC consists of identifying the VSC’s path followed by creating a symbolic link pointing to that path and the built-in Windows vssadmin command can accomplish this. The command also displays a lot more information including when each VSC was created. The command below will show the VSCs on the mounted volume with the drive letter C:
vssadmin list shadows /for=C:
The picture below shows the output from that command.
As can be seen in the screenshot, VSCs paths start with \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy and each VSC will have a unique number. For this specific volume the VSCs are numbered starting with the number 1 then increasing to 12 since there are 12 current VSCs. To access the first VSC a symbolic link needs to be created pointing to the path \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1. The built-in Windows mklink command can create the symbolic links to VSCs. I’ve only been reading WFA 3/e for a few days and the book as already made me change how I approach VSCs. Harlan was using the mklink’s /d switch to mount a VSC to a symbolic directory which means the link acts as a normal folder. I updated my scripts to use the /d switch instead of /j (creates a directory junction). The following command will create a symbolic link named vsc1 pointing to C volume’s first VSC and the picture shows the result:
mklink /d c:\vsc1 \\?\GLOBALROOT\Device\HardDiskVolumeShadowCopy1\
To access every VSC of interest means someone would have to execute the mklink command multiple times. To access all 12 VSCs on my C volume means I need to type the mklink command 12 times. After working my first case involving Windows 7 I learned pretty quickly the need to automate VSCs access. My post A Little Help with Volume Shadow Copies discussed and provided a batch script that automates creating symbolic links to VSCs. The script worked great but I have since updated it. One change was to incorporate mklink’s /d switch but the more important change is making it easier to access specific VSCs.
Automate Accessing VSCs
If you are only interested in the access-vsc script then skip ahead to the last paragraph in this section for the script’s download link. Otherwise, you can continue reading on to see what and why I changed the script. I already mentioned the significance of mklink’s /d switch so I won’t rehash it here. Just know that I did update my scripts to use this switch. The issue I encountered with my access-vsc script was the difficulty in narrowing my focus on specific VSCs that were not sequential. For example, if I wanted to identify the differences between VSC1, VSC3, and VSC6 then it was difficult due to the For loop used in the script. To show the issue I will discuss how the old For loop worked. The following was the loop in my old script (the command uses two % symbols since the command launches from a batch file):
for /l %%f in (start,step,stop) do echo %%f
Start represents the number the For loop should start at which in this case is 1 for the first VSC. Stop represents the number the loop should stop at which in this case is 6 for the last VSC. Step represents the number to increment each time the loop goes through. If the step was set to 2 then the For loop’s output looks like the following:
As shown in the screenshot setting the increment number to 2 only resulted in numbers 1, 3, and 5 when starting at 1. This means symbolic links would only be created for VSC1, VSC3, and VSC5 while missing VSC6. The only increment number that would work for automation is 1 and this was how my old script worked. Now the For loop’s output looks like the following:
The For loop now counts from 1 to 6; meaning symbolic links would be created for VSC1, VSC2, VSC3, VSC4, VSC5, and VSC6. That’s great since it provides access to the three VSCs of interest (VSC1, VSC3, and VSC6). However, there are VSCs being accessed that I didn’t want. This is only a small issue but it’s pretty significant when trying to automate comparing the differences between VSCs. To get around this issue I change the For loop so it uses numbers listed in a text file:
for /f %%f in (vscs-2-parse.txt) do echo %%f
The text file contains one number per line and in this case the numbers are 1, 3, and 6: Now the For loop’s output looks like the following:
As shown in the screenshot, the numbers count from 1 to 3 then 6. This would provide access to only the three VSCs of interest. To some this issue may seem small because I’m using small numbers. The volume I keep referencing throughout the post has 12 VSCs. If I wanted to access VSC1, VSC6, and VSC12 then the old script would create symbolic links to every VSC. This also means whatever data I want to parse through automation would get parsed in every VSC instead of the three I’m interested in. My new script provides access to only the VSCs someone wants; to see how check out the For loop below:
for /f %%f in (vscs-2-parse.txt) do mklink /d c:\vsc%%f \\?\GLOBALROOT\Device\HardDiskVolumeShadowCopy%%f\
The only difference in this For loop compared to the previous ones I showed is that the echo command was replaced by the mklink command. To access VSCs 1, 6, and 12 means the text file (vscs-2-parse.txt) should contain these numbers. The end result is having access to specific VSCs as shown below.
The cool thing about using a text file is that the same file can be leverage by other scripts to rip data inside VSCs. The access-vsc script pretty much works the same way as the old script. The only noticeable change is that it allows you to create a text file with the VSC numbers of interest (file gets dropped in the same directory as the script). The new script can be located at my blog’s Google Code site here. I’m releasing the script since I previously blogged about and shared the old one. I’m also releasing a series of scripts that work together to rip VSCs and will provide a short demo video showing their capabilities in my next blog post.
Ripping Data
Data can be parsed once the symbolic links pointing to VSCs are created. All that has to be done is to run a command against the data traversing through the symbolic link. For example, the Windows dir command can be executed directly against the symbolic link vsc1 to see what’s in the root directory of the VSC it’s linked to.
Continuing on with the example, the dir command can also show the files located in the Regripper folder inside VSC1.
Programs can run against VSCs’ data by going through the symbolic link. Just switch out the dir command with any other command-line program. So many days ago I switched out the dir command with Regripper. Here’s a screenshot showing Regripper parsing the Software hive’s uninstall registry key inside VSC1.
Automate Ripping Data
The previous Regripper command was only executed against the Software hive in VSC1. To process other software hives that same command needs to be ran against each VSC of interest. Examining VSCs in this manner is doable but the work is timing consuming and tedious. Not only does it take longer to execute the commands manually but typing the commands is error prone. I remember my first case working with VSCs; I was manually creating the symbolic links to VSCs and parsing registry hives. With over 15 VSCs it got old really quick; I had typos thus making the commands not work, wasted time trying to copy commands, and I learned how boring it is to type the same thing over and over. That experience is what influenced me to learn about batch scripting and the same concept applies to ripping VSCs. What option looks better: write a command once to extract information in seconds or write a command many times that takes minutes/hours to extract the same information? I bet most people would be pick door number one; that door is the main motivation to automating ripping VSCs.
One doesn’t have to be an expert in batch scripting to automate ripping VSCs using the Practitioner Method. I think all that someone needs to know is how a For loop works in a batch script. The Automate Accessing VSCs section in this post explained the For loop used in the script to create symbolic links. If you skipped that section; don’t worry and I won’t make you go back to re-read it. The important thing about the section is that the script uses a text file named vscs-2-parse.txt and the file contains a number on each line. The numbers are used to create symbolic links to each VSC. For example, the number 1 on a line results in a link named vsc1 and it points to VolumeShadowCopy1. A For loop can be written which uses the same text file to rip data inside VSCs. The simple batch script below can be used as a template:
@echo off
for /f %%f in (vscs-2-parse.txt) do (
do something against c:\vsc%%f
)
The @echo off line turns off the displaying the commands running in the batch file. The line isn’t needed but most people prefer not to display command executing. The rest of the script is just a For loop. The /f switch makes the loop work against a text file which is specified between the parenthesis (vscs-2-parse.txt). %%f will be the variable used to hold the data on each line in the text file. Quick tip: a For loop in a batch file requires two percent symbols (%%) since it strips out one symbol. However, only use one percent symbol (%) when running a For loop from the command-line. This little nuance caused me a lot of headaches when I first started working with batch files. Everything between the next set of parenthesis is the loop and will be executed until the loop reaches the last line in the text file (vscs-2-parse.txt). To rip VSCs, a program needs to be pointed to the symbolic links using the loop’s variable (%%f).
I know this may seem complicated to those who have never worked with batch files before. I swear, it just seems that way writing and reading about it. All that really has to be done is to copy the template, insert whatever program is to be executed, and save the text file with a .bat file extension. The loop below will rip the Software hive’s uninstall registry key from each link pointing to a VSC and all I did was copy the template.
@echo off
for /f %%f in (vscs-2-parse.txt) do (
rip.exe -r C:\vsc%%f\Windows\System32\config\SOFTWARE -p uninstall
)
The output from the above batch script would just be displayed on the screen. A slight change by -redirecting the output – can save the output to a text file as shown below. Just make sure that >> is used to append the output to the text file.
@echo off
for /f %%f in (vscs-2-parse.txt) do (
rip.exe -r C:\vsc%%f\Windows\System32\config\SOFTWARE -p uninstall >> C:\output.txt
)
The batch script template discussed is the foundation to ripping VSCs with the Practitioner Method and the next post will demonstrate how it can be used.
Up Next: Ripping VSCs – Practitioner Examples
Background
I wanted to provide a little more background about the Ripping VSCs approach and why I needed this capability. At my day job the majority of my cases are fraud related and one activity I need to do is track users’ activity so I can determine where financial data is located. As most examiners know the registry stores information about what a user was doing on a Windows computer including what files they accessed. Over time I grew accustomed to using Regripper when performing registry analysis. A cool thing about Regripper is it comes with some other useful tools and one of them is RipXP. RipXP enables you to parse a registry key from a hive on a system and then it will extract that same key from every registry hive in the system restore points. On my cases where I wanted to know what files were accessed? I would parse specific registry keys from my forensic image then parse those same keys from all system restore points. RipXP automates this process which was not only a time saver but it enabled me to get a more complete picture about a user’s activity over the course of time.
When I received my first few cases involving Windows 7 (and one Vista) systems then I lost the ability to use RipXP. The issue was that Windows 7/Vista replaced the restore points with VSCs. VSCs have a different structure than system restore points which means RipXP doesn’t work against them. I didn’t want to lose this capability when faced with Windows 7 systems so I went on a quest to figure out what my options were for ripping registry hives in VSCs. I first reviewed others’ research about VSCs and their forensic significance. I proceeded to learn and attempt the two well known approaches to VSCs examination including the robocopy method for copying data. I took what I learned and wanted to take the robocopy method to another level. My logic was if robocopy can copy data from VSCs then Regripper could parse registry hives inside VSCs. I manually ran Regripper against hives in VSCs through symbolic links showing I was on the right track. For the technique to be useful I needed automation so I could replicate how RipXP worked. I had to run the Regripper command in a loop to execute it repeatedly against registry hives in different VSCs. I was working on looping Regripper through the command-line and reached out to Harlan for some help. The end result was a command that would rip registry hives across VSCs. I saw that Harlan shows the exact command in Chapter 3 in Windows Forensic Analysis 3rd Edition.
The technique worked and replicated RipXP’s functionality. However, all you have to do with RipXP is run a script which means the technique had to be scripted. I taught myself Windows batch scripting and created a few scripts to rip registry hives in VSCs thereby getting my lost RipXP capability back. One of these initial scripts is included in the materials that accompanies WFA 3/e (I have made some significant changes too the script since it was given to Harlan). Now my logic was if Regipper can parse registry hives then any program can be automated to parse data inside VSCs. Again I was on the right track and this is how the Ripping VSCs approach came about.
Practitioner Method Overview
The Practitioner Method uses one existing tools to parse data inside a mounted volume’s VSCs by traversing through a symbolic link. I won’t rehash how to mount a volume of interest since it was discussed in the introduction. The method will be explained from the point after the volume was mounted and below illustrates the examination process.
The method can be broken done into the following three steps:
1. Accessing VSCs
2. Ripping Data
3. Removing Access to VSCs
Before breaking down the three steps I wanted to discuss one of the lost DFIR commandments: Thou Shall Not Fear the Command-line. This commandment should be kept in mind because the Practitioner Method doesn’t have a nice GUI since its command-line based. For those who don’t like to interact with the command-line should check out Girl Unllocated’s Basic Command Prompt video since it may be a helpful tutorial. With all joking aside, the method does leverage command-line tools since they can be automated in scripts. I’ve found overtime the technique is very powerful because of the sheer number of free DFIR tools that run from the command-line.
Accessing VSCs
I just started reading Harlan’s WFA 3/e Kindle version (I’m on chapter 4 at the time of this post) and chapter 3 does an outstanding job explaining the process about accessing VSCs. From explaining what VSCs are to mounting a forensic image to creating symbolic links to VSCs to various tools for examining data inside VSCs. WFA 3/e goes into more depth than this post because I’m only providing a quick overview.
Accessing a VSC consists of identifying the VSC’s path followed by creating a symbolic link pointing to that path and the built-in Windows vssadmin command can accomplish this. The command also displays a lot more information including when each VSC was created. The command below will show the VSCs on the mounted volume with the drive letter C:
vssadmin list shadows /for=C:
The picture below shows the output from that command.
As can be seen in the screenshot, VSCs paths start with \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy and each VSC will have a unique number. For this specific volume the VSCs are numbered starting with the number 1 then increasing to 12 since there are 12 current VSCs. To access the first VSC a symbolic link needs to be created pointing to the path \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1. The built-in Windows mklink command can create the symbolic links to VSCs. I’ve only been reading WFA 3/e for a few days and the book as already made me change how I approach VSCs. Harlan was using the mklink’s /d switch to mount a VSC to a symbolic directory which means the link acts as a normal folder. I updated my scripts to use the /d switch instead of /j (creates a directory junction). The following command will create a symbolic link named vsc1 pointing to C volume’s first VSC and the picture shows the result:
mklink /d c:\vsc1 \\?\GLOBALROOT\Device\HardDiskVolumeShadowCopy1\
To access every VSC of interest means someone would have to execute the mklink command multiple times. To access all 12 VSCs on my C volume means I need to type the mklink command 12 times. After working my first case involving Windows 7 I learned pretty quickly the need to automate VSCs access. My post A Little Help with Volume Shadow Copies discussed and provided a batch script that automates creating symbolic links to VSCs. The script worked great but I have since updated it. One change was to incorporate mklink’s /d switch but the more important change is making it easier to access specific VSCs.
Automate Accessing VSCs
If you are only interested in the access-vsc script then skip ahead to the last paragraph in this section for the script’s download link. Otherwise, you can continue reading on to see what and why I changed the script. I already mentioned the significance of mklink’s /d switch so I won’t rehash it here. Just know that I did update my scripts to use this switch. The issue I encountered with my access-vsc script was the difficulty in narrowing my focus on specific VSCs that were not sequential. For example, if I wanted to identify the differences between VSC1, VSC3, and VSC6 then it was difficult due to the For loop used in the script. To show the issue I will discuss how the old For loop worked. The following was the loop in my old script (the command uses two % symbols since the command launches from a batch file):
for /l %%f in (start,step,stop) do echo %%f
Start represents the number the For loop should start at which in this case is 1 for the first VSC. Stop represents the number the loop should stop at which in this case is 6 for the last VSC. Step represents the number to increment each time the loop goes through. If the step was set to 2 then the For loop’s output looks like the following:
As shown in the screenshot setting the increment number to 2 only resulted in numbers 1, 3, and 5 when starting at 1. This means symbolic links would only be created for VSC1, VSC3, and VSC5 while missing VSC6. The only increment number that would work for automation is 1 and this was how my old script worked. Now the For loop’s output looks like the following:
The For loop now counts from 1 to 6; meaning symbolic links would be created for VSC1, VSC2, VSC3, VSC4, VSC5, and VSC6. That’s great since it provides access to the three VSCs of interest (VSC1, VSC3, and VSC6). However, there are VSCs being accessed that I didn’t want. This is only a small issue but it’s pretty significant when trying to automate comparing the differences between VSCs. To get around this issue I change the For loop so it uses numbers listed in a text file:
for /f %%f in (vscs-2-parse.txt) do echo %%f
The text file contains one number per line and in this case the numbers are 1, 3, and 6: Now the For loop’s output looks like the following:
As shown in the screenshot, the numbers count from 1 to 3 then 6. This would provide access to only the three VSCs of interest. To some this issue may seem small because I’m using small numbers. The volume I keep referencing throughout the post has 12 VSCs. If I wanted to access VSC1, VSC6, and VSC12 then the old script would create symbolic links to every VSC. This also means whatever data I want to parse through automation would get parsed in every VSC instead of the three I’m interested in. My new script provides access to only the VSCs someone wants; to see how check out the For loop below:
for /f %%f in (vscs-2-parse.txt) do mklink /d c:\vsc%%f \\?\GLOBALROOT\Device\HardDiskVolumeShadowCopy%%f\
The only difference in this For loop compared to the previous ones I showed is that the echo command was replaced by the mklink command. To access VSCs 1, 6, and 12 means the text file (vscs-2-parse.txt) should contain these numbers. The end result is having access to specific VSCs as shown below.
The cool thing about using a text file is that the same file can be leverage by other scripts to rip data inside VSCs. The access-vsc script pretty much works the same way as the old script. The only noticeable change is that it allows you to create a text file with the VSC numbers of interest (file gets dropped in the same directory as the script). The new script can be located at my blog’s Google Code site here
Ripping Data
Data can be parsed once the symbolic links pointing to VSCs are created. All that has to be done is to run a command against the data traversing through the symbolic link. For example, the Windows dir command can be executed directly against the symbolic link vsc1 to see what’s in the root directory of the VSC it’s linked to.
Continuing on with the example, the dir command can also show the files located in the Regripper folder inside VSC1.
Programs can run against VSCs’ data by going through the symbolic link. Just switch out the dir command with any other command-line program. So many days ago I switched out the dir command with Regripper. Here’s a screenshot showing Regripper parsing the Software hive’s uninstall registry key inside VSC1.
Automate Ripping Data
The previous Regripper command was only executed against the Software hive in VSC1. To process other software hives that same command needs to be ran against each VSC of interest. Examining VSCs in this manner is doable but the work is timing consuming and tedious. Not only does it take longer to execute the commands manually but typing the commands is error prone. I remember my first case working with VSCs; I was manually creating the symbolic links to VSCs and parsing registry hives. With over 15 VSCs it got old really quick; I had typos thus making the commands not work, wasted time trying to copy commands, and I learned how boring it is to type the same thing over and over. That experience is what influenced me to learn about batch scripting and the same concept applies to ripping VSCs. What option looks better: write a command once to extract information in seconds or write a command many times that takes minutes/hours to extract the same information? I bet most people would be pick door number one; that door is the main motivation to automating ripping VSCs.
One doesn’t have to be an expert in batch scripting to automate ripping VSCs using the Practitioner Method. I think all that someone needs to know is how a For loop works in a batch script. The Automate Accessing VSCs section in this post explained the For loop used in the script to create symbolic links. If you skipped that section; don’t worry and I won’t make you go back to re-read it. The important thing about the section is that the script uses a text file named vscs-2-parse.txt and the file contains a number on each line. The numbers are used to create symbolic links to each VSC. For example, the number 1 on a line results in a link named vsc1 and it points to VolumeShadowCopy1. A For loop can be written which uses the same text file to rip data inside VSCs. The simple batch script below can be used as a template:
@echo off
for /f %%f in (vscs-2-parse.txt) do (
do something against c:\vsc%%f
)
The @echo off line turns off the displaying the commands running in the batch file. The line isn’t needed but most people prefer not to display command executing. The rest of the script is just a For loop. The /f switch makes the loop work against a text file which is specified between the parenthesis (vscs-2-parse.txt). %%f will be the variable used to hold the data on each line in the text file. Quick tip: a For loop in a batch file requires two percent symbols (%%) since it strips out one symbol. However, only use one percent symbol (%) when running a For loop from the command-line. This little nuance caused me a lot of headaches when I first started working with batch files. Everything between the next set of parenthesis is the loop and will be executed until the loop reaches the last line in the text file (vscs-2-parse.txt). To rip VSCs, a program needs to be pointed to the symbolic links using the loop’s variable (%%f).
I know this may seem complicated to those who have never worked with batch files before. I swear, it just seems that way writing and reading about it. All that really has to be done is to copy the template, insert whatever program is to be executed, and save the text file with a .bat file extension. The loop below will rip the Software hive’s uninstall registry key from each link pointing to a VSC and all I did was copy the template.
@echo off
for /f %%f in (vscs-2-parse.txt) do (
rip.exe -r C:\vsc%%f\Windows\System32\config\SOFTWARE -p uninstall
)
The output from the above batch script would just be displayed on the screen. A slight change by -redirecting the output – can save the output to a text file as shown below. Just make sure that >> is used to append the output to the text file.
@echo off
for /f %%f in (vscs-2-parse.txt) do (
rip.exe -r C:\vsc%%f\Windows\System32\config\SOFTWARE -p uninstall >> C:\output.txt
)
The batch script template discussed is the foundation to ripping VSCs with the Practitioner Method and the next post will demonstrate how it can be used.
Up Next: Ripping VSCs – Practitioner Examples
Labels:
script,
volume shadow copies
Posts
Great post, Corey! Extremely useful, puts a viable solution immediately and directly into the hands of the practitioner.
Thanks. I hope that other practitioners actually use the info I'm providing and pointing to. Especially after my next post since it contains code, scripts (with documentation), and demo video. It would be unforunate if anyone looks at this and disregards the info because there is no GUI.
Hi,
Be sure I'll use it :)
Thanks for your work.
Excellent post, sir! Really great information in an easy to follow manner. Thanks for sharing. Can't wait to test this out.
Great write-up! Thanks for putting all of this together, it's very useful.
Corey. Thanks for posting your work on this. You're method is simple to employ. Thanks for sharing this.