Damn Reboot using the shell - Page 5

knc1 · 06-23-2012, 10:07 AM

[QUOTE=wlaf;2124990]Using "setenv rdinit /bin/sh" I got:

Code:

uboot> setenv rdinit /bin/sh
uboot> boot

You need to add that to the existing command line argument strings.
You __must__ use the equals sign.

U-boot contains a small shell, when you print all of the environment variables, you are reading shell scripting.

So you need to modify one of the existing arguments (notice multiple environment variables that are referred to by name).

The rest of your post just shows that the rdinit=/bin/shell argument was never passed along with the rest of the command line arguments.

It does not matter what the problems with the hardware storage media might be, you will be running "memory resident" without reference to the eMMC device.

hawhill · 06-23-2012, 12:51 PM

And as for ATK: You get your K3 into the required mode by holding the Vol- button during reboot. The K3 will present as a different USB device if successful.

However, I'm currently playing with it and did not really get it to do something useful. I think the provided bootstrap files ("image/" subfolder of ATK) don't fit the Kindle 3 platform, they are rather tailored towards Freescale evaluation boards. Looking at the uboot sources, there's quite a bit of setup needed... So I'm not sure if using ATK leads anywhere useful. There's work involved, and work that typically needs a tough experienced hacker... plus lots of the hacker's time.

knc1 · 06-23-2012, 01:58 PM

One theory occurred to me today while answering another post...

The eMMC, like other flash based devices, does not "write".
It "reads, merges, erases, and re-programs".

I have not examined my own kindle or the firmware images (yet), but...

The "power off" command of *nix is often associated with the "reboot" command. (Highly implementation Dependant.)

For non-flash based systems, "reboot" will typically flush (sync) the VFS file buffers followed by un-mounting the file systems (among other things).

Both the "sync" and the "umount" (normally) are blocking events.
BUT in the case of flash media, the "writes" generated will all return before the micro-controller finishes its sequence on each erase block involved.

Then if "power off" is implemented to actually remove power from the electronics (or at least from the eMMC)...

Then it would be possible to remove power before the micro-controller finishes.
This is one, certain, way to corrupt the flash media internally.

When, if ever, we get this unit restored to operation, it would be nice to learn exactly how it was damaged.
But so far it does read like internal corruption of the flash media.

wlaf · 06-23-2012, 02:58 PM

Quote:

Originally Posted by knc1

Quote:

Originally Posted by wlaf

Using "setenv rdinit /bin/sh" I got:

Code:

uboot> setenv rdinit /bin/sh
uboot> boot

You need to add that to the existing command line argument strings.
You __must__ use the equals sign.

U-boot contains a small shell, when you print all of the environment variables, you are reading shell scripting.

I think my command was in right format. U-Boot has a different syntax compared to bash, grub, etc. The output shows that the command actually worked. I can provide the output of the "printenv" command.

Right now, I'm using these two documents for U-Boot:

Freescale Semiconductor
U-Boot Quick Reference
http://www.lysator.liu.se/~kjell-e/e...E5200BUBPG.pdf

and this nice presentation:

Free Electrons, E,bedded Linux Developers
The Uboot bootloader
http://free-electrons.com/doc/u-boot.pdf

I also found this document, and for the first time I learned that Kindle 3 has a builtin microphone!

Kindle3 hacking
https://brmlab.cz/_media/event/lt-kindlehacking.pdf

After all, It seems brute forcing the password is the easiest remaining option. For doing this, I should know what exactly happens after you enter a correct password in recovery menu. The last document above provides a simple script for serial brture forcing, but it's useless for my situation and need to be changed completely.

Quote:

Originally Posted by hawhill

I'm currently playing with it and did not really get it to do something useful. I think the provided bootstrap files ("image/" subfolder of ATK) don't fit the Kindle 3 platform, they are rather tailored towards Freescale evaluation boards. Looking at the uboot sources, there's quite a bit of setup needed... So I'm not sure if using ATK leads anywhere useful. There's work involved, and work that typically needs a tough experienced hacker... plus lots of the hacker's time.

