Hung Truong: The Blog!

Open Sourcing Stuff on Github

A common piece of advice to developers that I often hear is that they should try to contribute to open source projects. One thing that I haven't really been good at before is having actual code that I've written out in the open for people to see and maybe even use. I've started to rectify this with a few public Github repos.

The killer feature of Github really is the social aspect of it. I could either have a mediocre piece of code that sits around and keeps sucking, or I could post it to Github and anyone who wants to use it and possibly improve on it can. Not only does having code out there help your rep, but the act of putting it out there raises your standards quite a bit.

What follows are a few projects I've posted on Github under “freeish” licenses. I don't know too much about them, but a pal once told me that the MIT one is pretty open. Most of these are things I've used in my own code or things I used to learn a language (like the Chef recipe). I've learned to not care about perfection and just let people try it. I'm sure they'll let me know if it sucks (especially if it hits Hacker News).

• ObjTweet – a helper class for Twitter related stuff on iOS (now deprecated in favor of the official integration.
  
• LinkedIn Password Leak Checker – some people made a web based form version of this, which I thought was a really, really bad idea.
• Weathergram – an example of an “award winning” Twilio contest app. Some super low quality code here, folks.
• Google TTS CLI – I wrote more about this Google hack here.
• Chef recipe for Duo Unix – I was learning Chef so I thought I'd make a recipe for a cool startup in town.
• Runscope iOS – This is a subclass of NSMutableURLRequest that makes it easy to use Runscope, which is a cool product for helping you analyze and debug API requests.

These are mostly one-off simple hacks or convenience classes, so hopefully one of these days I'll release something more substantial and open source it.

Hacking Google’s Text To Speech “API”

When I was at my previous job, one task I had was localizing a large set of phrases to multiple languages, both in text and audio files. I did this by using the awesome Google Translate API.

The Google Translate website has features for translating text and playing audio of it in the translated language. There's no official API for getting audio, though. Luckily, I've never let a lack of an official API stop me before.

Google Reader and Skating to Where The Puck Used To Be

I just wrote a couple of tweets about this, but maybe this is a better blog post subject.

Google Reader is shutting down, apparently because its user base is shrinking and Google wants to focus on fewer products. Because of the huge void this will leave, many startups are rushing to fill the space that Google Reader took up. So far I've heard of plans from Digg, Flipboard, Zite (whatever that is), Feedly, and maybe some others.

While this might be a good opportunity for those startups, it strikes me as odd. There's a concept called being a “fast follower” where you copy some innovative company's product immediately after they release it. Think of Facebook's clone of that Snapchat app. What we're seeing now is sort of the “slow(est) follow.”

I suppose it makes sense to go into a space that you know is going to swell up with demand, but honestly, how much longer does the classic Google Reader style app have left? How much of the original Google Reader market are you going to get? Will you be able to re-create the community that the sharebros loved so much? On top of that, do any of these new products have a solid plan on monetization?

To put it another way, what is the opportunity cost of rebuilding Google Reader (even if it's a “reimagined” version) versus putting time into another product that might actually be new and useful? At this point, it's probably not worth it considering how many others are eager to clone Reader.

iOS Photo Editing Controls With A Custom Camera Overlay

This is one of those blog posts that's basically for me and anyone else who cares to Google these search terms, so yeah.

I'm currently working on an app that does camera capture. Instead of using the normal Apple control, I'm using a custom overlay. Typically to do this, you do two things: set the UIImagePickerController's “allowsEditing” to YES and add your overlay view to the controller's “cameraOverlayView” view. Oh, and you also set the sourceType to UIImagePickerControllerSourceTypeCamera, obviously.

I learned through searching about 10 StackOverflow questions and doing my own testing that the custom photo editing control only shows up when you show the normal apple camera controls. So unless you want to do some weird hacking to get your overlay to show up over the normal controls and then have them disappear when the photo is taken, it's not possible to use a custom overlay and still get the built in photo editing tool.

Unless someone wants to correct me…

The annoying part is this is not captured in Apple's official documentation (or anywhere, really). So hopefully this blog post helps someone who is trying to use a custom overlay and the built-in Apple photo cropping tool.

Pharma Hack Update: Finally Gone

A good while ago, I wrote a blog post about how my blog was pharma hacked, and I thought I had gotten rid of it. I was actually extremely wrong, and it's taken about half a year of off/on again fiddling to get rid of the infection for good. I thought I'd write up what I did in case anyone else has issues with this hack.

In order to remove it, I tried searching for solutions from other bloggers. They got me to a certain point, but after following the directions and letting my blog sit for a week or so, I'd use the Google Webmasters feature to “fetch as Googlebot” and find that my site was reinfected.

Here's a step by step summary of what I had to do to finally get rid of the nasty pharma hack.

I downloaded the latest tar.gz from WordPress here and extracted it to my root web directory. My blog lives in the subfolder “/blog/” so I just moved the wp-config.php file from /blog/ to the /wordpress directory, then I renamed the blog folder to something else and renamed wordpress to blog. I found that I'd also have to re-set the permalink settings to get pages besides my home page to show up correctly.

My main mistake was copying the wp-contents subfolders back to the /blog/ directory. I assumed that the main infected file (wp-loads.php) was the only culprit. It turned out that I also had multiple php backdoors in my wp-contents directories, in /plugins, /themes, and even /uploads.

I basically had to re-download anything in plugins and themes so that I knew those directories would be fresh. I ran a command to delete anything in /uploads that was a .php file, as that was how the backdoor worked. I believe it was something like

find /path/to/uploads -name "*.php" | xargs rm

but you probably want to double check that before running it on your server.

I also noticed that some backdoors existed in the root of my web directory, where I keep my portfolio. If you have other directories besides your blog in your web root, it's probably worthwhile to check those out.

At this point I was pretty close to having a clean WordPress install. But for some reason my site would still eventually fall to the pharma hack. I checked my server logs and it looked like someone was modifying header.php in my theme directory from the admin panel. This was pretty surprising because I thought I had my password locked down pretty tight. I am actually still not sure whether the password was compromised, or some other feature in php (or a cookie) allowed the hacker to access the admin theme editor. Either way I'm pretty sure the header.php was hacked to write a new backdoor file which would then create other backdoors. Pretty smart!

To fix this, I put another layer of security on my wp-admin directory with a .htaccess and .htpasswd file. I also updated my password to a 40 character random string that even I can't remember. Finally, I just erased the file that does theme editing in the admin interface since I never use it and it seems like a really weak vulnerability.

So far, the pharma hack hasn't resurfaced and it's been about two weeks. I'm going to say that I'm slightly confident it won't return (unless there's another vulnerability in WordPress that pops up).

I feel like I learned quite a bit about security while playing whack-a-mole with this hack. I got to look at the backdoor files and figure out how they were hidden and obfuscated, and eventually found what I think was the root of the problem in the WordPress theme editor. I also hacked together some scripts to show recently modified files (hacked together from stuff I found doing some searches). If I end up getting hacked like this again, I'll probably be able to remove it faster.

For a while, I was considering moving to Jekyll for my blog. But that seemed like a bit too much work moving posts and comments, and learning a new blogging system, especially for how infrequently I blog nowadays. For now, I will stick with WordPress with all of its vulnerabilities, which have hopefully been mitigated with the few extra precautions I've added.