wismna/hackpi
1
0
Fork 0
mirror of https://github.com/wismna/HackPi.git synced 2025-10-03 15:40:16 -04:00
Code Issues Packages Projects Releases Wiki Activity

Better installation procedure

Browse Source
This commit is contained in:
wismna
2017-01-16 11:50:38 -05:00
committed by GitHub
parent 780c38f162
commit f473cbb5a5
1 changed files with 64 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

85
readme.md
View File

@@ -9,25 +9,66 @@ I wanted to integrate the two hacking mechanisms on a single Raspberry Pi Zero s
<ol>
<li>Install the necessary software:
<ul>
<li>sudo apt-get update</li>
<li>sudo apt-get upgrade</li>
<li>sudo apt-get -y install isc-dhcp-server dsniff screen nodejs bridge-utils</li>
<li><code>sudo apt-get update</code></li>
<li><code>sudo apt-get upgrade</code></li>
<li><code>sudo apt-get -y install isc-dhcp-server dsniff screen nodejs bridge-utils</code></li>
</ul>
</li>
<li>Copy or clone <a href="https://github.com/samyk/poisontap">PoisonTap</a> into your user's home folder (usually /home/pi)</li>
<li>In the poisontap folder, replace the <i>pi_startup.sh</i> file with mine</li>
<li>Copy or clone <a href="https://github.com/lgandx/Responder">Responder</a> into your user's home folder (usually /home/pi)</li>
<li>Copy or clone the umap folder from my repository into your user's home folder (usually /home/pi)</li>
<li>(optional) Make a backup of the <i>dwc2.ko</i> file in <b>/lib/modules/4.4.38+/kernel/drivers/usb/dwc2</b></li>
<li>Move the <i>dwc2.ko</i> file from the /home/pi/umap folder to <b>/lib/modules/4.4.38+/kernel/drivers/usb/dwc2</b></li>
<li>Copy or clone <a href="https://github.com/wismna/HackPi">Hackpi</a> into your user's home folder (usually /home/pi):
<br/>
<code>git clone https://github.com/wismna/HackPi</code>
</li>
<li>Copy or clone <a href="https://github.com/samyk/poisontap">PoisonTap</a> into your user's home folder (usually /home/pi):
<br/>
<code>git clone https://github.com/samyk/poisontap</code>
</li>
<li>In the poisontap folder, replace the <i>pi_startup.sh</i> file with mine
<br/>
<code>mv -f hackpi/pi_startup.sh poisontap/</code>
</li>
<li>Copy or clone <a href="https://github.com/lgandx/Responder">Responder</a> into your user's home folder (usually /home/pi)
<br/>
<code>git clone https://github.com/lgandx/Responder</code>
</li>
<li>Move the umap folder from my repository into your user's home folder (usually /home/pi)
<br/>
<code>mv hackpi/umap ~</code>
</li>
</li>
<li>(optional) Make a backup of the <i>dwc2.ko</i> file in <b>/lib/modules/4.4.38+/kernel/drivers/usb/dwc2</b>
<br/>
<code>sudo cp /lib/modules/4.4.38+/kernel/drivers/usb/dwc2/dwc2.ko /lib/modules/4.4.38+/kernel/drivers/usb/dwc2/dwc2.ko.bak</code>
</li>
<li>Move the <i>dwc2.ko</i> file from the /home/pi/umap folder to <b>/lib/modules/4.4.38+/kernel/drivers/usb/dwc2</b>
<br/>
<code>sudo mv umap/dwc2.ko /lib/modules/4.4.38+/kernel/drivers/usb/dwc2/</code>
</li>
<li>Replace system files (optionally make a backup of your originals beforehand)
<ul>
<li><i>config.txt</i>, located in /boot</li>
<li><i>modules</i>, located in /etc</li>
<li><i>rc.local</i>, located in /etc</li>
<li><i>isc-dhcp-server</i>, located in /etc/defaults</li>
<li><i>dhcpd.conf</i>, located in /etc/dhcp</li>
<li><i>interfaces</i>, located in /etc/network</li>
<li><i>config.txt</i>, located in /boot
<br/>
<code>sudo mv -f hackpi/config.txt /boot/</code>
</li>
<li><i>modules</i>, located in /etc
<br/>
<code>sudo mv -f hackpi/modules /etc/</code>
</li>
<li><i>rc.local</i>, located in /etc
<br/>
<code>sudo mv -f hackpi/rc.local /etc/</code>
</li>
<li><i>isc-dhcp-server</i>, located in /etc/defaults
<br/>
<code>sudo mv -f hackpi/isc-dhcp-server /etc/defaults</code>
</li>
<li><i>dhcpd.conf</i>, located in /etc/dhcp
<br/>
<code>sudo mv -f hackpi/dhcpd.conf /etc/dhcp</code>
</li>
<li><i>interfaces</i>, located in /etc/network
<br/>
<code>sudo mv -f hackpi/interfaces /etc/network</code>
</li>
</ul>
</li>
<li>Reboot the Pi, it should work!</li>
@@ -40,16 +81,18 @@ For troubleshooting, you should be able to connect to your Raspberry Pi via the
<h2>How it works</h2>
<h3>Creating the ethernet gadget</h3>
This was the most irritating part of all. The really simple way to do this on the Pi is to follow <a href="https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget/ethernet-gadget">this guide</a> and use <b>g_ether</b> kernel module. However, this is the old way of doing it and it would definitely not work at all on Windows. During all my test, the gadget was systematically recognized as a COM3 device. I couldn't even force newer versions of Windows (10) to use an Ethernet driver. Also, it's impossible to emulate more than one device at the same time.
The really simple way to do this on the Pi is to follow <a href="https://learn.adafruit.com/turning-your-raspberry-pi-zero-into-a-usb-gadget/ethernet-gadget">this guide</a> and use `g_ether` kernel module. However, this is the old way of doing it and it would definitely not work at all on Windows. During all my test, the gadget was systematically recognized as a COM3 device. I couldn't even force newer versions of Windows (10) to use an Ethernet driver. Also, it's impossible to emulate more than one device at the same time.
So, I started with this <a href="http://isticktoit.net/?p=1383">great guide</a>, and used the <b>libcomposite</b> kernel module. This was far more advanced as it allows precise configuration of the gadget, as well as giving the ability to emulate more than one device at the same time.
So, I started with this <a href="http://isticktoit.net/?p=1383">great guide</a>, and used the `libcomposite` kernel module. This is far more advanced as it allows precise configuration of the gadget, as well as giving the ability to emulate more than one device at the same time.
I used an Ethernet gadget adapter as well as the serial adapter configuration. The serial adapter is very very useful, especially while testing the Ethernet configuration, as if you make a breaking change and can't ssh back to your Raspberry Pi Zero, you still can use the console: <br/>
<code>sudo screen /dev/ttyACM0 115200</code>
`sudo screen /dev/ttyACM0 115200`
To make the Ethernet gadget work on Windows, I used a little trick. When it's starting the adapter, it will look in its .inf files for a matching driver based on idVendor and idProduct (as well as bcdDevice for revision). Knowing this, I used <br/>
<code>echo 0x04b3 > idVendor</code><br/>
<code>echo 0x4010 > idProduct</code><br/>
```
echo 0x04b3 > idVendor
echo 0x4010 > idProduct
```
so that Windows would load its generic RNDIS driver <i>netimm.inf</i>.
However, this still wouldn't work for me, even though it appeared to be working for other people. Windows would load the drive but fail to start the adapter with a code 10 error.
@@ -60,7 +103,7 @@ And lo and behold, it worked! Windows correctly loaded the driver and the adapte
I realized (thanks to the serial console) that each configfs configuration creates a new network interface (usb0, usb1 and so on). However, all the servers were listening exclusively on usb0, which was assigned to the RNDIS configuration. Linux ignored this configuration to load the CDC ECM one, where no servers (especially ISC-DHCP) were listening and no routes nor iptables rules were added.
The easy solution would have been to duplicate everything, but I decided to create a bridge interface instead, <code>br0</code>, which would be the master of all <code>usbX</code> interfaces. Then, I would make the servers listen on that interface, as well as add the routes and iptable rules.
The easy solution would have been to duplicate everything, but I decided to create a bridge interface instead, <code>br0</code>, which would be the master of all usbX</code> interfaces. Then, I would make the servers listen on that interface, as well as add the routes and iptable rules.
After a bit of fiddling around, it worked!
My gadget was now automatically recognized by Windows and Linux, without having to change anything to the configuration files. But, as there is always a but, you may have noticed that I stopped talking about Mac... and this is because since version 10.11, MacOs is no longer smart enough to load the CDC ECM configuration if it isn't the first one! I now needed a way to make the gadget recognize the host it was connected to via USB fingerprinting, so that I could better configure libcomposite.