I think it will be useful anyway. For example, "Download" and "Dump" features of the Flash tool seems to be promising. Dump the MMC, etc of a working Kindle and then reprogram another Kindle. In theory, it should provide a fast and painless recovery.

hawhill · 06-23-2012, 03:34 PM

On the ATK side-track: I've gotten a bit further (but only on the knowledge side, nothing practical). The thing is, ATK is basically a) a memory patcher, which is used in the first step to set a few SoC registers (memory mapped) to certain values in order to set up RAM type and timing etc.; b) it is an image uploader which then pushes a custom boot loader onto the device, and c) a frontend for some functionality of that boot loader.

"Download" is probably from the view of the device, i.e. it's a firmware uploader. I didn't dare to play with it yet. "Dump" should dump to a file; however, I did not manage to get it to work. I carefully sniffed the USB connection, and it seems that it uses almost the same protocol as the serial bootloader (which I recognized when I saw this: http://api.ning.com/files/6TZuB9Rylm...ad_Protocol.py). I couldn't make something out of the "06 06" command that is used in USB downloader mode. But it should be possible to write an ATK clone for linux, for example.

However, I don't think the Kindle SoC is correctly set up by the default scripts that come with ATK. That would need careful investigation of the u-boot initial device set up, I think.

wlaf · 06-23-2012, 06:37 PM

So, I sort the solutions by their complexity:

1. Find the password (brute forcing, finding the password using serial no., etc)
2. Building custom kernel, transfering with the serial, boot and fix.
3. Using ATK to flash MMC/SD card (does it actually mean what I want?)

wlaf · 06-23-2012, 07:21 PM

Quote:

Originally Posted by knc1

Quote:

Originally Posted by wlaf

Using "setenv rdinit /bin/sh" I got:

Code:

uboot> setenv rdinit /bin/sh
uboot> boot

You need to add that to the existing command line argument strings.
You __must__ use the equals sign.

U-boot contains a small shell, when you print all of the environment variables, you are reading shell scripting.

I checked again, and it seems that you're right. The correct format seems to be:

Code:

setenv bootargs $bootargs init=/bin/sh
boot

And for testing purpose:

Code:

exec init

from here:
http://docwiki.gumstix.org/index.php/U-Boot
There are more complex usages that I don't want to test initially!

Btw, the original init was this (see page 3 for the logs from the initial state):

Code:

/sbin/init.sysvinit

hawhill · 06-23-2012, 07:39 PM

edit: I was a bit slow typing and checking. This is the answer to your "ordered list".

Yes, I think that's the right order.

Hm, I'm currently dissecting the initramfs. There seems to be a shell in there, /bin/sh (for experiments using the kernel command line). However, the normal entry is /init, which is a symlink to /bin/recovery-util. That program is responsible for the messages you see on the console after uboot and the one-liner of the kernel. It also displays the rescue system screen (when booting with <Enter> key pressed) and the rescue system menu on serial console. It loads modules, installs update packages (and checks their signatures), and contains the password check routines for whole-mmc export.

I'm in the middle of a disassembler session (and I don't have proper tools for this), but it seems that the password for whole-mmc export is _not_ read from the root file system's /etc/passwd. It is rather directly constructed from the serial number. So resetting the "linux" password should not have had any effect on that. At least that's how I read the disassembly. There are huge gaps in my general overview of it, though.

An interesting side note: This file, recovery-util, also does the set up for a special start mode where the root file system is read via NFS - via the USB ethernet gadget link! However, I'm still unsure on how to trigger that mode - and if it is possible at all. It's the function nfs_boot() in that file (yes, it has symbol information...).

knc1 · 06-23-2012, 07:50 PM

Quote:

Originally Posted by wlaf

I checked again, and it seems that you're right. The correct format seems to be:

Code:

setenv bootargs $bootargs init=/bin/sh
boot

That is the "correct format" for a different purpose.
Although it is nice to hear someone admit that this crazy old man sometimes "gets it right".

The kernel command line argument: init=
Will run that executable as the first executable (PID 1) after the runtime file system is mounted.

