Chase Kanipe
by Chase Kanipe
May 13, 2021

For this project I did a partial analysis of the Wyze V2 Camera. It's a small camera that allows one to live stream video in 1080p to your phone from anywhere. It also supports motion/sound recording with cloud storage via AWS. This data can also be stored to an SD card.

Extracting the firmware

Extracting the firmware proved to be the most time-consuming challenge of this project. Initially, I downloaded several versions of the firmware from their website and extracted them using binwalk. These images turned out to be diffs though, so they weren't sufficient for analysis.
My second attempt at extracting the firmware was to read it over SPI from a small chip inside the camera. Unfortunately the equipment I had available was very limited. While I did have a bus pirate, the soldering iron I had avaliable's tip was much too large to solder onto the tiny chip legs, and the jumper cables I used were as thick as the legs themselves. These hardware limitations made it difficult to solder the last two jumper cables to the legs, and the connection was never stable enough for the bus pirate to read a complete firmware image.
Eventually, Matt from Margin Research found a public repo called WyzeHacks, which had various tools for augmenting the Wyze firmware. He used this to install a backdoor into the camera so that binaries could be pulled off the device. Below is my analysis of a file he sent me.

Manual Reverse Engineering


I began my analysis process with a manual analysis of the hl_client binary using Radare2. Hoping to find some low-hanging fruit, I started by looking for cross references to commonly vulnerable library calls. Here I get a list of imports, filtering to those containing the string "str".

[0x0041112c]> ii~str
4   0x004015dc GLOBAL FUNC       strcpy
37  0x004017bc GLOBAL FUNC       strnlen
51  0x0040185c GLOBAL FUNC       strstr
54  0x0040188c GLOBAL FUNC       strncmp
57  0x004018bc GLOBAL FUNC       strncpy
76  0x0040199c GLOBAL FUNC       strcmp
96  0x00401aac GLOBAL FUNC       strlen
97  0x00401abc GLOBAL FUNC       strchr

This binary imports strcpy, a potentially dangerous function.

[0x0041112c]> axt strcpy
sym.read_IP_file 0x401ba8 [CALL] jal strcpy
sym.msgarrv 0x40370c [CALL] jal strcpy
sym.msgarrv 0x4039ac [CALL] jal strcpy
sym.print_string_ptr 0x413d60 [CALL] jal strcpy
sym.print_object 0x416060 [CALL] jal strcpy
sym.iot_get_log_handler 0x418a3c [CALL] jal strcpy
sym.iot_delete_sensor_handler 0x419000 [CALL] jal strcpy
sym.iot_bind_cancel_handler 0x41952c [CALL] jal strcpy

Manual analysis revealed that most of the uses are innocuous. For example, copying static strings embedded in the binary to an appropriately sized buffer. However, at least one of them appears to be vulnerable to a stack buffer overflow. We'll start by disassembling the block containing the relevant cross reference.

:> pdb 0x401b64
¦           0x00401b64      b800c48f       lw a0, 0xb8(fp)
¦           0x00401b68      4200023c       lui v0, 0x42
¦           0x00401b6c      689b4524       addiu a1, v0, -0x6498
¦           0x00401b70      9470100c       jal fopen           ; Opens file
¦           0x00401b74      00000000       nop
¦           0x00401b78      1800c2af       sw v0, 0x18(fp)
¦           0x00401b7c      2400c227       addiu v0, fp, 0x24
¦           0x00401b80      21204000       move a0, v0
¦           0x00401b84      01000524       addiu a1, zero, 1
¦           0x00401b88      80000624       addiu a2, zero, 0x80
¦           0x00401b8c      1800c78f       lw a3, 0x18(fp)
¦           0x00401b90      8470100c       jal fread           ; Reads data from stream
¦           0x00401b94      00000000       nop
¦           0x00401b98      2000c2af       sw v0, 0x20(fp)
¦           0x00401b9c      2400c227       addiu v0, fp, 0x24
¦           0x00401ba0      b000c48f       lw a0, 0xb0(fp)
¦           0x00401ba4      21284000       move a1, v0
¦           0x00401ba8      bc6f100c       jal strcpy          ; Copies data until \0
¦           0x00401bac      00000000       nop

