hons.un-excogitate.org

5 node Beowulf in a single chassis

Cray CTO: Linux clusters outshined by supercomputers in HPC, Part 1

Making JTR-MPI perform a wordlist attack 2

Further analysis of the wordlist.c file, especially the outer do {} while (rules) loop (around the code that was looked at earlier - see Part 1) reveals that this cracking code works as follows:

1. open the main do/while loop (lines 191 - 233)
2. open the "check-rule" if loop that will check the current rule (lines 192 - 205)
3. check the current rule for formatting, then accept or reject. This is output to the logger (lines 194 - 204)
4. close the "check-rule" if loop at section 2
5. open the "perform-crack" while loop that will iterate through every word applying the rule and attempting to crack (lines 208 - 224)
6. try to crack a password using the current rule with the current word crk_process_key(word) (line 219)
7. close the "perform-crack" while loop at section 5
8. open the "next-rule" if loop, that will check for a new rule to be used (lines 226 - 232)
9. close the "next-fule" if loop
10. close the main do/while loop

This was tested by performing a simple wordlist attack on a shadow file. The command used was: ./john --wordlist=/usr/share/dict/words --rules shadow.

By then performing a tail -f john_log.0 and seeing when another rule was announced via a "Rule #7", for example, then clicking a key on the console running the john process, you could see which rule was being used.

The plain-text versions of the rules were being pulled from the john.conf file under the [List.Rules:Wordlist] section.

Modifying jtr-1.6.36-mpi to perform distributed wordlist attacks using MPI, jtr-1.6.36-mpi-wlcmf

Modifications to the wordlist.c file are listed as below:

1.Insert appropriate headers

  #include "mpi.h"
  #include "ryan.h"
  #include <time.h>


