yashsingh1/xdaforums huggingface dataset:
[Off-topic] t-o-f-u:
flash on the wink is http://www.spansion.com/Support/Datasheets/S34ML01G1_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:

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.
[Off-topic] t-o-f-u:
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
[Off-topic] 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:

[YOUTUBE]ErynYK9l41M[/YOUTUBE]

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.
[Off-topic] iSecks:
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!
[Off-topic] roto22:
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.
[Off-topic] bdjohns1:
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.
[Off-topic] 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).
[Off-topic] zeroepoch:
Changing the u-boot delay

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.

=> 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:

$ 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.

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

#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
[Off-topic] zeroepoch:
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.
[Off-topic] dmikester1:
Am I correct in assuming that this will work on any firmware?
[Off-topic] grantmc:
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
[Off-topic] Zenofex:
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 ----------

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).
[Off-topic] optikshell:
So, I've successfully gained root access by following the video/write-up and shorting the GND to 29th pin on the NAND (executed setenv bootargs 'noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi init=/bin/sh'

and

nand read ${loadaddr} app-kernel 0x00400000 && bootm ${loadaddr}).

However, I'm not really sure what to do next... as all of the previous guides rely on the "curl..." variations. I'm pretty sure this is a stupid question, but after digging around the forum post, and 5-6 other guides, I don't see one that directly applies after gaining root access via the NAND pin 29 short.

Thanks in advance.
[Off-topic] zeroepoch:
It worked for me with updater 00.08 and rootfs 00.86. I never rooted my wink hub before and I always just hit ok when it asked me to perform an update. Unless they update the bootloader to halt instead of returning to the prompt when something fails to load this should continue to work. I could be wrong but I think the bootloader is in /dev/mtd0 which isn't even listed in the update file at https://wink-hub-images.s3.amazonaws.com/00.01/upgrade_00.01.txt.
[Off-topic] zeroepoch:
IMO the simplest approach is to first enable root through the UART and then reboot normally and work on getting SSH access using other guides. Once you have UART access it will be like you used the PHP hacks to enable SSH authorized_keys and SSH'd in.

$ vi /etc/inittab
# uncomment this line
ttyAM0::respawn:/sbin/getty -L ttyAM0 115200 vt100 # GENERIC_SERIAL
$ passwd
# enter new root password twice
$ sync

"reboot" doesn't work when init=/bin/sh so "sync" and then hit the reset button. I'd recommend changing the bootdelay while you're working on it (reset it back to 0 before reassembly) just so you don't need to jumper the pins on the flash more than once.

---------- Post added at 12:37 AM ---------- Previous post was at 12:08 AM ----------

