Security device made of Misfit tracker

hackaday post 07/2016

Hardware of Misfit fitness tracker (“Misfit Link”/”Misfit Flash”, $15-$30) is converted to a security device by re-flashing with custom firmware. Accelerometer watches for tiny (or not) movements and reports trigger events if predefined conditions are met.

Triggers are delivered via BLE (Bluetooth Low Energy) link to a smartphone device (Android). On triggers smartphone plays sounds (alarms) and/or takes pictures even in the background. At the same time, on trigger events, accelerometer data and device orientation can be recorded to internal memory of the device and later be watched on a smartphone.

After re-flashing, firmware updates or new programs can be uploaded over-the-air with dfu bootloader.

Development includes 2 parts: a) firmware for NRF51822 Nordic Semiconductor MCU (program and bootloader) and 2) Ionic framework Android apk. Android OS >4.4 is needed (BLE support).
Source is available.

Re-flashing is not reversible, fitness trackers becomes new device permanently.

© Mikhail Sharonov, 2016, aka obelix662000

teardown_small_all

Usage scenarios

Attach to a surface. Knock the surface and picture of the scene will be taken. (hidden camera trigger)

Attach to a door, a pipe, a chair, a computer, a purse, a bag, wine bottle etc. Alarm will sound and/or picture will be taken on every touch/move of the object.

Attach to a package, a cat, a window frame. Current orientation of the object is clearly seen remotely. If recorded, can later be analyzed.

Attach to a bed frame, a pipe, a furnace, a pijama, a parcel. Record move events for a period of time (up to months). Latter we can easily see how we move in the sleep, what was cat doing during the day, when furnace/air conditioner was turned on and off, when someone was used the bed and how, how parcel was handled.

​​

Video

Security device video (June, 2016). Turn sound on. (https://youtu.be/XsGhyzCalJk)

Internals

Teardown. Remove plastic ring by applying force with small screwdriver at 3 joints. Take device apart.

teardown_small

Key parts are: NRF51822AA by Nordic Semiconductor MCU+BLE, LIS2DH 3axis accelerometer by STMicroelectronics, button and 12 red LEDs

2 pictures below show pinout of major components to NRF51822 pins. UART is flexible and is assigned by my firmware, it is used for debug purposes only. Release version of firmware does not use UART

bottom_drawtop_draw

Reflashing

NRF51822 chip is protected by Misfit. So to reflash we need to erase the whole chip by hardware way (“erase all” from Keil will not work). According to NRF51822 reference manual, we need first write “erase enabled” (2) to UICR control register at 0x4001e504 address, and then “erase all” (write 1) to “erase all” register at 4001e50c

Here is how it looks for Segger J-link debugger

J-Link>w4 0x4001e504 2
Writing 00000002 -> 4001E504
J-Link>w4 0x4001e50c 1
Writing 00000001 -> 4001E50C
J-Link>

Now we are able to flash the chip with custom firmware.
The firmware consists of 3 parts: 1. SoftDevice (some kind of RTOS developed by Nordic Semiconductor) it is fixed and is a part of SDK, it occupies first ~80 kB of flash memory. 2. Our program which does the job is located above SoftDevice 3. DFU Bootloader, it located at the top of memory space.

~100 kB of free space between top of the program and bottom of the bootloader is used as a storage space for data in a record mode.

At the bottom of the page source code (Keil u-Vision projects, requires Keil+MDK ADM) are available. The “mshdev_firmware” folder must be unpacked to the “SDK_PATH/examples/ble_peripheral” folder of SDK to keep all paths to SDK valid. “mshdev_bootloader” folder is located at the “SDK_PATH/examples/dfu”

The SDK must be installed by “zip” installer way (see https://developer.nordicsemi.com/, SDK v9 was used.

The sequence is: a) flash SoftDevice b) flash the program and run c) flash bootloader. Restart the program. No need to write “bootloader address” and “application valid” to UICR, program does it on its first run automatically.

Alternatively you can flash all 3 parts with provided compiled *.hex files (“Intel hex format” ) , or merge them into one and flash at once (google “mergehex” tool from Nordic).

Short description

There are 3 major states of the device:

a). “OFF”, MCU and accelerometer are off. The only way to wake up is to push the button.

b). “ACTIVE”, consists of two submodes: bb) “ADVERTISING” (1s intervals) this is one-way communication from the device to a smartphone and bbb) “CONNECTED” is two-way communication like wireless UART

c). “DFU”, in this mode device is advertising itself as “dfuTag” and firmware can be uploaded with standard Nordic Semiconductor tools.

To switch device to the “OFF” mode, long push the button. The ring of LEDs light indicates this mode