2. Encompass the computational while loop in an if statement that checks if the word number is for this node id

  if ( ((linenumber - 1) % mpip) == (mpi_id) ) {


3. Throw in a debugging option

Within the while loop an log_event() call was issued which will print out information, but this is not recommended to be used as it will fill flood the hdd's

Testing

To test the funtionality i compiled jtr with the debugging option (by passing mpicc the -DCMF_DBG option) - then tested john running as a single node, with 2 nodes, 3 nodes and 4 nodes. The tests were performed on an AMD K6-2 550MHz x86 machine with 256 MB's of SDRAM. Even though it was tested on a single machine, MPICH can connect to itself to run.

The resulting johnlog.* files were then analysed to see which words john attempted to crack. All the tests were a success. Analysing the johnlog files numbers 0 through 3 showed that each node would only check each nth word (where n equaled 1, 2, 3, or 4 - depending on which test)

Number of Virtual Nodes	Test successful?
1	Yes
2	Yes
3	Yes
4	Yes

Making JTR-MPI perform a wordlist attack 1

To modify JTR-MPI so it is able to perform a word-list attack using multiple nodes requires a close look at the while loop (line: 205) in wordlist.c. This while loop iterates through the word_file, applying any rules it can:

word = apply(line, rule, -1)

then performing the crk_process_key() function on the word.

A possible way of parallelising this functionality would be to first check if you are the first node, if so, you don't do any processing, but instead hand out words from the word-file, if you are NOT the first node, you make calls to the first-node for word inputs. The downside to this method would be that the network traffic would be large, especially if compute nodes were not applying any rules to the words, in which case that would constantly be requesting words. With rules being applied to each word this will be slowed down.

Another possible solution is to incorporate it so each node can buffer a preset number of words, this means the granularity of the task would be increased, and hence network bottlenecks would be lessened.

Modifying jtr-1.6.37 for MPI

To apply the same changes that Lim applied to jtr-1.6.36 to make it perform its brute-force attacks in parallel using the MPI libraries required me to see the differences between the src directories of jtr-1.6.36 and jtr-1.6.36-mpi.

Using WinMerge revealed 16 files which needed to be modified, and 2 files which had to be copied. The files which needed modifications were:

• bench.c
• benc.h
• charset.c
• cracker.c
• external.c
• inc.c
• john.c
• loader.c
• logger.c
• Makefile
• misc.c
• options.c
• params.c
• recovery.c
• signals.c
• status.c

The files which needed copying were:

• ryan.c
• ryan.h

In the copy of the jtr-1.6.37 folder, jtr-1.6.37-mpicmf, the two ryan files were copied, then the other files were modified. To find which lines had to be added/edited WinMerge was used, but this time used to compare the two different source files.

Results from this new version of jtr-1.6.37 will be posted as soon as tests are performed.

FIPS 181 - (APG), Automated Password Generator

FIPS 112 - Password Usage

APG (Automated Pasword Generator)

Freedom to Tinker: SHA-1 Break Rumored

Joux found a collision for SHA-0 !

CRYPTO 2004: Main Page

NIST Computer Security DRAFT Publications - Guidelines on PDA Forensics

Submitted Conference Papers

Last night i submitted two papers to be reviewed for the 2nd Australian Computer, Network & Information Forensics Conference 2004.

The first paper i submitted was based on an analysis of the integrity of digital forensic images acquired from Palm OS PDA devices, when acquired by PDD. The technical, experimental notes from this paper are what i've been writing up over here (Day 1 Day 2 Day 3 Day 4)

The second paper was one that i had written last semester for a unit - mostly based on the analysis and reports of my pilot tests on John the Ripper on the x86 Beowulf, Igneous. (Links: pilot experiments on clustered password cracking, pilot experiment results)

Also, on the same day, finally got my printouts of my proposal out so they could be formally submitted - which is great!

Anyway, need to go to work for a bit.

10 Years of Beowulf Clustering

Passwords, 64 Characters, Changed Daily?

PDD Day 4

The fourth day (Day 1 Day 2 Day 3) of using pdd was more focused in an analysis of the images created by pdd, both RAM and ROM images. The images which were analysed were the images created when not performing a soft-reset, the images created when performing a soft-reset, and also images after the contacts and memos have been deleted from the palm.

Analysing images which were created from pdd when set to not soft-reset the device - 040803 12.20pm

Using an evaluation copy of WinHex 11.6 SR-18, the RAM files, 040803-01.out and 040803-02.out, were opened up. Going to the "View" menu, "Synchronise & Compare" was ticked, which then highlighted all the hexidecimal characters (and their equivalent ASCII characters) which were different in the files. Counting manually, there were 144 differences, some were a single character which was different, all the way up to one case where there was 512 characters which were different (where a character is 8 bits, or a byte - represented by 2 hexidecimal characters). In total there were 1013 characters(bytes) which were different between the two images.

A quick examination of the ASCII text revealed only a few of those differences which were accountable for the palm's clock. The memory range used for the palms clock went from 0x00002922 to 0x00002929, which on the first run contained the values "31 32 3A 31 34 20 70 6D" which translated to "12:14 pm" and on the second run contained the values "31 3A 30 32 20 70 6D 00" which translated to "1:02 pm".

The range from 0x000383D6 to 0x000385D5, where there was exactly 512 characters which were different, is assumed to be the dynamic heap for running applications.

Between the last change in the image, 0x000400FF, to the beginning of where no more data is kept (a repetitive string of 0x55 characters) at 0x000514C4, is where most of the readable ASCII text is stored, a quick search through this section of the image reveals some of the contacts and memos. This area of the image was roughly 70KB's.

Performing a quick search for ".com" in ASCII, in the goal of finding any URLs or emails, returned 8 positive results. One of these included the email added to the contacts (see Day 1) for Pete. Just scanning over the area between 0x000417C7 and 0x000433D1 a lot of english words are visible in the ASCII code, slowly scrolling through this section i come across the memo i made about the container ship (see Day 1).

Analysing images which were created from pdd when set to soft-reset the device - 040805 6.20pm

Firstly the palm was soft-reset (by pressing the reset button on the back) then the images were acquired one after the other, except this time with a soft-reset in between. Due to the palm being soft-reset between the acquisitions, the stylus had to be re-aligned and the console mode had to be re-initiated.

Like before, both the image files (040805-01.out and 040805-02.out) were opened up in WinHex to see the differences between the images.

Before making the 2nd image - i had to re-align the stylus - and re-enter the palm into console mode.

In total there were 310 differences between the two images, but in those 310 differences, there was only 977 characters(bytes) which were different. At first these results looked wrong, especially considering that the number of bytes which differed between the images when the palm was not soft-reset was higher, at 1013 bytes of difference.

Inspecting the range from 0x000383D6 to 0x000385D5, which was where there was exactly 512 bytes of difference in the above test, did not yield the same results. In fact, there was no change in the two images at this range, which might mean that the range is not in fact the dynamic heap, unless it's starting offset can change.

Like the above test, the clock information still resided from 0x00002922 to 0x00002929.

Analysing images after contacts and memos were deleted - 040808 1.00pm

After the palm was soft-reset, re-aligned, and entered into console mode the base image was acquired with pdd "pdd of=040808-01.out" allowing the device to be soft-reset once the acquisition was finished.

Enter console debug mode [ .. 2]

pdd process beginning.

Resetting Palm OS device.

pdd successful. Exiting.

After this image was acquired successfully, the stylus was re-aligned and then the memo and the contact (see Day 1) were deleted from the palm device. Immediately following their deletion the palm was put into console mode and then an image was acquired for the second time "pdd of=040808-02.out". The palm once again was soft-reset by pdd automatically.

Enter console debug mode [ .. 2]

pdd process beginning.

Resetting Palm OS device.

pdd successful. Exiting.

To test if a soft-reset on the palm would wipe the deleted information, the palm was acquired for a third time after the stylus was re-aligned and the palm was put into console mode - "pdd of=040808-03.out".

Enter console debug mode [ .. 2]

pdd process beginning.

Resetting Palm OS device.

pdd successful. Exiting.

To test if a hard-reset on the palm would wipe the deleted information, the palm was acquired for a fourth time, after the device was hard reset (holding down the power button whilst pressing the reset button), the stylus re-aligned and the palm put into console mode - "pdd of=040808-04.out".

Enter console debug mode [ .. 2]

pdd process beginning.

Resetting Palm OS device.

pdd successful. Exiting.

1. Searching for information immediately after deletion

Using a hexeditor to perform ASCII searches of the 040808-02.out image showed that the contact details for Pete were still available within the image. This included the mobile number, the email and his full name.

Performing a search for "December" also showed that the memo that was made was also still available within the image.

These results showed that similar to regular file-systems, which don't actually delete the information but the links to the information, the palm os doesn't delete information when it is deleted. Under the assumption that the way data is stored on a palm device is similar to that of desktop filesystems it is also safe to assume that after sufficient use of the palm device, this unallocated space would eventually be over-written.

2. Searching for information immediately after deletion and a soft-reset

Using a hexeditor to perform ASCII searches of the 040808-03.out image did not reveal the contact information or the memo that was used to exist on the palm. Using the successful searches from earlier to find where the information used to be stored on the palm did not help either. From this you can assume that even though a soft-reset doesn't wipe the RAM on the palm, it does re-set (almost like a defrag) the RAM image.

3. Searching for information immediately after deletion, a soft-reset then a hard-reset

Using a hexeditor to perform ASCII searches of the 040808-04.out image did not reveal any of the information that was deleted. This was the expected result for this test as the hard-reset wipes the RAM of the device.

PDD Day 3

The 3rd day (Day 1 Day 2) of analysing pdd will be focusing on modifying pdd to not soft-reset the device, and also a look at PDA-Seizure, from Paraben Computer Forensic Software.

Modifying the pdd source, offering a chance to NOT soft-reset the palm after a successful acquisition - Process - 040802 10am

The 3 files i had to modify were main.c, pdd.h and pdd.c

Idea

The modifications to pdd.exe would allow an additional argument to be passed to the executable, allowing the option of NOT soft-resetting the palm device at the end of the acquisition. This argument would be passed like any of the other arguments that pdd.exe can take - when performing a pdd -h returns:

Joe Grand [jgrand@mindspring.com], June 2002 v1.11

NAME
        pdd - Memory imaging tool for forensic analysis of Palm OS
        platform devices

USAGE
        pdd  [ operand=value ... ]

        Place the Palm device in the cradle or attach to a HotSync
        cable connected to a serial port on the desktop PC. The Palm
        OS Console Mode must be enabled.

OPERANDS
        if=value     : name of serial communications port [default = COM1]
        of=value     : name of output file [default = standard output]
        card=n       : Palm card number [default = 0 for built-in card]
        type=value   : Palm card memory type; RAM or ROM [default = RAM]
        -? or -h     : help [you're reading it]

So, the new argument would be in the format of reset=value, where value could either be yes or no (the default being yes - as in the original un-modified program)

File: main.c

The first change to the main.c file would be to add a variable declaration at the beginning of the main() function

After unsigned char of[FILENAME_MAX]; a new line was added:

unsigned char reset[FILENAME_MAX];

The 2nd change would be to set the default argument to the reset variable

after the line type = RAM; a new line was added:

strcpy (reset, "");

This set the reset value to be empty, which is the default value.

The 3rd change would be to add a check, in case the only argument was a reset=value argument

After strstr (argv[1], "type=") == NULL && a new line was added:

strstr (argv[1], "reset=") == NULL &&

This made sure that if pdd.exe was passed NO arguments, the usage() function would be called.

The 4th change would be to ensure that the argument was accepted by pdd.exe

After the else if ((delim = strstr(argv[c], "type=")) != NULL) /* memory type */ block of code, a new else if block was added:

else if ((delim = strstr(argv[c], "reset=")) != NULL) /* soft reset */
    {
        param = delim + 6;
        if (*param) strncpy (reset, param, FILENAME_MAX-1);
        else
            usage(argv[0]);
    }

This new block of code checked for the reset= argument (ie: != NULL) and then copied the value into the reset variable, which would later be passed to the pdd() call.

The 5th change was to add the new reset variable to the pdd() call

pdd (port, of, card, type);

Was changed to:

pdd (port, of, card, type, reset);

The 6th and final modification to main.c was in the help() function, to add the text output describing the new argument

After the fprintf(stderr, "\n\ttype=value : Palm card memory type; RAM or ROM [default = RAM]"); line, the following line was added:

fprintf(stderr, "\n\treset=value  : Soft-reset the palm; yes or no [default = yes]");

File: pdd.c

The 1st modification to pdd.c was to change the function definition of the pdd() function from:

void pdd (char* port, char* of, unsigned short cardNo, MemoryType memtype)

To:

void pdd (char* port, char* of, unsigned short cardNo, MemoryType memtype, char* reset)

The 2nd and final change to pdd.c would be to enclose the pdd_SysReset() call within an if block, which checks for the reset parameter, and if it equals 'no' then the pdd_SysReset() function call would not be called.

Instead of:

pdd_SysReset();

The code was changed to:

if ((*reset) && (!strcmp(reset,"no")))
{
    fprintf(stderr, "\nNOT Resetting Palm OS Device.\n");
} else {
    pdd_SysReset();
}

File: pdd.h

The only change to this file was adding the reset parameter to the pdd() function definition, so:

void    pdd (char* port, char* filename, unsigned short cardNo, MemoryType memtype);

Was changed to:

void    pdd (char* port, char* filename, unsigned short cardNo, MemoryType memtype, char* reset);

Using the modified pdd to perform 2 acquisitions, one after the other, without having to perform any activity on the palm in between - Process - 040803 12pm

Firstly the palm was soft-reset (by using a paperclip with the reset button on the back), then placed on the cradle and turned on - The "Stay on in Cradle" option was verified to be enabled, then on the desktop a new folder called pdd2 was created, with the new modified version of pdd.exe. On the desktop we used a cmd.exe to "cd pdd2" and then performed a "pdd of=040803-01.out reset=no" - which resulted in:

Enter console debug mode [<shortcut> .. 2]

I performed the shortcut on the palm, then the desktop responded:

pdd process beginning.

This process completed successfully, the desktop returning:

NOT Resetting Palm OS Device.

pdd successful. Exiting.

After this I immediately typed into the desktop "pdd of=040803-02.out reset=no", which started the pdd acquisition again:

Enter console debug mode [<shortcut> .. 2]

pdd process beginning.

This acquisition also completed successfully:

NOT Resetting Palm OS Device.

pdd successful. Exiting.

The two files, 040803-01.out and 040803-02.out are compared below:

040803-01.out ; size = 8,388,608 bytes ; md5 = 7d3b5880559db8712cbd870a9ffc12c2

040803-02.out ; size = 8,388,608 bytes ; md5 = 2dc8e755df721ef4d383e39c702919a6

From this we can determine that even though the palm device is not being soft-reset by pdd, the image files are still changing. This is most likely because the palm cannot be put into a read-only mode, or a halted mode - one of the changes occuring within the system would be some sort of clock function (at least).

A quick look at PDA Seizure (Demo) - Process - 040803 2.30pm

PDA Seizure, version 3.0.0.15, was installed on the desktop with no problems, once the program was started it reported that it was running as a DEMO version and was limited in the following ways:

• Generate Report is disabled
• Load is disabled
• Memory acquisition is limited to 4,000,000 bytes
• File acquisition is limited to 75 files

(Screengrab)

To perform an acquisition you simply click on the "Acquire" button, which opens up the "PDA Seizure Acquisition" Wizard dialogue. You have a choice of:

• Palm OS Devices
• Windows CE/Pocket PC Devices
• RIM Blackberry Devices

The options for palm acquisition are quite extensive, including options to Acquire Memory or just Acquire Files, an option to disable the soft-reset and an option to decode the password (for palm os < 4.0) (Screengrab)

Unfortunately because this version was only a demo it could only acquire images which were smaller than 4MB's, which meant that only half the RAM of our palm could be acquired properly - To see what files and images were acquired PDA Seizure was set to Acquire Memory and Acquire Files.

The next screen advises the user on how to place the palm device into console mode, this is followed by a screen showing options for which memory (and cards) to acquire from - for this demonstration i only selected the RAM image.

The software provided a nice clear progress dialog (Screengrab)

After the acquisition had been completed, the device reset itself - and the desktop was waiting for me to press the sync button on the cradle - after i did, PDA Seizure began downloading the individual databases from the palm to the software (Screengrab)

At the end of the file acquisition process PDA Seizure crashed and wouldn't restart again. After a restart of the desktop, the software restarted successfully.

The process was started as above and like above - crashed, except this time at the completion of only the acquisition, not the collection of files.

The process was tried one more time, this time just an acquisition of the files, not the RAM (as this works successfully using pdd) - but once again the software crashed.

This issue could be because the software was running as a demo, and further testing will be required using a fully licensed copy.

PDD Day 2

This is the writeup for my continued analysis of PDD (see PDD Day 1 here for the first part).

First step, to perform 2 successful acquisitions - one immediately after the other - hopefully the only changes to the palm will be pdd's automatic soft-reset, a re-alignment of the stylus and the input of the [(shortcut) . . 2] to enable console mode.

Attempting to perform 2 acquisitions one after the other, minimising activity on the palm in between - Process - 040801 11.44am

Placed the palm on the cradle, turned on the device, and ensured that "Stay on in Cradle" was still enabled.

Opened up a cmd.exe terminal, and changed to the "pdd" directory.

Executed: pdd of=040801.out

The terminal then reported:

Enter console debug mode [<shortcut> .. 2]

I then input the command into the palm, the terminal then reported:

pdd process beginning.

This first attempt failed, the terminal reporting a:

CRC-16 Checksum invalid.

Because this did not occur in between the 2 acquisition tests, we restarted the test, outputing to 040801-2.out. This test ran successfully:

Resetting Palm OS device.

pdd successful. Exiting.

After the palm reset - i realigned the stylus, and then executed "pdd of=040801-3.out" on the desktop, which required me once again to put the palm into console mode:

Enter console debug mode [<shortcut> .. 2]

pdd process beginning.

This 3rd test ran successfully:

Resetting Palm OS device.

pdd successful. Exiting.

These two final tests then had been performed successfully, one after the other, with a minimal amount of interference between each one:

• PDD's automatic soft-reset of the device
• Re-aligning of the stylus
• Putting the palm into console mode

The two files, 040801-2.out 040801-3.out are compared below:

040801-2.out ; size = 8,388,608 bytes ; md5 = f79b6c2a2038d967d8b6de6f1165955c

040801-3.out ; size = 8,388,608 bytes ; md5 = fd9f99ae611f0528fb18be30005479af

Once again, like the first round of tests, these 2 images have been modified in between the 2 acquisitions, even though none of the actual data entries have been modified (the contacts or memos or calendar etc) the process of the soft-reset, the realignment of the stylus, and the entering into console mode has changed the image slightly.

Performing an acquisition of the ROM from the palm - Process - 040801 3pm

This was another test of the pdd application, to successfully download the ROM image of the palm device (not the RAM image, which is what i've been doing up until now) - with this ROM image, it should be possible to load up a Palm Emulator on the desktop with this ROM to make a logical palm on the computer, with the exact same OS as that on the device itself (though without any of the data on the palm - as this is in the RAM image, not the ROM image)

With the palm and the desktop still connected, in a cmd.exe the following was executed

pdd of=040801rom.out type=ROM

This required the re-entering of the console mode:

Enter console debug mode [<shortcut> .. 2]

pdd process beginning.

This completed successfully:

Resetting Palm OS device.

pdd successful. Exiting.

After installing the Palm OS Emulator version 3.5, i executed it on the desktop and loaded the 040801rom.out file successfully. view screengrab