It appears that this code opens a file and copies the data, regardless of size, to a buffer. We can get cross references to the function:

sym.getServerStr 0x401ce8 [CALL] jal sym.read_IP_file

Disassembly of getServerStr is shown below:

[0x00401ca4]> pdb
            ; CALL XREF from sym.client_ParamInit @ 0x403dc4
+ 124: sym.getServerStr (int32_t arg1, int32_t arg3, int32_t arg_18h);
¦           0x00401ca4      d8ffbd27       addiu sp, sp, -0x28
¦           0x00401ca8      2400bfaf       sw ra, 0x24(sp)
¦           0x00401cac      2000beaf       sw fp, 0x20(sp)
¦           0x00401cb0      21f0a003       move fp, sp
¦           0x00401cb4      1800c0af       sw zero, 0x18(fp)
¦           0x00401cb8      4300023c       lui v0, 0x43
¦           0x00401cbc      e0e24424       addiu a0, v0, -0x1d20
¦           0x00401cc0      21280000       move a1, zero
¦           0x00401cc4      80000624       addiu a2, zero, 0x80
¦           0x00401cc8      9870100c       jal memset
¦           0x00401ccc      00000000       nop
¦           0x00401cd0      4300023c       lui v0, 0x43
¦           0x00401cd4      e0e24424       addiu a0, v0, -0x1d20
¦           0x00401cd8      1800c227       addiu v0, fp, 0x18
¦           0x00401cdc      21284000       move a1, v0
¦           0x00401ce0      4200023c       lui v0, 0x42
¦           0x00401ce4      949b4624       addiu a2, v0, -0x646c
¦           0x00401ce8      b306100c       jal sym.read_IP_file
¦           0x00401cec      00000000       nop
¦       +-< 0x00401cf0      04004014       bnez v0, 0x401d04
¦       ¦   0x00401cf4      00000000       nop

It appears that there's a buffer overflow from reading and copying the file /configs/IOT_server.txt. The data is read into a fixed size buffer, but its length is unbounded due to the use of strcpy. This could lead to a stack buffer overflow.


We can also look around for any format string vulnerabilities. We'll start by getting cross references to printf:

[0x0041bf00]> axt
sym.read_IP_file 0x401af8 [CALL] jal printf
sym.common_process_data 0x401d8c [CALL] jal printf
sym.parse_action 0x401fb4 [CALL] jal printf
sym.parse_action 0x402188 [CALL] jal printf
sym.parse_action 0x4021cc [CALL] jal printf
sym.parse_action 0x402210 [CALL] jal printf
sym.parse_action 0x402254 [CALL] jal printf
sym.parse_action 0x402298 [CALL] jal printf
sym.msgsend 0x4028c8 [CALL] jal printf
sym.msgsend 0x402928 [CALL] jal printf
sym.delta_handler 0x40298c [CALL] jal printf
sym.delta_handler 0x402b28 [CALL] jal printf
sym.delta_handler 0x402b9c [CALL] jal printf
sym.delta_handler 0x402c74 [CALL] jal printf
sym.get_shadow_handler 0x402cf4 [CALL] jal printf
sym.get_shadow_handler 0x402e54 [CALL] jal printf
sym.get_shadow_handler 0x402ec8 [CALL] jal printf
sym.get_shadow_handler 0x402fa0 [CALL] jal printf
sym.msgarrv 0x403038 [CALL] jal printf
sym.msgarrv 0x4030d4 [CALL] jal printf
sym.msgarrv 0x403178 [CALL] jal printf
sym.msgarrv 0x403334 [CALL] jal printf
sym.msgarrv 0x403438 [CALL] jal printf
sym.setTopic 0x403b28 [CALL] jal printf
sym.setTopic 0x403b5c [CALL] jal printf
sym.setTopic 0x403b90 [CALL] jal printf
sym.setTopic 0x403bc4 [CALL] jal printf
sym.disconnectCallbackFunc 0x403d68 [CALL] jal printf
sym.client_ParamInit 0x403ddc [CALL] jal printf
sym.client_ParamInit 0x403ec0 [CALL] jal printf
sym.clientMqttConnect 0x403f8c [CALL] jal printf
sym.clientMqttConnect 0x403fb0 [CALL] jal printf
sym.clientMqttConnect 0x4040ac [CALL] jal printf
sym.clientMqttConnect 0x4040cc [CALL] jal printf
sym.aws_iot_subscribe_publish 0x404608 [CALL] jal printf
sym.get_message_handler 0x4047e0 [CALL] jal printf

