FORUMS
Remove All Ads from XDA

Wink Hub root

45 posts
Thanks Meter: 29
 
By FreeFly, Member on 10th December 2014, 09:47 PM
Post Reply Email Thread
19th April 2015, 11:32 PM |#211  
Junior Member
Thanks Meter: 1
 
More
cf_url
oh by the way, since i formatted /database, i see at boot an error like "/database/cf_url not found".

does this file exist normally? can someone tell me what should be there?

thanks
 
 
19th April 2015, 11:34 PM |#212  
Junior Member
Austin, Tx
Thanks Meter: 8
 
More
We (Exploitee.rs) actually found andsubmitted this to wink a while back, they told us they wont be patching it. We had intended to write a blog post on the subject but never got around to it.

Here's the youtube video of the process:



Pictures of the pinout and the NAND on the device are attached.

and here is the POC instructions:
#####################
NAND "Glitch" POC Instructions

The idea behind this attack is that we short out the data pins on the NAND while the kernel is being read from the NAND flash by the bootloader, this causes U-Boot to drop into a interactive shell over UART since a valid kernel can not be read.

1.) Take apart Wink hub.
2.) Attach USB to TTL adapter to UART pins.
3.) Power On Wink Hub
4.) After U-Boot starts, as the kernel begins loading, hold a wire and run it from GND to the NAND I/O 0 pin (#29). The kernel image will fail to load, dropping the user back to a U-Boot shell.
5.) The bootloader will default to an unsecure configuration.*

From here, you can alter kernel arguments, and set init=/bin/sh , booting to a root shell. This can be seen in the video below.

Quote:
Originally Posted by t-o-f-u

flash on the wink is http://www.spansion.com/Support/Data...L01G1_04G1.pdf

pins to be shorted are are any 2 of the ones shown in the attached image, circled. just stick a conductive piece of metal between the two pins.

you'd do this at boot right after u-boot starts when it starts to load the kernel, after it says "press any key to stop boot" but before the kernel actually boots. as in, when it's loading the kernel from NAND

it might take a few tries to get the timing right. just make sure that you aren't doing it when the kernel has already BOOTED (and filesystems are being mounted, etc.)

once you do this you can type:

Code:
setenv bootargs 'noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi init=/bin/sh'
nand read ${loadaddr} app-kernel 0x00400000 && bootm ${loadaddr}
and it will boot to a root shell. good luck! let me know how it goes.

Attached Thumbnails
Click image for larger version

Name:	NAND_Glitch_IO_Pin.jpg
Views:	510
Size:	149.2 KB
ID:	3271599   Click image for larger version

Name:	Wink_Hub_Spansion_Nand_Pinout.png
Views:	488
Size:	24.6 KB
ID:	3271600  
19th April 2015, 11:47 PM |#213  
Member
Thanks Meter: 7
 
More
Quote:
Originally Posted by t-o-f-u

flash on the wink is http://www.spansion.com/Support/Data...L01G1_04G1.pdf

pins to be shorted are are any 2 of the ones shown in the attached image, circled. just stick a conductive piece of metal between the two pins.

you'd do this at boot right after u-boot starts when it starts to load the kernel, after it says "press any key to stop boot" but before the kernel actually boots. as in, when it's loading the kernel from NAND

it might take a few tries to get the timing right. just make sure that you aren't doing it when the kernel has already BOOTED (and filesystems are being mounted, etc.)

once you do this you can type:

Code:
setenv bootargs 'noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi init=/bin/sh'
nand read ${loadaddr} app-kernel 0x00400000 && bootm ${loadaddr}
and it will boot to a root shell. good luck! let me know how it goes.

I don't have any UART connectors but I will be asking friends or ordering one later. I'll reply here if I get it done. Thanks!
20th April 2015, 04:05 AM |#214  
Junior Member
Thanks Meter: 0
 
More
Quote:
Originally Posted by hahack

Here you go:

You'll also need to change /database/cf_fver3 to 00.86 for the server to accept it - but that might just work.

