[solved] RASPBIAN STRETCH Support

[KonstantinDimitrov]

Raspbian stretch support, thank you !

[mame82]

Not sure if I'm going to do this in near future. According to here https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.html interface names got changed. So I can't keep backward compatibility without having to handle JESSIE vs STRETCH with if/else conditions in several boot scripts. As I still change these scripts on regulary basis, this has to wait.

P4wnP1 is meant to be a tool supporting pentests and not a production system. Thus the advantages of fully migrating to stretch aren't obvious to me (except the patched broadcom vuln).

[Swiftb0y]

The broadcom vuln, the newer dd version, newest kernel version, debian stretch... There are a lot of advantages, so I would appreciate an update in the near future as well.

[PoSHMagiC0de]

First, love this project. I bought 2 Zeros just because of this to try it out. Have plenty of Pi 1s, 2s and a 3. Anyway, I got P4wnP1 to work with stretch with little extra work. The big difference is a lot of stuff has to be ran with sudo now. After installation I had to hand install pydispatcher as sudo, pycrypto too. I had to go into the payload scripts to add sudo in front of the led commands and the command that fires off the P4wnP1 server so it had access to /dev/hidg. Got that error. So far the duckyscript and the hid_backdoor is functioning fine. Network-only does too. I have not tried the lock picker and stuff to see if it will complain. I got this for the backdoor hehe. I have tons of responder projects already though this one is cool that it is supposed to type out the password if it is discovered.

Anyway, love the project. Thought I would post I do have it working on stretch so far. Seen someone want to mix metasploit with it. I am going with Empire because it is python too and might can figured out to merge them into one though I am lazy so who knows. :-P

[mame82]

@PoSHMagiC0de thx for your feedback om this. But I'm wondering about some facts:

• pycrypto and pydispatcher are ran with sudo by install.sh
• backdoor server is started by a systemd service with root privs, so access to /de /hidg* should be granted (thats needed on Jessie, too)
• the payload itself should run with root provs, too. Thus led_blink should work. The exception is onLogin callback, which uses a modified led_blink command with sudo, already.

I have to tesr stretch, as soon as I got the time to do

[PoSHMagiC0de]

@mame82 I have several SD Cards so i will go through the install again. I think I made 1 mistake but do not know if it caused the issue. I was is such a hurry I made the image to my SD but never ran raspi-config to expand my storage. Doh. Wonder if I had space issues. I am going to go through the process again this evening with a fresh SD card and expanding the storage first before installing P4wnP1. I did get red running the install script but it was mainly with the pip stuff. I got it afterwards too when I tried to correct by hand. Only a day alter when i tried again it installed the missing dependencies for python.

Will post here again if my missing step was the issue and if Stretch is all good. But besides that, the interfaces and everything work as intended. All my issues with dependency issues and permission that I hope was my goof up.

Oh, I may steal your idea of compiling agents as .NET dlls to be launched with powershell. I forgot about that in my project I have posted for the BashBunny. Its agent is all Powershell too.

[PoSHMagiC0de]

@mame82

So, took me several tried this time to get it to go through. Raspian does an auto resize on first boot so no issue there. Install steps I did was first I updated and did the install myself for git, python, python-crypto and python-pip. When done I rebooted, just be be sure and reconnected with the Pi. I then did the sudo pip install for pycrypto and pydispatcher myself which gave no red like it normally does. I remarked out the jessie check if statement in the setup.cfg after cloning the repo. I then ran the install which still gave an error on the pip dependencies but I knew they were installed so were fine. Wonder if the kernel patching it is doing is needed for stretch but it finished.

I rebooted and sshed back in to see if network worked. Sor some reason I can ping stuff on my network but cannot inet share to the internet. No name resolution or pinging of IPs while in network mode on a linux machine. Hmm.

Changed payload to be hid_backdoor and rebooted. Logged into wifi and sshed into pi, menu works on first try. Something is miffing during the install if not done a certain way like I get errors with the pip installs on your script but didn't when I did it by hand on a clean reboot.