The kernel command line argument: rdinit=
Will run that executable as the first executable (PID 1) of the Early User Space file system, before the runtime file system is mounted.

You can find that documented in <kernel_version>/Documentation of any kernel source tree. Google can most likely also find you a copy of: "Linux Early Userspace".

Since the runtime file system is trash, we want rdinit= not init= command line argument.

The Early userspace file system is a compressed, cpio, archive of a minimal filesystem, appended to the kernel binary, and loaded into the VFS (virtual file system) buffers prior to any other file system.

The typical EUS file system will have an init program or more often init scripting that runs to handle the setup for the runtime filesystem. In this case, one of the things that scripting is doing is that "auto-pilot" action.

So the rdinit=/bin/sh command line argument will cause that shell program to be executed rather than the EUS scripting which is failing to find, fix and mount the runtime file system.

With that command line prompt from the shell running in EUS (memory resident) we can explore this problem, and hopefully fix it.
Since I can't know in advance what is wrong, I can't tell you in advance what the commands are.
You will just have to get it into this shell and post back here, then we can explore the problem together as I walk you through finding out what is wrong.

Edit: Note: It is possible to remove, alter and replace that EUS archive on the end of the kernel binary. Once we know what we want to put in there.
Let us hope that the current one isn't 110% closed source, compiled code as Hawhill seems to be finding present.

wlaf · 06-23-2012, 08:10 PM

Quote:

With that command line prompt from the shell running in EUS (memory resident) we can explore this problem, and hopefully fix it.
Since I can't know in advance what is wrong, I can't tell you in advance what the commands are.
You will just have to get it into this shell and post back here, then we can explore the problem together as I walk you through finding out what is wrong.

Thanks for your detailed description of the problem, and I'm sorry If I judged quickly without reading the manual carefully. :-)
Just one more question: If everything goes wrong, do you think it's possible to use dd to dump images transfered/NFS mounted over serial/net/etc over the filesystem?

NiLuJe · 06-23-2012, 09:30 PM

FWIW, the MMC export password is the same as the default root password, If memory serves me...

wlaf · 06-24-2012, 04:42 AM

Quote:

Originally Posted by NiLuJe

FWIW, the MMC export password is the same as the default root password, If memory serves me...

Ok. At last I could be able to recover the password! The password was the one generated for "4.0.1", not 3.0 here:

http://members.ping.de/~sven/kindle.html

This is the disk I see now in Windows Disk Management:

I want to dump the provided images on the partitions.

knc1 · 06-24-2012, 05:34 AM

Quote:

Originally Posted by wlaf

Ok. At last I could be able to recover the password! The password was the one generated for "4.0.1", not 3.0 here:

http://members.ping.de/~sven/kindle.html

This is the disk I see now in Windows Disk Management:

I want to dump the provided images on the partitions.

That "report" is only showing the file system contents of the one file system type it recognizes (blk0p4, FAT-32, a.k.a: USB-storage).
It is just a pretty GUI picture of the partition table, plus it has detected and auto-mounted the FAT-32 partition.

You will have to load an ext2/ext3 driver for your Windows box to recognize the first three.
It has been awhile, but the last time I looked there are several available to choose from.

Even after loading the Windows ext2/ext3 driver, Windows Disk Manager will only show you the file system contents.
We want the storage media contents that underlies the file system.

You will have to try some of the Windows "Disk Clone" and/or "Disk Backup" loose in the world to get storage media contents.

Hmm...
Well, at this point, you can at least dump the contents of the USB-storage partition.
I would not (yet) run any Windows FAT-32 disk repair programs on it - it would be nice to get the copy of the media before letting some end-user auto-repair program loose on the only copy (the one on the flash media).

wlaf · 06-24-2012, 05:52 AM

Quote:

Originally Posted by knc1

That "report" is only showing the file system contents of the one file system type it recognizes (blk0p4, FAT-32, a.k.a: USB-storage).
It is just a pretty GUI picture of the partition table, plus it has detected and auto-mounted the FAT-32 partition.

You will have to load an ext2/ext3 driver for your Windows box to recognize the first three.
It has been awhile, but the last time I looked there are several available to choose from.