Thanks!! Updating the cert and version got me up and running again on my old version (I think 0.55, but honestly don't remember). Will hold off on doing a full update until I have a reason to do so.
20th April 2015, 04:14 AM |#215  
Member
Thanks Meter: 8
 
More
Quote:
Originally Posted by Zenofex


The idea behind this attack is that we short out the data pins on the NAND while the kernel is being read from the NAND flash by the bootloader, this causes U-Boot to drop into a interactive shell over UART since a valid kernel can not be read.

Awesome that this will always be a fallback option. I can live with them not patching something that requires physical access to the device and some level of technical skill.
20th April 2015, 11:15 PM |#216  
Junior Member
Thanks Meter: 1
 
More
Quote:
Originally Posted by Zenofex

We (Exploitee.rs) actually found andsubmitted this to wink a while back, they told us they wont be patching it. We had intended to write a blog post on the subject but never got around to it.

Here's the youtube video of the process:



Pictures of the pinout and the NAND on the device are attached.

and here is the POC instructions:
#####################
NAND "Glitch" POC Instructions

The idea behind this attack is that we short out the data pins on the NAND while the kernel is being read from the NAND flash by the bootloader, this causes U-Boot to drop into a interactive shell over UART since a valid kernel can not be read.

1.) Take apart Wink hub.
2.) Attach USB to TTL adapter to UART pins.
3.) Power On Wink Hub
4.) After U-Boot starts, as the kernel begins loading, hold a wire and run it from GND to the NAND I/O 0 pin (#29). The kernel image will fail to load, dropping the user back to a U-Boot shell.
5.) The bootloader will default to an unsecure configuration.*

From here, you can alter kernel arguments, and set init=/bin/sh , booting to a root shell. This can be seen in the video below.

i think it's a lot easier to short together a couple of the address pins than to try to get a single pin on the tsop shorted to ground. ymmv but it'd take some real finesse to touch a grounded lead to that pin in the short time period you have, unless you soldered a jumper wire (again, finesse).
21st April 2015, 09:21 AM |#217  
Senior Member
Flag San Francisco, CA
Thanks Meter: 205
 
Donate to Me
More
Changing the u-boot delay
Quote:
Originally Posted by Zenofex

From here, you can alter kernel arguments, and set init=/bin/sh , booting to a root shell.

Actually what I found even more convenient, in case you ever update and need to re-root or you're too lazy to deal with all the updater patching, is to just change the boot delay. This way you won't need ninja skills to short a couple I/O pins again. You can use the following uboot commands to change the bootdelay from no delay to 1 second.

Code:
=> setenv bootdelay 1
=> saveenv
Saving Environment to NAND...
Erasing NAND...
Erasing at 0x260000 -- 100% complete.
Writing to NAND... OK
If you already have root try:

Code:
$ fw_setenv bootdelay 1
Now you can just press enter right after boot and get to a u-boot prompt. It persists across power downs, but since I haven't done an upgrade yet I'm not sure if it will persist across upgrades but I'm quite sure it will. I was too lazy and never rooted my device before and was already running 00.86 after doing the "recovery" DNS fix. I did do an update to fix up the database, but to the same version. There is a file "/database_default/u-boot.env" that may be worth modifying in case of an update.

For some reason my database partition got corrupted like t-o-f-u. Probably related to the pin shorting. What's strange is that the first boot I did before shorting pins, which resulted in the normal blue light, also said the database partition needed recovering. Maybe that's just because I rebooted using the switch instead of a normal reboot.

UPDATE:

I'm quite sure now it was because I shorted the pins accidentally at the wrong time. The updater script has some logic to try and recover from a bad "database". To avoid corrupted files I decided to just start over with a fresh database. The following code is basically what the updater script does to recover the database.

Code:
mount -a
ubiformat /dev/mtd3 -y -q
ubiattach -p /dev/mtd3
mknod /dev/ubi1 c 252 0
ubimkvol /dev/ubi1 -m -N database
mount -t ubifs ubi1:database /database
You can find the full code at the top of /root/platform/platform.sh

Code:
#make sure the database is mounted
dbcheck=`mount | grep 'database'`
if [ "" == "$dbcheck" ]; then
    #attach the UBIFS
    ubiattach -p /dev/mtd3
    if [ 0 != $? ]; then
        #something is wrong. Format the UBIFS.
        ubiformat /dev/mtd3 -y -q
        ubiattach -p /dev/mtd3
        mknod /dev/ubi1 c 252 0
        ubimkvol /dev/ubi1 -m -N database
        if [ 0 != $? ]; then
            log_output "could not attach db. Exit."
                end 1
        fi
    fi

    #mount the UBIFS
    mount -t ubifs ubi1:database /database
    if [ 0 != $? ]; then
        #something is wrong. Format the UBIFS.
        ubidetach -p /dev/mtd3
        ubiformat /dev/mtd3 -y -q
        ubiattach -p /dev/mtd3
        mknod /dev/ubi1 c 252 0
        ubimkvol /dev/ubi1 -m -N database
        mount -t ubifs ubi1:database /database
        if [ 0 != $? ]; then
            log_output "could not mount db. Exit."
                end 1
        fi
    fi