The full list is rather long. We'll filter it down by constructing a command to see if each use is preceded by a format string. We can get the full list of cross references with the axt printf command. We can filter this list to just the offsets by getting the column using ~[1] and we'll write it to a file using > offsets.txt. The full command is as follows.

[0x0041067c]> axt printf~[1] > offsets.txt

We can cat this list (truncated).

[0x0041067c]> !cat offsets.txt

We can print the full block for each offset using the pdb command. We can iterate this command over the list using @@, giving us the full command below.

[0x0041067c]> pdb @@.offsets.txt

We can then scan through this output, making sure each use of printf has a corresponding static format string. All uses of printf appear to be secure, except for possibly one.

:> pdb
¦           ; CODE XREF from sym._iot_tls_verify_cert @ 0x410644
¦           0x0041068c      4200023c       lui v0, 0x42
¦           0x00410690      60b24424       addiu a0, v0, -0x4da0
¦           0x00410694      4200023c       lui v0, 0x42
¦           0x00410698      38b94524       addiu a1, v0, -0x46c8
¦           0x0041069c      3a000624       addiu a2, zero, 0x3a
¦           0x004106a0      c06f100c       jal printf
¦           0x004106a4      00000000       nop
¦           0x004106a8      2c04c28f       lw v0, 0x42c(fp)
¦           0x004106ac      0000428c       lw v0, (v0)
¦           0x004106b0      1800c327       addiu v1, fp, 0x18
¦           0x004106b4      21206000       move a0, v1
¦           0x004106b8      00040524       addiu a1, zero, 0x400
¦           0x004106bc      4200033c       lui v1, 0x42
¦           0x004106c0      c0b26624       addiu a2, v1, -0x4d40
¦           0x004106c4      21384000       move a3, v0
¦           0x004106c8      c06f100c       jal printf
¦           0x004106cc      00000000       nop
¦           0x004106d0      0a000424       addiu a0, zero, 0xa
¦           0x004106d4      b46f100c       jal fcn.0041bed0
¦           0x004106d8      00000000       nop
¦           0x004106dc      4200023c       lui v0, 0x42
¦           0x004106e0      60b24424       addiu a0, v0, -0x4da0
¦           0x004106e4      4200023c       lui v0, 0x42
¦           0x004106e8      38b94524       addiu a1, v0, -0x46c8
¦           0x004106ec      3b000624       addiu a2, zero, 0x3b
¦           0x004106f0      c06f100c       jal printf
¦           0x004106f4      00000000       nop
¦           0x004106f8      1800c227       addiu v0, fp, 0x18
¦           0x004106fc      21204000       move a0, v0
¦           0x00410700      0470100c       jal fcn.0041c010
¦           0x00410704      00000000       nop
¦           0x00410708      0a000424       addiu a0, zero, 0xa
¦           0x0041070c      b46f100c       jal fcn.0041bed0
¦           0x00410710      00000000       nop 

We can see that the second printf in this basic block uses a buffer passed into the function as the format string. When manually tracing this back, we can see this is tainted by a AWS related network call. It's hard to determine through manual static analysis if this is exploitable. There's a lot of code between the network call and the use, so it would be best to test this dynamically.

