- I may have installed GQRX from the Applications/System Tools/Add Remove Software utility. I can't remember; I added a ton of stuff.
- Plugged in my SDR dongle with an antenna connected
- Opened GQRX
- Set the frequency to 144.390 (US frequency for APRS)
- Opened the AFSK1200 decoder
Tuesday, November 4, 2014
SDR Dongle and APRS with GQRX on Kali
Monday, October 13, 2014
Building and Using Mac-Robber on Android
Compiling and Installing mac-robber on Android
You can learn more about mac-robber for Android and iOS here. Note that, in Sawyer's article he includes the following instruction for compiling. This is incorrect:arm-linux-gnueabi-gcc -static -o -mac-robber mac-robber.c
The - before mac-robber is unneccesary. The correct command is
arm-linux-gnueabi-gcc -static -o mac-robber mac-robber.c
- First step is to download the source files from http://www.sleuthkit.org/mac-robber/download.php.
- Next, add a repo so you can cross-compile mac-robber onto the Android platform:
sudo add-apt-repository ppa:linaro-maintainers/toolchain - Next, install the GNU compiler:
sudo apt-get install gcc-arm-linux-gnueabi - Finally, compile the source:
arm-linux-gnueabi-gcc -static -o mac-robber mac-robber.c
Running mac-robber
Interpreting the Results
- Download the sleuthkit from http://www.sleuthkit.org/sleuthkit/download.php
- CD into the extracted sleuthkit
- Build the sleuthkit. Note: I skipped the last step (sudo install) simply because I didn't want to run the risk of clobbering my OS's mactime with the sleuthkit's version
- ./configure
- ./make
- Copy "mactime" into your mac-robber directory
Friday, September 26, 2014
Ubertooth - building and using
I have followed the Ubertooth build guide to a T, but when I plugged in my ubertooth and tried to use the Spectrum Analyzer (as described in the Getting Started Guide), I encountered problems.
FeedGnuPlot
BTBB CMake Error
Thanks a lot for your information (I'm a bluetooth noob so have lots of reading up to do). I'll try to do some more tests tomorrow and add the capture. I also have some BLE devices and I'm curious to see them in action.
To add on the build requirements - in the setup guide it's mentioned that to install the wireshark plugin you should run:
$ cmake -DCMAKE_INSTALL_LIBDIR=/usr/lib/wireshark/libwireshark1/plugins ..
But this didn't work for me (I couldn't find the btbb inside the wireshark filters). I tried both libwireshark1 and libwireshark3 folders. However the instructions inside the README at libbtbb/wireshark/plugins/btbb/ says that you should run
$ cmake .
That did work for me, perhaps this should be updated in the guide too? It's all quite confusing :)
ubertooth-specan
Friday, September 19, 2014
Flipping the “Production” bit on a Nexus 7
As a security researcher, I’m constantly battling the lack of access on my retail Nexus 7. I spent about 12 hours today messing with this, rooting the device and modifying boot images. Each time, my device would get stuck in a “soft-brick/bootloop’.
It was frustrating.
I followed every step-by-step I could find, continuously modding the setting in build.prop but to no avail. Funny enough – the trick I was using to root and recover my device is what ended up offering a solution!
Root Your Device, For Real
There are a number of roots out there, but none as good as “Nexus Root Toolkit’ by WugFresh. I was a little hesitant, but believe me – if you follow EVERY STEP (esp deleting and installing drivers) it works fantastic.
Run through the wizard. Follow the YouTube videos. A child can do this.
But Not Really
However, after you’ve rooted your device, you’re still in “Production” mode and you still can’t get root in shell. To accomplish that, you need to flip the production bit. But, as mentioned, I could never figure out how to flip the bit and then restore the boot image. Whenever I flashed the image back onto the device, it would go into a continuous reboot. At some point, however, I was poking around the Nexus Root Tooklit UI and saw the “Advanced Utilities” option to temporarily boot on an opened image.
I used it a couple times to see what was going on with my device – it would boot on the “modified boot image,” even when it wouldn’t boot on my slightly modified image. And when I adb shell’ed into the device, I had that wonderful root option!
It was only around hour 11.5 that I realized I could have flashed that image (their modified boot image) onto the boot partition, and my device would no longer be in production mode.
So it’s simple…
- Launch NRT
- Click “Advanced”
- Under “Boot Flash Image,” switch the option from “Boot (Temporary)” to “Flash (Permanent)”
- Select the modified boot image in the \data\modified boot image directory in the NRT install folder
- Let it flash
Your device is now no longer in production mode – you can mount it as root:
Further Research
I’m sure I could simply flip that bit somehow, but I just haven’t figured out how. After a full 12 hours (on top of an 8-hour work day), I decided to just move on. Anyone with better ideas – leave a comment!
Saturday, September 6, 2014
WiFi Pineapple Radios
Looking at front w/antennas on bottom:
Light Radio radio wlan# Location
Blue AR9331 radio0 wlan0 Lower right by SD card
Red RTL8187 radio1 wlan1 Lower left near dip switches
Some of this info came from https://forums.hak5.org/index.php?/topic/33485-physically-what-is-the-wlan0wlan1-antenna/?hl=%2Bwhich+%2Bantenna
Typically WLAN0 is the access point clients connect to (the access point) and WLAN1 is the NIC used to connect to another wireless network. Why is this important?
- If you're trying to lure users to connect to your pineapple, having a high-gain antenna connected to WLAN0 would be helpful. That's the blue antenna, AR9331 radio, lower right by the SD card.
- If you're trying to connect/assess remote wireless networks (say with a Yagi directional antenna) connecting your antenna to WLAN1 would be helpful. That's the red antenna, lower left near the dip switches.
- 00:11:37 is associated with "Orient Power Home Network Ltd (this is radio0, the AR9331)
- 00:13:37 is also associated with "Orient Power Home Network Ltd" (this is radio1, the RTL8187)
Thursday, September 4, 2014
WarPi–The Build
The War Pi is a Raspberry Pi project running Kismet, with GPS enabled. The project is a SANS Gold Paper project by Scott Christie; you can read the paper here. For the WarPi to work “mobile”, you need the following:
- Raspberry Pi
- SD Card (4 GB or larger)
- Alfa wireless network adapter
- USB GPS
- USB battery pack
- Misc USB cables
Operating System
The first step was choosing from the several options for operating systems. The folks at RaspberryPi.org are awesome about building, updating and releasing operating systems (you can find them here). I chose Raspbian because it is the most common OS, and because it was the base OS for the WarPi build. There’s potentially a reason to go with one of the OS’s (for instances, Arch Linux), to have a smaller kernel and such. For the purpose of this project, sticking with the norm is probably the best solution.Configuring the OS
I’ve written a longer blog on how to image, update, upgrade, and reimage the Raspberry Pi operating system, you can read it here. These are the steps I took to get to my current base image.Customizing the Hostname
My base image includes SSH server running at startup, so I can get logged in whenever it’s live on a network. One thing I like to do is customize my hostname—in this case, it’ll be “WarPi”. Some people recommend a stealthier name, but given that the WarPi will only be used for client engagements, I want to be completely transparent.There’s a nice article on the steps to accomplish this. You can read it here.
Expanding Filesystem
Scott Christie’s article calls for expanding the file system as a first step. I don’t do this, because once the system is built I want to image it back off. If I expand the file system, my image will be quite large (my card is 6 GB). So I’ll hold off until all the apps are installed and working.Next: build the WarPi.
Installing Applications
Scott Christie’s WarPi build follows these steps:- Install and configure GPSD (the GPS Daemon)
- Install and configure Kismet
- Auto-start Kismet
GPSD – The Good, the Bad, the Ugly
In my initial efforts to build a WarPi, I was using an older Microsoft Streets and Trips GPS device. My early proof of concept was just using it with minicom to review serial communications – that worked fine and I blogged a bit about it. When I combined GPSD and my old GPS unit, however, I ran into trouble and learned a lot about debugging GPS units. Unfortunately, it appears GPSD fried my old SiRF GPS unit – even though I’ve got it back to NMEA mode, the unit cannot get a GPS fix anymore. So I’m understandably wary of GPSD. In some testing I did the other day, I discovered that Kismet works fine with my new GPS unit in NMEA mode over serial, so my plan now is to skip the GPSD installation and let Kismet speak serial/NMEA to the GPS.Therefore, my build steps will be:
- Test the GPS
- Install and configure Kismet for serial NMEA GPS
- Test Kismet with the GPS
- Auto-start Kismet
Step 1: Testing the GPS
Install Minicom
Minicom is a great little serial tool, but it doesn’t come preinstalled in the OS, so we’ll be installing that prior to using the GPS. Simple:sudo apt-get install minicom
And voila – you have minicom installed! To make sure it works, enter the following:
sudo minicom –s
And the minicom app will start at the settings screen:
Just choose “Exit from Minicom” by arrowing down—we have to get the GPS working before we can use minicom.
Connect the GPS
When you connect the GPS over USB, the sudden change in power can cause your Pi to restart. The best strategy is to shut down your Pi, connect the GPS, and then power up.Once the system boots, you’ll need to discover your GPS’s “location” in the system. Type the dmesg command and scroll through the output looking for “USB-Serial” or such. Eventually you’ll see a series of entries for the GPS, ending in “pl2303 converter now attached to ttyUSB0” or something similar, as highlighted below:
Now you’re ready to use minicom to view NMEA strings coming from the GPS. Type:
sudo minicom –s
to enter the settings screen. Let’s get going!
- First select “Serial Port Setup” by mousing down to it and pressing the Enter key.
- Next, press the “A” key, then backspace and edit the entry to read /dev/ttyUSB0 (or wherever your GPS unit ended up). Then press “Enter” to set your changes.
NOTE: the location for your GPS is case sensitive!
- Now we need to modify the serial communications settings. Press “E” to open the Comm Parameters menu:
- Press “B” until the Current comm speed is 4800:
- Make sure the “Current” reads 4800 8N1 as above. If it doesn’t, press “Q” to set the second half of the string.
- Once the settings are correct, press “Enter” to exit each screen (two times).
- Now arrow down to “Save setup as dfl” and press “Enter”
- Next, arrow down to “Exit” and press “Enter”. You will drop directly into minicom and see NMEA strings pass by…
The big white box is an attempt to anonymize my location. - To close out of minicom, press “Ctrl+A” then press “Q” and choose to leave without reset.
Installing Kismet
It’s actually not an “install” per-say, but a download and build. Christie’s instructions are still accurate – the link is correct as of September 2014, and the instruction steps are all accurate. I’ll summarize:- First perform the wget command to download the source.
- Next, install the dependencies as documented
- Then extract the source
- Then prepare the code to compile and install
- Finally, make and install Kismet
UPDATE: 03/2016
NOTE that there is a bug in Kismet, so it places access points all over the antarctic. Not kidding. See this Kismet forum article for details on how to fix it (you're going to have to modify code).
If you look for the K7JTO repository on Github, you can download the updated Kismet files, or just hand-fix them yourself.
Configuring WLAN0 Out
By default, Raspbian wants to hot-plug and use a wireless device as much as it does an ethernet device. Kismet however wants full access to the WLAN device, so it will squawk at you:I poked around quite a bit, but ultimately fixed this by editing /etc/default/ifplugd and changing the line INTERFACES=”auto” to “INTERFACES=”eth0”
This instructs ifplugd to only look at eth0 to autoconfig, and not to the WLAN. Inconvenient if I actually want it to auto-configure a WLAN connection, but I actually don’t want it to. Kismet needs full control of wlan0.
Smoke Test
This is a good time to make sure Kismet is working. It’s simple – just typesudo kismet
If it’s working, you’ll get a bunch of prompts as recorded in the whitepaper. Eventually you’ll see the Kismet server logs, which will look like this:
Pressing the Tab key will highlight the “Close Console Window” and take you to the Kismet interface, which will look like this:
(GPS coordinates blanked out)
If you’ve gotten this far, you are golden – configure Kismet to auto-start and to log output and you have a WarPi. Congrats!
From this point on, you can follow the WarPi directions in the article and everything should go just fine. NOTE that you might want to use dd again to make a base WarPi image so you don’t have to go through all of this again if your card dies or something.
Wednesday, September 3, 2014
Basic Raspberry Pi Hacks
- AirPi Tracker: using a cheap USB SDR dongle, track local flight paths. Why? I'm not interested in flight paths actually, just interested in Pi and using it with SDR. This project comes from the fantastic book "Raspberry Pi Hacks" (loaded with great ideas)
- PiGame: another project from Raspberry Pi Hacks, this sets up your Pi as an emulated game console for a series of classic games. Having three teen sons, I am thinking this one is going to be a hit.
- War Pi: this is the main project for the time being, creating a "war walking" 802.11 analysis device. With an Alpha wireless adapter and a GlobalSat BU-353S4 GPS, I can walk around client buildings and assess the location and signal strength of surrounding 802.11 access points (which pose the threat of employees connecting to external wireless points).
- Pi Fence: this project is in its infancy, but the idea is to build a Pi distro for home network security, including a firewall and an authenticated proxy (authenticated by user, not by device).
Base Pi Image
Windows absolutely stinks at this. My Win8 machine is at the point where it can't even see a card with a Pi image on it - it's very frustrating. Luckily I do a lot of work in Linux (my personal project laptop runs Mint, and my workstation runs Ubuntu), so I have been able to work very efficiently with the SD card process. If you don't have a Linux machine, you could try running Linux in a Virtual Box virtual machine. If you have a USB SD card reader, you could (rather ironically) use a Pi to do all of this. That's what this blog post is all about - getting the image onto your card, upgrading it, customizing it, and then storing your personal image.
Step 1: Clear Your Card
Step 2: Image Your Card
- The "if" option is the source file. Enter the path to the image you have downloaded from the Raspberry OS downloads page.
- The "of" option is the destination--in this case, enter whatever your SD card is
Step 3: Grow Your Pi Image
You may have noticed that, when you used the dd command to image your SD card, there was a large chunk of unallocated space. Don't worry - you'll get to use that space eventually. For now, we just want to grab a little bit of it, so you can upgrade your Pi OS and then create your own, updated, base image.- Open GParted again
- Click on the file system partition (usually /dev/mmcblk0p2 for me)
- From the "Partition" menu, select "Resize/Move"
- Increase the size by about 500 MB (just add 500 or so to the "New Size"
Step 4: Update and Upgrade
Step 5: Make Any Other Changes
- Networking: you have already set up networking so you could get to the Internet, but if you want to make any changes that will be part of your base image, do so. For me, I disable the wireless network and I specify a static IP address so when my Pi boots, it's a known host on my internal LAN.
- Firewall: you may want to enable a firewall at this point, or install anti-virus (Clam is a great AV tool for Linux)
- Add or remove applications: if there are applications you know you won't need (perhaps Scratch or another programming application) you can remove those at this time. If there are other apps you need or want, install them.
- Disable services: there may be services running which you don't need, and disabling them means you free up system resources. Go for it.
Step 6: Create Your Personal Base Image
- Back on your main computer, insert your SD card and use the dmesg command again to make sure you know how to reference it.
- If you want to shrink your image again, do the following
- Open Gparted again
- See how much space is used on the /dev/mmcblk0p2 partition and how much is free
- Next, you are going to use the dd command, but in this instance you'll reverse directions and copy from the SD card to a base image.
- In the terminal window type sudo dd if="/dev/mmcblk0" of="personal_pi_image.img"
- OPTIONAL If you want to shrink your image, you can take a chance, modify the dd command, and copy fewer bytes from your card. The dd command looks like this: sudo dd if="/dev/mmcblk0" of="personal_pi_image.img" bs=1M count=2700
- Note: the value for count should be the desired size in MB of your final image. That's what you found in step 2. Add some free space just in case.
Storing Your Cards
Conclusion
Monday, August 25, 2014
Android Application Logs
Background
View the Log over ADB
Saturday, August 23, 2014
Debugging GPS Units
I’m working to build a WarPi (see other blog posts on this effort). To get that project going, here’s what I did:
- First, I found an old Streets & Trips GPS unit – yah! No cost, baby…
- I proved it worked on my Mint box (see my blog post about it)
- Then I connected it to my PI and did the same thing – using Minicom, I proved it worked on the Pi
- Then I started the install steps to get the WarPi configured, including installing GPSD.
It was here that things fell apart. Once GPSD was installed, I ran the GPSD client to check that the GPS worked correctly – all I got was garbled text. Everything I read said garbled text is a symptom of baud rate connection issues, but I knew I had it right: 4800 7E1. Over and over I troubleshooted stuff. It didn’t matter what com settings I specified, I still got garbage.
Finally I ran across this article that indicates gpsd puts the GPS into binary mode—which explains the garbage!
Troubleshooting Tips: Important Commands
Kill GPSD: my Pi keeps flipping to British keyboard and I can’t find the pipe symbol ( | ), so it’s difficult to find GPSD’s PID. Here’s a tip for another way to kill the process:
- ps –C gpsd –fww is used to get the PID for gpsd
- sudo kill <PID> will kill gpsd
GPSCTL – controlling your GPS
In this article, I figured out how I got into binary mode (scroll to the bottom). It also lists how to get out of binary mode, which works intermittently for me, at best.
sudo gpsctl –f –n –s 4800 /dev/ttyUSB0 should reset the Pharos GPS-360 device to NMEA mode. But it doesn’t work for me.
GPSD Debug Mode
This article on setting up GPSD was helpful for putting GPSD output on the screen. The command
gpsd -D 5 -N -n /dev/ttyUSB0
should get you going.
Conclusion
For some reason, my GPS unit won’t honor the command to switch back to NMEA mode. All is not lost, however – if you let a GPS sit unpowered for 3 days, it reverts on its own. After waiting the 3 days I plugged my GPS unit back in and saw that it was in NMEA mode. It now has a second issue – it’s no longer communicating successfully with satellites (the “validity” bit is set to “V” which—while you’d think means ‘valid’—actually means there is a warning. The NMEA string contains bad data.
I understand these old Streets and Trips USB devices can take 30-45 min to pick up enough satellites the first time, so I’m letting it sit and burn electrons.
The ultimate goal here is to feed GPS data to Kismet, which can be done via gpsd or Kismet can read NMEA strings directly, so I think I’ll uninstall GPSD, let the GPS sit for a few days, then configure Kismet to read the NMEA string off serial. I also intend to invest in a modern USB GPS unit—I need something that’s robust, and my old device… just isn’t.
Friday, August 22, 2014
Disabling Windows User Accounts
Active Directory rocks – as long as you’re not a home user (in which case you don’t have it). Windows Premium is great too – unless you don’t have it. So what do you do if you’re running Windows 7 or Windows 8 and you want to manage (enable/disable) user accounts?
Or put another way: how do I disable user accounts in Windows 7 home or Windows 8 home? Simple – the net user command.
To disable an account:
net user John /active:no
To enable an account
net user John /active:yes
Lemme tell you, this feature works great when you have kids who aren’t doing their chores. Disable their account for a bit, it freaks them out and gets them committed!
Wednesday, August 20, 2014
Pulling data from Android
I do a lot of Android security assessment work lately, and there are a few commands I’m finding to be really helpful.
Pulling Data With Sudo
Sometimes it’s just a hassle to copy data with long paths and such. This is a creative solution when you have root:
adb shell su -c cat /data/data/app.package.name/databases/application.sqlite | sed 's/\r$//' > application.sqlite
Thanks to Sergei Shetsov for that tip (http://blog.shvetsov.com/2013/02/access-android-app-data-without-root.html)
In the same post, Sergei points out that you can do a backup over ADB and, if you don’t give it a password, you can pull data out of the backup:
adb backup -f ~/data.ab -noapk app.package.name
Then all you have to do is extract the data. Sergei points out that Nikolay Elenkov posted on the backup file format and provided a Java program to pack and unpack backup files.
Once you’ve got your backup, open it in your favorite file carver, or just do a quick dd command to extract it:
dd if=data.ab bs=1 skip=24 | openssl zlib -d | tar -xvf -
That’s all!
Need more info? Read Sergei’s blog post. I document things here so I have one-stop shopping; all the credit goes to Sergei for a great work-around.
Sunday, August 17, 2014
War Pi–Part 1 (the prep)
I’ve been planning to put one of my older Raspberry Pi devices to use as a “War Pi,” based on a SANS Reading Room whitepaper by Scott Christie titled “WAR PI”. This article is the adventure that got me to finally being ready to build the War Pi. The adventure took a few wrong turns right around the GPS area…
Gathering the Parts
There are a few items needed to make the War Pi:
- Raspberry Pi (I have two 256 MB Pis and one 512 MB Pi – I’m starting with the latter)
- USB 802.11 wireless device capabale of packet injection (I have an Alfa Networks AWUS036NH which I use for a variety of wireless ‘research’ projects)
- USB GPS receiver (I mentioned in an earlier blog post that I found an old Microsoft Streets and Trips GPS unit, and got it working on Linux Mint; that’s what I’m using with my War Pi)
- Power supply (don’t have one yet – I may have to make one today, or just pick one up at a local store)
Here they are, all ready to use:
I had a 4 GB MicroSD card I wanted to use, but for some reason it can’t be recognized by Windows or by the Pi. I have research to do here…
Initial Boot and Config
I finally found an 8 GB card with a fresh (but outdated) Pi image. I modified a few settings in raspi-config:
- Medium overclock
- Enabled SSH server
- Boot direct to desktop
- Expanded the image to fill the card
And with that, I see a beautiful fresh desktop:
Next, I’ll admit – I cheated a bit and used the WiFi Config rather than editing the wifi by hand. Call it lazy, or say I checked in my engineer card… Regardless, I set up my Alfa wireless device temporarily so I could update the Pi. First a quick
sudo apt-get update
and then a
sudo apt-get upgrade
brought me up-to-date. Of course, it’s always good to do this more than once, since dependencies are being updated and sometimes multiple rounds are helpful. Sure enough, round two resulted in another 205 MB of updates. Clearly I started with an old build of Raspbian. And not surprisingly, my Pi died in the midst of the second update – sometimes that happens.
I probably should have started with a latest OS image, but my luck reading and writing images to SD cards lately has been pretty bad, so I decided to just power through upgrading. As an aside, the full upgrade lasted over an hour—it pays to take this in little bites!
USB Conflicts
I ran into a very interesting issue – as I was adding peripherals to perform various tasks (like plugging in my wireless device or my GPS), I had a really tough time getting them to all work together happily. When I plugged in high-draw devices like the GPS, the Pi would reboot. Upon reboot, the mouse and keyboard wouldn’t work. I think there are a couple things at play here: insufficient power availability on the Pi (meaning I need a powered USB hub) and/or IRQ assignment conflicts.
UPDATE: using a powered 10-port USB replicator, I am not only running with all 4 peripherals (keyboard, mouse, Alpha and GPS), but I’m doing it without supplying power to the Pi. Interesting…
War Pi Setup
With the Pi updated, it’s time to install the main tools for War Pi: minicom, GPSD and Kismet.
- The minicom tool isn’t called for in the whitepaper, but it’s a nice lightweight tool for proving a GPS is working.
- GPSD is a tool for interacting with GPS. Kismet can read directly from most GPS units, so GPSD should just be there as backup, but sometimes GPSD can read from a GPS which Kismet cannot, and then Kismet can read from GPSD.
- Kismet is an 802.11 wireless utility for detecting, sniffing, and interacting with wireless networks.
MiniCom
Setting up MiniCom was easy – just follow the instructions on my blog post about getting a Microsoft Streets and Trips GPS unit working in linux. I was able to use MiniCom to show my GPS was working – important, because I had a lot of trouble in the next step (GPSD).
GPSD
So now that the Pi is updated and running reliably, it’s time to move ahead with the WarPi instructions – next step is setting up GPSD. This was relatively easy, although something happened the first time I ran apt-get install gpsd, so when I tried the sudo dpkg-reconfigure gpsd, it failed to launch. Rerunning apt-get install gpsd fixed it.
Once GPSD was installed and configured as per the instructions, I rebooted and started the CGPS client. Interestingly enough, the GPS just started sending garbage. CGPS kept showing the GPS couldn’t connect. When I disabled GPSD and rebooted, I booted minicom and it showed nothing but garbled text. After an hour of troubleshooting (including connecting it to my linux box where it worked perfectly), still no joy. I gave up for the night.
UPDATE: in reading around, I discovered these SirF GPS receivers are quite touchy. I’m working on another blog post about them, but basically if you use a SiRF receiver with GPSD, GPSD puts it into binary mode simply because the way it determines whether or not the GPS is a SiRF device is by sending a –b command. Heisenberg in action…
By waiting 3 days, the GPS resets itself back to NMEA mode (which I’ve confirmed in minicom). Now I’m having trouble because the “Validity” bit (sixth bit in the NMEA string) is showing “V”. You’d think that means “Valid” but it actually means “WARNING”. I’ve heard these old Streets and Trips GPS units can require quite some time before picking up satellites, so I’m going to let it sit for a couple hours and see what happens.
New GPS, New Hope
Like the Jedi rising from the ashes, my new GlobalSat USB BU-353S4 worked perfectly out of the box when connected to minicom on my Linux box. I’m going to start up a new step-by-step in another blog entry, to cover the actual build process.
Lots was learned about serial communications, SiRF, and GPS. But now it’s time to go war Pi’ing.
Friday, July 25, 2014
Secure Delete on Linux
To install the secure delete tools:
user@machine:~$ sudo apt-get install secure-delete
To delete a file, just use the "srm" command:
user@machine:~$ srm filename
The more ya know...
Thursday, June 12, 2014
Microsoft Streets and Trips GPS Running on Linux Mint
and
I have an old Dell laptop running Linux Mint. I've been wanting to build the War Pi described in this SANS Reading Room article:
http://www.sans.org/reading-room/whitepapers/incident/war-pi-34435
But I wasn't sure if I could, because I don't have an external GPS. Well, I was rooting through my junk box and found the old S&T GPS and wondered if maybe I could make it work. Sure enough:
Terminal Serial Output |
How did I do it? Dirt simple, folks:
- Plug in the USB GPS unit
- Open a terminal window and type "dmesg"
- Look for the serial GPS unit appearing:
[ 1317.276429] usb 6-1: new full-speed USB device number 2 using uhci_hcd
[ 1317.435627] usb 6-1: New USB device found, idVendor=067b, idProduct=aaa0
[ 1317.435641] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1317.435649] usb 6-1: Product: USB-Serial Controller
[ 1317.435656] usb 6-1: Manufacturer: Prolific Technology Inc.
[ 1317.435663] usb 6-1: SerialNumber: 12345678
[ 1317.475503] usbcore: registered new interface driver usbserial
[ 1317.475534] usbcore: registered new interface driver usbserial_generic
[ 1317.475554] usbserial: USB Serial support registered for generic
[ 1317.480504] usbcore: registered new interface driver pl2303
[ 1317.480533] usbserial: USB Serial support registered for pl2303
[ 1317.480578] pl2303 6-1:1.0: pl2303 converter detected
[ 1317.493517] usb 6-1: pl2303 converter now attached to ttyUSB0 - See at the bottom, it says "ttyUSB0"? That's where the device is...
- If it's not installed, install minicom:
sudo apt-get install minicom - Run minicom as sudo in settings mode (sudo minicom -s)
- Select "Serial port setup"
- Set serial device to /dev/ttyUSB0 (or wherever your device showed up in dmesg)
- Set Bps/Par/Bits. This one is a bit obtuse - the lowest screen setting is 9600, which results in garbage streaming in. But if you press B for "<prev>", you can set the speed to 4800.
- Set stopbits to "7-E-1"
- Exit back to the minicom screen and choose "Save setup as dfl" then choose "Exit"
By the way: great article here about using the Microsoft Streets & Trips GPS unit on a Raspberry Pi.
Friday, May 23, 2014
Mak5 WifiPineapple - the basics
First Steps - Setting Up
Network Access
Shall We Play A Game?
- https://scotthelme.co.uk/wifi-pineapple-karma-dnsspoof/
- https://www.youtube.com/watch?v=avJfT9JyiiM
Things to Know
- Most of the tutorials say it's easier to tether over a network cable. None of my current laptops have network cables, but I'm able to tether just fine over WiFi. Don't be afraid to do it that way.
- USB... To do any serious logging, you need to have a USB drive connected. I do not, yet, so that'll probably be the next blog.
Monday, April 7, 2014
Mounting a USB Device in a Linux VM
I recently did some work for a customer. Part of the project included a security analysis of a Linux-based VM client. The client is configured to VPN into the customer’s data center, so there’s really no way to network into or out of it (not easily). My challenge was pulling a few files off the client. Solution? Not all that difficult, actually:
- Plug a USB device into the host machine
- In VMWare, connect to the USB device
- In linux, you need to create a mount point for the USB device, and then mount it
- From there, it’s a simple copy command.
mkdir –p /mnt/myusb
mount –t vfat –o rw,users /dev/sdb1 /mnt/myusb
Oops another challenge:
- How do U know where the USB device ends up? I scratched my head for a while on that, until my buddy recommended I grep the logs.
Solution: I searched the logs for SCSI connections, by entering grep SCSI /var/log/messages and saw where the USB device had been attached.
Finally, it was a simple matter of copying the file, which was of course cp /root/myfile.txt /mnt/myusb and I was rocking!Wednesday, March 12, 2014
Virtual Private Cloud
For a while now, I’ve been wanting to leverage a cloud service to host a scanning tool I’m working with. Given that the scan results are sensitive, I don’t really want to have the scanner publicly available. So it’s always struck me that a virtual private cloud with point-to-site VPN is the solution. Straightforward, right?
Well, no…
AWS doesn’t support it. I suppose I could configure something with an additional VPN server that straddles the Interwebz and the VPC but seriously? One more machine, more config, more support… blech.
Enter Azure – turns out, they support point-to-site VPN connections. It made my VPC hosting decision pretty easy.
Caveat: I didn’t look into Rackspace or the myriad of other “me-too’s!” out there. Just AWS and Azure.
You can read up on point-to-site VPNs here: http://msdn.microsoft.com/library/windowsazure/dn133792.aspx Keep in mind, this feature is currently (as of 2/2014) in CTP mode so it’s not exactly production ready. But since my site is small and won’t have a ton of traffic, I’m OK taking some chances on availability.
So finally the project kicks off today – ironically, creating the Azure VPC is quick but creating just the simple gateway? Not so much… Azure’s been churning away for 20 minutes already and still the gateway hasn’t completed. I guess I’ll capture the next step in another post.