Thursday, December 13, 2012

Named Pipes between C# and Python

There's a lot of over-complicated information on the internet for communicating between a C# process and a Python process using named pipes on Windows.  I'll start with the code:

// Open the named pipe.
var server = new NamedPipeServerStream("NPtest");

Console.WriteLine("Waiting for connection...");

var br = new BinaryReader(server);
var bw = new BinaryWriter(server);

while (true) {
    try {
        var len = (int) br.ReadUInt32();            // Read string length
        var str = new string(br.ReadChars(len));    // Read string

        Console.WriteLine("Read: \"{0}\"", str);

        str = new string(str.Reverse().ToArray());  // Just for fun

        var buf = Encoding.ASCII.GetBytes(str);     // Get ASCII byte array     
        bw.Write((uint) buf.Length);                // Write string length
        bw.Write(buf);                              // Write string
        Console.WriteLine("Wrote: \"{0}\"", str);
    catch (EndOfStreamException) {
        break;                    // When client disconnects

Console.WriteLine("Client disconnected.");

import time
import struct

f = open(r'\\.\pipe\NPtest', 'r+b', 0)
i = 1

while True:
    s = 'Message[{0}]'.format(i)
    i += 1
    f.write(struct.pack('I', len(s)) + s)   # Write str length and str                               # EDIT: This is also necessary
    print 'Wrote:', s

    n = struct.unpack('I',[0]    # Read str length
    s =                           # Read str                               # Important!!!
    print 'Read:', s

In this example, I implement a very simple protocol, where every "message" is a 4-byte integer (UInt32 in C#, 'I' (un)pack format in Python), which indicates the length of the string that follows. The string is ASCII. Important things to note here:
  • Python
    • The third parameter to open() means "unbuffered". Otherwise, it will default to line-buffered, which means it will wait for a newline character before actually sending it through the pipe.
    • I'm not sure why, but omitting the seek(0) will cause an IOError #0. I was clued to this by a StackOverflow question.

Wednesday, November 14, 2012

Rename SVN Repository

It happens sometimes: You'd like to rename your SVN repository.  Well simply renaming the directory on the server won't do the trick.

Thanks to Miky Dinescu's post, we find that the best way to do this is use svnadmin dump and svnadmin load to export, and import the old repository into a new one, without losing anything.

I wrapped this process up in a nice, foolproof script. Hopefully it makes your life easier.

Saturday, June 9, 2012

Cyanogenmod 9 Nightly!

I am happy to say that I am running Cyanogenmod 9 (nightly, dated 20120608) on my Galaxy Nexus!

I am very happy with it, and have noticed no problems, which is pretty impressive because this is a nightly build, not even a Beta / RC. The CM9 team has done a fantastic job with this version, and stuck very close to the original ICS look and feel.

Things I am happy about:
  • The settings menu. The stock build just seems so crippled to me now, after seeing the CM9 settings. It is too expansive to screenshot, but still quite organized. You can tweak everything from display gamma settings, to the lock screen, to individual volumes, to kernel performance, to (my favorite!) the notification LED.

    Coming from the Incredible, which just had the orange and green notification LED, having an RGB LED that I can play with is great. I have a green blink for texts, slow red for Gmail, and fast light blue for missed calls.
  • The notification drawer. (I couldn't get a screenshot, because the drawer retracts before it is taken.) I really missed these widgets, and now have quick access buttons to toggle Wi-Fi, LTE (So happy about this one!), GPS, Silent/Vibrate/Loud, and Auto-Rotate.  There are other buttons you can add, but these are the ones I wanted.  Also, I tweaked the battery icon.
  • Customizable navigation buttons. I re-ordered the buttons at the bottom (to more closely match my Incredible, actually) and added the search button, which behaves the same way.
  • All of the familar 'root stuff' built right in.  Superuser (of course), Wi-fi tethering, screenshot, etc.
Over I am quite pleased, and will probably keep using this on a day-to-day basis. This is the way Android was meant to be. Can't wait for an RC!

Additional note: Of course, this comes without the Google Apps, so you'll want to download that zip from

Monday, June 4, 2012

Android 4.0.4 OTA update

A couple days ago, I started getting notifications that a system update was ready for install. This was the IMM76K (Android 4.0.4) OTA update that people had been impatiently waiting on for a while.  After making a nandroid backup (via CWM), I decided to give it a try.

The system rebooted, and went to the screen with the android's belly open and the blue spinny thing. Then he was on his back, with the dreaded red triangle.  I wasn't surprised that the OTA update wasn't going to work with my modified phone.

This excellent post on xda-developers gave links to the official OTA updates for the different versions of the G-Nex. So I downloaded the mysid IMM76K from ICL53F, and adb push'd it to /sdcard. Rebooting into CWM recovery, I tried to install the update, but it failed with:

assert failed: apply_patch_check("/system/app/VZWBackupAssistant.apk".....

I knew why it was failing. I had removed some of the VZW garbage apps that cam pre-installed. Luckily, I didn't actually delete them, I had just renamed them to .apk.REMOVED.  After putting them back1 the update installed successfully.

Another thing to note - I didn't realize it, but the xda post pointed out this important detail: Verizon OTA updates include a script that runs every boot, whose purpose is to restore the recovery image if it is not the expected stock image.  The script is at /system/etc/ and the recovery image (for flashing) is /system/recovery-from-boot.p.   Thus, if you don't wan't to lose CWM (or other custom recovery), you need to rename these files.

1 - I didn't realize it, but ADB is supported in CWM. When I looked in device manager while my phone was connected and in CWM, I saw one device just named "Full".  I manually specified the same Samsung drivers (already installed) from before, and bingo, my phone showed up in adb devices.

Saturday, May 12, 2012

Galaxy Nexus (CDMA)

Well after several months of putting up with my rebooting (sometimes looping) when I used any substantial amount of 3G data, I decided to upgrade. I was looking at the HTC Rezound and the Samsung Galaxy Nexus, and found this really good comparison article on phoneArena. Ultimately, after many recommendations by friends, I went with the Nexus.

It arrived, running Android 4.0.2.  This time, I lasted about 2 days before rooting it.  Everybody has their own half-assed write ups of this, but I wanted to mainly include my sources for some of these files:

ADB / Fastboot Drivers
I downloaded the USB drivers directly from Samsung's site on their SCH-I515 download page. It's a 23MB download which is a bit ridiculous, but I wan unable to isolate exactly which driver was required from the compressed exe.

After installing them, I was able to plug in my phone, turn on USB debugging, execute "adb devices" and see my device.  Next, I rebooted into fastboot mode (hold all three buttons to turn it on). At this point, the device showed up as "Android 1.0".  However, I was able to fix that by:

Then, there should be just one "SAMSUNG Android ADB Interface" listed.

After correcting the driver issue, I was able to execute "fastboot devices" and see my device.

Unlock Bootloader
Next step is "fastboot oem unlock" !

After unlocking, I rebooted, and the Google screen now has an unlocked icon!

ClockworkMod Recovery
After making sure the phone booted OK, I flashed the latest (touch) version of CWM from the ClockworkMod ROM Manager page.  At this time, that version was recovery-clockwork-touch-  Simply download and "fastboot flash recovery recovery-clockwork-touch-".

Next, I rebooted, and went through the initial setup.  Now it's time to actually get root!  The page that I had been following included some version of SuperSU. I didn't really want to just use what they gave me, and went on the hunt for the latest su.

Note for root newbies: "Root" essentially means having access to the su ("superuser") binary, which allows a process to run as the root user.  On android, "root" is two components: The su binary (linux executable), and Superuser.apk, which is the accompanying Android app, which manages requests for root, logs, etc.

It  appears that is the true "home" of superuser for Android. So I downloaded the latest,, and used "adb push /sdcard/" to push it to my phone.

Then I rebooted into recovery again ("adb reboot recovery"), and tried to install it, with the “Install zip from sdcard” option. However, I got the following: “E:Error in /sdcard/ (Status 0)".  Doing a little research, I found the following posts:

I tried everything, but could not get it to install. Instead, I found myself on  In /su/, I found seven different "-test" versions, and in /test/ there is one (I can't for the life of me find the site that linked to that one.)  It turns out that that is the one that worked for me. I don't quite understand, but whatever, it successfully installed via CWM.  After rebooting, Superuser was installed, and showed the correct version of the binary (and updated it too!).

What's Next
Next, I'm probably going to upgrade to the stock Android 4.0.4 ROM, as it supposedly makes some big improvements.  That page links to this thread.  Also in my sights for a new ROM are this IMM76K 4.0.4 mod, and of course CyanogenMod 9, which is currently available only in nightlies.


Sunday, April 29, 2012

Never knew Downloader.Agent2.BBLD was so simple

I had just started writing a new C++ console app (under Visual Studio 2010  10.0.40219.1 SP1Rel) to test something out, and had just this:

#include <stdio.h>
#include <Windows.h>

int main(int argc, char** argv)
  return 0;

I unintentionally clicked Start Debugging, and much to my surprise,

Really? How did I screw up something so simple? Several seconds later AVG popped up this "Resident Shield Alert":


Are you kidding me?  So I added a printf...

int main(int argc, char** argv)
    printf("WTF is going on\n");
  return 0;

Again, threat detected! This time Downloader.Agent2.BAZE.  I disabled AVG, built it again (successfully!) and threw the EXE into IDA, worried that I had some impressive virus injecting a trojan into EXEs I build.  Nothing out of the ordinary found, just the typical complicated CRT startup code, and my simple main().

I uploaded it to VirusTotal to see if this was just AVG being retarded or what. It had a detection ratio of 8 / 42. Check out that link to see each AV and what they detected it as.  It is important to note that AVG picked up the file before it had even finished building (hence the link error) with Resident Shield, but also the finished EXE with a manual scan.

"This is absurd!" I'm thinking. One more try....

int main(int argc, char** argv)
    printf("WTF is going on\n");
    printf("This is ridiculous\n");
    return 0;

Finally, this one built okay and AVG let it alone.  Curious, I uploaded this one to VirusTotal too. It was picked up by only 1 / 42 AVs:   McAfee-GW-Edition identified it as Heuristic.BehavesLike.Win32.Suspicious.H. Sounds more like Heuristic.WeHaveNoIdea.FlagEverything.H