The intent of this week was to take a deauth attack and roll it into having a trigger. Except I took on helping to organize a conference that happened this week, and so this project was sidelined. I did manage to get a successful deauth attack running on a generic ESP2866 via a tutorial and a few github repos, but didn’t really get to dig into why it was working and modding it. That said, I did start looking up books and lessons that I could read /do that would help me understand the wireless stack a bit better. Some of them were:
Overview: For this week, my goal was to poke around with Wireshark and learn a bit more about networks. I decided I would also try using pyshark, which is a python wrapper around Wireshark’s command-line utility tshark. Originally I had thought I would pipe some data into Processing to do some viz with it, but at the end of the week realized that Processing already had Carnivore as a library, which allowed packet for in-Porocessing packet sniffing. Wish I’d thought of looking to see if that existed earlier. But oh well? Its nice to know it exists, and I will explore it in the future.
What I ended up doing instead was writing some utility functions to comb through captured data and return the most active of whatever items you send through it. Pyshark has some good ways to dig down into packets, but it can also just grabs all the summaries. So if you want to compare traffic, look for protocols, or just poke around, you can toss together some basic functions to do so.
I think in the end I liked doing the utility functions more than the idea of visualizing it. I would get to the point of having a dataset, and instead of moving on, would go back and dig around in the packets a bit more.
Of Note: One thing to note though is that LiveCapture in pyshark can sometimes be borked in OSX. Wireshark (and other sniffers) require read access to “/dev/bpf*” which is usually owned by root/wheel. When you use Carnivore, you have to change the permissions on this to 777, which is…very permissive. You will have to do this each time. Wireshark creates a user group, and adds the person who installed wireshark to this group. So pyshark should be able to use tshark under your user without this extra step.
If you can’t get it working then either you need different permissions, or like me, you are trying to read a networking interface that doesn’t exist…because you weren’t paying attention. Then ended up in a 1 day rabbit hole…but I learned some things about what’s depreciated in the OSX system.
Other things I rediscovered: using man pages, and using python’s dir() function. Which is really useful when you want to know what kind of methods you can use on something.
Heartbeater was a pretty straightforward idea: Make a small IoT based notifier to tell you what someone else’s heartbeat is. It was a way to get reacquainted with some IoT services, and experiment with mapping data. However, there ended up being a lot of troubleshooting. I didn’t get a chance to start on an enclosure, but did get to a proof of tech stage.
Components
Using It
Bean Test
Proto Test
Neopixel Values
I/O Feed
UART Feed
UART Feed
XCode Failing
System: In the end I made a basic BLE based heartbeat reader out of a feather that someone could carry with them, and a wifi notifier on the other end that could remain stationary in someone’s home. I had considered making them both ble, but ran into some issues.
Things I Experimented With: Lightbluebeans, Xcode, Particle Dev, Adafruit ble library.
Things I learned: IoT tools are very inconsistent. I’ve used Adafruit I/O before, and I like it for simple things. In this case, I had originally thought of making both devices strictly wifi, but then thought “no the pulse sensor should be a carry item” and switched to a BLE > Phone setup. The beans, while great to use, don’t have an out of the can phone > BaaS provider, so I first tried rolling my own iOS app (its been a while), but fell into an Apple update spiral (it wanted me to update everything). Bluefruit Connect LE ended up being what I used to get the UART data to I/O, but its not consistent across devices (ie: MQTT service wasn’t in the ipad app). So I switch the notifier back to just wifi. I experimented putting things on a Feather protoboard, but had some issues w/ pins. So i flipped back to the photon. This project probably could have gone smoother if I had plotted out my system a bit better.
Future Versions: I think I would try again to roll my own iOS app and using two smaller beans on either end chatting through two phones, this would make them very portable. I might also consider a GMS breakout, which might be nicer.
Of Note: ble feathers do not have the 1v analog pin issue that the huzzah does. Bean currently has system issues in OSX with the virtual serial port, but a nice new command line tool. The particle command line tool is still my favourite. I find serial printing on the feather boards a bit of a pain sometimes. Pulse sensors are very inaccurate. The Huzzah issue I had had previously w/ the I/O library colliding with the Neopatterns Class seems to have been fixed by Adafruit.
