Displaying 2 results from an estimated 2 matches for "c1742f25a4".
2019 Mar 28
2
Encoding problem with the unicodePwd stored into sam.ldb
...ePwd
....
# record 494
dn: CN=XXX,CN=Users,DC=YYY,DC=ZZZ,DC=fr
unicodePwd:: wXQvJaSkn0gvg1POsY9Icw==
uidNumber: 5110
userPrincipalName: XXX
...
ok. Then, I convert the password from utf-16 to hex :
$ echo 'wXQvJaSkn0gvg1POsY9Icw==' | base64 -d -w 0 | hexdump -e '/1 "%02X"'
C1742F25A4*
9F482F8353CEB18F4873
why there is a * and a new line ? base64 (and hexdump) are silent about
that.
If I run hd instead of hexdump :
00000000 c1 74 2f 25 a4 a4 9f 48 2f 83 53 ce b1 8f 48 73
|.t/%...H/.S...Hs|
the problem is with the second 0xa4 character.
Is the format of the password stored...
2019 Mar 28
0
Encoding problem with the unicodePwd stored into sam.ldb
...N=Users,DC=YYY,DC=ZZZ,DC=fr
> unicodePwd:: wXQvJaSkn0gvg1POsY9Icw==
> uidNumber: 5110
> userPrincipalName: XXX
> ...
> ok. Then, I convert the password from utf-16 to hex :
> $ echo 'wXQvJaSkn0gvg1POsY9Icw==' | base64 -d -w 0 | hexdump -e '/1
> "%02X"' C1742F25A4*
> 9F482F8353CEB18F4873
>
> why there is a * and a new line ? base64 (and hexdump) are silent
> about that.
>
> If I run hd instead of hexdump :
> 00000000 c1 74 2f 25 a4 a4 9f 48 2f 83 53 ce b1 8f 48 73
> |.t/%...H/.S...Hs|
>
> the problem is with the second 0xa4...