I’m working to build a WarPi (see other blog posts on this effort). To get that project going, here’s what I did:
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!
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:
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.
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.
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.
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!
I do a lot of Android security assessment work lately, and there are a few commands I’m finding to be really helpful.
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.
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…
There are a few items needed to make the War Pi:
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…
I finally found an 8 GB card with a fresh (but outdated) Pi image. I modified a few settings in raspi-config:
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!
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…
With the Pi updated, it’s time to install the main tools for War Pi: minicom, GPSD and Kismet.
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).
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.
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.
