July 31, 2004
July 29, 2004
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.
July 28, 2004
pilot experiment results
after finishing my initial pilot test (read: Pilot Experiments on Clustered Password Cracking) i compiled a report/assignment/paper for my supervisor, beneath is a copy of the report from the method until the end..
RESEARCH METHOD
Hardware Configuration
Two separate hardware configurations were used for the experiments. Both of these configurations were trying to bring the effect of different hardware to a minimum. The basis of the setup relied on x86 Intel based processors, inter-connected with 100Mbps networking hardware.
The Beowulf configuration used for testing John the Ripper-MPI was comprised of 13 nodes. One of the 13 nodes was used as the head-node and did not perform any of the work, but was required in the configuration as all the program and data files were hosted on this machine.
Beowulf Node Configuration:
Processor Make: Intel Pentium III
Processor Clock Speed: 866MHz
Motherboard:
Memory: 256MB SDRAM
Hard Drive: 20GB IDE
Network: 100Mbps
The head-node was configured with an extra 128MB of memory, providing it with 384MB of SDRAM, and also a faster disk drive .
The nodes were inter-connected with a Baystack 10/100 24 port managed switch.
Combining the processor speed and memory of the 12 compute-nodes resulted in a Beowulf cluster which had approximately 10.4GHz clock speed, and 3GB of memory.
The OpenMosix configuration used for testing Cisilia was comprised of 14 nodes, a head-node, 6 compute-nodes with hard drives and 7 compute-nodes without hard drives. Even though there was a head-node, computational work was still performed on this machine as well.
OpenMosix Node Configuration:
Processor Make: Intel Pentium III
Processor Clock Speed: 733MHz
Motherboard:
Memory: 256MB SDRAM
Hard Drive: 20GB IDE
Network: 100Mbps
The disk-less nodes had the same configuration, just without the 20GB hard drive.
Combining the processor speed and memory of the 14 nodes resulted in an OpenMosix cluster which had approximately 10.3GHz clock speed, and 3.5GB of memory.
Software Configuration
Two different software configurations were used for the experiments. Both of these relied on the use of the Linux operating system, not just because that is what the software was designed on, but also because the separate clustering-systems, Beowulf and OpenMosix, relied on the use of Linux.
The Beowulf clusters operating system was built using the Rocks Cluster distribution (NPACI Rocks, 2004) version 3.1.0 which is based on top of the Red Hat Enterprise Linux 3 Advanced Workstation distribution. The software installation allowed the setup of the head-node, followed by a network boot and auto configuration of the remaining 12 compute-nodes. The kernel version of the system was 2.4.21, compiled for i686.
The research used a modified version of John the Ripper called John the Ripper-MPI (JtR-MPI) (Lim, 2004) and Cisilia to perform its tests because both utilities perform brute-force attacks, both can crack Microsoft Windows LAN Manager or Samba based passwords, and both can perform these attacks using a cluster of computers. One of the differences between the two utilities and their style of breaking passwords is their parallel paradigm. JtR-MPI is designed specifically to use message passing between computers to run in a parallel way. Cisilia uses a different method of parallelisation, it is designed to spawn multiple copies of itself, which when run on a load-balancing cluster will split the load between computers and therefore run in a parallel way.
The version of JtR-MPI used was 1.6.36-mpi which is John the Ripper version 1.6.36 which has been modified to work in a Beowulf environment using MPICH for inter-node communication.
MPICH version 1.2.5.2 was used for both the compilation and the execution of JtR-MPI.
SSH version 3.7.1 was used to start the individual JtR-MPI processes on each of the nodes in the Beowulf cluster.
The OpenMosix clusters operating system was built using CHAOS version 1.2 (FIAT & Gobbledok, 2004) on the compute-nodes, and ClusterKnoppix (Vandersmissen, 2003) version 3.3-2003-11-19 on the head-node. The software installation allowed the setup of the head-node and compute-nodes from live CDs, which meant that the operating-system ran entirely off RAM disks and CD-ROMs. The kernel version of the system was 2.4.22-openmosix-2, compiled for i386.
Cisilia version 0.7.3 was used for the tests on the OpenMosix cluster.
Password samples
To test a common set of passwords required the use of a password format that both Cisilia and JtR-MPI could crack. The only matching password format was Microsoft’s LAN Manager (LANMAN) or Samba based passwords. The algorithm used to create these passwords has been proven to be quite weak, and is only being used for backwards compatibility with older Microsoft operating systems (Shaffer, 2004). LANMAN passwords are created by:
- Converting all alphabetic characters to their uppercase equivalent
- Truncating or padding the password to 14 characters (bytes)
- Splitting the password into two 7 character (byte) halves
- Using each 7 character half as a key to encrypt a known string using the DES encryption algorithm
- The two cipher-texts are then concatenated and stored on file
To test the two cracking utilities the password samples had to represent the broad spectrum of passwords from weak to strong. To create random passwords that represented this spectrum required the use of a method to create and determine a password and its strength.
The method used to create the password samples was taken from a system previously implemented in IBM’s Lotus Notes and Domino (2004) software. Williams’ (2001) article on the algorithms used to determine a passwords quality was used as the guidelines for creating passwords which had a rating from 5 to 14. Some of the factors of the algorithm include the passwords strength, its fallibility to dictionary-attacks and if it contains one or more mixed-case, numeric or punctuation characters. Some example rules for a password of quality eight (8) might include:
- A password that contains at least six (6) characters and includes at least two (2) number, mixed-case or punctuation character
- A password that contains at least seven (7) characters and includes at least one (1) number and one (1) mixed-case character
- A password that contains at least eight (8) characters and does not include words from the dictionary
Tests Performed
The first test was performed by JtR-MPI on the Beowulf cluster. A maximum time was set to 3 days to ensure that the results from all the tests could be compared, and also to ensure that the tests could be finished on time. The results collected from this test included:
- Half the cipher-text password
- Half the plain-text, cracked password
- The username
- A digit representing which half of the password was cracked (a 1 or 2)
- A time in the format D:HH:MM:SS
Following this first test, a second test was performed with the same configuration. This test was used to measure the reliability of the utility.
The third test was performed by Cisilia on the OpenMosix cluster. Similar to the JtR-MPI tests, results which took longer than 3 days were discarded. Cisilia was configured to return results which contained:
- A time in the format HH:MM:SS.SS
- The username
- The plain-text, cracked password
During all the tests, no other processor-intensive tasks were being performed on the nodes. For the full 3 day period the only processes running on the clusters, apart from operating-system tasks, were the cracking utilities.
RESULTS
Initial results from the JtR-MPI tests looked to be very impressive, with the cracking tool reporting 22 cracks within the first hour. In the next two hours of execution, the software successfully performed 8 more cracks. During the next 21 hours a further 4 more hashes were cracked, which meant after the first 24 hours JtR-MPI had broken 34 hashes. After the first day the software slowed down substantially, only cracking a further 4 more hashes in the next 2 days.
At the end of 3 days the utility had cracked 38 hashes.
Number of LM Hashes Cracked vs Time
Problems with Cisilia caused the program to run inconsistently. After decreasing the number of nodes down to 8, the test eventually started correctly. Unfortunately, after 5 hours and 37 minutes, the program stopped working only after having cracked 4 passwords.
A second test on 8 nodes ran for longer, but was manually stopped after having run for 3 days. During this time Cisilia only managed to crack 4 passwords, 2 of which were different from the first test.
Due to instability and inconsistency of Cisilia the results were discarded and a comparison between Cisilia and John the Ripper could not be performed.
Analysis
Analysis of the results from the successful John the Ripper test show that only 12 passwords were cracked in their entirety, meaning that both of the two separate hashes were cracked correctly. A further 27 passwords had their first half correctly cracked, meaning that the first 7 characters of the password were cracked correctly. This left a final 11 passwords which did not have either half cracked.
Of the 12 passwords which were completely cracked, 10 were cracked within the first 3 hours. The final 2 passwords took an additional 37 hours to be cracked. Of the 26 half-passwords which were successfully cracked, 24 were cracked within the first day.
An inspection of the time each password took to crack and its relative strength rating, according to the article by Williams (2001), revealed that in the case of the test, the rating did not have a strong effect on the order and time each password was cracked. An example of this is in the 2nd and 3rd passwords which were cracked, both which were rated quite highly.
Password Strength vs Time to Crack
These results could be explained by the method in which LANMAN passwords are created. By first splitting the password in half, LANMAN passwords are effectively reduced to two passwords, each with a maximum length of 7. After inspecting the 2nd and 3rd passwords it is easy to see that each is made up of two separate, 7 character-long strings, each consisting of only alphabetic characters. Due to the fact that each separate half was easily cracked, it meant that the entire password could be cracked in no time.
The passwords which took longer to crack, even though they had weaker password strength ratings than others, took longer because of their use of non-alphabetic characters such as a “(“ character or “+” character. This is the case in the 2 passwords which took longer than 1 day to crack.
Limitations
The main limitation during this research was due to the instability of Cisilia. Without results from Cisilia, a comparison of two different clustered, password cracking utilities could not be performed. This also hindered the research into the method of parallelisation used by Cisilia to break passwords using multiple computers.
Another limitation to the research was the use of LANMAN passwords instead of a different password encrypting algorithm, such as MD5 or even DES based passwords. The LANMAN password format could explain why so many of the passwords were not cracked. Upon inspection of the log files produced by each node in the cluster, it would appear that the 3 day test should have produced many more positive cracks. Some possible answers to this problem could be that during the creation of the LANMAN passwords, the truncating and padding was done incorrectly, or else the method by which John the Ripper pads and truncates possible passwords was done incorrectly. After inspecting the list of cracked passwords this is confirmed, as 95.35% of the passwords had a length of 7 characters. Of the remaining 11 un-cracked passwords, none were a length of 7 characters.