It looks like your rootfs got corrupted. You can boot into the updater and rerun the updater script (might do that on it's own after the network is up) which will reflash the app partition and kernel. From the app partition you can rerun that updater script to reflash the updater partition and that kernel. If you reformat the database partition before starting all this then you'll pretty much have reflashed everything but the bootloader.

In u-boot, do printenv, and look for updater_args and updater_boot, which mirror appboot_args and app_boot. You will need to use the init=/bin/sh trick as well on the updater and then enable UART access by changing inittab and setting the root password. You should also format the database partition using instructions I posted earlier since it might be messed up as well. We finally boot normally into the updater with root. You'll need to connect to the network and then it should reflash the app partition and kernel. Once you boot with root the app partition you can run /root/platform/upgrade.sh to reflash the updater partition and kernel. It's the same script in the updater partition as the app partition if you wanted to force it in case it doesn't happen on network connect. If you don't reformat the database partition you should at least remove /database/cf_fver*. Otherwise it won't think an update is needed.

Sorry if this sounds like a lot of steps and vague detail for each step, but to explain it all with actual commands would take quite a while. After getting access by shorting a bunch of random pins with a screw driver I went though this process to get everything back into a clean state. I think only /database was messed up for me. It took a few hours to get a grasp on the reflashing process and to get everything pristine. If you get stuck then just ask.
[Off-topic] grantmc:
Thanks. I was able to boot into the updater partition and reformat it with the steps below. I then was able to boot into single-user mode and make my changes. It's working now.

ubiformat /dev/mtd5 -f /tmp/app-rootfs.ubi
ubiattach -p /dev/mtd5
[Off-topic] rp1831:
bad PEB handling and broken upgrade image

First, great thread. It's been great fun trying to recover my hub with the info here. Thanks!

I used my arduino to perform the UART short hack and gained root. I encountered a similar corruption issue as previously reported on this thread and was able to solve it by reflashing the ubi image. I made partial progress updating the app-rootfs, but now I have encountered a couple issues I'm stuck on.

1. The bootloader interface complains when trying to attach the database partition, despite the fact that when the app boots it is accessible:

=> ubi part database
UBI: mtd1 is detached from ubi0
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 126976 bytes
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 2048 (aligned 2048)
UBI: data offset: 4096
UBI warning: ubi_eba_init_scan: cannot reserve enough PEBs for bad PEB handling, reserved 1, need 2
UBI error: ubi_wl_init_scan: no enough physical eraseblocks (0, need 1)
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -28
UBI init error 28

I tried formatting the database partition as suggested earlier and it doesn't seem to have worked. I don't believe it did this before. Does anyone know how to fix this error, or if it's even a problem? It does seem to prevent the database fs from being mounted during boot, and therefore the bootloader can't examine the content of DO_UPGRADE. The effect was originally that the upgrade partition would always load. Until...

2. The (or my) upgrade process on the app seems to have broken the upgrade partition, in the bootloader:

=> run updater_boot
NAND read: device 0 offset 0x300000, size 0x300000
3145728 bytes read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!

I tried downloading the updater-rootfs and flashing it to the correct MTD, but that didn't fix it. I might also have borked the updater-kernel partition at some point, and I tried to flash the updater-uImage downloaded from aws and recieved an error saying the image length was not divisible by the block size. I'm not sure what I did here, but has anyone successfully reflashed the kernel images? Any other suggestions?
[Off-topic] rp1831:
Nevermind, I missed the post here that shows how to flash the update kernel image. I think I'm back in business.
[Off-topic] trunzoc:
Are either of these the proper item to have for step 2?

http://www.amazon.com/PL2303HX-RS23...m_sbs_e_1?ie=UTF8&refRID=1GAMF9NEVBYRQW8S4FA4

http://www.amazon.com/JBtek®-WINDOW...id=1430311447&sr=1-2&keywords=microusb+To+TTL

I've never done something like this, but have a couple new spare hubs that have never been plugged in. The old root methods don't work on them, so willing to try this.
[Off-topic] Zenofex:
Yes, either of those two will work. Also, Fry's sells a USB to FTDI adapter for ~15.00 if you want something local, otherwise there's always the eBay option which can get you one for around $2 to $3 but can take a few weeks.
[Off-topic] trunzoc:
Thanks for the quick response. I'd rather spend the extra $3 and get it from Amazon tomorrow :D (I live 25 miles from a distro hub, so Prime = tomorrow)
[Off-topic] trunzoc:
I got the cable and soldered it on. This IS 3.3v right? The cable came setup for 5v, but I moved the wire on the connector over to the 3.3v point.

When I plug it in, turn it on and fire up Putty using the serial com connection, all I get is gibberish. I double checked and made sure everything was firmly and cleanly soldered.

Is that normal over serial, or should I be seeing real text?
[Off-topic] shaddie:
I ran into the same issue yesterday. The serial speed is much higher: 115200 or something.

The details on how to do the rest of this process are a complete mystery to me. I jumped the pin to ground a lot and probably corrupted my root FS. I never could get to what they did in the video though.

I'll post some logs in a bit -- hopefully someone can point out what i'm doing wrong. I couldn't find anyone mention the actual timing of this trick.

---------- Post added at 12:40 AM ---------- Previous post was at 12:26 AM ----------

I'm actually kind of embarrassed. As soon as I wrote that, I figured out wtf to do.

So, in short, most of this video posted isn't the "trick." I failed to realize that and had the timing way way off. I wish there were a few more notes or an explanation of whats happening in the video. I'm dumb. :(

To do this, you really start about 1.5 seconds into the power on process, and you simply jump from pin 29 to the empty ethernet ground solder point. It drops you to a console that looks like =>

Then you do the append for init and stuff.

For ground, I used the C282 outline and the point closest to the NAND chip.

The part I was doing wrong is that.. the video shows a ton. Really, the video at about 1:10 seconds is the actual process. He boots, bridges the connection, and immediately falls into the unsecure mode. There were other parts in the video, especially the beginning, that lead me astray.

Now to fix my rootfs as the other guys explained.
[Off-topic] trunzoc:
That 115200 did it. I get real text now. Thanks for that. Let see if I can get the rest done based on your edit as well.
[Off-topic] shaddie:
Fixed the rootfs pretty easily.

Someone summarized the general idea but I had problems lol

Shortened version:

Use the pin trick to get to the unsecure loader as described above.

setenv bootargs 'noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=2 root=ubi0:rootfs rw gpmi init=/bin/sh';

run updater_args && nand read ${loadaddr} updater-kernel 0x00300000 && bootm ${loadaddr}

Please note: I use the full line, which included the updater script. That first bit I think runs the updater and mounts the database mtd3. It all worked out though somehow. My database wasn't corrupt, or it got cleared by the rootfs wipe.

Anyway, next up you should be in the backup / updater partition.

At this point, I brought my network up. Change the XX's to the right thing.

curl "hXXp://192.168.0.1/index.php" -d '{"ssid":"my_ssid","pass":"my_wifi_password"}'

Download the rootfs. I have no idea how to get the current version but this one at least made my hub work again. Change the XX's to the right thing.

cd /tmp

wget hXXp://wink-hub-images.s3.amazonaws.com/00.01/app-rootfs.ubi

Format the real rootfs

ubiformat /dev/mtd5 -f /tmp/app-rootfs.ubi

I'm not sure if this is needed or not, but I did it just in case.

echo "0" > /database/DO_UPDATE

After a reboot and following the normal steps I'm at a root console. I did have to do the update again to get off the .01 version or whatever.

^_^

My reference:

hxxp://winkhubroot.wordpress.com/
[Off-topic] jconnell:
Has anyone figured out how to get it to boot without returning this value to zero?
[Off-topic] zeroepoch:
You need to trick the wink hub into thinking you have a serial device attached to the UART. To do this jumper together the RX and 3V3 pins on the UART. After doing a bit of quick research I found out that the RS-232 protocol idles high (mark) instead of low (space) hence the need to jumper to 3V3 instead of GND. When I attached only TX, so I could see what the hub was doing, it was stuck at the u-boot prompt.
[Off-topic] LivinOne:
Thanks to this thread I got my Wink running... thank you all!
[Off-topic] jeze519:
If you brick the device try running the below commands

setenv bootargs 'noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi init=/bin/sh'

setenv bootargs 'noinitrd console=ttyAM0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs rw gpmi badupdater'

nand read 0x42000000 app-kernel 0x00400000; bootm 0x42000000

This will boot the wink into a badupdater partion with ssh access.
[Off-topic] BJHiltbrand:
So, does this method work with hubs that shipped with the 0.89 firmware? I ask because I hooked up my UART to USB adapter and got no output in PuTTY. I'm not sure if I should see anything there during a normal boot, or not. Without console output, I don't know when / how to jumper the leads or to initiate arguments.
[Off-topic] duckstab:
Yeah, you should see it booting. Something's not hooked up right or configured right in your terminal program I'd guess.
[Off-topic] CantSleepAWink:
Missed something - Bricked the Wink

So I followed the steps to perform the NAND Flash exploit detailed earlier in the thread.

I was attempting to connect pin 29 to the UART ground (though before that I tried the Ethernet cage, as mentioned earlier in the thread), and must have done something wrong.

*edit* I've successfully gotten in and used the following commands:

=> setenv bootdelay 1
=> saveenv

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}

To get into the filesystem. However, when I let it boot normally, I still get the below:

Once it gets to

Launch upgrade script
+ /root/platform/run_upgrade.sh
+ FILE=/tmp/isalive

It will loop continually at this:

+ '[' '!' -e /tmp/isalive ']'
+ sleep 1

Is there a way to recover, or should I make my second exchange :eek: (The first was actually for the same reason, but I didn't get into the device due to stupidity in Putty config).

There were a few other failures before this behavior was exhibited, however.

I should also mention that I may have done something very silly - I ran this, and may have screwed everything up. You see, I had paired the wink with my phone, and updated the wink. When I first saw the loop above, I ran this (really without thinking about the consequences)

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

Ideas? I really garfed it up.
[Off-topic] Unheard:
EDIT EDIT:

Fixed it, had to clear out the wpa_xxx file (can't remember the name)

-------

EDIT:

Ok, the Wink's AP is up and running, and I can connect, but all I get is the Home Page text from the index.php when I try to browse the IP. I feel like I'm getting close, but the Wink still has no external access to the web. Is there an alternate method I can push the UBI?

--------

Trying to figure this out. I managed to soft-brick the wink during NAND booting to a root shell (not sure how), but it now boots to a BUS ERROR.

I am able to U-BOOT into a BADIMAGE shell based on another posts recommendation. My issue is trying to get the unit connected to my WiFi so I can download an update image to recover the Wink.

I follow the directions and this is what I am getting:

(UnheardNet.Legacy is my 2.4ghz N AP)

Any thoughts or suggestions?
[Off-topic] GenesisFactor:
I have a question to all at the bottom :). Before that, i wanted to offer some assistance:

I went through what you did, CantSleepAWink

ps -ef will get you a list of the PID. find the one that says run upgrade.sh. Mine were usually about 1120s or 1130s

kill -9 <pid#>

kills that annoying loop.

Then, follow http://www.rootwink.com/viewtopic.php?f=6&t=4, which i used to update the winkhub and fixed it mostly. (i have a problem too) :)

Hope that helps.

ONTO MY QUESTION

right now i get this error when trying to connect to wifi. It blinks blue for a few minutes, but then does nothing but sends these errors about 3 or 4 times. ifconfig returns nothing

dhd_aoe_hostip_clr failed code -23
ace_update_host_ipv4_table_failed

any ideas on ?
[Off-topic] BuckSinister:
I am interested.

Would you send me the old firmwares. I am trying to downgrade my newly purchased hub using a man in the middle attack. I am documenting teh procedure and if i get to work i will send you the instructions.

e
[Off-topic] jconnell:
How do I return the wink hub to stock?