07-20-2012, 11:10 AM | #271 |
(offline)
Posts: 2,907
Karma: 6736092
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
|
07-20-2012, 12:23 PM | #272 |
Tech Geek Forever
Posts: 230
Karma: 568824
Join Date: Jun 2012
Location: USA
Device: Kindle Touch hacked
|
noob question but does margins patch for beta version 2.0.0 also work on full version of jbpatch 2.0.0
|
07-20-2012, 12:40 PM | #273 |
(offline)
Posts: 2,907
Karma: 6736092
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
|
07-20-2012, 05:35 PM | #274 |
Enthusiast
Posts: 28
Karma: 20614
Join Date: Jun 2012
Device: Kindle Touch
|
En JBpatch log file
Initializing patches FATAL ERROR: Firmware ID could not be determined. Kindle touch 5.1.1 Saludos !! |
07-20-2012, 05:40 PM | #275 |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
Hmm... Some kind of record, only took 27 hours to become obsolete.
|
07-20-2012, 06:14 PM | #276 |
(offline)
Posts: 2,907
Karma: 6736092
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Yes, that is normal. We have been begging for 5.1.1 images for weeks now. Since nobody wants to provide such an image, I cannot support that firmware version.
|
07-20-2012, 06:21 PM | #277 |
(offline)
Posts: 2,907
Karma: 6736092
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
|
07-20-2012, 06:35 PM | #278 |
Definitely not King Kong
Posts: 126
Karma: 59238
Join Date: Jul 2012
Location: United States
Device: Kindle Touch
|
Great work ixtab, I love the margin hack and just wanted to say thanks!
P.S. - If you don't mind me asking what's with your alias, thanking about committing suicide? ;-) |
07-20-2012, 10:39 PM | #279 | |
(offline)
Posts: 2,907
Karma: 6736092
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Quote:
...just a mayan goddess... |
|
07-20-2012, 11:38 PM | #280 |
Enthusiast
Posts: 28
Karma: 20614
Join Date: Jun 2012
Device: Kindle Touch
|
|
07-21-2012, 01:03 AM | #281 | |
Definitely not King Kong
Posts: 126
Karma: 59238
Join Date: Jul 2012
Location: United States
Device: Kindle Touch
|
EDIT: Disregard this post please!
I think Ixtab means a firmware image (the entire nand memory [if the kindle uses nand]). Or the operating system of the kindle. You would basically be backing up the kindle. The guide on the Wiki is a little old. You could write a shell script something like this and execute it (through usbnetwork or xterm). Quote:
P.S. - If he did mean screenshot you can just execute the "screenshot" command from usbnetwork. Last edited by Titano; 07-21-2012 at 03:28 AM. |
|
07-21-2012, 01:29 AM | #282 |
Carpe diem, c'est la vie.
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
|
dd will be very slow using the default 512 byte block size. 4K is much faster. You should test your script before publishing it.
|
07-21-2012, 01:46 AM | #283 |
Definitely not King Kong
Posts: 126
Karma: 59238
Join Date: Jul 2012
Location: United States
Device: Kindle Touch
|
Thanks again Geekmaster, totally forgot about BS. Oh well, It's fixed. Can I go higher than 4K? How big is the kindle OS though? (Just out of curiosity..) It can't be over 700mb?
Last edited by Titano; 07-21-2012 at 02:02 AM. |
07-21-2012, 03:05 AM | #284 | |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
Quote:
mmc -- is, well, an MMC device. In the Kindles, an eMMC device (e == embedded) but the drivers don't care if the device plugs in or gets soldered in. It does not matter how the storage is implemented, the device has a built-in "high level" controller. Although in the case of the Kindles, the eMMC part does implement the storage in NAND behind the controller. (The tech. data sheet is indexed in the "Tools Prefix" index.) mtd -- Memory Technology Device. This is the driver that is used for "lower level" flash devices (NAND, NOR of various kinds). In Linux (a Unix work-alike), true to its heritage, "all devices are files" or at least that was the Unix design goal, that all devices share the semantics of files. (Plan-9, the successor to Unix, does a better job reaching that goal.) In legacy *nix (and Linux) all "device files" (specifically: device nodes) appear in the file system in the /dev directory. So just the pathname: /dev/mmcblk0p1 (first block of MMC memory, first partition) is tells you that this is a device not a file and that it has a "high level" controller in front of its storage. The controller provides a: read/write/seek/etc interface, the lower level mtd devices provides a: read/erase/re-program interface. The fact that you can use programs that do "file operations" on it is just "*nix at work". In the Kindle case - the backing storage of the eMMC controller is NAND and that NAND (an mtd type device) has an erase block size of 4,096 bytes. So if you provide the eMMC controller with 4K blocks to write, it can implement that as one 4K byte one read/erase/re-program cycle. Using the default 512 byte block size, the eMMC controller has to use 8 read/merge/erase/re-program cycles to get the same job done. The partitions of an eMMC device, like those of a (spinning) hard disk drive need not describe the entire storage area of the device. In the case of the Kindles, they do not, there is storage area "outside" of that described by the partition table. The /mnt/us is a file system, ultimately stored on the /dev/mmcblk0p4 device. I write "ultimately" because there are a couple of VFS layers involved before the bits and bytes actual hit the silicon. Translation: There is a lot of useful information in a *nix /dev/name. Now, to continue with the topic at hand, getting a forensics's image file .... We know there are four partitions; We know the partitions 3 and 4 (mmcblk0p3 and mmcblk0p4) are not of any interest; We know there is storage area outside of the partition table described areas; We know that either partition 1 or partition 2 (or both) will be mounted (in-use) during "normal" operation; We know that we can not get a complete (in the sense of being correct) image of the backing store of a file system while the file system is "in-use"; A procedure that "will work" - Boot the system that uses partition 1 as its file system ("main"), copy partition 2; then: Boot the system that uses partition 2 as its file system ("diags"), copy partition 1; and: somewhere along the way (from either system): Read the partition table of mmcblk0 (the "raw" device) and copy the storage area from 0 ... the block prior to the first block described in partition 1. A much better procedure - Use one of the "service and maintenance" tools that boot the Kindle into a state where it is using a RAM RESIDENT file system; Read the partition table; Copy from 0 .. the block prior to the start of partition 3. Then, off-kindle, sort out the various parts of the copied image. Since we want a quality copy of this 5.1.1 release, the second procedure is the desired one. And GM can best recommend which of the various "service and maintenance" tools to use for this job. |
|
07-21-2012, 03:29 AM | #285 | |
Definitely not King Kong
Posts: 126
Karma: 59238
Join Date: Jul 2012
Location: United States
Device: Kindle Touch
|
Quote:
|
|
Tags |
jbpatch, kindle touch hacks |
Thread Tools | Search this Thread |
|