Commit ccb4d09f authored by Chipp Jansen's avatar Chipp Jansen
Browse files

Merge branch 'main' of ../linz-workshop-2021 into main

parents 9a52fde3 c14a82c0
This diff is collapsed.
% Language setting
% Replace `english' with e.g. `spanish' to change the document language
% Set page size and margins
% Replace `letterpaper' with`a4paper' for UK/EU standard size
% Useful packages
\usepackage[colorlinks=true, allcolors=blue]{hyperref}
\title{Hardware Hacking Workshop -- Building the Zombie Cloud}
\author{Chipp Jansen \\ \texttt{}}
\date{Nov 2021}
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %
\section*{Day 2}
% Day 2 Ideas
% A. Demonstrate Cross Compile on a Linux Laptop.
% B. Have Compiled a mips gcc for the Pi that lets them compile and install an existing program.
% C. Steps to Prepare your own Cross Compiler for NEOS, needs to run on a Pi. Note that on an existing Linux -- you can apt-get and/or use the tools in the Dafang-Hacks
% D. Work on compiling (Micro)Python on Linux Laptop for the NEOS, Install and Run on NEOS
% E. Brainstorm and Design around the Horgesbord Idea.
Today's workshop is a bit more open ended.
\paragraph{Continue on Day 1} You can continue to work on Day 1 or are new and can start working through the Day 1 portion of this workshop. Even if there is no fresh NEOS camera to open up, you can use an already open one and go through the steps to accessing it.
\paragraph{More hacking} Some of you might be interested in continuing to work on the NEOS and continue to work on a idea that you started with in Day 1. Please continue hacking, that is the spirit of this workshop.
Today, there are instructions in setting up a \textit{toolchain} to compile and work on your own program on it. Typically with embedded devices like the NEOS, you would not prepare the programs on the device itself. Instead you \textit{cross-compile} the program on a separate machine (such as your laptop or the Raspberry Pi), and copy the program over to device.
However, this process of cross-compiling and copying is tedious. IoT devices these days are powerful enough to run interpreted languages, such as Python and Javascript. (They are running shell scripts in Linux after-all). With Python, for example, there are great systems that are available to work with embedded devices. CircuitPython (\url{}) (which is a variant of MicroPython \url{}) eases this development loop by allowing one to see the device like a USB drive. Connect the device to a laptop, and then edit a file, \textit{}, and then as soon as you save the file, the device resets with your new running code. While these devices are typically micro-controllers, this is a great pattern for working with a device such as the NEOS.
\paragraph{Co-design} With this spirit of increasing the ease of hacking a device in mind, we can use this time in the workshop to dream, brainstorm and design novel ways of working with old devices. What would enable artists, designers, hackers and curious folks in ways of hacking?
\subsection{What is Cross-compiling}
A \textbf{compiler} is a program that converts a text file that contains \textbf{source code} into a binary file that can be run on a piece of hardware (i.e. an \textbf{executable}). In C and C++ programming, a commonly used compiler is the GNU C Compiler, or \texttt{gcc}. Usually, the compiler is run on the same hardware as the produced executable program. For example, you would use \texttt{gcc} on your Raspberry Pi to produce a executable program that also runs on the Raspberry Pi.
However, in embedded and IoT development, the device you are building programs for is not set-up to compile programs. In this case you do \textbf{cross-compiling}, where you run the compiler on a \textbf{host} system (i.e. the Raspberry Pi) and produce executable programs for a \textbf{target} system (i.e. the NEOS). There are also other tools that you use to help the compiler to produce executable programs. This collection of tools and files is called a \textbf{toolchain}.
%Tour of the Repo -- it's a mess. Toolchain is a binary that runs on Linux. If you are familiar with the C compiler, gcc, it's in toolchain/bin/mips-linux-gnu-gcc.
\subsection{Setting up BuildRoot}
Fortunately, we do not need to begin from scratch, as others have created handy tools to build toolchains and do cross-compiling. We will be using the Buildroot project (\url{}) to help us set-up a cross-compiling toolchain on the Raspberry Pi to compile programs for the NEOS. I have already set-up a NEOS specific toolchain with Buildroot, which we will use today.
\paragraph{Set-up Toolchain to Raspberry PI} Copy the files from the SD-CARD to your Home directory.
Then in a new Terminal window, you will unpack the files with these commands (\textit{Note: it may take some time for all of the files to unpack as it is circa 4GB of files!}):
pi@raspberry:~ $ tar zxvf buildroot-2021.08.2.tar.gz
pi@raspberry:~ $ tar zxvf neos-toolchain-empty.tar.gz
There are now two directories \texttt{buildroot-2021.08.2} and \texttt{neos}. Buildroot is the system for managing cross-compiling for embedded devices. \texttt{neos} is the already prepared toolchain for compiling for the NEOS. You will find the cross-compilers in \texttt{neos/host/bin}:
pi@raspberry:~ $ ls neos/host/bin
All of these files that start with \texttt{mipsel-linux-} are the tools that we use on the Raspberry Pi to build files for the NEOS. FYI: the NEOS has a MIPS architecture, which is a type of computer chip, just like how laptops and desktops usually have an Intel x86 architecture, and phones have an ARM architecture.
\subsection{Hello World}
Let's prepare a hello world program to test our cross-compilation toolchain.
On the Raspberry Pi, using the Text Editor create a new file in your Home directory called \texttt{hallo.c}.
Copy the code below into the file. This is a basic C program. You can see that it will print out a little message when it runs:
int main(void) {
printf("Hallo Servus!\n");
return 0;
\paragraph{Compiling Hello World} You can compile a C program with the GCC compiler (\texttt{mipsel-linux=gcc}) in our toolchain.
pi@raspberry:~ $ neos/host/bin/mipsel-linux-gcc hallo.c -o hallo
You now should have a binary executable file called \texttt{hallo}. You can find information about any file using the \texttt{file} command:
pi@raspberry:~ $ file hallo
hallo: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/, not stripped
It tells use that this an executable file, or a program that you can run, in the MIPS architecture. There is additional information about what C libraries it will use and details about the processor that it will run on (i.e. a 32-bit processor).
\paragraph{Copy the program to the NEOS} We cannot run our program on the Raspberry Pi. We need to copy it to the NEOS. We will do that over the network using the command \texttt{scp}.
\textbf{Important!} Replace \texttt{YOURHOSTNAME} with the hostname of your NESO that you set-up earlier.
pi@raspberry:~ $ scp hallo root@YOURHOSTNAME.local:~/
\paragraph{Run the program on the NEOS} Now we can log into the NEOS and run our program. We can use the debug terminal window connected to the NEOS. Or you can \texttt{ssh} to login to the NEOS (use the password \texttt{ismart12}:
pi@raspberry:~ $ ssh root@YOURHOSTNAME.local
root@YOURHOSTNAME.local's password:
And now you can run your program:
[root@chippneos.local:~]# ./hallo
\textbf{Bravo!} You have successfully cross-compiled and run a program on the NEOS!
\subsection{Using Buildroot to Compile Programs}
Building more sophisticated programs than our \texttt{hallo} is more complicated. Often times you want a specific existing program to run on your device. The process for this would be to get the program source code and cross-compile it yourself which with programs written in C can be a long and confusing process.
We can use \texttt{Buildroot} to help us do this as a sort of \textit{package manager}.
\paragraph{Browse the Available Packages} In order to use \texttt{Buildroot} to do this, we need to figure out what packages are available. There is a sort of menu which we can use to do this.
First, open a new Terminal on the Raspberry Pi. Then, in the Terminal, go into the \texttt{neos} directory to run \texttt{Buildroot} menu:
[root@chippneos.local:~]# cd neos
[root@chippneos.local:~]# make menuconfig
After a while this starts a sort of menu system that is similar to the \texttt{raspi-config} menu we used earlier.
Under the \textit{Target packages} option, you will find different categories of things that we can cross-compile. For instance, under \textit{Games}, you will find some interesting named options.
With any option selected, you can press \texttt{?} to get a little bit information about the package.
Under \textit{Game}, view the extra information for the \textit{sl} package. This is the package we are going to build. We need to remember the name from the menu of the package. In this case, it is \texttt{sl}.
You can exit the menu system by hitting the \texttt{ESC} key repeatedly.
\paragraph{Compile the Package} Using \texttt{Buildroot}, compiling the package is simple. To start the process we will use the \texttt{make} command:
pi@raspberry:~ $ make V=1 sl
This will take a long time to compile.
\paragraph{Copy the Compiled Files to the NEOS}
Now, the compile file \texttt{sl} is located in the directory \texttt{neos/target/bin}.
In a new Terminal on the Raspberry Pi, you can copy it to your NEOS with the \texttt{scp} command:
pi@raspberry:~ $ scp neos/target/usr/bin/sl root@YOURHOSTNAME.local:~/
Then on the NEOS, you can run the program:
[root@chippneos.local:~]# sl
You will find that you have an error and you have some library files missing.
\paragraph{Copy the Library Files to the NEOS}
Back on the Raspberry Pi, copy the library files onto the NEOS.
pi@raspberry:~ $ scp neos/target/usr/lib/* root@YOURHOSTNAME.local:/system/sdcard/lib
Then on the NEOS, you can run the program, again:
[root@chippneos.local:~]# sl
You'll notice that there is another error, \texttt{sl} requires an environment variable to be set on the NEOS:
[root@chippneos.local:~]# setenv TERMINFO=/system/sdcard/lib/terminfo
Now, finally you can run \texttt{sl} and finally be rewarded with a small animation:
[root@chippneos.local:~]# sl
% Setting up the tool chain to compile your own tools to run on the device. Requires cross-compiling. Here is an example of compiling something for the device.
% The Dafang-Hacks Github repository \footnote{\url{}} has the cross-compile set-up for the build environment.
% Building more sophisticated programs is more complicated. Often times you want a specific existing program, get the source, build it and then install it on the device. There is no package manager for the NEOS (at least not yet!). So this is done manually.
% Even though all of the \verb|compile*.sh| scripts look different, they follow the same pattern.
% \begin{enumerate}
% \item Set-up Environment variables. Here this is done with \verb||
% \item Get the source code. Using \verb|git| or downloading a compressed snapshot of the source (a \verb|.tar.gz| file).
% \item Optionally, modify the source code so that it will work with the NEOS. Typically using complicated Unix commands.
% \item Run a \verb|configure| command, which prepares the compilation process for your specific environment. For example, make sure the final compiled binary is placed in a specific directory.
% \item Run \verb|make|. This uses a \verb|Makefile| which controls the sequence and running of the necessary toolchain programs, such as \verb|mips-linux-gnu-gcc|
% \item Install the compiled program (and related shared libraries). Typically one calls \verb|make install|, but sometimes this is done by individual commands. In this case, the scripts install the binaries into the directory \verb|_install| at the root of the \verb|Dafang-Hacks/Main| repository.
% \end{enumerate}
% \section{Example cross-compile script}
% Below is the \verb|| script\footnote{\url{}} to compile \verb|bftpd| an FTP server.
% % Demonstration with bftpd with Linux Laptop
% \begin{Verbatim}[numbers=left,xleftmargin=5mm]
% #!/usr/bin/env bash
% set -e # fail out if any step fails
% . ../../
% if [ ! -d bftpd ]
% then
% wget
% tar xvfz bftpd-5.4.tar.gz
% rm bftpd-5.4.tar.gz
% cat << EOF > bftpd/mypaths.h
% #define PATH_BFTPD_CONF "/system/sdcard/config/bftpd.conf"
% #ifdef PREFIX
% #define PATH_BFTPD_CONF_WITH_PREFIX PREFIX"/system/dafang/bftpd.conf"
% #endif
% #define PATH_STATUSLOG "/dev/null"
% fi
% cd bftpd
% ./configure --host=mips-linux --enable-debug --prefix=${INSTALLDIR}
% make clean
% sed -i "s/LIBS= -lcrypt/LIBS=\${TOOLCHAIN}\/..\/mips-linux-gnu\/libc\/uclibc\/usr\/lib\/libcrypt.a -muclibc/" Makefile
% make
% cp bftpd ${INSTALLDIR}/bin
% \end{Verbatim}
% Line 5 is where the Environment variables are set (with the \verb||) -- notably the \verb|INSTALLDIR| variable is where the compiled program will be placed once compilation is done.
\subsection{Onward Routes}
Writing your own programs for an IoT device, such as the NEOS, often requires very detailed documentation on the chips that make up the embedded systems. Maker-friendly devices such as the Arduino, Raspberry Pi and the CircuitPython community aim to abstract the system's details in order to ease the process for building software. Unfortunately, the Ingenic-T10/20 chips, and NEOS are not supported by these software efforts -- but \textit{that does not mean that they don't have to!}
While the NEOS was not built to be developed on, like the Raspberry Pi, this whole process of cross-compiling would be easier if we could use already all of the great creations tools that exist in the Open Source Hardware community. For the NEOS the first steps of gathering information on the Ingenic chip has been done. You will find some documentation on the Dafang-Hacks github repo \footnote{\url{}} for developing for the Ingenic chip. Maybe the experience with this workshop has peaked your interest in doing some hacking or has given you some ideas on how to make it more possible to re-use and re-purpose some IoT devices.
% \section{Creating your own Firmware}
% Once you
% \subsection{Dumping Original Firmware}
% \textcolor{red}{This is something that can be done on the device and Raspberry Pi}
% \textcolor{red}{This is something that can be done on the device and Raspberry Pi}
% %
% In this device's case, creating your own firmware is a matter of bundling a linux file-system together. We do this by getting the original firmware, un-squashing it, add the bits we want, and resquash it.
% A security issue here might be that the device expect a signed firmware - a secure method of guaranteeing that the firmware is not modified. But, in this devices case, there is no check being done. This security oversight is to our advantage, and it allows us the ability to create our own set-up.
% \subsection{Adding new Software to the Device}
%% Here we are going to load Python, CircuitPython, or MicroPython.
% Other ideas:
% \begin{itemize}
% \item Flashing new firmware / setting-up CircuitPython
% \item OpenOCD on Raspberry PI
% \end{itemize}
% \section{Using CircuitPython or MicroPython}
% - Reading/Writing I/O - Buttons and Blinking LEDs
% - Sensor Data
% - Drawing on the Device Screen
% - Audio
% - Images from Camera
With the experience of doing some talking and hacking with computers, here we can maybe brainstorm and imagine some future direction and possibilities here.
% \textcolor{red}{Informal whiteboard and discussion. Exercises in case nobody feels like talking or to spur discussion?}
The original idea that inspired me for this project was to combine the reality that we have a growing horde of un-used and old electronics. While not cutting edge, there is a bit of a wasted opportunity here. While electronics recycling exists, it resides within a capitalistic system and currently requires market forces to motivate it to be done. It's also the case that this circuilar supply chain is not working, and recycling electronics ends up in landfills and incinerated.
When there is an abundance of an dis-used resource, a little tender loving care (TLC) can go a long way. Look at the housing squat movements, which re-inhabited abandonded spaces and there are/were moments of creativity and positive re-used.
Here we have 12 used IoT security cameras, can we connect them together to make one larger single camera? How about an impromptu streaming studio?
What can one do with a 20 discared mobile phones? Can we connect them together and make a highly redundant web-server spread across multiple devices?
How about 101 really old SD-CARDs? Could they become one large SD-CARD, however faulty?
Being able to re-use old devices also offers opportunities to experiment with lesser cost or harm to new ``good'' devices.
% \href{}{choose your plan}.
% \verb|.bib|
% \begin{figure}
% \centering
% \includegraphics[width=0.3\textwidth]{frog.jpg}
% \caption{\label{fig:frog}This frog was uploaded via the file-tree menu.}
% \end{figure}
% \bibliographystyle{alpha}
% \bibliography{sample}
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment