Date: Fri, 27 Aug 2010 18:16:31 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: A puzzling hash from the past On Fri, Aug 27, 2010 at 10:18:07AM +0200, fijam 7 wrote: > I recently analyzed the firmware of a certain discontinued router that > I have and managed to extract a cramfs filesystem. There, I found > /etc/shadow with a strange hash: > > user:$1juTFYmn618Y:12086::99999:::: > > To my understanding, a DES hash should have 13 characters in base64 > digits (including the salt). Any ideas why does it start with a '$'? Yes: a program setting the password attempted to use an MD5-based crypt hash, so it provided a salt proper for that hash type, but the system's libc (or libcrypt) lacked the support, so it produced a DES-based crypt hash with the invalid salt of "$1" instead. > It appears that the firmware utilized tinylogin 0.80 and uClibc > 0.9.26. I had a look at the source but found no clues. Different implementations of DES-based crypt(3) process invalid salts differently. I don't know how uClibc in particular processes them. JtR implements one of the possible mappings, but if it's not right for your target system (for uClibc in this case) then you need to replace the '$' character with a "correct" one that maps to the same 6-bit value that uClibc maps the '$' to. Please refer to these older postings for more detail on the topic: http://www.openwall.com/lists/john-users/2009/02/28/1 http://www.openwall.com/lists/john-users/2008/10/03/2 Both are linked from: http://openwall.info/wiki/john/mailing-list-excerpts * Invalid salts with traditional DES-based crypt(3) (2009/02/28) * Invalid salts - more info on the two known mappings (2008/10/03) Since then, I found out that FreeSec - the DES-based crypt(3) code in use on free *BSD systems - maps all invalid salt characters simply to all zero bits (same as the '.' character). However, this shouldn't be relevant to your case. I mention it for the sake of completeness (for others reading this, including via the mailing list archives). I've recently fixed the copy of FreeSec in Owl and in PHP 5.3.2+ (submitted/committed via a PHP developer) to mimic UFC-crypt instead, since obviously mapping all invalid salt characters to just one equivalent character would make the common application problems worse (for broken apps that feed those invalid salts to crypt() when setting a new password, which I imagine is especially common for PHP scripts). I hope this response helps, despite of the excessive detail. ;-) Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.