To wake up from the “OFF” to the “ADVERTISING” mode, short push the button. One LED is flashing indicating advertising. It will turn off in about 15 sec.

To switch to the “DFU” mode, long push (>2s) the button when device is in the “OFF” mode. 3 LEDs will be flashing. DFU mode switches itself to the advertising mode in the case of either a)new firmware uploaded or b) 1 min passed. DFU mode cannot be canceled, if you need to switch dfu off just wait for 1 min until it terminates by itself.

VIDEO: “OFF”-“ADVERTISING”-“DFU” modes and over-the-air firmware update example. (https://youtu.be/SlxVI5KYimM)

Firmware logic

1. “Live” mode. The device and a smartphone are connected. The accelerometer is sending 3 axis data (DC mode) continuously via connected link to a smartphone. A smartphone plots the graph, calculates angles and draws 3D model .

2. “Online alarm”. The device and a smartphone are connected. Predefined trigger conditions are sent to a device. The accelerometer is in AC mode. When trigger conditions are met, the accelerometer issues hardware interrupt. On interrupt, “alarm” state is sent via BLE link immediately, the MCU starts read the accelerometer and continuously sends data over BLE link. If no new trigger conditions occur within predefined “rest interval”, the firmware switches the accelerometer to DC reading, calculates angles and sends it to a smartphone. This is done to get static angles not being affected by acceleration. If new trigger condition occurs within “rest interval” firmware continue reading and sending accelerometer data.

3. “Offline alarm”. The device and a smartphone are disconnected. This mode is useful in case of rare events; it saves battery because two-way connection requires more current. In opposite, a smartphone in this mode is more current consuming, because it is in a scan mode. This mode is also convenient to see current state of the device fast. Just run the program and watch for status and 3D model. In this mode device is sending advertising packets every 1s. Each advertising packet includes name of the device, rssi, battery level, current state of the device and last known angles. The accelerometer is set similar to the above “live alarm” mode, but on interrupt it a) inserts “alarm” to the next advertising packet b) starts reading data to FIFO of the accelerometer, on FIFO fill, it reads the data and picks maximal values of the acceleration (total of 3 axis)(the values are used in the “record” mode only), on FIFO read, FIFO fills again etc. Until “rest interval” conditions are met. (FIFO is used to avoid current consuming MCU at HF clock as much as possible) Firmware calculates angles and inserts it into advertising packet.

live_trigger_firmware2

3. “Record”. The device and a smartphone are disconnected. Same as above but on “at rest” condition it in addition saves timestamp, maximal acceleration and static angles into its own flash memory. Total of about 12000 records are fit. The memory is filled in a circular way. After pointer reaches next sector; it erases it and starts fill with data. At the end of memory it starts writing from the beginning. Data are available until next record request, even if the device is switched off. In addition to the above data, the “record” mode inserts current number of records to the advertising packets.

All time another 3s timer is running to update advertising packets with battery level and current state.

RTC is synchronized on every connection to a smartphone and is running with a great accuracy with 32768 quarz which is a part of the misfit hardware.

Current consumption

Here are approximate valus of average current draw:

1. DFU advertising ~1mA

2. Advertising, “stopped” ~50uA

3. Connected, “stopped” ~200uA

4. Connected, “live” 100Hz ~350uA

5. Offline alarm, 100Hz ~70uA, 10Hz ~57uA

6. Device off ~1uA

Please remember, to measure current, the debugger should be disconnected and the device should be restarted. Otherwise you will see currents in mA range.

Android Apk

The program

Android application is a hybrid ionic framework app. It uses the following plugins and JS libraies:

a) https://github.com/randdusing/cordova-plugin-bluetoothle

Modified (added a function) to send not encoded packets.

Modified to a) make pictures seen in “Pictures” immideately, and b) add proper rotation of the image.

Modified to rotate to absolute angles, not increments.

The “android” part of an ionic project can be downloaded from the “download” section. The apk can be build with Android Studio, “import”-build.cradle; the project does not require anything else to build (no need to install plugins, libraries or frameworks).

Status bar

Apk turns BLE automatically. If not, please check permissions of the app on the smartphone.

The status bar shows connection status. a) If there is nothing displayed on the status bar, the application does not see any BLE packets from the device (the device is off). 2) Battery level and status should be seen immediately after the device is on. 3) Click “CONNECT” menu item to connect. When connected (usually takes 1-10 s) BLE icon appears at right.

off_adv_conn

Menu

Menu list depends on the mode. For example, if the device is just turned on, only “CONNECT”, “FILE”, “EXIT APP” are available.

DISCONNECT

Disconnect the device. The device is still advertising.

