Serial number.

[geekmaster]

Originally Posted by NiLuJe

@geekmaster: K3_WIFI="true" should be calling (& trusting) login/pam/whatever to do the auth, so that's weird (granted, I may have borked the patch, I only tested this via sharedkey auth ^^).

I tried multiple times. When K3_WIFI="true" on my 2.5.8 DXG, the "login" command works with the 3 hex digit fiona root password, but ssh fails.

I just tested my 2.5.8 DX (white). It has had problems with SSH being extremely slow to even try to authenticate, but eventually it would let me login via ssh. At this time though, my ssh password is failing, even though it works from a "login" command after I telnet into it -- and that is with K3_WIFI="false".

The 4 hex digit fiona passwords that Sir Alex's KDT report do not work for any of my kindles (3G, 3w, DX or DXG).

Which passwords would I need when accessing this from the serial port (3 or 4 hex digits)?

Also, would installing the version 3 update on my DXG affect how many hex digits of the S/N md5sum are needed on the fiona password?

I have a friend who has a kindle 2. I will borrow that to see it it behaves differently. I find it strange that others on mobileread.com say they need 4 hex digit fiona passwords when all my kindles only want 3 hex digits...

I may need to switch to shared key auth like I use on some of my routers...

[geekmaster]

I have been investigating my K1 (Kindle 1st generation), and amongst many differences with newer kindles, the password algorithm (now built into kindletool) DOES NOT WORK for this device. The generated passwords (both 3 and 4 hex digit fiona passwords) are incorrect.

However, using the wordlist above, JOHN immediately found a DIFFERENT 4 hex digit fiona password, after JOHN had been trying to crack it for some time (on an admitted already very busy CPU).

Hmm... On my K1, the fiona hex digits are still md5sum bytes 8-11 of the serial number. Because DES passwords are only 8 chars, SSH root password is truncated to 3 hex digits. I wonder why kindletool is not calculating this correctly??? Need to check the source code after some sleep.

EDIT: The online Amazon Kindle root password tool calculates the correct root password(s), so it seems that kindletool has a problem. Too tired to fix it at the moment. TTYL...

EDIT2: I examined the latest kindletool source code, and it *appears* correct. I need to step through it with my K1 serial number and see where it fails in the (pre-Wario) password computation.

[NiLuJe]

Huh. What's the exact and complete output?

The only thing I can imagine is it being misidentified as a >= Wario device. Which shouldn't happen, unless the prefix is weird or something... But, still.

FWIW, a random test appears to behave properly:

kindletool info B001234567890123
Platform is pre Wario
Root PW            fiona231
Recovery PW        fiona2314

[geekmaster]

No, it says "pre-Wario". And the online tool gives the correct PW. I am running the mingw version on win7x64. As my EDIT2 says above, the code *looks* correct. Here is my output (only serial modified for this post):

.\kindletool info B101xxxxxxxxxxxx
Platform is pre Wario
Root PW            fiona98f
Recovery PW        fiona98f0

Whereas the online kindle password tool (and examining md5 chars 8-11 = 19e1) shows correctly:

Possible root passwords:
mario
fiona19e
fiona19e1

I think we need to display the md5 and compare that to the generated password, to see where it goes wrong. I will PM you my exact serial number now.

EDIT: PM sent. Kindletool source code looks okay at first glance, so this is weird. I am not setup to build this yet, or this would have been fixed already...

[knc1]

I might have had the same problem with my B003 (before I bricked it) -
But I only tried twice, thought that I had typo'd the entry and switched to pub. key auth.

[geekmaster]

Okay, this is weird. The kindletool source code writes the kindle serial number to a temp file WITH NEWLINE (which varies between linux and Windows boxen):

PHP Code:

fprintf(temp, "%s\n", serial_no) ...
if(md5_sum(temp, md5) ... 


But that makes me wonder how the md5 could EVER be correct, if it always includes a '\n' newline (either LF, or CR/LF, depending on OS). It seems "more better" to just calc md5 of the string instead of a file (especially with that newline)...

EDIT: Or for a quick-and-dirty fix, just leave out the newline? For example, fprintf(temp, "%s", serial_no) ...

[NiLuJe]

Ouch. That's probably a remnant of the original md5 hashing code that relied on OpenSSL's terrible API.

I should indeed be able to hash the string directly much easily now that everything is neat with nettle .

[NiLuJe]

And yeah, you hit the nail on the head, I get the correct result on Linux .

So it's indeed most likely a CR/LF issue, nice catch .

[geekmaster]

For a quick hack fix (not unlike my minimal win32 temp path fix), try removing the "\n" from the print statement (see edit above for details). Unless md5sum REQUIRES a line terminator (in which case replace "\n" with "\v" so forced linefeed only, even in windows).

Of course, the clean way *IS* an md5 of the string instead of a temp file.

[NiLuJe]

Yep, this should take care of things... .

I'll push updated snapshots sometime this weekend . Thanks!

(Because, yeah, we actually need the LF. I'm guessing to match the actual format of /proc/usid).

EDIT: I actually went with '\xA' to make completely sure no compiler will have any bright ideas about what that '\n' is supposed to be... It's not in a printf-like function, so I don't think it would have hurt, but, still...

EDIT²: Snapshots updated .

[knc1]

Yup - the original programmers forgot to "trim whitespace (I.E. the \n)" from /proc/usid when they came up with this system.

(Note: some values in /proc do not include the \n in their output, but this isn't one of them.)