Paperwhite 2nd Gen

[knc1]

Originally Posted by npoland

What do you mean by a "split" u boot?

It was broken into a two-stage bootstrap -
First part has a small memory footprint and very limited functions, the second part is a more complete build with more functions but has to be started manually (I think).

I am not even sure I recall its name, bist, I think.

EDIT 1: Yes, it is called bist (Built In Self Test) - that should be the full featured build of u-boot if you want to try it from the u-boot menu.

EDIT 2: Ah, I see you already did that. Thanks, that is indeed still the fuller featured build of u-boot.

Really, really, nice to see that lab126 hasn't (yet) thought through the locking down of an embedded *nix (Unix) system machine.

[knc1]

Originally Posted by npoland

Here are some more files with information in them. One is uboot and what commands can be executed (I ran a few of them). The other is the emergency boot mode. I got it to print out the kernel buffer.

Lots of good information in those files.

It does show that we can take over the machine using the features offered over the serial port.

[knc1]

Originally Posted by npoland

So these might be developments, but I don't really know.

I managed to get into fastboot mode and the kindle fastboot tool works on it!

From there i booted to the diag system. I tried the login again using:
login: framework
password: mario
And it worked!
The fionaXXXX and mario do not work for root though.

Is having access to this filesystem of much use?
Fastboot has a bunch of interesting stuff it can do.

It can completely re-flash the system memory.
In fact, once it is in fastboot mode (however it got there), then Kubrick can be extended to handle de-bricking a Kpw2.

It looks like you have documented that everything the Kindle-Krackers might need is still present.

Way past this old man's bedtime -
Will just wait for the dev's in other time zones to get caught up, reading all of this information.

They will probably ask you to do some more things with your device over the serial port, such as make copies of the firmware.
I am far to sleepy to even dare to give you step-by-step on doing that.

But if you can leave your working setup alone, until someone else wakes up . . . .

We may not know if the end-user will very be able to "Jailbreak" the device, but we are now certain that we can de-brick one over the serial line.

Many thanks for all this information !

I can see that you have been reading Geekmaster's de-bricking threads (and the related threads) - smart move to learn what you can about the device first.

Well done.

[npoland]

I have also gained root access to the diag partition. Which seems to be...

#!/usr/bin/env python
import hashlib
print("fiona%s"%hashlib.md5("XXXYOURSERIALXXX\n".encode('utf-8')).hexdigest()[13:16])

This is for the diag partition.

[npoland]

I will try to check this page a few times, but I have class and some studying to do for an exam on the 2nd. So I won't be doing a whole lot with this kindle till late at night.

But if there are people who want me to try stuff let me know.

And I am excited to learn this stuff so anyone who wants to give information about what I am seeing/what needs to be done would be awesome. As well as any resources I should look into

[knc1]

Originally Posted by npoland

I have also gained root access to the diag partition. Which seems to be...

#!/usr/bin/env python
import hashlib
print("fiona%s"%hashlib.md5("XXXYOURSERIALXXX\n".encode('utf-8')).hexdigest()[13:16])

This is for the diag partition.

Which is one step on the path.

Once you can login as root on the 'diag' partition (/dev/mmcblk0p2), then you have permissions that allow you to mount the 'main' partition (/dev/mmcblk0p1).
(just make a mount point in /tmp of some name)

With the 'main' partition mounted (say, at: /tmp/main) you can then navigate to the passwd and shadow files of the main partition.

Then give the password cracker utility a go at root's password in the 'main' partition.

Then you will have access as 'root' in either 'diags' or 'main' mode.
You do need both, because you can not reliably copy the contents of a partition that is in-use.
I.E: You have to be in 'diags' to copy out /dev/mmcblk0p1 and you have to be in 'main' to copy out /dev/mmcblk0p2.

(and you have to be in the ram-resident, 'recovery mode' to copy out the hidden partitions of the flash chip.
That gets a bit technical, you have diddle registers on the flash chip.
So for that, then the pictures that show part numbers is required. Have to id the flash chip part number and look up its datasheet.)

- - - well, back to the 'user' visible parts of the flash storage - - -

Flash storage is copied in units of an 'erase block' size.
Without knowing the flash chip part number, assume: 4096 bytes.

The eMMC flash chip will have a DOS format disk label at the start of the device.
You can read that using:

fdisk -l /dev/mmcblk0

that option is lower case ell.

You will find in that output that the partitioned portion of the flash does not start immediately after the disk label.
It starts some 'offset' amount into the raw device.

The area from the end of the disk label to the start of the first partition (outside of any file system) is in use.
That holds device and user specific data.
You will want a back-up copy of that, but DO NOT post it. (although one or more of the Kindle-Krackers may PM you for a copy of that - those people you can trust not to mis-use the information - you can tell who they are from their post history here)

With a post of the output of that fdisk -l command, we can tell you how many erase blocks to copy.

ok - that takes care of the storage area outside of the main partitioned, user visible.

while running in 'diags' mode, you can copy-out the 'main' mode filesytem storage area (/dev/mmcblk0p1)

while running in 'main' mode, you can copy-out the 'diags' mode filesystem storage area (/dev/mmcblk0p2)

