VoIP and Toll Fraud

I recently got to analyze some VoIP toll fraud and created an algorithm for detecting different types of fraud whether it was international or interlata calling.  The algorithm alerted on a couple of false positives, but overall has been an overwhelming success in combating the fraudulent behavior.  Today, we are mostly detecting when a customer's PBX gets compromised and can shut down the fraud quite quickly and notify the affected customer before they even notice that they were compromised.

Prior to implementing my detection algorithms, there could be $1,000s or even $10,000s racked up in fraudulent calls and the detection would occur about 8 to 10 hours after the fraud started.  Today, we're catching the fraud in most cases when the fraudster is placing their test calls to see if the credentials they obtained even work. It is always within the first hour of the fraud occurrence.

I'm sure that I'll need to extend my algorithms over time as the fraudsters change the signature of their attempts, but I'll take that as a challenge. It is much more pleasurable being on top of the fraud and squashing their every attempt.

Beaglebone Black

I have a little embedded computer called a Beaglebone Black (http://beagleboard.org/Products/BeagleBone+Black) that has an Arm processor and I'm running Ubuntu linux on it. The default linux distribution that came with it was called Angstrom.  The sshd was broken because of an empty file and I had to connect with a serial cable to fix it. It didn't take much to have me switch to the Ubuntu distribution as the Debian style package manager is so convenient and apparently more mature in it's development than the Angstrom distribution. If you're like me, you just want to be able to install the packages/applications you require and get to work or learn some of the cool features instead of debugging why you cannot ssh into the device.

The Beaglebone Black has some connectors with GPIO that can be used to control external devices.

For example, I have it controlling some LEDs and a small 5VDC fan.  Simple enough and it's a good mechanism for testing the use of GPIO.

Here's a circuit that I used to drive the 5VDC fan.  The GPIO is simply used to turn on/off the transistor's base like a switch.

Client / Server Application and 32-bit v. 64-bit

I recently wrote a client / server application where I developed on one of my linux boxes that happened to be 32-bit.  Everything was functioning swimmingly until I moved it onto the destination platform which was x86_64.  I observed a segfault occur where I was getting the client IP and Port for logging purposes. I suspected exactly where the exception was occurring and stepped right to it using gdb.

It was a call to:

printf("connection from client: %s\n", (char *)inet_ntoa(cliaddr.sin_addr));

The error was occurring in libc (vsprintf).

I simply compiled with the -m32 flag and linked to the 32-bit libs.  Everything functioned properly when compiled as 32-bit.  So this is a good reminder from an article written by Michael Barr (http://embeddedgurus.com/embedded-systems-bloggers/michael-barr/) titled something like "Test Everything." It was primarily written for embedded systems, but as you can imagine how it can extend to virtually any aspect of engineering just by reading the title.

I'll modify the code to use some of the newer C networking methods.  Here's a really good reference (http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html) that I've referenced over the years.  Primarily the calls that accommodate IPv4 and IPv6.