Heap Issues

We can also look for heap related issues like use-after-frees, double frees, unchecked malloc returns, etc. By searching through the functions that call free, we can build a list of potentially interesting functions which may have heap bugs.

[0x00419818]> axt
(nofunc) 0x400c18 [UNKNOWN] invalid
sym.msgarrv 0x403a50 [CALL] jal
sym.upload_resend_list_again 0x405510 [CALL] jal
sym.upload_resend_list_again 0x405544 [CALL] jal
sym.cJSON_InitHooks; 0x4123a4 [DATA] addiu v1, v1,
sym.cJSON_InitHooks; 0x412408 [DATA] addiu v0, v0,
sym.cJSON_Delete 0x41252c [CALL] jalr t9
sym.cJSON_Delete 0x412570 [CALL] jalr t9
sym.cJSON_Delete 0x412588 [CALL] jalr t9
sym.ensure 0x412be0 [CALL] jalr t9
sym.ensure 0x412c4c [CALL] jalr t9
sym.print_array 0x4150a8 [CALL] jalr t9
sym.print_array 0x4150e0 [CALL] jalr t9
sym.print_array 0x4151f8 [CALL] jalr t9
sym.print_array 0x415230 [CALL] jalr t9
sym.print_object 0x415c38 [CALL] jalr t9
sym.print_object 0x415e60 [CALL] jalr t9
sym.print_object 0x415ea8 [CALL] jalr t9
sym.print_object 0x415ee0 [CALL] jalr t9
sym.print_object 0x415ef8 [CALL] jalr t9
sym.print_object 0x416110 [CALL] jalr t9
sym.print_object 0x41613c [CALL] jalr t9
sym.print_object 0x416174 [CALL] jalr t9
sym.print_object 0x41618c [CALL] jalr t9
sym.cJSON_AddItemToObject 0x416560 [CALL] jalr t9
sym.cJSON_AddItemToObjectCS 0x416618 [CALL] jalr t9
sym.xxtea_ubyte_encrypt 0x4185c4 [CALL] jal
sym.xxtea_ubyte_encrypt 0x418618 [CALL] jal
sym.xxtea_ubyte_encrypt 0x418624 [CALL] jal
sym.xxtea_ubyte_decrypt 0x4186e8 [CALL] jal
sym.xxtea_ubyte_decrypt 0x41873c [CALL] jal
sym.xxtea_ubyte_decrypt 0x418748 [CALL] jal
sym.is_resend_action_func 0x4196c4 [CALL] jal
sym.delete_guid_from_linklist 0x41981c [CALL] jal 

After scanning through these manually, there is one potential issue here.

:> pdb
¦           ; CODE XREF from sym.xxtea_to_ubyte_array @ 0x417f98
¦           0x00418008      1800c28f       lw v0, (var_18h)
¦           0x0041800c      01004224       addiu v0, v0, 1
¦           0x00418010      21204000       move a0, v0
¦           0x00418014      0c70100c       jal sym.imp.malloc
¦           0x00418018      00000000       nop
¦           0x0041801c      2000c2af       sw v0, (var_20h)
¦           0x00418020      2000c48f       lw a0, (var_20h)
¦           0x00418024      3000c58f       lw a1, (arg_30h)
¦           0x00418028      1800c68f       lw a2, (var_18h)
¦           0x0041802c      fc6f100c       jal memcpy      ; Null pointer dereference
¦           0x00418030      00000000       nop
¦           0x00418034      2000c38f       lw v1, (var_20h)
¦           0x00418038      1800c28f       lw v0, (var_18h)
¦           0x0041803c      21106200       addu v0, v1, v0                                                                     
¦           0x00418040      000040a0       sb zero, (v0)       

