hons.un-excogitate.org/category/technical

Fixing Obsidians Network Problem

Came in on monday the 27th to find that a lot of the cluster seemed to be messed up.

The workstations couldn't ping the frontend-0, frontend-0 didn't appear to have it's routing or network addresses working appropriately.

Fix:

• halt all the machines
  From frontend-0: "cluster-fork halt -t now"
• fix the frontend-0 network
  From frontend-0: modified the /etc/sysconfig/network-scripts/ifcfg-eth1
  replacing the DHCPD option with a static IP option
  New network settings:
  IP: 172.16.2.240
  Netmask: 255.255.0.0
  This also automatically fixed the "route"ing tables, now any 172.16.x.x traffic was going through eth1
• reboot the comp-pvfs nodes
• to aid in daniel's quest, i then turned dhcpd off - which was giving him dramas. (After resetting frontend-0 DHCPD will be started again

*nb: the dhcpd.conf on frontend-0 doesn't actually give out IP's - only to nodes that were assimilated via "insert-ethers" - which meant that machines requesting IP's from frontend-0 were hanging.

Even though i considered modifying the frontend-0's dhcpd.conf to allow it to give out IP's - because the file is automatically updated via "insert-ethers" - i thought it better not to touch it.

Creating non-pronouncable passwords with APG

Number of passwords: 80
Length of passwords: 7-14 (8 groups of passwords)
Therefore, there are 10 passwords of each length.

To create the passwords:

./apg -a 1 -n 10 -m 7 -x 7 > apg07.txt
./apg -a 1 -n 10 -m 8 -x 8 > apg08.txt
./apg -a 1 -n 10 -m 9 -x 9 > apg09.txt
./apg -a 1 -n 10 -m 10 -x 10 > apg10.txt
./apg -a 1 -n 10 -m 11 -x 11 > apg11.txt
./apg -a 1 -n 10 -m 12 -x 12 > apg12.txt
./apg -a 1 -n 10 -m 13 -x 13 > apg13.txt
./apg -a 1 -n 10 -m 14 -x 14 > apg14.txt

Then:

cat apg0*.txt > apg-nonpron-passlist.txt

A bashfile was used to automate this task - see netsec01:/home/xian/apg-2.2.3/gen-nonpron-passlist.sh

Creating pronouncable password with APG

Number of passwords: 80
Length of passwords: 7-14 (8 groups of passwords)
Therefore, there are 10 passwords of each length.

To create the passwords:

./apg -n 10 -m 7 -x 7 > apg07.txt
./apg -n 10 -m 8 -x 8 > apg08.txt
./apg -n 10 -m 9 -x 9 > apg09.txt
./apg -n 10 -m 10 -x 10 > apg10.txt
./apg -n 10 -m 11-x 11 > apg11.txt
./apg -n 10 -m 12 -x 12 > apg12.txt
./apg -n 10 -m 13 -x 13 > apg13.txt
./apg -n 10 -m 14 -x 14 > apg14.txt

Then:

cat apg0*.txt > apg-pron-passlist.txt

A bashfile was used to automate this task - see netsec01:/home/xian/apg-2.2.3/gen-pron-passlist.sh

Configuring PVFS on Obsidian

following instructions from the appendix in http://www.scalablesys.com/training/1-4-RocksAdmin.swf

1. ensure /pvfs-meta exists

2. on frontend run "mkmgrconf"

   The inputs i used:
   /pvfs-meta
   root
   root
   777
   frontend-0
   3000
   comp-pvfs-0-0, comp-pvfs-0-1, comp-pvfs-0-2, comp-pvfs-0-3, comp-pvfs-0-4
   7000

3. on the frontend run "/etc/init.d/mgr restart"

   This spat out errors:

   Stopping PVFS daemon: FAILED
   Starting PVFS daemon: Coult not setup device /dev/pvfsd
   (pvfsd.c, 684): Did you remember to load the pvfs module?
   (pvfsd.c, 453): pvfsd: setup_pvfsdev() failed

   I then ran "/sbin/lsmod" and there was no pvfs module so i attempted "/sbin/insmod pvfs"

   This spat out the same errors as before

   BUT - performing a "ps aux |grep mgr" revealed that a /usr/sbin/mgr process was indeed running

4. According to https://lists.sdsc.edu/pipermail/npaci-rocks-discussion/2004-January/004195.html it looks like there are issues with the PVFS kernel module and the Opterons running rocks 3.1<

An attempt at using Sun's Grid Engine (SGE) for job submission

This was a test to see if i could get john-1.6.37-mpiwlcmf2 to execute via the Sun Grid Engine (SGE) job management system.

...

