Possible fix deployed by Amazon ?

[ggiraudon]

Hi Hunz,

Great work on this project. Looked like a fun thing to do so I thought I would give it a try.
I was able to find the UART pins easily enough and am able to see the output.
That being said, the assembled audio doesnt seem to trigger code execution.

Here is an exerp of what I see in the debug console :

    ****    TAOS Bootloader 0.2.11    ****
0x00000004  ms    0x000000FB  us
Reset Trigger : FIRST POWER UP
(APP)(INFO)Chip ID 1503a0
FOPP)(INFO)DriverVerInfo: 0x134a134a
(APP)(INFO)Firmware ver   : 19.4.10 Svnrev 12577
(APP)(INFO)Firmware Build May 10 2016 Time 00:50:07
(APP)(INFO)Firmware Min driver ver : 19.3.0
(APP)(INFO)Driver ver: 19.4.10 Svnrev 12577
(APP)(INFO)Driver SVN URL branches/WIFIIOT-1400_2
(APP)(INFO)Driver built at Jan 11 2017	19:23:49
DBG: Set MAC address [redacted]
DMA OVERRUN
DMA OVERRUN
Invalid Packet Length
Invalid Packet Length
Invalid Packet Length
Invalid Packet Length
Invalid Packet Length
Invalid Packet Length
Invalid Packet Length
Invalid Packet Length
Invalid Packet Length
Shutting Down

As you can see, every time I send an audio packet, I get "Invalid Packet Length".
After reviewing your demo video, I noticed one thing : It looks like the Driver build date is different (mine seems to be newer).

Could that be the cause ?
Everything else seems to be the same....

I'm attaching the raw and wav files I generated with your script just in case you might want to compare them with yours. (Lua complained when running assemble, it gave me a " lua: assemble.lua:7: =' expected near function' " but the raw file still did get generated and looked legit - I'm using LUA 5.0) .

If you have any insights, I'd love to hear them :-)

Kind regards,

Mad Beggar

clorox-button-payload.zip

[znuh]

Yes I recently heard from someone else that they fixed the overflow. So a new exploit is needed, but to me the dash button hack was a one time thing. I haven't done anything with the buttons since then and I'm not planning on digging into it again, sorry. Maybe someone else will.

[ggiraudon]

No problem. Thanks for the great work in any case. I'm going to continue digging.
Out of curiosity, I had a question regarding your presentation.
In one of your slides, you have a picture of a little breakout board you made to read the flash with a Rasp Pi and flashrom.
I'm trying to do the same by following the docs from Micron (but havent succeeded yet).
What cought my attention is that the pinout you seem to be using between the flash and the header doesnt seem to match the pinout on the Pi.
So I was curious, did you board work by plugging it directly into the Pi's GPIOs ? Or did you wire things between you breakout board and the Pi ?
(For example, you seem to have VCC and VSS going to 2 pins that are side by side on the GPIO header but there is no such instant on the Pi's pinout)

Cheers,
MadBeggar

[znuh]

I made a custom PCB for this. Vcc needs to be connected to 3.3V and Vss to GND.

[ggiraudon]

Hi again Hunz

I was wondering if it wouldnt be too much trouble for you to take a very quick look at what I have in https://github.com/ggiraudon/Dashv2-internals .
In particular at the file called dash-flash-dump.bin

I have managed to dump the flash as you did but I'm hitting a snag :

The vector table is where is should be (0x00404200) and the addresses seem legit :

ROM:00404200 DCD 0x200204D0 ; Start of vector Table = Initial SP
ROM:00404204 DCD 0x433EED ; Reset
ROM:00404208 DCD 0x433FBD ; NMI
ROM:0040420C DCD 0x433FBD ; Hard Fault
ROM:00404210 DCD 0x433FBD ; Memory Management Fault
ROM:00404214 DCD 0x433FBD ; Bus Fault
ROM:00404218 DCD 0x433FBD ; Usage Fault
ROM:0040421C DCD 0 ; [reserved]
ROM:00404220 DCD 0 ; [reserved]
ROM:00404224 DCD 0 ; [reserved]
ROM:00404228 DCD 0 ; [reserved]

but if I jump to 0x433EED, what I find doesnt seem to be a valid ARM instruction :

ROM:00433EE9 DCB 0x3E ; >
ROM:00433EEA DCB 0x43 ; C
ROM:00433EEB DCB 0
ROM:00433EEC DCB 0
ROM:00433EED DCB 0xB5
ROM:00433EEE DCB 0x85
ROM:00433EEF DCB 0xB0
ROM:00433EF0 DCB 0x25 ; %
ROM:00433EF1 DCB 0x4B ; K
ROM:00433EF2 DCB 3
ROM:00433EF3 DCB 0x93
ROM:00433EF4 DCB 0x25 ; %
ROM:00433EF5 DCB 0x4B ; K
ROM:00433EF6 DCB 2
ROM:00433EF7 DCB 0x93
ROM:00433EF8 DCB 3
ROM:00433EF9 DCB 0x9A
ROM:00433EFA DCB 2
ROM:00433EFB DCB 0x9B
ROM:00433EFC DCB 0x9A
ROM:00433EFD DCB 0x42 ; B

Is it possible that I could have missed something ?

Thanks in advance

MadBeggar

[znuh]

you need to jump to 0x433EEC because the last bit of the address is used to keep thumb2-mode enabled.

[ggiraudon]

Thanks a lot Hunz, that explains a lot. I was able to reverse part of the arm code.
Obviously however, I'm missing a chunk of the rom (between 0x00400000 and 0x00404000).
Would you mind sharing your dump of that section ? Or does it contain too much personal/proprietary information ?

[badbeef]

Sorry to stir up this issue again. I understand this exploit is fixed. But is it fixed only for new Dash buttons or does old Dash buttons also get updated firmware when they phone home? Reason is I bought a bunch of them while on sale so this project could still be very useful to me.

[ggiraudon]

All buttons get updates so they are probably already patched or fixed.
I'm still working on them when I have time to waste here and there. At this point I'm focusing of the built-in web stack to see if something can be do via that door but I havent found anything conclusive yet.
You can still use them by detecting their DHCP requests... it works, just not very elegant :-)