DEVICE OFF

Turns the device off completely. The same to long push button. After that the device can be awaken only with button push (short push – advertising, long – dfu, see “the device” page)

EXIT APP

!IMPORTANT!

Application can run in the background. If forgotten it may drain battery of a smartphone. If application is terminated from the background by android’s swipe- out way, BLE is still running.
The best way to terminate the application is “EXIT APP” menu item, it both suspends application from running in the background and switches BLE off.
“EXIT APP” does nothing to the device.
Smartphone’s hardware “back” button is programmed to perform the same action as “EXIT APP” menu item.

menu

Graph

To “zoom” swipe the area from left to right. To “pan” use cross icon at top right of the graph. To reset click “reload” icon at the right-top of the graph. To see value labels click to the line or column on the graph.

Orientation

At zero angles 3D model is shown from some predefined viewpoint. The zero-angles view can be adjusted by swiping the screen left-right, top-bottom (in the “stop” mode).

To reset to default view click pitch or roll angles.

If there are multiple data loaded with “read record” or “file load” the data can be navigated with “next-right”, “next-left” buttons or played (consequence click to “play” will call frames with 1s, 0.5s, 0.2s, 0.1s intervals (x1,x2,x4,x8), to stop click “next-left” or “next-right” button);

model

Settings

PERFORMANCE

How fast the device sends data

Graph and model drawing performance depends on a smartphone. If a smartphone gets unresponsive, reduce stream period, and/or increase graph/model update periods

Were to save/load files. “File” menu

ACCELEROMETER

Full range, resolution is 10 bits from -range to +range, e.g. at 2g resolution is 4mg/digit

settings1
settings2.png
settings3.png

TRIGGER

1 step is ~4x resolution of the accelerometer, e.g. at 2g of full scale 1 step is 16mg

time interval after which angles are calculated and reported (see “the device” page for the diagram)

Select combination of axes and logic to generate trigger event

At what frequency accelerometer does sampling (both “live” and “offline”) and at what frequency FIFO is filled (“offline” modes). Higher frequency means more accurate response. (higher is better).
On the other hand, higher frequency means also more current consumption by the accelerometer: 10Hz: 4uA, 50Hz: 11uA, 100Hz: 20uA, 200Hz: 40uA. Total battery drain is this current +MCU activity (calculation etc.) current+BLE current.

ACTION

Disallows (unchecked) alarms and photos in “record” mode regardless of “play sound” and “take photo” settings. Allows if “play sound” and/or “take photo” are set (AND logic to them).

Play alarm sound on trigger conditions. Select sounds from the dropdown list

How long the alarm is played.

How much time should pass until next alarm/photo will be allowed. To filter frequent alarms/photos.

Enabler, back or front camera, folder to save photos

Another filter to pictures. Maximal number of photos allowed. Now# shows current number of pictures taken since the program start. If new max. number is entered, current number resets to zero.

There are two categories of the settings. Device related (stream period, accelerometr and trigger settings etc) and apk related (folders, alarm on/off alarm/photos settings, etc.). Device related setting require the “connection” state. If the device is disconnected, warning dialog will be shown and the settings in the app’s fields will be restored. Nontheless apk related settings will be applied regardless of connection state and warning dialog. This is done to have a chance to change alarms without interference with the “offline” modes of the device. Note “atRecord” checkbox belongs to device’s setiings, since it is used by the firmware. In any case aftr “APPLY” button click the apk shows actual data on the screen.

DFU ZIP maker

Nordic Semiconductor dfu protocol requires “application.zip” file which is *.hex file and some “*.dat” file (CRC, and preamble). This PC windows program creates “application.zip” file from firmware “*.hex” file.

Just browse to the “*.hex” file (e.g. created with Keil) and ready-to-dfu-upload “application.zip” file will be created in the program’s folder. For the DFU upload procedure please watch “techical info 1” video at the “the device” page.

dfu_zip.png

Firmware source| firmware Keil prj |mshdev_firmware_keil.zip (~118kB)

SoftDevice hex |SoftDevice hex (part of SDK) |s110_softdevice.zip (~97kB)

DFU ZIP maker |windows program |dfu_zip_maker.zip (~370kB)

DFU bootloader source |bootloader Keil prj |mshdev_bootloader_keil.zip (~77kB)

Firmware hex |firmware hex file |mshdev_firmware_hex.zip (~28kB)

Bootloader hex |bootloader hex file |mshdev_bootloader_hex.zip (~15kB)

Android apk source |android apk source | android_source_apk.zip (~24MB)

Android apk | android apk |mshdev_apk.zip (~4MB)

1 Comment

Comments are closed.