I've tested EXT-IFS before. It's a great tool

Ext2/3 Installable File System For Windows
http://www.fs-driver.org/

Quote:

Even after loading the Windows ext2/ext3 driver, Windows Disk Manager will only show you the file system contents.
We want the storage media contents that underlies the file system.

You will have to try some of the Windows "Disk Clone" and/or "Disk Backup" loose in the world to get storage media contents.

I will do the job by attaching the USB to the Linux Box I have in VMWare. The rest of the job seems to be straightforward in Linux. There is also several versions of "Windows DD" availabe, but I prefer Linux.

Quote:

Hmm...
Well, at this point, you can at least dump the contents of the USB-storage partition.
I would not (yet) run any Windows FAT-32 disk repair programs on it - it would be nice to get the copy of the media before letting some end-user auto-repair program loose on the only copy (the one on the flash media).

It's a good Idea. :-)

wlaf · 06-24-2012, 06:47 AM

And at last...We're Back!! :-)

Reading was so fast, but writing the image was slow and made me worry:

Making Backup:

Code:

root@ubuntu:~# dd if=/dev/sdc1 of=kindle1.img
1331256+0 records in
1331256+0 records out
681603072 bytes (682 MB) copied, 61.8736 s, 11.0 MB/s

root@ubuntu:~# dd if=/dev/sdc2 of=kindle2.img
49152+0 records in
49152+0 records out
25165824 bytes (25 MB) copied, 2.65295 s, 9.5 MB/s

root@ubuntu:~# dd if=/dev/sdc3 of=kindle3.img
16384+0 records in
16384+0 records out
8388608 bytes (8.4 MB) copied, 0.691376 s, 12.1 MB/s

Dumping the provided image

Code:

root@ubuntu:~# dd if=mmcblk0p1.img of=/dev/sdc1

1331256+0 records in
1331256+0 records out
681603072 bytes (682 MB) copied, 634.65 s, 1.1 MB/s

Now the Kindle is up and running! :-)
Thank you guys, for your help.

Do you think that the same root password should work now?

06-23-2012, 10:07 AM	#61
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	[QUOTE=wlaf;2124990]Using "setenv rdinit /bin/sh" I got: Code: uboot> setenv rdinit /bin/sh uboot> boot You need to add that to the existing command line argument strings. You __must__ use the equals sign. U-boot contains a small shell, when you print all of the environment variables, you are reading shell scripting. So you need to modify one of the existing arguments (notice multiple environment variables that are referred to by name). The rest of your post just shows that the rdinit=/bin/shell argument was never passed along with the rest of the command line arguments. It does not matter what the problems with the hardware storage media might be, you will be running "memory resident" without reference to the eMMC device.

06-23-2012, 01:58 PM	#63
knc1 Going Viral Posts: 17,212 Karma: 18210809 Join Date: Feb 2012 Location: Central Texas Device: No K1, PW2, KV, KOA	How? One theory occurred to me today while answering another post... The eMMC, like other flash based devices, does not "write". It "reads, merges, erases, and re-programs". I have not examined my own kindle or the firmware images (yet), but... The "power off" command of nix is often associated with the "reboot" command. (Highly implementation Dependant.) For non-flash based systems, "reboot" will typically flush (sync) the VFS file buffers followed by un-mounting the file systems (among other things). Both the "sync" and the "umount" (normally) are blocking events. BUT* in the case of flash media, the "writes" generated will all return before the micro-controller finishes its sequence on each erase block involved. Then if "power off" is implemented to actually remove power from the electronics (or at least from the eMMC)... Then it would be possible to remove power before the micro-controller finishes. This is one, certain, way to corrupt the flash media internally. When, if ever, we get this unit restored to operation, it would be nice to learn exactly how it was damaged. But so far it does read like internal corruption of the flash media.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Damn you Amazon...	apastuszak	Amazon Kindle	37	05-03-2012 07:42 PM
What's with all the damn vampires?	Jack Silkstone	General Discussions	99	11-23-2011 10:23 AM
PRS-600 well...damn.	Zerhackermann	Sony Reader	11	01-23-2010 08:50 AM