The inet sharing thing is wierd. Wonder if it has to do with the extra nics being made.

[mame82]

Thanks for the effort you put into analyzing Stretch compatibility.

According the ICS problem, it sounds to me like your network adapter got a "public" profile assigned.

I've done a small tutorial on how to get around this problem: https://youtu.be/QEWaIoal5qU

[PoSHMagiC0de]

@mame82 Hey, I figured out my ICS issue. I am working off of Linux. Parrot OS to be exact so public/private thing doesn't apply to me hehe. The issue I was having was the ethernet type. It is the same issue I see with the BashBunny that certain modes work better with certain OSes. I Pi Zero default doesn't have a selection for this but I am glad your project adds the ability. I disabled RNDIS in the network only payload so only ECM will be used on my system. Result was no DHCP to usb0 but after applying an ip, enabling ip forwarding and adding a table to masquerade I was was able to get DNS resolution to the outside. RNDIS enabled me to get an IP and ssh to the PI but not get ICS going. I looked at traffic through wireshark and it was just not getting any response on anything though the query was hitting my machine. The RNDIS and ECM thing I am fine with as it is what I am used to and ICS will only be used when I am needing to work on the PI so when I need it for an attack I can switch it to RNDIS since it will work on both OSes and my attacks will be local anyway. That explains why I got two interfaces coming up but only 1 had an IP but that one did not work and the only time it worked was the first time I loaded it I was fiddling with so many settings I think i set the ecm one up with an IP that got it up and going that one time but didn't realize it. Oh well. I figured it out and got it working.

[mame82]

@PoSHMagiC0de

Great analysis on this. If both, ECM and RNDIS are enabled, P4wnP1 internally polls both interfaces on its end for link (carrier). As soon aa one of the both internal interfaces (usb0 = RNDIS, usb1 = ECM) has link, the other one gets disabled. The purpose is to only run one DHCP server with a single configuration (same subnet) on the interface in use. In case the target supports both interfaces (link on usb0 and usb1 internally), RNDIS gets disabled and ECM is uses. The shortcoming is, that the target has an active RNDIS device, although the endpoint on P4wnP1's end has been disabled.

Logic is here:

https://github.com/mame82/P4wnP1/blob/master/boot/init_usb_ethernet.sh#L42

[PoSHMagiC0de]

@mame82 So, I figured out the errors in the install script. I finally saw the final errors after the pips ran. If you run pip while in the P4wnP1 folder, it will read that setup.cfg for P4wnP1 and error out. Either the install.sh has to temporarily rename that file while it does its thing or that file will need a permanent renaming that doesn't clash with the other tools that may need to be ran from that folder. I did "another" clean install and this time I renamed the setup.cfg file temporarily since there was only an echo statement referring to it in the install.sh. Ran the install with a new modified line that checks for stretch too and it ran with no errors. Changed setup.cfg file back and rebooted. Everything works as intended.

You could also move the install.sh into an install folder and redo the install script to work from that folder also. Or maybe on that part of the script switch directories out of that folder to do the pip installs and switch back when done. Keep coming up with ideas after commenting.

[mame82]

@PoSHMagiC0de Thx to your analysis, I was able to quickly make the installer stretch compatible: https://github.com/mame82/P4wnP1/commit/a022e7fbba8417270e290fe09efbcc95c8b3bd62#diff-3fbb47e318cd8802bd325e7da9aaabe8

Temp. renaming of setup.cfg was chosen (wasn't able to find a way to supress python setuptools reading setup.cfg). Not the best way, but it works. I haven't tested all payloads so far, but at least there isn't an issue with renamed interfaces, as stated here: https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.html

So I hope everything is fine.

@all Help on updating install instructions would be appreciated. PRs on this are welcome. So thx for pointing me to stretch update.

[mame82]

@jcstill thx for PR with instruction update