day1.tex 77.6 KB
 Chipp Jansen committed Nov 12, 2021 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 \documentclass{article} % Language setting % Replace english' with e.g. spanish' to change the document language \usepackage[english]{babel} % Set page size and margins % Replace letterpaper' witha4paper' for UK/EU standard size \usepackage[a4paper,top=2cm,bottom=2cm,left=3cm,right=3cm,marginparwidth=1.75cm]{geometry} \usepackage{wrapfig} % Useful packages \usepackage{amsmath} \usepackage{graphicx} \usepackage[colorlinks=true, allcolors=blue]{hyperref} \usepackage{caption} \usepackage{subcaption} \usepackage{fancyvrb} \title{Hardware Hacking Workshop -- Building the Zombie Cloud} \author{Chipp Jansen \\ \texttt{chipp.jansen@kcl.ac.uk} \\ \\ Davide Bevilacqua \\ \texttt{davide@servus.at}} \date{Nov 2021} \renewcommand*\contentsname{Outline} \begin{document} \maketitle \tableofcontents \section*{Day 1} \section{Introduction} \subsection{Motivation and Vision} The world is becoming littered with old mobile phone discarded as “upgrade” culture entices us to the shiny latest thing and obsolete Internet of Things (IoT) gadgets from failed start-ups where their dependent cloud services renders the device a plastic brick. While manufacturers are increasingly locking and securing the devices we have “purchased”, the right to repair movements aim to re-use these electronics in new and surprising ways. The first step towards this culture of circular use is to be able to re-purpose a device for general purpose computation. What if we could re-purpose and reclaim these devices, especially those discarded and pool their resources to build our own duct-taped together cloud''? In this hardware hacking'' workshop, we will look at a typical IoT internet security camera and discover how to \textbf{talk to it} and \textbf{re-program} it for our own customised uses. The spirit of this workshop is to also to generate ideas for an eventual system for combining discarded electronics into a re-usable general purpose computational system. No previous hardware or software “hacking” experience is necessary for this step-by-step workshop, and all of the necessary supplies will be provided. \section{Materials} For the hardware hacking portion of the workshops (Section \ref{sec:hardware-hacking}), you will need: \begin{itemize} \item NEOS V2 SmartCam (the device we will hack) \item Small Philips screw-driver with a long neck (Figure \ref{fig:screwdriver}) \item A \textit{spudger} (preferably metal) or a butter knife. (Figure \ref{fig:spudger}) \item 3 Solder-less test-point connectors (Figure \ref{fig:solderless}) \item (\textit{optional}) Tweezers to help position the test-point connectors onto the circuit board. \item (\textit{optional}) Magnifying glass to help read the circuit board markings \end{itemize} % % - Screw-driver % \begin{figure}[h!] % \centering % \includegraphics[width=0.3\textwidth]{figures/screwdriver} % \caption{Screwdriver with long shaft, Philips size 0 works, although other sizes work as well.} % \label{fig:screwdriver} % \end{figure} % % - Spudger % \begin{figure}[h!] % \centering % \includegraphics[width=0.3\textwidth]{figures/spudger} % \caption{Spudgers are small flat plastic or metal wedges used to pry open electronics casing. A dull butter knife works as well.} % \label{fig:spudger} % \end{figure} % % - Solderless test points % \begin{figure}[h!] % \centering % \includegraphics[width=0.3\textwidth]{figures/solderless} % \caption{Solder-less test points used to ease connecting clamps to through-hole solder pads on printed circuit boards} % \label{fig:solderless} % \end{figure} \begin{figure}[h!] \centering % - Screw-driver \begin{subfigure}[b]{0.3\textwidth} \includegraphics[width=\textwidth]{figures/screwdriver} \caption{Screwdriver with long shaft, Philips size 0 works, although other sizes work as well.} \label{fig:screwdriver} \end{subfigure} \hfill % - Spudger \begin{subfigure}[b]{0.3\textwidth} \includegraphics[width=\textwidth]{figures/spudger} \caption{Spudgers are small flat plastic or metal wedges used to pry open electronics casing. A dull butter knife works as well.} \label{fig:spudger} \end{subfigure} \hfill % - Solderless test points \begin{subfigure}[b]{0.3\textwidth} \includegraphics[width=\textwidth]{figures/solderless} \caption{Solder-less test points used to ease connecting clamps to through-hole solder pads on printed circuit boards} \label{fig:solderless} \end{subfigure} \caption{Tools and Materials} \end{figure} For connecting to and re-programming the device (Section \ref{sec:rooting-device}), you will need: \begin{itemize} \item 512 MB SD-CARD for loading the firmware onto the NEOS (see below). % TODO - Image of the Test Lead clips \item 3 test lead wires with clips \item Raspberry Pi Single Board Computer (RPI 3 or RPI 4) \item SD-CARD (at least 8GB) with Debian OS for the RPI \item USB to SD-CARD adaptor for the RPI to program the NEOS SD-CARD. \item Mouse, keyboard and monitor peripherals \end{itemize} A note about the SD-CARD for the NEOS SmartCamera -- the device is sensitive to having a SD-CARD of 512MB in size (very small!). Instead of having an old and small SD-CARD, you can create a 512MB partition on a larger SD-CARD, but the camera will only be able to access this small partition. As an alternative to using the Raspberry PI, you can use a laptop with a USB to TTL Serial cable, also known as a Serial Console cable \footnote{\url{https://www.adafruit.com/product/954}}. \section{Hardware Hacking} \label{sec:hardware-hacking} \subsection{Good devices to Hack} Early IoT devices have the worst security. Also, lesser-known or generic'' brand of devices might not have the incentive or motivation to instill good security. For example, for Apple or Amazon, having an insecure device makes headlines and bad press. Also, larger companies have the resources to invest in security. Bad security is great, because it leaves routes through which to access the device and allow us to modify their behaviour. The device we will be working on is the \textbf{NEOS SmartCam 2 (NS-CAM-02)}\footnote{\url{https://shop.neos.co.uk/products/neos-smartcam}}, which we will refer to the \textit{NEOS} for short in this workshop. It is also sold under different brand names -- the Xiaomi Xiaofang or Dafang and Wyze Cam. It is common for an original equipment manufacturer (OEM) for such generic devices to sell to other companies that re-brand the device. The advantage here is that often the device has the flexibility to be re-configured for re-branding. This flexibility is to our advantage to re-configure the device for our purposes. \subsection{Gathering Information about Device} Simple internet searches on the device name (i.e. \textit{NEOS SmartCam''}) with the keywords \textit{hacking''}, \textit{security audit''} or \textit{tear-down''} will reveal a number of pages where others have already taken the device apart \footnote{An example of a nice tear-down link \url{https://rasmithuk.org.uk/entry/neos-teardown}}. Tear-down guides are nice, because it helps guide opening a device up. It also provides images of another device to compare what's inside one's own device. Even though the outside product looks the same, the inside guts might differ as a different version. Repair sites, such as \textit{iFixit}\footnote{\url{https://www.ifixit.com/})}, are great repositories for step-by-step tear-downs. Often, security professionals probe at new devices to discover how vulnerable they are. They often do security audits on write-ups on blog-posts \footnote{\url{https://research.nccgroup.com/2020/07/31/lights-camera-hacked-an-insight-into-the-world-of-popular-ip-cameras/}}. Security audits are nice because they highlight how one might access and modify your device. As you'll find out, the NEOS is a very open device security-wise. \subsubsection{Communication Compliance Databases} Any wireless devices that requires certification or compliance often is required to deposit screenshots of their interior guts online. In the US, the Federal Communications Commission (FCC) provides a way to look up the device on the web-page. A device is required to have the FCC ID on the device or in the user manual. You can look up the device at \url{https://www.fcc.gov/oet/ea/fccid}. However, a better search engine for FCC registrations is at \url{https://fccid.io/}. Searching for \textit{NEOS''} reveals the original equipment manufacturer, TianJin HuaLai Technologies. Looking up their listing of registered products (\url{https://fccid.io/2ANJH}) reveals the WyzeCam 2, which is what the camera is branded for the US market (the NEOS is a UK device and has no FCC ID). On the WyzeCam2 page (\url{https://fccid.io/2ANJHWYZEC2}), you can find external and internal photos of the device, which helps verifies that you found the correct device. Often though, the required filed schematic, block diagram and operators manual are confidential. The internal photos are useful to see what is inside the device instead of tearing it apart (\url{https://fccid.io/2ANJHWYZEC02/Internal-Photos/Internal-Photos-4793839}). \subsubsection{Phoning Home} IoT devices especially, since they are connected to the internet, often communicate to a hosted cloud-base service (i.e. the mothership). Often this is possible by looking at what web-pages the devices is loading by looking at Domain Name Server (DNS) requests via the network router the device is connected to. A more in depth approach is to intercept the network traffic using \textit{packet capture} or \textit{packet sniffing}, using a tool such as Ettercap\footnote{\url{https://www.ettercap-project.org/}}. With a network protocol analysis tool such as WireShark \footnote{\url{https://wireshark.org}}, you can interpret this communication, and possibly see what the communication is about. This can be done by monitoring the web-traffic that is conducted by the device, through a proxy or your internet router\footnote{As an example, Are my lightbulbs phoning home?'' \url{https://mansfield-devine.com/speculatrix/2021/04/are-my-lightbulbs-phoning-home/}}. One of the main reasons here is to check if there are \textit{over-the-air} updates to the devices firmware, the operating system that the device is running. IoT devices often have feature to update their firmware regularly via network connections. Security audits online \footnote{\url{https://research.nccgroup.com/2020/07/31/lights-camera-hacked-an-insight-into-the-world-of-popular-ip-cameras/}} have found that these NEOS-like Cameras make a series of connections to the following urls: \begin{itemize} \item \url{https://www.hualaikeji.com/en} \item \url{https://www.ismartalarm.com/} \item \url{https://shop.neos.co.uk/} \item \url{https://wyze.com/} \end{itemize} This is another good reason to take apart and look into these IoT devices that we are bringing into our homes. Once connected to our home networks, we really don't know what or how often these devices are connecting to outside services. \subsubsection{Firmware Download} From this network analysis, you can discover where the updates to the firmware of the device are downloaded from online. Sometimes the company's web-sites even have Software Updates'' or Firmware Download'' sections where you can get a copy of the firmware. The firmware is often a large single binary file, which you can run the tool \verb|binwalk| to see what is in the firmware. % TODO - Here is what is in the NEOS SmartCam 2's firmware. The video, \textit{Back-dooring a IoT Camera} \footnote{\url{https://www.youtube.com/watch?v=hV8W4o-Mu2o}}, is a nice overview of this technique. \subsubsection{Online Communities} Hardware hacking communities spring-up around modifying these devices. The challenge and curiosity to gain access and tinker with a device is compelling. % They might also publish vulnerabilities via CVE. % TODO look-up certs For example, the IoT camera we are looking at had a flurry of hacking that got into modifying and creating their own firmware. You can often find these communities share their research on Github such as the \textit{Xiaomi Dafang Hacks} Github Repository \footnote{\url{https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks}} and \textit{Dafang Hacking Organisation}\footnote{\url{https://github.com/Dafang-Hacks/}}. This workshop relies a lot on the efforts and work of this community. \clearpage \subsection{Opening and looking at the Device} From our research online, we can figure out the main processor of the NEOS -- the Ingenic T20 \footnote{\url{http://www.ingenic.com.cn/en/?product/id/14.html}}. It operates at 1 GHz with a floating point processing unit (FPU) and has built in memory (64/128 MB of RAM). It also has additional video processors which allows the encoding of video captured from the camera to H.264 (a common web video format) at a resolution of 1080 x 970 pixels at 60 frames per second (FPS). It has a 32-bit MIPS core, which is the chip architecture. Knowing the chip architecture important is important if you want to compile your own software or firmware to use on the device. \paragraph{What does this mean?} This means that it's a pretty powerful (embedded) processor equipped with some specialised video processing capabilities, which can be used for your own custom Audio/Video creations. \subsubsection{Tear-down} Here's a step-by-step tear down of the device. % % Opening the case % \paragraph{Opening the case} You will see that the NEOS (Figure \ref{fig:outside-iso}) has a leg that unfolds (Figure \ref{fig:front}). Looking underneath the camera on its foot reveals some addition information (Figure \ref{fig:underneath}), notably the MAC (Media Access Control \footnote{\url{https://en.wikipedia.org/wiki/MAC_address}} address. The MAC address is handy to identify the device once it joins a network. \begin{figure}[h!] % - Outside \begin{subfigure}[b]{0.3\textwidth} % \begin{wrapfigure}{r}{0.33\textwidth} \centering \includegraphics[width=\textwidth]{figures/outside-iso} \caption{NEOS (folded up)} \label{fig:outside-iso} % \end{wrapfigure} \end{subfigure} \hfill % - Outside Extended \begin{subfigure}[b]{0.3\textwidth} %\begin{wrapfigure}{r}{0.33\textwidth} \centering \includegraphics[width=\textwidth]{figures/front} \caption{NEOS (leg extended)} \label{fig:front} \end{subfigure} \hfill % - Outside Extended \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/underneath} \caption{Underneath the NEOS} \label{fig:underneath} \end{subfigure} \caption{NEOS SmartCam 2} \end{figure} Extend the leg and unscrew the two bottom screws (Figure \ref{fig:underneath-screws}). You see that the bottom panel is tightly affixed to the rest of the body of the camera (Figure \ref{fig:underneath-back}). Carefully, insert the spudger (preferably metal) or a butter-knife to bend the sides to pry up the underneath panel. Work the spudger around the edge to pry up the panel (Figure % \ref{fig:underneath-pried} and \ref{fig:underneath-pried2} ). You can remove the entire panel to reveal the insides of the camera assembly (Figure \ref{fig:open-top}). % Prying it open \begin{figure}[h!] \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/underneath-screws} \caption{Underneath Screws} \label{fig:underneath-screws} \end{subfigure} \hfill \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/underneath-back} \caption{Underneath Back} \label{fig:underneath-back} \end{subfigure} \hfill \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/underneath-prying} \caption{Underneath Prying} \label{fig:underneath-prying} \end{subfigure} \hfill % \begin{subfigure}[b]{0.3\textwidth} % \centering % \includegraphics[width=\textwidth]{figures/underneath-pried} % \caption{Underneath Pried} % \label{fig:underneath-pried} % \end{subfigure} % \hfill \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/underneath-pried2} \caption{Underneath Pried} \label{fig:underneath-pried2} \end{subfigure} \hfill \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/open-top} \caption{Open Bottom with Legs Removed} \label{fig:open-top} \end{subfigure} \caption{Prying open the NEOS} \end{figure} \clearpage Using the spudger or butter-knife (Figure \ref{fig:open-pried}), start to pry the sides away from the back panel (the one with the micro USB port). You will be able to release the back panel (Figure \ref{fig:open-pried-released}). Unplug the speaker cable (Figure \ref{fig:open-pried-speaker-plug-highlighted}) before removing the back panel. \begin{figure}[h!] \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/open-pried} \caption{Carefully and with some force pry open the sides of the case} \label{fig:open-pried} \end{subfigure} \hfill \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/open-pried-released} \caption{With both sides released you can remove the back panel} \label{fig:open-pried-released} \end{subfigure} \hfill \begin{subfigure}[b]{0.33\textwidth} \centering \includegraphics[width=\textwidth]{figures/open-pried-speaker-plug-highlighted} \caption{Unplug the attached speaker plug (circled in red) as you remove the panel} \label{fig:open-pried-speaker-plug-highlighted} \end{subfigure} \caption{Prying off the sides of the NEOS} \end{figure} With a fingernail or very gently with a spudger, unplug the antenna (highlighted in red on Figure \ref{fig:open-antenna-highlighted}) from the circuit board. Try to pry the golden plug instead of pulling on the antenna wire (Figure \ref{fig:open-antenna-unplugged}). This is the WIFI antenna, so later in the workshop when we start using the WIFI on the device, we'll have to reattach the antenna. \begin{figure}[h!] \centering \begin{subfigure}[b]{0.45\textwidth} \centering \includegraphics[width=\textwidth]{figures/open-antenna-highlighted} \caption{WI-FI antenna plug (circled in red)} \label{fig:open-antenna-highlighted} \end{subfigure} \hfill \begin{subfigure}[b]{0.45\textwidth} \centering \includegraphics[width=\textwidth]{figures/open-antenna-unplugged} \caption{WIFI antenna unplugged} \label{fig:open-antenna-unplugged} \end{subfigure} \caption{Unplugging the WIFI Antenna} \end{figure} \clearpage In order to remove the electronics assembly from the case, unscrew the third screw which is located at the bottom of a plastic screw well (Figure \ref{fig:open-third-screw}). You will need a longer necked Phillips screw-driver (Figure \ref{fig:open-third-screw-driver}). \textit{Optional} In the case that you screw driver does not reach the screw, you might have to carefully cut off a bit of the plastic screw well (Figure %\ref{fig:open-third-screw-cutting-off} and \ref{fig:open-third-screw-cut-off}). \begin{figure}[h!] \centering \begin{subfigure}[b]{0.33\textwidth} \centering \includegraphics[width=\textwidth]{figures/open-third-screw} \caption{Remove the screw to release the assembly.} \label{fig:open-third-screw} \end{subfigure} \hfill \begin{subfigure}[b]{0.33\textwidth} \centering \includegraphics[width=\textwidth]{figures/open-third-screw-driver} \caption{You will need a longer necked Phillips screw-driver} \label{fig:open-third-screw-driver} \end{subfigure} % \begin{figure}[h!] % \centering % \includegraphics[width=0.3\textwidth]{figures/open-third-screw-cutting-off} % \caption{You may have to cut off some plastic from the assembly to reach the screw.} % \label{fig:open-third-screw-cutting-off} % \end{figure} \hfill \begin{subfigure}[b]{0.33\textwidth} \centering \includegraphics[width=\textwidth]{figures/open-third-screw-cut-off} \caption{Here is the plastic screw-well cut off} \label{fig:open-third-screw-cut-off} \end{subfigure} \caption{} \end{figure} \clearpage \paragraph{Disassemble the internals boards} Now you can lift the electronics assembly out of the case. You will see that there is an internal plastic mount with three circuit boards sandwiching it (Figure \ref{fig:assembly}). \begin{figure}[h!] \centering \includegraphics[width=0.3\textwidth]{figures/assembly} \caption{Internal assembly showing the USB side up.} \label{fig:assembly} \end{figure} Next, remove two screws from the USB side (Figure \ref{fig:assembly-usb-top}) and from the camera side of the assembly (Figure \label{fig:assembly-camera-bottom}). Start unwrapping the assembly by lifting the camera side off and unplugging the camera module's power plug (Figure \ref{fig:assembly-camera-remove}). % Unpacking the boards \begin{figure}[h!] \centering \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/assembly-usb-top} \caption{Two screws to remove on the assembly: USB side.} \label{fig:assembly-usb-top} \end{subfigure}% \hfill \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/assembly-camera-bottom} \caption{Two screws to remove on the assembly: Camera side.} \label{fig:assembly-camera-bottom} \end{subfigure}% \hfill \begin{subfigure}[b]{0.3\textwidth} \centering \includegraphics[width=\textwidth]{figures/assembly-camera-remove} \caption{Unplug the camera module's power plug and lift the camera board off of the assembly} \label{fig:assembly-camera-remove} \end{subfigure}% \caption{} \end{figure} Remove the middle board from the plastic mounting bracket by unscrewing only the two outer screws (Figure \ref{fig:assembly-middle-board}). Do not remove the interior screws. They hold the camera module in place, and removing them might disturb the alignment of the camera optics. \begin{figure}[h!] \centering \includegraphics[width=.8\textwidth]{figures/assembly-middle-board} \caption{Removing the two circled screws separates the camera board from the plastic mounting bracket. Do not remove the two internal screws, as that separates the camera from the board and might disturb the camera optics.} \label{fig:assembly-middle-board} \end{figure} Figure \ref{fig:internals-spread-out} shows the three boards. On the left is the the camera board, with the unplugged camera power cable. In the middle is the USB board (with the plug for the WIFI antenna). On the right is the SD-CARD reader, the power plug for the camera power cable and a button. \begin{figure}[h!] \centering \includegraphics[width=0.9\textwidth]{figures/internals-spread-out} \caption{Internal boards spread out: (\textit{left}) camera board, (\textit{center}) USB board, (\textit{right}) SD-CARD board.} \label{fig:internals-spread-out} \end{figure} \paragraph{Tour of the boards} Let's take a closer look at the boards. When investigating new hardware, we want to take note of the types of chips, markings on the circuit boards and look for \textit{debug} ports. These are typically unsoldered pads or exposed pads on the circuit board, used to diagnose or program the piece of hardware. Commercial hardware will typically go through a quality control stage, where it's circuit boards are placed in a test rig which attaches to \textit{test points} on the board. These test points are also helpful as they might give easy access to certain pins on chips mounted on the board. % \textcolor{red}{TODO - Tour of top/bottom of each board} Figure \ref{fig:guts-middle-board} is the top of the USB board, the middle board, which has the main processor, the T20, highlighted in red. There is a flash memory chip, which is separate form the main processor which holds the firmware and other persistent storage memory next, highlighted in magenta. There is a separate Realtek WIFI module which is a small circuit board soldered onto the main board, highlighted in yellow. The WIFI module is where we disconnected the antenna, the gold plug. In the upper right-hand corner of the board (highlighted in green) are three through-hole solder pads in a row. This is a good indication that this is a debug port. There are different types of communication ports, and it is a serial port, also known as a UART (Universal Asynchronous Receiver and Transceiver) port \footnote{\url{https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter}}. % TODO - new picture WITHOUT the soldered headers. \begin{figure}[h!] \centering \includegraphics[width=0.5\textwidth]{figures/guts-middle-board-good} \caption{Internals of the (middle) USB board, with the main components highlighted -- the T20 main processor (red), flash memory chip (magenta), the Realtek WIFI module (yellow) and the debug port in the upper right corner (green)} \label{fig:guts-middle-board} \end{figure} Take a look at the other boards -- feel free to ask questions about any of the other components on the boards. % TODO - link to the schematic? There is a schematic available for this device at... \subsubsection{Connect Debug Port} Here we are going to connect the NEOS to the Raspberry Pi (RPI) via the debug port. Returning to the USB board, flip it over to see the debug port pads (Figure \ref{fig:guts-debug-port}). \paragraph{Add test points} Instead of soldering directly to the NEOS, we are going to use solder-less test point loops (Figure \ref{fig:solderless}). Using nimble fingers, or tweezers, plug the wired legs of the solder-less test point loops into the debug port. Place them on the \textit{other} side of the board from the USB port. % Alternatively, you can solder a pin header onto the circuit board for a more permanent fixture. \begin{figure}[h!] \centering  Chipp Jansen committed Nov 12, 2021 457  \includegraphics[width=0.6\textwidth]{figures/guts-debug-port-good2}  Chipp Jansen committed Nov 12, 2021 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000  \caption{Debug port showing GND, RX and TX pins.)} \label{fig:guts-debug-port} \end{figure} \paragraph{Connect debug port to Raspberry PI} The three pins on the NEOS are Ground (bottom), Data Receive (RX), Data Transmit (TX) (Figure \ref{fig:guts-debug-port}). We will connect these to the UART on the Raspberry Pi using the clip headers. In order to communicate properly, the Data Transmit (TX) on the NEOS needs to be connected to the Data Receive (RX) on the Raspberry Pi, and vice versa. Table \ref{tbl:connections} for the connection mapping, as well as Figures \ref{fig:debug-port-connect} and \ref{fig:rpi-connect}. % https://pinout.xyz/pinout/uart# % https://www.raspberrypi.org/documentation/computers/configuration.html \begin{table}[h!] \centering \begin{tabular}{c|c|c|c|c} \textbf{On RPI} & \textbf{RPI Pin Name} & \textbf{Cable Color} & \textbf{On NEOS} & \textbf{NEOS Pin Name} \\ Pin 6 & Ground (GND) & black & bottom (3rd from corner) & Ground (GND) \\ Pin 8 & TX (GPIO14) & grey & top (1st from corner) & RX Pin \\ Pin 10 & RX (GPIO15) & white & center (2nd from corner) & TX Pin \\ \end{tabular} \caption{Connections between the NEOS and the Raspberry Pi} \label{tbl:connections} \end{table} \begin{figure}[h!] \begin{subfigure}[b]{0.4\textwidth} \includegraphics[width=\textwidth]{figures/debug-port-connect} \caption{Connecting to the debug port} \label{fig:debug-port-connect} \end{subfigure}% \hfill \begin{subfigure}[b]{0.4\textwidth} \centering \includegraphics[width=\textwidth]{figures/rpi-connect} \caption{Connecting to the Raspberry Pi's Serial Port (the UART)} \label{fig:rpi-connect} \end{subfigure} \caption{Wired connections between NEOS and Raspberry Pi} \end{figure} % TODO - probing possible debug ports on the device. \paragraph{Mind the Voltage} An important thing to consider here is the operating voltages of the boards. The Raspberry Pi's I/O and board operates at 3.3V, which is a common voltage for contemporary IoT devices. The NEOS also operates at 3.3V. However, older devices might run at 5V (like Arduino boards). You can use a multi-meter first on the device to see at what voltage level the board is powered at. If you have different voltages, you'll need to add \textit{level-shifters} to the UART lines to match the voltages. \paragraph{Enable Serial Port} On the Raspberry Pi, in a terminal prompt, we will first check that the hardware UART is enabled \footnote{These steps are from the Raspberry Pi documentation at \url{https://www.raspberrypi.com/documentation/computers/configuration.html\#disabling-the-linux-serial-console}}. (You only have to do this once on the Raspberry Pi). \begin{enumerate} \item Start raspi-config: \verb|sudo raspi-config| \item Select option 3 - Interface Options. \item Select option P6 - Serial Port. \item At the prompt \textit{Would you like a login shell to be accessible over serial?} answer 'No' \item At the prompt \textit{Would you like the serial port hardware to be enabled?} answer 'Yes' \item Exit raspi-config and reboot the Pi for changes to take effect. \end{enumerate} \paragraph{Test the connection} We will use the program \verb|picocom| on the Raspberry PI to access the serial port on the device. First, check whether \verb|picocom| is installed by running \verb|which picocom| in the terminal. (If it is not found, then you can install it by running \verb|sudo apt-get install picocom|. In order to connect to the Raspberry Pi, you will need to know the device path to the serial port. Running \verb|ls /dev| shows all of the device files for the Raspberry Pi. On the Raspberry Pi, the device path to the serial port is \verb|/dev/serial0| and you should find it in the list of device files after running \verb|ls \/dev|. On other systems, such as a Linux laptop or a Mac, the serial device might be another name that starts with \verb|ttyS| or \verb|cua|. The other thing we need to know is the speed that the serial port is operating at, which is a \textit{baud} rate. For modern systems, 115200 is a good starting point \footnote{9600 is another common baud rate. For more common rates \url{https://en.wikipedia.org/wiki/Serial_port\#Settings}}. In general, you will get some sort of output, but if the baud rate is wrong, then you'll get random characters. A more sophisticated approach would be to measure the speed of the output lines with an oscilloscope. Now you can run the command to connect to the NEOS: \begin{verbatim} picocom -b 115200 /dev/serial0 \end{verbatim} Initially, \verb|picocom| will print out how it is configured. The next thing to do is to turn on the NEOS. If the wires are connected to the debug port, you'll see some output that starts like this: \begin{verbatim} U-Boot SPL 2013.07 (Jul 05 2018 - 13:33:27) pll_init:365 l2cache_clk = 375000000 pll_cfg.pdiv = 8, pll_cfg.h2div = 4, pll_cfg.h0div = 4, pll_cfg.cdiv = 1, pll_cfg.l2div = 3 nf=36 nr = 1 od0 = 1 od1 = 1 cppcr is 02404900 CPM_CPAPCR 0470890d nf=42 nr = 1 od0 = 1 od1 = 1 cppcr is 02a04900 CPM_CPMPCR 07d0c90d nf=50 nr = 1 od0 = 1 od1 = 1 cppcr is 03204900 CPM_CPVPCR 0320490d cppcr 0x9a794410 apll_freq 860160000 mpll_freq 1000000000 vpll_freq = 1200000000 ddr sel mpll, cpu sel apll ddrfreq 500000000 cclk 860160000 l2clk 286720000 h0clk 250000000 h2clk 250000000 pclk 125000000 DDRC_DLP:0000f003 U-Boot 2013.07 (Jul 05 2018 - 13:33:27) Board: ISVP (Ingenic XBurst T20 SoC) DRAM: 128 MiB Top of RAM usable for U-Boot at: 84000000 Reserving 399k for U-Boot at: 83f9c000 Reserving 32784k for malloc() at: 81f98000 Reserving 32 Bytes for Board Info at: 81f97fe0 Reserving 124 Bytes for Global Data at: 81f97f64 Reserving 128k for boot params() at: 81f77f64 Stack Pointer at: 81f77f48 Now running in RAM - U-Boot at: 83f9c000 MMC: msc: 0 the manufacturer 1c SF: Detected FM25Q64 ... \end{verbatim} If you see no output, then double-check the wiring between the NEOS and the Raspberry Pi. The other thing that could be wrong is that \verb|picocom| is using the wrong device file. Another thing that could be wrong is that you get output but it is non-text and un-readable. Your Raspbery Pi might be underpowered, as this affects the hardware in strange ways. This is also a sign that the baud rate is set incorrectly, and double-check that you are running \verb|picocom| at the correct rate. Now we verified that we have a successful connection to the NEOS via the Raspberry PI. In the next part we look at how you can access and modify the firmware for the device. \section{Rooting the Device} \label{sec:rooting-device} \subsection{Exploring the Bootloader} When the NEOS starts up, it first loads a \textit{bootloader}, which is a program that loads the operating system or the main program for the device. The NEOS runs a version of embedded Linux (MIPS Linux) as its operating system. The bootloader that the NEOS uses is \texttt{U-Boot}\footnote{\url{https://github.com/u-boot/u-boot}}, which is a common open source boot-loader used on embedded devices. On start-up, right before \texttt{U-Boot} loads the Linux kernel (the main operating system), it waits for 1 second to listen for any input on the debug port. If there is any input (such as sending a key-press via a serial console connected to the debug port), then it pauses start-up and gives you access to the \texttt{U-Boot} menu. With the NEOS connected to the Raspberry Pi, restart the NEOS while holding down a key on the Raspberry Pi's keyboard (such as the space bar) in the running \verb|picocom| terminal window. You will have to be quick to catch it, and ultimately have to try a couple of times. If successful, the loading output will stop and you will get a prompt \texttt{isvp\_t20\#} in the terminal: \begin{verbatim} ... misc_init_r after change the SD_able_gpio ret is 0 misc_init_r before change the wifi_enable_gpio gpio_request lable = wifi_enable_gpio gpio = 62 misc_init_r after gpio_request the wifi_enable_gpio ret is 62 misc_init_r after change the wifi_enable_gpio ret is 1 Hit any key to stop autoboot: 0 isvp_t20# \end{verbatim} Typing in \verb|help| gives you the menu of \verb|U-Boot| options available to you: \begin{verbatim} isvp_t20# help ? - alias for 'help' base - print or set address offset boot - boot default, i.e., run 'bootcmd' boota - boot android system bootd - boot default, i.e., run 'bootcmd' bootm - boot application image from memory chpart - change active partition cmp - memory compare coninfo - print console devices and information cp - memory copy crc32 - checksum calculation echo - echo args to console env - environment handling commands fatinfo - print information about filesystem fatload - load binary file from a dos filesystem fatls - list files in a directory (default /) gettime - get timer val elapsed, go - start application at address 'addr' help - print command description/usage loadb - load binary file over serial line (kermit mode) loads - load S-Record file over serial line loady - load binary file over serial line (ymodem mode) loop - infinite loop on address range md - memory display mm - memory modify (auto-incrementing address) mmc - MMC sub system mmcinfo - display MMC info mtdparts- define flash/nand partitions mw - memory write (fill) nm - memory modify (constant address) printenv- print environment variables reset - Perform RESET of the CPU run - run commands in an environment variable saveenv - save environment variables to persistent storage sdupdate- auto upgrade file from mmc to flash setenv - set environment variables sf - SPI flash sub-system sleep - delay execution for some time source - run script from memory version - print monitor, compiler and linker version \end{verbatim} \verb|U-Boot| gives you access to many aspects of the hardware for the device. For instance the command \verb|gettime| responds with the system timer, the number milliseconds that have elapsed since the device was booted. Also, \textit{U-Boot} can have \textit{sub-systems}, a kind of plug-in, that provides access to types of hardware. In this case, there is a Serial Peripheral Interface (SPI) flash memory sub-system which allows access to external memory chips connected to the main processor. You can see the sub-system commands via \verb|help sf|. \begin{verbatim} isvp_t20# help sf sf - SPI flash sub-system Usage: sf probe [[bus:]cs] [hz] [mode] - init flash device on given SPI bus and chip select sf read addr offset len - read len' bytes starting at offset' to memory at addr' sf write addr offset len - write len' bytes from memory at addr' to flash at offset' sf erase offset [+]len - erase len' bytes from offset' +len' round up len' to block size sf update addr offset len - erase and write len' bytes from memory at addr' to flash at offset' \end{verbatim} And you can see what kind of flash chip is attached via \verb|sf probe|: \begin{verbatim} isvp_t20# sf probe the manufacturer 1c SF: Detected FM25Q64 --->probe spend 4 ms \end{verbatim} On the NEOS, the main processor is connected to a FM25Q64 flash memory chip\footnote{Remember the flash chip from Figure \ref{fig:guts-middle-board} - \url{http://eng.fmsh.com/nvm/FM25Q64_ds_eng.pdf}}. It stores the system's operating system and file system. The \verb|sf| commands provide a way, via U-Boot, to read/write portions of the flash chip via the system memory. We can gather more information about how the NEOS starts up by looking at the bootloader's environment variables via the \verb|printenv| command: \begin{verbatim} isvp_t20# printenv baudrate=115200 bootargs=console=ttyS1,115200n8 mem=104M@0x0 ispmem=8M@0x6800000 rmem=16M@0x7000000 init=/linuxrc rootfstype=squashfs root=/dev/mtdblock2 rw mtdparts=jz_sfc:256k(boot),2048k(kernel),3392k(root),640k(driver),4736k(appfs),2048k(backupk),640k(backupd),2048k(backupa),256k(config),256k(para),-(flag) bootcmd=sdupdate;sf probe;sf read 0x80600000 0x40000 0x280000; bootm 0x80600000 bootdelay=1 ethaddr=00:11:22:33:44:55 gatewayip=193.169.4.1 ipaddr=193.169.4.81 loads_echo=1 netmask=255.255.255.0 serverip=193.169.4.2 stderr=serial stdin=serial stdout=serial Environment size: 596/16380 bytes \end{verbatim} These environment variables are used by \verb|U-Boot| to control the rest of the start-up process. % For instance, there are network configurations (i.e. \verb|ipaddr|, \verb|gatewayip|, etc...) for booting the device via a network server. The environment variable \verb|bootargs|, are passed to the operating system, the Linux kernel, after the \verb|boot| command runs. In the next sections we will see how to use \verb|bootargs| to possibly gain root access to the Linux system that is running on the NEOS. \subsection{Getting Root on the Device} The \verb|bootargs| environment variable are parameters sent to the Linux kernel on start-up (\footnote{\url{https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html}})). It will set-up a serial \texttt{console}, to login into the Linux operating system, with the same debug port we are using to to talk to \verb|U-Boot|. It maps memory addresses (\verb|mem|,\verb|ispmem|,\verb|rmem|) and sets-up the root file system (\verb|root|). The \verb|init| argument is which, process, or program to run, once the system is set-up. In this case \verb|linuxrc| runs and initialises devices and sets-up more of the file-system. We can modify the \texttt{bootargs} variable and change \texttt{init} portion to run a different program, in this case we will run a terminal shell \texttt{/bin/sh}. We will use \texttt{setenv} in \verb|U-Boot| to do this. First, copy the \texttt{bootargs} environment variable to a text editor. On the Raspberry Pi, you can access a Text Editor in the upper-left hand raspberry'' menu and find it under \textit{Accessories}. Then, edit the line so that it starts with \verb|setenv bootargs | (note there is \textit{no} \verb|=| after \verb|bootargs|). Also, change the \verb|init| option to it is modified to be \verb|/bin/sh|. The rest of the options, such as the memory addresses are left as is. Remember that the entire command needs to be a single line. It's edited below on multiple lines to help you see all the arguments: \begin{verbatim} setenv bootargs console=ttyS1,115200n8 mem=104M@0x0 ispmem=8M@0x6800000 rmem=16M@0x7000000 init=/bin/sh rootfstype=squashfs root=/dev/mtdblock2 rw mtdparts=jz_sfc:256k(boot),2048k(kernel),3392k(root),640k(driver), 4736k(appfs),2048k(backupk),640k(backupd),2048k(backupa),256k(config), 256k(para),-(flag) \end{verbatim} After you run the command, you can verify that the change took place by running the \verb|printenv| command again. Check that the \verb|bootargs| variable has the modified \verb|init| option. Now, run the command \verb|boot| to continue the boot process with your modified \verb|bootargs|. Note that, if you reset or switch the device off before running \verb|boot|, the changes will be lost and you will have to go through the editing process again. If all goes well, you should see this output: \begin{verbatim} isvp_t20# boot jiabo_do_auto_update!!!!!!!!!!!!!!!!!!!!!!!! gpio_request lable = sdupgrade gpio = 46 the manufacturer 1c SF: Detected FM25Q64 jiabo_update_to_flash!!!!!!!!!!!!!!!!!!!!!!!! jiabo_au_do_update!!!!!!!!!!!!!!!!!!!!!!!! start=0 start=40000 len=40000 flash check read... FWGRADEUP not find !!!!!!!!! gradeup check fail!!!!!!!!!!!!!!!!!!! the manufacturer 1c SF: Detected FM25Q64 Erasing SPI flash...addr align as 10000 ! sfc erase error the manufacturer 1c SF: Detected FM25Q64 --->probe spend 4 ms SF: 2621440 bytes @ 0x40000 Read: OK --->read spend 380 ms ## Booting kernel from Legacy Image at 80600000 ... Image Name: Linux-3.10.14 Image Type: MIPS Linux Kernel Image (lzma compressed) Data Size: 1907357 Bytes = 1.8 MiB Load Address: 80010000 Entry Point: 80421870 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting kernel ... [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.10.14 (shizhong@shizhong-pc) (gcc version 4.7.2 (Ingenic r2.3.3 2016.12) ) #4 PREEMPT Tue May 26 13:03:48 CST 2020 [ 0.000000] bootconsole [early0] enabled [ 0.000000] CPU0 RESET ERROR PC:00830202 [ 0.000000] CPU0 revision is: 00d00101 (Ingenic Xburst) [ 0.000000] FPU revision is: 00b70000 [ 0.000000] CCLK:860MHz L2CLK:430Mhz H0CLK:200MHz H2CLK:200Mhz PCLK:100Mhz [ 0.000000] Determined physical RAM map: [ 0.000000] memory: 0056e000 @ 00010000 (usable) [ 0.000000] memory: 00032000 @ 0057e000 (usable after init) [ 0.000000] User-defined physical RAM map: [ 0.000000] memory: 06800000 @ 00000000 (usable) [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x00000000-0x067fffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00000000-0x067fffff] [ 0.000000] Primary instruction cache 32kB, 8-way, VIPT, linesize 32 bytes. [ 0.000000] Primary data cache 32kB, 8-way, VIPT, no aliases, linesize 32 bytes [ 0.000000] pls check processor_id[0x00d00101],sc_jz not support! [ 0.000000] MIPS secondary cache 128kB, 8-way, linesize 32 bytes. [ 0.000000] Built 1 zonelists in Zone order, mobility grouping off. Total pages: 26416 [ 0.000000] Kernel command line: console=ttyS1,115200n8 mem=104M@0x0 ispmem=8M@0x6800000 rmem=16M@0x7000000 init=/bin/sh rootfstype=squashfs root=/dev/mtdblock2 rw mtdparts=jz_sfc:256k(boot),2048k(kernel),3392k(root),640k(driver),4736k(appfs),2048k(backupk),640k(backupd),2048k(backupa),256k(config),256k(para),-(flag) [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Memory: 99104k/106496k available (4202k kernel code, 7392k reserved, 1356k data, 200k init, 0k highmem) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] NR_IRQS:418 [ 0.000000] clockevents_config_and_register success. [ 0.000024] Calibrating delay loop... 858.52 BogoMIPS (lpj=4292608) [ 0.087755] pid_max: default: 32768 minimum: 301 [ 0.092744] Mount-cache hash table entries: 512 [ 0.097858] Initializing cgroup subsys debug [ 0.102119] Initializing cgroup subsys freezer [ 0.109216] regulator-dummy: no parameters [ 0.113513] NET: Registered protocol family 16 [ 0.136452] bio: create slab at 0 [ 0.142794] jz-dma jz-dma: JZ SoC DMA initialized [ 0.148058] SCSI subsystem initialized [ 0.151986] usbcore: registered new interface driver usbfs [ 0.157559] usbcore: registered new interface driver hub [ 0.163006] usbcore: registered new device driver usb [ 0.168319] i2c-gpio i2c-gpio.1: using pins 57 (SDA) and 58 (SCL) [ 0.174522] (null): set:249 hold:250 dev=100000000 h=500 l=500 [ 0.180658] media: Linux media interface: v0.10 [ 0.185229] Linux video capture interface: v2.00 [ 0.192000] Switching to clocksource jz_clocksource [ 0.196956] cfg80211: Calling CRDA to update world regulatory domain [ 0.204071] jz-dwc2 jz-dwc2: cgu clk gate get error [ 0.209010] jz-dwc2 jz-dwc2: regulator vbus get error [ 0.214091] DWC IN OTG MODE [ 0.367340] sft id =========================off [ 0.371936] dwc2 dwc2: Keep PHY ON [ 0.375325] dwc2 dwc2: Using Buffer DMA mode [ 0.579472] dwc2 dwc2: Core Release: 3.00a [ 0.583594] dwc2 dwc2: DesignWare USB2.0 High-Speed Host Controller [ 0.589923] dwc2 dwc2: new USB bus registered, assigned bus number 1 [ 0.597303] hub 1-0:1.0: USB hub found [ 0.601044] hub 1-0:1.0: 1 port detected [ 0.605204] dwc2 dwc2: DWC2 Host Initialized [ 0.609697] NET: Registered protocol family 2 [ 0.614672] TCP established hash table entries: 1024 (order: 1, 8192 bytes) [ 0.621698] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) [ 0.628178] TCP: Hash tables configured (established 1024 bind 1024) [ 0.634631] TCP: reno registered [ 0.637830] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 0.643784] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 0.650385] NET: Registered protocol family 1 [ 0.655106] RPC: Registered named UNIX socket transport module. [ 0.661040] RPC: Registered udp transport module. [ 0.665872] RPC: Registered tcp transport module. [ 0.670575] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.677628] freq_udelay_jiffys[0].max_num = 10 [ 0.682056] cpufreq udelay loops_per_jiffy [ 0.686523] dwc2 dwc2: ID PIN CHANGED! [ 0.690300] init DWC as A_HOST [ 0.693403] 12000 59885 59885 [ 0.696625] 24000 119771 119771 [ 0.700068] 60000 299428 299428 [ 0.703703] 120000 598857 598857 [ 0.707161] 200000 998095 998095 [ 0.710692] 300000 1497142 1497142 [ 0.714438] 600000 2994285 2994285 [ 0.718109] 792000 3952457 3952457 [ 0.721817] 1008000 5030400 5030400 [ 0.725627] 1200000 5988571 5988571 [ 0.735050] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.741876] NFS: Registering the id_resolver key type [ 0.747051] Key type id_resolver registered [ 0.751215] Key type id_legacy registered [ 0.755333] jffs2: version 2.2. (NAND) \u00a9 2001-2006 Red Hat, Inc. [ 0.761872] msgmni has been set to 193 [ 0.767067] io scheduler noop registered [ 0.771003] io scheduler cfq registered (default) [ 0.777611] jz-uart.1: ttyS1 at MMIO 0x10031000 (irq = 58) is a uart1 [ 0.785904] console [ttyS1] enabled, bootconsole disabled [ 0.785904] console [ttyS1] enabled, bootconsole disabled [ 0.801064] brd: module loaded [ 0.806461] loop: module loaded [ 0.810371] zram: Created 2 device(s) ... [ 0.814855] logger: created 256K log 'log_main' [ 0.820158] jz SADC driver registeres over! [ 0.825583] jz TCU driver register completed [ 0.830606] the id code = 1c7018, the flash name is EN25QH128A [ 0.836762] JZ SFC Controller for SFC channel 0 driver register [ 0.842927] 11 cmdlinepart partitions found on MTD device jz_sfc [ 0.849171] Creating 11 MTD partitions on "jz_sfc": [ 0.854249] 0x000000000000-0x000000040000 : "boot" [ 0.859787] 0x000000040000-0x000000240000 : "kernel" [ 0.865503] 0x000000240000-0x000000590000 : "root" [ 0.870997] 0x000000590000-0x000000630000 : "driver" [ 0.876747] 0x000000630000-0x000000ad0000 : "appfs" [ 0.882339] 0x000000ad0000-0x000000cd0000 : "backupk" [ 0.888185] 0x000000cd0000-0x000000d70000 : "backupd" [ 0.894022] 0x000000d70000-0x000000f70000 : "backupa" [ 0.899788] 0x000000f70000-0x000000fb0000 : "config" [ 0.905594] 0x000000fb0000-0x000000ff0000 : "para" [ 0.911116] 0x000000ff0000-0x000001000000 : "flag" [ 0.916679] SPI NOR MTD LOAD OK [ 0.920007] tun: Universal TUN/TAP device driver, 1.6 [ 0.925285] tun: (C) 1999-2004 Max Krasnyansky [ 0.931835] usbcore: registered new interface driver zd1201 [ 0.937685] usbcore: registered new interface driver r8152 [ 0.943472] usbcore: registered new interface driver usb-storage [ 0.949815] usbcore: registered new interface driver usbserial [ 0.955949] usbcore: registered new interface driver usbserial_generic [ 0.962746] usbserial: USB Serial support registered for generic [ 0.969029] usbcore: registered new interface driver ch341 [ 0.974765] usbserial: USB Serial support registered for ch341-uart [ 0.981300] usbcore: registered new interface driver cp210x [ 0.987126] usbserial: USB Serial support registered for cp210x [ 0.993305] usbcore: registered new interface driver ftdi_sio [ 0.999312] usbserial: USB Serial support registered for FTDI USB Serial Device [ 1.007009] usbcore: registered new interface driver pl2303 [ 1.012825] usbserial: USB Serial support registered for pl2303 [ 1.519956] i8042: i8042 controller selftest timeout [ 1.525613] jzmmc_v1.2 jzmmc_v1.2.0: vmmc regulator missing [ 1.563517] jzmmc_v1.2 jzmmc_v1.2.0: register success! [ 1.568920] jzmmc_v1.2 jzmmc_v1.2.1: vmmc regulator missing [ 1.614443] jzmmc_v1.2 jzmmc_v1.2.1: register success! [ 1.619917] hidraw: raw HID events driver (C) Jiri Kosina [ 1.625804] usbcore: registered new interface driver usbhid [ 1.631580] usbhid: USB HID core driver [ 1.635660] Netfilter messages via NETLINK v0.30. [ 1.640594] nf_conntrack version 0.5.0 (1548 buckets, 6192 max) [ 1.647357] ip_tables: (C) 2000-2006 Netfilter Core Team [ 1.652962] TCP: cubic registered [ 1.656448] NET: Registered protocol family 17 [ 1.661194] Key type dns_resolver registered [ 1.666659] input: gpio-keys as /devices/platform/gpio-keys/input/input0 [ 1.673942] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [ 1.685403] VFS: Mounted root (squashfs filesystem) readonly on device 31:2. [ 1.693042] Freeing unused kernel memory: 200K (8057e000 - 805b0000) [ 1.814730] dwc2 dwc2: ++OTG Interrupt: A-Device Timeout Change++ /bin/sh: can't access tty; job control turned off ~ # \end{verbatim} Which ends with a live Unix prompt, \verb|~ #|. If you are familiar with moving around a Unix file-system, take a look around. \begin{verbatim} ~ # ls backupa bin driver linuxrc opt root sys tmp backupd configs etc media params run system usr backupk dev lib mnt proc sbin thirdlib var ~ # \end{verbatim} \paragraph{Mine didn't work?!!?} Some of the later NEOS cameras have stock firmware which disables the serial console. This means that the device does not let you access a root Unix shell and the device reboots into the stock firmware. If this is the case, don't fret, because... It turns out the NEOS has an easier way to load new firmware, direct from an SD-CARD, which we will see in the next section. In fact, one does not have to use the debug port to replace the firmware on the device! \clearpage \subsection{Loading New Firmware} \label{loading-cfw} The Dafang Hacks community\footnote{The NEOS is a variant of the Xiaomi Dafang SmartCam \url{https://github.com/Dafang-Hacks}} has prepared a Custom Firmware (CFW), which is an alternative firmware to load onto the NEOS, that makes it very flexible to load and modify the NEOS. \paragraph{Get the CFW} % If you already have a 512MB SD-CARD already prepared with this firmware, you can skip this part, to \textbf{Flashing the Device} below. On the Raspberry Pi, click on the Folder Icon in the top left side of the toolbar to open your Home directory. There will be a copy of the CFW which is a file named \verb|cfw-1.2.bin| \footnote{You will find the firmware from this site: \url{https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks/blob/master/hacks/install_cfw.md}. You will want the \texttt{Wyzecam V2 / Neos SmartCam} firmware.} \paragraph{Prepare the SD-CARD} Next, we will have to prepare a new SD-CARD. The NEOS will only work with a 512 MB partition on the SD-CARD (or a 512 MB SD-CARD). Insert the SD-CARD in the USB adaptor. You might get a Removable medium is inserted'' pop-up dialog, which you can \textit{Cancel}. Run \verb|gparted| (Figure \ref{fig:gparted}). (You will have to enter the root password, which in Raspbian the default password is \verb|raspberry|) \begin{figure}[h!] \centering \includegraphics[width=0.9\textwidth]{figures/gparted.png} \caption{Use \texttt{gparted} to format the SD-CARD} \label{fig:gparted} \end{figure} Select the SD-CARD in the upper-right hand corner, it should be the one with almost 512 MB (or more if you are using a larger SD-CARD). Highlight the partition, and select \verb|Partition->Unmount| from the drop-down menu (in the case that the SD-CARD has no partitions, you might not need to do this step). You want to create a new FAT23 partition with 512MB as the size. With a larger SD-CARD, you will have to create a new partition (verb|Partition->New|) that is 512MB in size. In the case of the 512MB SD-CARD, you can simply highlight the single partition. With the partition selected, format it to \verb|FAT32| (in the file menu \verb|Partition->Format-fat32|). \textbf{Important}: Click on the green tick' (check-mark) to apply the changes. Figure \ref{fig:format} shows a successful format. \begin{figure}[h!] \centering \includegraphics[width=0.9\textwidth]{figures/format.png} \caption{Format the SD-CARD with a single 512MB partition} \label{fig:format} \end{figure} \begin{figure}[h!] \centering \includegraphics[width=0.9\textwidth]{figures/renamed-demo.png} \caption{Rename \texttt{cfw-1.2.bin} to \texttt{demo.bin} on the SD-CARD} \label{fig:renamed} \end{figure} \paragraph{Copy and Rename CFW} Remove and reinsert the SD-CARD. When the pop-up appears this time choose \textit{Open in File Manager}. Copy the CFW (i.e. \verb|cfw-1.2.bin|) to the SD-CARD, and re-name it \verb|demo.bin|. \textbf{Important}: in the upper right hand corner of the Desktop, click on the eject icon in the toolbar (it's next to the bluetooth icon), and select the SD-CARD from the drop-down. You can now remove the SD-CARD. \paragraph{Flashing the Device} Next, turn off the NEOS camera by unplugging the USB. It might be easier to remove the plug from the power strip, rather than the USB on the device to not disturb your debug port wires. Insert the SD-CARD with the custom firmware into the NEOS camera. Before you turn it on, find the Set-up'' button, which is on the same side of the PCB as the SD-CARD holder on the circuit board. Also, find the status LED (next to the USB connector on the back). You will need to hold the Set-up'' button for a long time, so use a piece of plastic or a tool to press the button to save your finger. With it held, turn the NEOS camera back on (you might want to have someone help you). Keep the button pressed, the status LED should turn from a solid yellow to a solid blue color. After 20-30 seconds, you release the button. Eventually the LED will blink rapidly to indicate the flashing of the new firmware was a success. This takes about 3 minutes.