EnScript to do Credit Card LUHN test + a little more

I was working on writing a custom EnScript for a friend and decided to make a small little LUHN validation EnScript to test the validity of a credit card. I later used the code to incorporate into the custom EnScript, but decided to post this little utility in case someone else has a use or wants to look at it for code ideas.

A LUHN validation test is a mod 10 algorithm that can test the validity of a credit card number. It does not guarantee that the number is actually a working credit card number, it just satisfies one of the major requirements in order to qualify the number as a valid credit card number. The process is explained here at wikipedia and also here is a good graphic from http://www.thetaoofmakingmoney.com/2007/04/12/324.html that illustrates the process:



The problem with just doing the LUHN test is that you will get false positive hits such as a credit card number of "6666666666666664" that passes the LUHN test, but is actually not a valid card number. EnCase has a built-in function called isValidCreditCard(). Since that function is a built-in function, there is no way to see exactly what the function is checking for, but it seems to do just a simple LUHN test as described above, because it passes the number of "6666666666666664" as being valid.

There is general table of credit card vendors located here: http://en.wikipedia.org/wiki/Credit_card_number that explains that the first few digits of a credit card number correspond to the card type (i.e. Visa, Mastercard, etc.) So using this list, I wrote the EnScript to validate the number using the LUHN algorithm, then to check this chart to see if it is assigned to a known vendor.





If the credit card number passes the LUHN test and is assigned to a known vendor according to the table discussed above, the following screen will be displayed:



Written and tested in EnCase v6.10

Download here

New version of EnCase includes stand-alone utility to capture RAM

Guidance Software has released version 6.11 of EnCase this past week. For awhile now, EnCase has had the ability to collect the RAM for the local machine that it is running on, as well as a remote machine in the Enterprise version. This was all great, but for the folks who had the Forensic version, it did not offer any realistic use, since nobody was going to load EnCase on a target machine in order to dump RAM.

The new version of EnCase (v6.11) now includes a stand-alone RAM collection tool called 'winen.exe'. This tool is installed with the standard installation of EnCase and is placed in the EnCase home folder. This tool was designed to be deployed on a flash drive or other media to a target machine and then used to collect the RAM contents before the system is shutdown. The tool collects RAM and places the collected information into an .E01 file automatically, which can then later be loaded into EnCase when doing the analysis portion of the response.

There is a 32-bit version as well as a 64-bit version located in the EnCase directory. To use, you can copy the "winen.exe" file or "winen64.exe" file to a flash drive or removable HD and then invoke at a command prompt or double click on the Windows GUI (not recommended). The tool is a console application so if it is launched in the GUI, it will spawn a command shell and then close after it completes.

No command line options are required when you run it, but by supplying some, you can skip the need to enter some information. When run with no command line options, you will need to answer six questions:

Z:\>winen.exe
Please enter a value for the option "EvidencePath":
Z:\memdump
Please enter a value for the option "EvidenceName":
ram2
Please enter a value for the option "CaseNumber":
001
Please enter a value for the option "Examiner":
Mueller
Please enter a value for the option "EvidenceNumber":
001
Please enter a value for the option "Compress":
0

The first question is a little deceiving by the wording. You must supply the path AND filename of the .e01 file you want to create. In this example, I created a file named "memdump" (.E01 is automatically added) on the Z drive. The EvidenceName option is for the name of the object inside EnCase. Once it is loaded in EnCase it will appear with that name in the Tree Pane. The rest are self-explanatory. The Compress option takes one of three values, 0=none, 1=good, 2=best.

By running "winen.exe -h" you can get a list of command line switches that let you specify all of this at the command line, making it completely automated and non-interactive for use in batch files, etc. You can also use the '-f' option to specify a text config file with these options. An example config fie is included in the EnCase home directory.

Z:\>winen.exe -h
Usage: [Options]
-p : Evidence File Path
-m : Evidence Name (Max Size:50)
-c : Case Number (Max Size:64)
-e : Examiner Name (Max Size:64)
-r : Evidence Number (Max Size:64)
-d : Compression level (0=None, 1=Fast, 2=Best) (Default: 0) (min:0 max:2)
-a : A semicolon delimated list of Alternate paths
-n : Notes (Max Size:32768)
-s : Maximum file size in mb (Default: 640) (min:1 max:10485760)
-g : Error granularity (Sectors) (Default: 1) (min:1 max:1024)
-b : Block size (Sectors) (Default: 64) (min:1 max:1024)
-f : Path to configuration file
-t: Turns off hashing the evidence file (default: true)
-h: This help message

The end result is a '.E01" file that loads into EnCase:



As far as the footprint left on the target system, the "winen.exe" program creates a service named "winen_". This obviously means that you need to have administrator privileges on the target system in order to use this tool. The program also drops a driver file named 'winen_.sys', in the directory where the program is run. Notice there is already a 'winen_.sys file' included in the EnCase home directory that you can copy and use with the winen.exe program, or when run, the program will create a new one. Take note of this, because the 'winene.exe' program creates a Windows service, this means there are changes in the registry occurring. Here is a screenshot of the service entry in the registry after running the tool on the target system:



The *downside* is that this service entry remains after the tool is run and if it is run from local media (i.e. C drive) then this service starts every time the system is rebooted.

The *upside* of this tool as it appears to dump the contents of RAM for all versions of the Windows NT platform, i.e. Windows 2000, XP, 2003 & Vista! Currently, there are very limited number of tools that can do this and most are not free!

I have not seen any "official" technical specs or details on the tool's capabilities, but the preliminary tests I have done seem to be very promising as a very useful Incident Response tool, especially if you are already an EnCase v6 user, then you just obtained a simple tool that can collect RAM on all of today's modern Windows platforms at no extra cost!

Nice job Matt! ;)