there is a partition of persistent system data, known as the /var/local/* sub-tree in either 'diags' or 'main' mode.
Same, same partition is used by both modes.
that will /dev/mmcblk0p3
You will want to make a back-up copy of that for yourself, but no need to post that (again, one or more of the Kindle-Krackers may PM you for a copy of that).

and then there is the partition used for the "user storage" area, visible over the USB cable by the end-user.

This one is a bit tricky - it is a DOS disk label partitioned storage area, located in the fourth partition for the primary DOS disk label.
(Yes - that is legal, although MS never used that, that I know of, although it is in their specs.)

So that disk label can also be read with the fdisk -l(ist) command.
Just tell it to read /dev/mmcblk0p4 as if that was the physical start of the storage device.

Here, you will find another "outside of the (second level) partitioned area.
You will want a backup of that.
The file system within the (second level) disk label partition is already accessible when the kindle is in 'mass storage mode' using the usb cable.

That will be the destination of all the copies made above (so that those binary copies will end up as files in the user's usb storage area when the device is running normally).

pant, pant, pant - - -
rather long, and I left out the copy commands in the above.
they aren't 'secret' by any means, but it would be better to work through this the first time interactively.
mostly because the above is all from memory of prior kindle system structure - and a new device may have hidden surprises.

See the sticky at the top of the forum index page about the IRC, kindle-dev channel.
Somebody (ixtab, NiLuJe, twobob, myself) will be there to meet you and walk you through all the commands and option numbers when you have some more free hobby time.

[NiLuJe]

Yep, add me to the list of people wanting to take a look at a dump of the rootfs & diags parts, as well as the full kernel .

Thanks .

FWIW, the root account is locked since FW 5.3, which might explain why the login over serial in main doesn't work. (Check the passwd file on the main part, there's a '!' somewhere to indicate that the account is locked).

[knc1]

Originally Posted by NiLuJe

Yep, add me to the list of people wanting to take a look at a dump of the rootfs & diags parts .

Thanks .

FWIW, the root account is locked since FW 5.3, which might explain why the login over serial in main doesn't work. (Check the passwd file on the main part, there's a '!' somewhere to indicate that the account is locked).

Yup - it was late (or early), I was tired, I forgot, {insert excuse here}.

but since he is now 'root' in the 'diags' partition, he can make a copy of mmcblk0p1 (main) for us and we can decide what to do about it.

Perhaps (one sleep-dulled idea) - stuff Dos1's event handler into the main system, then diddle from USB storage with custom event handlers.

Ah, I forgot where/what to use as the USB storage destination target file system of the dd copies (/mnt/base-us ?? or shall we look at the output of 'mount' first?).

Please someone, add that recommendation here.

[NiLuJe]

@knc1: I usually just dd to netcat when dumping a partition (it's also what's in the wiki, IIRC).

[knc1]

Originally Posted by NiLuJe

@knc1: I usually just dd to netcat when dumping a partition (it's also what's in the wiki, IIRC).

Sorry, I tossed out whatever I could remember that might help.

Right - maybe post a link?
This is npoland's first thread here.
Although he has obviously done his research on this subject.

The serial port connection is the same PCB pattern on the Kpw2 as the Kpw1 - so I would use the same labels on the connection points.
(Lazy draftsman - reused the connection layout file.)

Since npoland is either asleep or in class now -
Just stuff this thread with things he can use directly, without searching for it.

[NiLuJe]

For the backup procedure: https://wiki.mobileread.com/wiki/Kind...Hacking#Backup

Not sure get_kernels will handle the PW2, but if it can, I'd be very glad for a kernel dump too .

@npoland: Take your time, there's no rush .

[knc1]

Originally Posted by NiLuJe

For the backup procedure: https://wiki.mobileread.com/wiki/Kind...Hacking#Backup

Not sure get_kernels will handle the PW2, but if it can, I'd be very glad for a kernel dump too .

@npoland: Take your time, there's no rush .

Those directions might be a little confusing, since he only has a serial port connection to 'diags' at the moment.

We never got around to learning if USBnetworking is pre-installed in this 'diags' environment.

The only thing I have a serial port connection installed on here in my stack of things is a K3.
Duh...

Maybe some of the information in 'serial port de-bricking' threads could be adapted for npoland's use.
(sorry, still need another nap here)

[eureka]

npoland, thanks for your efforts. This topic is for now defintely the most interesting place for those who familiar with software internals of previous Kindles. Will wait for release of rootfs dump. Ahhh, suspense time...

UPD: BTW, mmc driver in PW2 kernel has access to eMMC internal boot partition (where U-Boot is stored). Here is relevant excerpt:

Originally Posted by PW2 kernel log

<6>[    0.394228] mmcblk0: mmc0:0001 MMC02G 1.83 GiB.                           
<6>[    0.394346] mmcblk0boot0: mmc0:0001 MMC02G partition 1 2.00 MiB
<6>[    0.394464] mmcblk0boot1: mmc0:0001 MMC02G partition 2 2.00 MiB
<6>[    0.396966]  mmcblk0: p1 p2 p3 p4                                         
<6>[    0.399315]  mmcblk0boot1: unknown partition table                        
<6>[    0.401401]  mmcblk0boot0: unknown partition table

[knc1]

Originally Posted by eureka

npoland, thanks for your efforts. This topic is for now defintely the most interesting place for those who familiar with software internals of previous Kindles. Will wait for release of rootfs dump. Ahhh, suspense time...

UPD: BTW, mmc driver in PW2 kernel has access to eMMC internal boot partition (where U-Boot is stored). Here is relevant excerpt:

Nice -
Should make it easier to install Tizen


Board/Parts pictures on the way, later in the day.

Amazon has already posted a (broken) link to the 5.4.0 sources.

[npoland]

Teardown Images. I may have heated some connectors a bit much while tearing it apart. Everything still works though.