It looks like they forgot to check the return of the malloc call and it is immediately freed. This could lead to a null pointer dereference if the malloc call fails (there are a variety of methods for inducing this) and the null pointer is passed to memcpy. Exploiting this kind of vulnerability, however, is generally difficult.


The summary of my manual results is:

  • 1 simple stack buffer overflow but you'd need to overwrite a local file
  • 6 would-be buffer overflows (some stack, some heap) if the function containing the library call was used incorrectly, but none of those appear to be exploitable
  • 2 format strings, exploitability not yet determined
  • 1 null pointer dereference
  • sscanf uses appear to be safe
  • A bunch of safe uses of strcpy

Preliminary Emulation

In the interest of proving the exploitability of some of these vulnerabilities, I started the process of emulating the binary. Unfortunately due to the timeframe of this project, the emulation wasn’t able to be completed. This appears to be an ideal use case for Qiling, a binary emulation framework built on unicorn and written in Python.


I wanted to be able to emulate the binary and visualize the coverage. I decided to do this by adding a basic block trace to the Qiling script and dumping these addresses to a file. Then, by reading this file in Binary Ninjaand highlighting the traced basic blocks, we can visualize the coverage. An example emulation script is below.

from qiling import *
import os

def hook_block(ql, address, size):
    if "0x4" in hex(address):
        print("At address: 0x%x" % address)
        with open("output.txt", "a+") as f:
            f.write(hex(address) + "\n")

def go():
    ql = Qiling(["/home/oem/margin2/hl_client"],
    os.system("rm output.txt; touch output.txt")


After running the script, we can then build a small Binary Ninjascript to visualize the contents of output.txt.

from binaryninja.interaction import ( 

from binaryninjaui import (

from PySide2 import QtCore
from PySide2.QtCore import Qt, QMimeData
from PySide2.QtGui import QBrush, QColor
from PySide2.QtWidgets import (

import pyqtgraph as pg

class RegisterView(QWidget, DockContextHandler):
    def __init__(self, parent, name, data):
        print(" ---------- Initializing visualization view ----------")

        QWidget.__init__(self, parent)
        DockContextHandler.__init__(self, self, name)

        self.parent = parent

        self.actionHandler = UIActionHandler()
        self._layout = QVBoxLayout()

        pg.plot([5, 6, 7, 8, 9])

        print(" ---------- Initialized visualization view  ---------- ")

class PlotView(QWidget, DockContextHandler):
    def __init__(self, parent, name, data):
        print(" ---------- Initializing visualization view ----------")

        QWidget.__init__(self, parent)
        DockContextHandler.__init__(self, self, name)
        self.parent = parent
        self.actionHandler = UIActionHandler()
        self.layout = QVBoxLayout()
        plt1 = pg.PlotWidget(name="Plot 1", clickable=False)
        plt1.setLabel("left", "Value", units="V")

        #plt = QLineSeries()


        plt1.plot([5, 6, 7, 8], [9, 10, 11, 12])
        # plt2.plot([5, 6, 7, 8], [9, 10, 11, 12])


        # pg.plot([5, 6, 7, 8, 9])

        print(" ---------- Initialized visualization view  ---------- ")

def get_window(name, parent, data):
    window = PlotView(parent, name, data)
    window.setWindowTitle("Here is a new title")
    return window

dock_handler = DockHandler.getActiveDockHandler()

    "SENinja Registers",

print("Done running test plugin") 

Some examples of the highlighted coverage in Binary Ninja shown below.

Here is more coverage from another function.


In summary, through manual analysis I found:

  • 1 simple stack buffer overflow but you'd need to overwrite a local file
  • 6 would-be buffer overflows (some stack, some heap) if the function containing the library call was used incorrectly, but none of those appear to be exploitable
  • 2 format strings, exploitability not yet determined
  • 1 potential null pointer dereference
  • sscanf uses appear to be safe
  • A bunch of safe uses of strcpy
  • The small qiling script is contained in The Binary Ninja plugin is contained in

Chase can be found on GitHub here:

Share this article:

arrow-up icon