fi
21st April 2015, 01:49 PM |#218  
Senior Member
Flag San Francisco, CA
Thanks Meter: 205
 
Donate to Me
More
Only set bootdelay with active UART connection
After unplugging the UART and assembling the Hub I found out that with bootdelay set to non-zero it will not boot (solid green light) unless there is a UART connection present. You probably want to set this back to zero when you are done rooting.
21st April 2015, 06:19 PM |#219  
Junior Member
Thanks Meter: 0
 
More
Quote:
Originally Posted by Zenofex

We (Exploitee.rs) actually found andsubmitted this to wink a while back, they told us they wont be patching it. We had intended to write a blog post on the subject but never got around to it.

Am I correct in assuming that this will work on any firmware?
21st April 2015, 07:23 PM |#220  
Junior Member
Thanks Meter: 0
 
More
I jumpered it after the kernel started booting unfortunately. It kernel panics on boot now. Does anyone know of a way to recover it thought u-boot? Thanks.

UBIFS: recovery needed
mmc0: new high speed SDIO card at address 0001
UBIFS error (pid 1): replay_log_leb: log error detected while replaying the log at LEB 5:0
List of all partitions:
1f00 3072 mtdblock0 (driver?)
1f01 4096 mtdblock1 (driver?)
1f02 28672 mtdblock2 (driver?)
1f03 8192 mtdblock3 (driver?)
1f04 8192 mtdblock4 (driver?)
1f05 78848 mtdblock5 (driver?)
fe00 74896 ubiblka (driver?)
No filesystem could mount root, tried: ubifs
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Backtrace:
[<8002b9d0>] (dump_backtrace+0x0/0x110) from [<802d90e0>] (dump_stack+0x18/0x1c)
r7:80023a14 r6:00008000 r5:83c13006 r4:803dfd58
[<802d90c8>] (dump_stack+0x0/0x1c) from [<802d915c>] (panic+0x78/0xfc)
[<802d90e4>] (panic+0x0/0xfc) from [<80008ee8>] (mount_block_root+0x25c/0x2ac)
r3:00000000 r2:00000020 r1:83c23f78 r0:8035bd98
[<80008c8c>] (mount_block_root+0x0/0x2ac) from [<80009038>] (prepare_namespace+0x94/0x18c)
[<80008fa4>] (prepare_namespace+0x0/0x18c) from [<800084f8>] (kernel_init+0x128/0x170)
r5:80022248 r4:803def40
[<800083d0>] (kernel_init+0x0/0x170) from [<80046f38>] (do_exit+0x0/0x6a4)
r5:800083d0 r4:00000000
22nd April 2015, 12:53 AM |#221  
Junior Member
Austin, Tx
Thanks Meter: 8
 
More
Quote:
Originally Posted by t-o-f-u

i think it's a lot easier to short together a couple of the address pins than to try to get a single pin on the tsop shorted to ground. ymmv but it'd take some real finesse to touch a grounded lead to that pin in the short time period you have, unless you soldered a jumper wire (again, finesse).

It's actually a lot easier than it sounds, Just take a jumper wire and run it from the holes for the unpopulated ethernet header casing (not the actual pins but the ground points that hold the header in place) or the UART GND point to the 29th pin on the NAND. There are also a number of other random ground points on the board that can be used. If you have a multimeter you can do a continuity test and probably find one in one of the other unpopulated headers. I was able to do it for the video in the first try.

Either method works but I'm leaning towards the GND method being safer.

---------- Post added at 12:53 AM ---------- Previous post was at 12:51 AM ----------

Quote:
Originally Posted by t-o-f-u

i think it's a lot easier to short together a couple of the address pins than to try to get a single pin on the tsop shorted to ground. ymmv but it'd take some real finesse to touch a grounded lead to that pin in the short time period you have, unless you soldered a jumper wire (again, finesse).

Quote:
Originally Posted by dmikester1

Am I correct in assuming that this will work on any firmware?

Yes it does work and will continue to work for all firmware versions of the Wink Hub (based on what the employee at Wink has told me).
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes