Hello !

For my "System security" course, I have to crack a bunch of windows & unix hashes.

So far I've managed to crack 43 of the 44 lm hashes. I know that the last one is at most 7 chars since the second part of the lm hash is empty.

I also think that the attack failed because of special characters being used, probably accents, since the passwords come from french speaking users...

In order to recover that last password, I have no other choice left but to brute force it. 7 chars is too much, so I'm going for 6. My question is : How are accents processed by the LM algorithm ? I know that the password is uppercased before being encrypted, so does that mean that "être" would become "ÊTRE" ? or is "être" first transformed as "^etre" and then "^ETRE" ?

On the ophcrack website, in their FAQ, they say that That doesn't help me that much

Does someone have a precise answer to that ? Thx !

can you post your lmhash? (the one with supposed french accents)

Yep, here you go :

claudine:1047:4efed4fa0c5a7d0eaad3b435b51404ee:d0582f0c70f31558b7f44e0b90ae2485:::

In the meantime, I've tried bruteforcing it up to 6 chars with the following charset:

ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()-_+=~`[]{}|\:;"'<>,.?/ §€µ£'°²³ÀÂÉÈÊËÎÏÔÙÛÇÆŒ

I've basically uppercased every possible accented vowels and I've also added special characters found on a french keyboard.

After 16 hours it didn't returned any result, so I think that the password is 7 chars long. But trying such a large charset with 7 positions is practically impossible, so I'm stuck !

I'm still not sure which accents are supported by the LM algorithm. Capitalizing a word isn't such a trivial thing to do. For example, the german letter ß doesn't have a equivalent uppercase letter : it must be replaced by SS !

You are in luck I just a few days ago I mapped out this. I don't have the results will me right now but I will post it in about 8 hours. Most the accents like À and  map to A, but I think Ë is not mapped to E. There are a few weird ones like ¹ and ³ get mapped to 1 and 3 respectively, but ² doesn't map to 2.

Coming from Micro$oft and seeing how they made their LM hashes weaker, this doesn't surprise me !

On the other hand, this is good news for me, since if they map accented chars to regular chars, it will decrease the size of my keyspace...

I'm still wondering if I will be able to crack that 7-chars LM hash though...

The map was created by basically generating 255 single letter passwords (all but the null character password) in Windows XP SP2. Then generated the same 255 single letter passwords using a DES function (this is the function that LM uses) and compared the two lists. The few letters that map to -1 do not produce a LM hash in Windows XP SP2. There is a very small chance that the LM hash in Windows XP SP2 is different than the original, but this would mean that Microsoft is retarded. Since they only continue to use LM to keep backwards compatibility.

This might be a more useful form. Ignoring the control characters (0 to 31), there are 105 unique characters that LM can use. This means worst case is 105^7 which is about 2^46.9997. So it will take about 251 days @ 6,500,000 h/s (2.8 GHz single core Xeon running John the Ripper). If you spend $10,000 USD then you can crack it in about 36 minutes (18 minutes on average).

mapped value - original value(s)
0 - 0
1 - 1
2 - 2
3 - 3
4 - 4
5 - 5
6 - 6
7 - 7, 149
8 - 8
9 - 9
10 - 10
11 - 11
12 - 12
13 - 13
14 - 14
15 - 15, 164
16 - 16
17 - 17
18 - 18
19 - 19
20 - 20, 182
21 - 21, 167
22 - 22
23 - 23
24 - 24
25 - 25
26 - 26
27 - 27
28 - 28
29 - 29
30 - 30
31 - 31
32 - 32
33 - 33
34 - 34, 147, 148, 168
35 - 35
36 - 36
37 - 37, 137
38 - 38
39 - 39, 146, 180
40 - 40
41 - 41
42 - 42
43 - 43, 134
44 - 44, 130, 132, 184
45 - 45, 150, 151, 173
46 - 46, 133
47 - 47
48 - 48
49 - 49, 185
50 - 50
51 - 51, 179
52 - 52
53 - 53
54 - 54
55 - 55
56 - 56
57 - 57
58 - 58
59 - 59
60 - 60, 139
61 - 61
62 - 62, 155
63 - 63
64 - 64
65 - 65, 97, 192, 193, 194, 195, 224, 225, 226, 227
66 - 66, 98
67 - 67, 99, 169
68 - 68, 100, 208, 240
69 - 69, 101, 200, 202, 203, 232, 234, 235
70 - 70, 102
71 - 71, 103
72 - 72, 104
73 - 73, 105, 204, 205, 206, 207, 236, 237, 238, 239
74 - 74, 106
75 - 75, 107
76 - 76, 108
77 - 77, 109
78 - 78, 110
79 - 79, 111, 140, 156, 210, 211, 212, 213, 216, 242, 243, 244, 245, 248
80 - 80, 112
81 - 81, 113
82 - 82, 114, 174
83 - 83, 115, 138, 154
84 - 84, 116, 153
85 - 85, 117, 217, 218, 219, 249, 250, 251
86 - 86, 118
87 - 87, 119
88 - 88, 120, 215
89 - 89, 121, 159, 221, 253, 255
90 - 90, 122, 142, 158
91 - 91
92 - 92
93 - 93
94 - 94, 136
95 - 95, 175, 190, 222, 254
96 - 96, 145
123 - 123
124 - 124
125 - 125
126 - 126, 152
127 - 127
128 - 199, 231
142 - 196, 228
143 - 197, 229
144 - 201, 233
146 - 198, 230
153 - 214, 246
154 - 220, 252
155 - 162
156 - 163
157 - 165
159 - 131
165 - 209, 241
166 - 170
167 - 186
168 - 191
170 - 172
171 - 189
172 - 188
173 - 161
174 - 171
175 - 187
216 - 135
221 - 166
225 - 223
230 - 181
241 - 177
246 - 247
248 - 176
250 - 183
253 - 178
255 - 160

From Jesper M. Johansson
Security Program Manager, Microsoft Corporation

Either it changed sometime between when he said that and Windows XP SP2 or he was incorrect. He's only off by 9. If you don't believe me then try these passwords (note coping the passwords below straight from the browser may give incorrect results, in these cases you will need to use the hex versions of the passwords). The way the passwords are set up it will test all of the colliding characters. The result of this test given the hashes match is that there is at most 133 unique characters (this includes control characters).

Thanks Sc00bz, that's exactly what I was looking for ! Now all I have to do is ask my faculty to lend me 10k$ !



I counted 133 "mapped values", minus the 32 control chars, that's 101 chars...



So what's the correct value in the end

There are four characters that get mapped to control characters. 149 => 7, 164 => 15, 182 => 20, and 167 => 21. That is why it is 105 and not 101.

Well I just passed your list to wc -l and subtracted the first 32 lines...

Anyway, that doesn't matter

Thanks again !

at least one character might be wrong... i tested a password with a ë (137) quite some time ago... the password could be cracked by cain, stating it is an E. It does not automaticcaly correct the character in the NTLM password (stays empty).

How did you generate your passwords?

"ë (137)" char 137 is ‰ "per thousand" symbol which looks like a percent sign with two zeros on the bottom. The lower case e with two dots above it is 235. Did you make a mistake on the number?
Cain doesn't use this mapping... actually nothing does currently, but will probably change in the future since I told the people at Ophcrack about the map.


I did most of it by hand. I made a program that outputted characters 1 to 255 then just copied one at a time into the password boxes and ran pwdump. I skipped a-z and A-Z since I knew those mapped to A-Z. I took some short cuts since Ophcrack states that these, ÈÊËèêëÙÚÛùúûÀÁÂÃàáâãÒÓÔÕòóôõÌÍÎÏìíîï, map to the EUAOI. So I just verified that with a few passwords.

i was confused with the ASCII character map vs. the ANSI character map i guess... ALT+137 = ë and ALT+0235 = ë.

i'll check some of the characters on a dutch version of windows and a windows 2003 install one of these days