06-23-2012, 12:51 PM	#62
hawhill Wizard Posts: 1,379 Karma: 2155307 Join Date: Nov 2010 Location: Goettingen, Germany Device: Kindle Paperwhite, Kobo Mini	And as for ATK: You get your K3 into the required mode by holding the Vol- button during reboot. The K3 will present as a different USB device if successful. However, I'm currently playing with it and did not really get it to do something useful. I think the provided bootstrap files ("image/" subfolder of ATK) don't fit the Kindle 3 platform, they are rather tailored towards Freescale evaluation boards. Looking at the uboot sources, there's quite a bit of setup needed... So I'm not sure if using ATK leads anywhere useful. There's work involved, and work that typically needs a tough experienced hacker... plus lots of the hacker's time.

06-23-2012, 03:34 PM	#65
hawhill Wizard Posts: 1,379 Karma: 2155307 Join Date: Nov 2010 Location: Goettingen, Germany Device: Kindle Paperwhite, Kobo Mini	On the ATK side-track: I've gotten a bit further (but only on the knowledge side, nothing practical). The thing is, ATK is basically a) a memory patcher, which is used in the first step to set a few SoC registers (memory mapped) to certain values in order to set up RAM type and timing etc.; b) it is an image uploader which then pushes a custom boot loader onto the device, and c) a frontend for some functionality of that boot loader. "Download" is probably from the view of the device, i.e. it's a firmware uploader. I didn't dare to play with it yet. "Dump" should dump to a file; however, I did not manage to get it to work. I carefully sniffed the USB connection, and it seems that it uses almost the same protocol as the serial bootloader (which I recognized when I saw this: http://api.ning.com/files/6TZuB9Rylm...ad_Protocol.py). I couldn't make something out of the "06 06" command that is used in USB downloader mode. But it should be possible to write an ATK clone for linux, for example. However, I don't think the Kindle SoC is correctly set up by the default scripts that come with ATK. That would need careful investigation of the u-boot initial device set up, I think.

06-23-2012, 06:37 PM	#66
wlaf Enthusiast Posts: 44 Karma: 40820 Join Date: Jun 2012 Device: Kindle 3 WIFI	So, I sort the solutions by their complexity: 1. Find the password (brute forcing, finding the password using serial no., etc) 2. Building custom kernel, transfering with the serial, boot and fix. 3. Using ATK to flash MMC/SD card (does it actually mean what I want?)

06-23-2012, 07:39 PM	#68
hawhill Wizard Posts: 1,379 Karma: 2155307 Join Date: Nov 2010 Location: Goettingen, Germany Device: Kindle Paperwhite, Kobo Mini	edit: I was a bit slow typing and checking. This is the answer to your "ordered list". Yes, I think that's the right order. Hm, I'm currently dissecting the initramfs. There seems to be a shell in there, /bin/sh (for experiments using the kernel command line). However, the normal entry is /init, which is a symlink to /bin/recovery-util. That program is responsible for the messages you see on the console after uboot and the one-liner of the kernel. It also displays the rescue system screen (when booting with <Enter> key pressed) and the rescue system menu on serial console. It loads modules, installs update packages (and checks their signatures), and contains the password check routines for whole-mmc export. I'm in the middle of a disassembler session (and I don't have proper tools for this), but it seems that the password for whole-mmc export is _not_ read from the root file system's /etc/passwd. It is rather directly constructed from the serial number. So resetting the "linux" password should not have had any effect on that. At least that's how I read the disassembly. There are huge gaps in my general overview of it, though. An interesting side note: This file, recovery-util, also does the set up for a special start mode where the root file system is read via NFS - via the USB ethernet gadget link! However, I'm still unsure on how to trigger that mode - and if it is possible at all. It's the function nfs_boot() in that file (yes, it has symbol information...).

06-23-2012, 09:30 PM	#71
NiLuJe BLAM! Posts: 13,478 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	FWIW, the MMC export password is the same as the default root password, If memory serves me...

Advert

Advert