I played with the various methods of submitting a job, but had no luck. I believe that the default queues and pools are not configured correctly in our installation of rocks, meaning that when jobs are submitted, they will wait indefinately until an available slot or spot becomes available - meaning that submitted jobs will just hang.

Running jtr-1.6.37-mpiwlcmf2 on LM passwords with a large wordlist

Instead of using the default password.lst file (as before) i used wordlist files from www.openwall.com

The two main password files were all.lst and mangled.lst

/passwd_cd/all.lst - 3,917,193 lines
This file has the following wordlists inside:

• passwords/password.lst
• passwords/languages/*

/passwd_cd/mangled.lst - 40,532,676 lines
This file has the following wordlists put through word-mangling rules:

• passwords/password.lst
• passwords/lower.lst
• languages/English/1-tiny/lower.lst
• languages/English/1-tiny/cap.lst
• languages/English/2-small/lower.lst
• languages/English/2-small/cap.lst
• languages/English/2-small/alnum.lst
• languages/English/2-small/mixed.lst
• languages/German/1-small/lower.lst
• languages/German/1-small/cap.lst
• languages/French/lower.lst
• languages/Danish/1-small/lower.lst
• languages/Dutch/1-clean/lower.lst
• languages/Italian/1-small/lower.lst
• languages/English/3-large/lower.lst
• languages/English/3-large/cap.lst
• languages/English/3-large/alnum.lst
• languages/English/3-large/acronym.lst
• then at the bottom all unique words from all.lst are included as well.

First test - using the all.lst file with rules turned off.
This test completed in 1 second, cracking the following username/plaintext:
test45:2 PENDENC
test50:1 NOITAMR
test15:1 TNEMERC

Each of these passwords was actually cracked twice! - As the 2 processors where both finding the first 7 characters of words which were in fact larger reoccuring, example:
pendencies and pendency
so node 0 would get PENDEC from pendencies and node 1 would get PENDEC from pendency

This does highlight that it might be useful for LM hashes to truncate these wordlists down to 7 characters long, and remove any duplicates

Second test - using the all.lst file with rules turned on.
This test completed in 37 seconds, cracking the following username/plaintext:
test45:2 PENDENC*
test50:1 NOITAMR*
test15:1 TNEMERC*
test40:1 SNOISSE*
test40:2 RPXEBUS
test35:1 SLAUGH7
test50:2 OFSNART

Passwords marked with a * were cracked twice - similar to what happened in the first test.

Third test - using the mangled.lst file with rules turned off.
This test completed in 13 seconds, cracking the following username/plaintext:
test50:1 NOITAMR*
test15:1 TNEMERC*
test45:2 PENDENC*
test40:1 SNOISSE*
test50:2 OFSNART*

Passwords marked with a * were cracked twice - similar to what happened above.

Running jtr-1.6.37-mpiwlcmf2 on LM passwords with a basic wordlist

Using the default password.lst file i attempted to run a crack against the Samba/LM password file created for last semesters work.

This test was once again performed on a single obsidian node (comp-pvfs-0-3) - the command was executed:

 mpirun -np 2 -nolocal -machinefile ~/machines2 ./john --wordlist=password.lst --rules smbpasswd

Initially i believed there were problems as the program appeared to quit almost immediately after pressing enter. Both the *.log and *.pot files had no entries for successful cracks, so i assumed something was broken.

To test this, i created a new smbpasswd file which had passwords based (or copied) from the password.lst wordfile.. i then executed:

 mpirun -np 2 -nolocal -machinefile ~/machines ./john --wordlist=password.lst --rules smbpasswd-test

Within 1 second all of the passwords were cracked...

I then realised that attempting to run a pure wordlist attack using the password.lst file against the initial smbpasswd file would in fact not crack any of the passwords successfully at all - and the reason the program appeared to quit for no reason was because it had actually successfully attempted to crack every word within the password.lst file (and 57 various permutations of each word) and had finished without a successful hit!

Mental note: A single opteron processor can crack ~ 4,128,614 LMhashes per second - so a wordlist file with 2290 lines is nothing.

Testing jtr-1.6.37-mpiwlcmf2's wordlist attack

After making the mods to jtr-1.6.37 to allow for wordlist attacks (john-1.6.37-mpiwlcmf2 .. see here) i had to test that it was in-fact working.

The initial tests were performed on a sindle node (with 2 processors) - comp-pvfs-0-3 of the obsidian cluster. This was performed by:

mpirun -np 2 -nolocal -machinefile ~/machines2 ./john --wordlist=password.lst --rules shadow

Where machines2 had a single entry:
comp-pvfs-0-3:2

Unfortunately, because no passwords were actually being cracked (due to the password.lst wordfile being insufficient, and the shadow file not containing simple enough passwords) - the test was re-run, this time the code had been compiled with the -D__CMF_DBG__ flag, which enabled extra output to be generated by john into the log files for each process.

Once again, the command was run - but after running for a few minutes was manually cancelled. Analysing the log files generated by each process, john_log.0 and john_log.1, showed that each node was in fact cracking alternate words from the password.lst wordfile.

Modifying jtr-1.6.37-mpi2 to perform Wordlist Attacks

After the successful modification of jtr-1.6.37 to jtr-1.6.37-mpicmf2, the next step was to repeat what was performed earlier on jtr-1.6.36 (see: Making JTR-MPI perform a wordlist attack 2) to make it perform wordlist attacks.

These modifications where made to the wordlist.c file, including adding the following header information

    #include "mpi.h"
    #include "ryan.h"

Then the addition of the additional if around the computational work, similar to before

      if ( ((line_number - 1) %mpi_p) == (mpi_id) ) {
      ..
      }

Voila

Modifying and Testing jtr-1.6.37 for MPI 2

After my initial test failed i had to re-try to get Lim's MPI mod of john-1.6.36 to work for john-1.6.37.

Instead of trying to apply the changes made by Lim to john-1.6.37 - i tried to apply the changes between john-1.6.36 and john-1.6.37 to john-1.6.36-mpi to give me john-1.6.37-mpi (it will be from here on called john-1.6.37-mpicmf2 as it's the 2nd trial and the mod is done by me)

This was performed as follows:

1) Set up the main working directory "john-1.6.37-mpicmf2/"
2) Copy the folder "john-1.6.36/" into "john-1.6.37-mpicmf2/" to give "john-1.6.37-mpicmf2/john-1.6.36/"
3) Copy the folder "john-1.6.37/" into "john-1.6.37-mpicmf2/" to give "john-1.6.37-mpicmf2/john-1.6.37/"
4) Copy the folder "john-1.6.36-mpi" as a new folder into "john-1.6.37-mpicmf2" to give "john-1.6.37-mpicmf2/john-1.6.37-mpicmf2/"

5) Run a comparison between:
"john-1.6.37-mpicmf2/john-1.6.36/src/"
and
"john-1.6.37-mpicmf2/john-1.6.37/src/"

6) Apply the differences between these two directories to the files in:
"john-1.6.37-mpicmf2/john-1.6.37-mpicmf2/src/"

The list of files that needed modifying is as follows:

To test this implementation worked correctly this new folder "john-1.6.37-mpicm2" was copied to the head node of the Obsidian cluster, compiled, then ran.

Due to only 3 of the nodes being available, the test was only able to run on 6 (3x2) processors, to ensure the correct nodes/processors were used the machinefile was modified to look like:

comp-pvfs-0-0:2   
comp-pvfs-0-1:2   
etc

The command to start the test was:

mpirun -np 6 -nolocal -machinefile ~/machines ./john --incremental passwordfile

To test that the processors had started up a brief examination of the john_log.* files revealed that the 6 individual running processes had started - and were cracking away.

Testing jtr-1.6.37 mpi mod

After finishing the work as detailed here - i ran some brief tests.

Unfortunately, even after compiling without errors, the program would suffer segfaults - Which lead me to my second attempt.

See here for the second trial.

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)

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.

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

PDD Day 1

Briefly, an analysis of the pdd (palm data dump) from a Palm (From here on called palm) Vx running Palm OS 3.5.3 (ID: 10GK12D067AM-J) to a MS Windows XP SP1 platform (from here on called the desktop).

PDD version 1.11 was used for this test.

Process - 040729 - 8.15pm

Hard reset the palm by holding down the on/off button and using a paperclip to press the reset button on the back.

Realigned the screen.

Installed Palm's HotSync manager version 4.1.0 on the desktop.

Synced the palm with the desktop (This is after successfully creating the "christian" user in the hotsync manager program - this processed required the palm to be reset - which was followed by a complete hard reset - same as above)

Opened the Palm Desktop software (version 4.1.4) on the desktop, and proceeded to create a memo:

Container ship 7KU arriving 8pm december 12 2004 costing per unit $500

(This memo was filed under Personal)

Proceeded to create a new contact:
Last Name: Wolski
First Name: Pete
Company:
Title:
Contact info
Work: 0401234567
Email: wolksi@hotmail.com

The contact was filed under Personal

Closed down the Palm Desktop - and performed another sync between the palm and the desktop.

I then verified the memo and the contact on the palm device.

On the desktop, a folder "pdd" was created - the pdd.exe was copied to this folder.

Using windows cmd.exe - i changed to the pdd directory "cd pdd".

On the palm, i modifed the settings so the device would not power down during data acquisition - this was done by going to "preferences" then "general" and ticking the "Stay on in Cradle" option.

Output from pdd was stored in a file called 040729.out - the command executed was:

pdd of=040729.out

Initially an "Error opening COM1" occured - after quiting the HotSync Manager and retyping the command the desktop reported that I should "Enter console debug mode [(shortcut) .. 2]" - this is to enter the palm into console mode - which allows backdoor access to a lot of the palms functions, usually used for debugging code on palms.

On the palm i used the stylus to draw the shortcut symbol, 2 dots and then finally a 2

The desktop then reported "pdd process beginning." This acquisition process went from 8.31:25pm til 9.13:50pm. After successfully finishing the palm reported:

Resetting Palm OS device.

pdd successful. Exiting.

The resulting output file, 040729.out, which was 8,388,608 byte had the following md5sum bce4942d9cd6cd37b7103adedf0c902f

To allow further tests, required me to re-align the stylus by entering into the preferences - digitisor menu - and then i had to also re-do the Shortcut . . 2 - on the input to allow the console mode.

To test whether the reset performed by pdd did in fact modify the RAM I performed the command again - pdd had the following output after writing 7,989,760 bytes of the file to 040729-2.out

pdd process beginning.

CRC-16 Checksum invalid.

Trying immediately again a 3rd time. (Because the 2nd run failed - the console mode was already activated - and therefore did not have to be manually started)

The third run completed successfully, including a soft-reset of the palm, and the file, 040729-3.out, which was 8,388,608 bytes created the following MD5 hash ba1b607dcb90486823caa0c22f4d60db

The hash of 040729.out and 040729-3.out are different, which would imply that some of the image was in fact modified between the end of the pdd acquisition and the beginning of the 3rd run of acquisition. Possible causes of modification to the palms system:

• Some sort of errors recording during the failed 2nd run
• The soft-reset automatically performed by PDD at the end of a successful acquisition
• Because of me having to manually re-align the stylus on the palm after the 1st successful acquisition (without performing this step - it's not possible to put the palm into the console mode - as this can only be enabled via graffiti on the palm)

Next steps?

• Try and perform 2 acquisitions one after the other - without a failed attempt, and see if the steps in the middle can be minimised? (possibly without having to re-align the stylus?)
• Attempt a pdd acquisition of the ROM
• Explore the code of pdd - to see if the soft-reset can be disabled
• If not, attempt to use PDA Seizure
• Begin analysis of the images.

igneous is complete

At the end of last week the 32-bit cluster, igneous, was completed. Initially my supervisor setup the 10-12 node cluster using Rocks 3.1.0 .. but after mis-trials of the Linpack benchmarking software they decided to try the beta version 3.2.0 .. unfortunately this could not successfully setup the nodes, so the system once again fell back to version 3.1.0

Hardware Specs:
At the moment there is 10 nodes (which will be expanded to 12 i believe)
Each node is configured with a PIII 866MHz Processor, with 256MB's of RAM, 100Mbps NIC, and a 20GB IDE HDD.
On top of this is the head-node which is configured with a PIII 866MHz Processor, 512MB of RAM, 100Mbps, and a 33GB SCSI HDD.

Each node is housed in a stock desktop case, which have been stacked on a table in the corner of a lab.

The LAN between the nodes and the head-node is a via a Bay Networks 10/100 Managed Switch.

The distribution in more detail is the Rocks cluster distribution, version 3.1.0

A Peek Inside JtR

MD5 related files: MD5_std.h MD5_std.c MD5_fmt.c formats.h formats.c
As mentioned yesturday, MD5_std.c contains all the code that is necessary to perform MD5 password checks, and the MD5_body() function is seen to be a direct copy (to some extent) of the MD5 algorithm as set out by RFC1321. This method itself receives multiple calls from within the MD5_std_crypt() function.

To allow for JtR to use different encryption algorithm's the use of formats.h describes a structure which allows the specific algorithm to store various descriptive elements as well as the links to the various functions, such as functions for initialisation, cyphertext checks, splitting functions, conversion functions, hashing functions, the actual crypt task, and comparison functions. This makes a lot of sense when viewing the fmt_MD5 struct as defined in MD5_fmt.c.

Apart from this structure this file also reveals important information about the algorithm such as the maximum length of plain-text passwords (15), the length of cyphertext (22), and the sizes of both the binary cyphertext in bytes (4) and the size of internal salt representations in bytes (8).

Returning back to the formats.h, this fmt_main structure is used by john.c itself as a way of registering all of the different algorithms at it's disposal, which would therefore imply that adding new algorithms is quite simple, as long as it conforms to the structures laid out by formats.h

Technical Content

Technical entries will go here (especially those with lots of code)