Welcome to Kirsle.net! This is the personal website of Noah Petherbridge, and it's where my various software projects and web blog lives.

[ RSS Feed | Older > ]
Goodbye, PerlSiikir!

Posted by Noah Petherbridge on Sunday, April 06 2014 @ 08:19:16 PM
As of a few minutes ago, Kirsle.net is no longer powered by Perl. Instead, I've been working on a new content management system written in Python to replace it.

The reasons for the switch-over are numerous:

  1. The old Perl code was originally written for my previous version of my other project, Siikir, and the code was for an entire social networking type of site with lots of features, among which were Blogs, Photo Albums, and Comments (the three that Kirsle.net made use of). Kirsle.net didn't make use of the other features.
  2. The Perl code also had some memory leaks, which I tried for a while to eliminate but wasn't making much progress with. It was running as a FastCGI script, and the most notable side effects of the memory leaks were that my web server would randomly kill off unrelated processes, such as Minecraft servers or my XMPP server, because my index.cgi on Kirsle.net was sucking up so much memory. ;)
  3. Setting up PerlSiikir on a brand new server was an hours-long task. It needed a recent version of Perl, which needed a perlbrew installation done, and then a lot of modules needed manual installation. Seriously, look at my install notes. The new Python web app takes only minutes to set up.
  4. I like Python better nowadays than Perl. :)
And the best news of all is that my new Python CMS is open source!

I named the new project Rophako, because I was sitting at the Github "new repository" screen for a half hour trying to think of a name, and ended up just making use of my Azulian Translator to come up with a name. So, Rophako is Azulian for "Website." I'm a clever genius, I know. ;)

You can check out Rophako on Github: https://github.com/kirsle/rophako. The "default website" that comes with it isn't very polished yet; I literally just finished writing the code to support Kirsle.net. So, sometime later I'll tidy up the default website and have a working copy of it running on some subdomain like rophako.kirsle.net.

Anyway, this is the new CMS. I ported over all my old blog posts, comments, comment subscriptions, and things of the sort. All the old URLs should work too, due to my kirsle_legacy.py module in Rophako. If anybody finds any broken links or issues with the site, let me know. :)

Update (4/9/14):

I've polished up Rophako's default site and have an example running here: http://rophako.kirsle.net/

That's the site you'd get if you download and install Rophako (minus the blog posts and photos ;) ). So... the project is officially in "beta" status now and is usable!


[ 0 comments | Add comment | Permalink ]

Exploring Grindr's Photo Cache

Posted by Noah Petherbridge on Friday, April 04 2014 @ 01:21:03 AM
A long time ago, the Grindr for Android app used to store its photo cache on your SD card, but lately they hid them away in the app's private space to make them slightly more difficult to get to. I decided to go exploring using Root Browser and see what I could find out.

When I say "photo cache" I mean the place where Grindr downloads pictures locally so that it doesn't need to keep redownloading everyone's pictures all the time and consuming a lot of unnecessary bandwidth. Grindr caches both profile pictures and pictures received over chat messages. They both go into the same place. So if you have access to that place, you can get high resolution copies of all pictures received over chat and have them on your PC. :)

First of all, you'll need a rooted Android device for this, because the Android OS normally doesn't allow apps to get into each other's private data folders. The Root Browser app is a file browser that's root-aware (so it will prompt for root permission when you attempt to open a folder that ordinarily you can't open without root).

So, without further ado, Grindr's photo cache is located at /data/data/com.grindrapp.android/cache/picasso-cache/. This folder may contain a lot of files, mine had 3,458 and so Root Browser took a while to load that folder. You can copy it somewhere under /mnt/sdcard and then get to your files from a PC that way. Make sure the files are no longer owned by "root" when put in the SD card part, or you may run into issues when accessing them from your PC.

Most of the files in this folder have hexadecimal names that appear to be hashes of some sort, and the names usually come in pairs, one with a ".0" file extension and the other with a ".1", for example one I found on my phone was 4e21d675447678d0493bc8cb41a56e8d.0.

The ".0" file is a plain text file, and most of the ".1" files are the JPEG images. I use Linux, and my file browser automatically identified the types of all the files and showed thumbnail images for all the ".1" files. So, most of the time if you rename one of the ".1" files to have a ".jpg" extension you can see the images under Windows.

Some of the .1 files aren't images though. Some are more text files, and I peeked inside one to see what it was:

$ cat c1749deee81d4fece16d836e177c5852.1
[{"messageId":16970,"title":"Calling All DJs & Bartenders","body":"Are you one of the sexiest DJs or bartenders and able to work a paid event on the afternoon of April 27th in Palm Springs? If so, send us your information and a link to your website to palmsprings@grindr.com or simply tap 'More' to email us directly. ","actionTitle":"More", "dismissTitle":null, "expirationDate":1396853940000, "url":"mailto:palmsprings@grindr.com"}]

These appear to be the broadcasted pop-up messages shown in the app sometimes.

Now, the other interesting files are the ones with the ".0" extensions. These appear to be debug information, and they're basically the full HTTP request dump used to download the ".1" file. Here's what the one looked like for my profile picture (in case the Grindr CDN link stops working and you're curious, it's this picture):

$ cat 4e21d675447678d0493bc8cb41a56e8d.0
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 72057
Content-Type: image/jpg
Date: Fri, 04 Apr 2014 20:09:05 GMT
Etag: "98af07f8697f854734874296a90c640f"
Last-Modified: Sat, 01 Mar 2014 22:05:22 GMT
Server: ECS (lax/2851)
x-amz-id-2: [REDACTED]
x-amz-request-id: [REDACTED]
X-Android-Received-Millis: 1396642144430
X-Android-Response-Source: CONDITIONAL_CACHE 200
X-Android-Selected-Transport: http/1.1
X-Android-Sent-Millis: 1396642144347
X-Cache: HIT
I edited-out the "x-amz" headers because I'm not sure how secret those are supposed to be.

When browsing through my cache folder I also saw some pictures that weren't profile pics, but were sent over chat messages. These always seem to be the full resolution of the original pic sent, i.e. not thumbnails or anything. The ".0" file looks the same as for a profile picture, except the URL downloaded begins with "http://cdns.grindr.com:80/grindr/chat/" and the server headers respond with a "Content-Type: binary/octet-stream" (which causes a web browser to download the picture to disk instead of displaying it in the browser).

Some of the ".1" files are actually empty (0 bytes), and their .0 files indicate that these are the ad banners (requesting a URL from googleads.g.doubleclick.net). So it looks like whatever system in Grindr is responsible for downloading pictures also sorta deals with downloading ad banners, except it doesn't actually save the banner into the cache folder.

The last somewhat not-very-interesting file in the cache folder is called "journal", and it's a text file. By reading the first couple lines, it appears to be part of libcore.io.DiskLruCache, a bit of Java code that provides a rotating offline cache. This probably means that, if Grindr's cache folder fills up, it will automatically remove old files to make room for new ones, so it can keep its overall disk usage under control automatically. The journal file appears to list the hash names of all the other files in the folder, along with words like "CLEAN", "DIRTY", and "REMOVE".


[ 1 comment | Add comment | Permalink ]

Skype and Windows Live Messenger

Posted by Noah Petherbridge on Friday, February 28 2014 @ 12:17:26 PM
Back in the day, I ran a couple of chatbots on Windows Live Messenger (although it was called MSN Messenger then), so I'm reasonably familiar with how the Microsoft Notification Protocol (MSNP) works. We had a Perl module called MSN.pm which works with the MSNP10 version of the protocol, and it probably still works today.

That's right, the Windows Live Messenger protocol is still perfectly alive and well today. A while back, I booted my Windows OS on my PC where I still had Pidgin set up to sign me into MSN, and surprisingly it still worked. One of my Skype contacts sent me a message over Pidgin, and their "MSN e-mail address" had an "@SkypeDomain.fakedomain" domain part. It seems that now, though, while the MSN servers are still up, they at least block non-Chinese users from authenticating (Pidgin says "invalid response from server").

The Skype/MSN merger was done in a pretty half-assed way by Microsoft:

It appears that the Skype client actually acts like a "mini Pidgin": when you sign in with your old MSN account, Skype actually signs you in separately to the Skype and MSN servers. And, on the MSN side of things, the "@SkypeDomain.fakedomain" extension was probably implemented similarly to what happened when MSN and Yahoo joined forces, and your Yahoo contacts on MSN would have "@yahoo.com" domain extensions.

I don't get why Microsoft doesn't just pull the plug on MSNP completely, and force everyone to get a Skype name if they don't already have one linked with their MSN accounts.


[ 0 comments | Add comment | Permalink ]

Minecraft Anti-Griefing in Vanilla

Posted by Noah Petherbridge on Thursday, February 13 2014 @ 01:35:18 PM
This is a trick I picked up somewhere from /r/Minecraft that lets you implement anti-griefing on a 100% vanilla Minecraft server.

It requires you to have operator rights on the server, and it involves command blocks. Give yourself a command block by typing the command /give your_name command_block, and place it somewhere in the center of the area you don't want being griefed. I usually will hide it just below the ground, or in a small hidden-away room in the middle of a building or something. Right-click it, and enter this command:

effect @a[m=0,r=36] 4 2 5
When activated, this command will apply a status effect to all Survival Mode players (m=0), within a radius of 36 blocks from the command block (r=36). The effect will be Mining Fatigue (effect ID 4), level 5, which will last for 2 seconds. See Status effect on the Minecraft wiki for details.

When Minecraft v1.8 is released, you can add the word "true" to the end of the command to hide the particle effects.

Mining Fatigue slows down the player's mining speed by 20% per level, so at level 5 your speed is slowed by 100%. What this basically means is that nobody can break anything while under Mining Fatigue 5. You can't even break a dandelion using a diamond axe. It makes the area completely grief-proof.

Adjust the radius to however large you think you'll need to cover the entire area you want protected. If the area is very large (i.e. so that the command block might end up being unloaded from memory when its chunk goes away), you'll need multiple command blocks positioned around the area to make sure the Mining Fatigue is still in effect.

Anyway, now you just need to hook up the command block to a redstone clock so that it's triggered repeatedly. My favorite is to just use a hopper clock. A comparator clock has too fast of a pulse and the command block will never be executed.

With a hopper block, just place two hoppers that connect to each other. For example, place a normal block like stone, and then with a hopper, right-click on the side of the stone block so the bottom of the hopper connects to the side. Remove the stone block, go to the side where it used to be, and hold down Shift and right-click the hopper to attach the second one.

Put a single item into one of the hoppers. If it worked, the item should disappear from the hopper's GUI and then reappear shortly after; the item is being passed back and forth between the hoppers. Now, pick one hopper and put a comparator and then a repeater next to it. Whenever this hopper has the item, the comparator will get a signal and the repeater will amplify it. And there you go. Here's a screenshot of the full setup:

Hopper Clock

After Minecraft 1.8 is released, you may also want to add a second command block that runs the command kill @e[type=Creeper,r=36] to kill any creepers that get near your anti-griefing area as well. This will prevent players from being able to lure a creeper in to blow stuff up. Something similar may work for destroying PrimedTnt entities, but it may be tricky due to the speed at which primed TNT can be launched.


[ 0 comments | Add comment | Permalink ]

Minecraft Server Wrapper

Posted by Noah Petherbridge on Thursday, February 13 2014 @ 12:33:24 AM
This is something I've been wanting to program for a while, and I finally have.

It's a Python app that wraps the Minecraft server and makes the server console available over a separate TCP socket (with password authentication, of course).

This allows you to telnet in to this TCP port, provide the password (or a challenge-response hashed version of it), and then you get access to the Minecraft server console. Anything the server outputs is broadcasted to all authenticated clients, and anything the clients send is sent to the Minecraft server. But the real strength in this isn't necessarily just being able to see and type commands into the server console (you can do this at the local shell running the server normally); it's for programs to do this automatically!

For example, you can have a whitelist of users who aren't operators, but you want them to be able to say for example !creative in the server chat window, and have their game mode switched to creative. This is one of the example scripts I included in my project, actually!


And as a more eccentric example, I connected a simple RiveScript bot to this so that it can chat with players using the in-game chat system:


You can get the source code and play around with this yourself at minecraft-control on GitHub!


[ 1 comment | Add comment | Permalink ]

[ RSS Feed | Older > ]
» Homepage (RSS)
» About Me
» Photo Albums
» Guestbook
» Contact Me
» Linux (48)
» General (46)
» Perl (34)
» Rant (22)
» Software (15)
» HowTo (11)
» RiveScript (9)
» Minecraft (9)
» Gnome 3 (8)
» Android (8)
» Windows (8)
» Curiosity (7)
» HTML (7)
» Siikir (7)
» Design (6)
» Tk (6)
» Gay (5)
» Java (4)
» Blackhat (4)
» Reviews (4)
» VirtualBox (4)
» Ideas (3)
» DOS (3)
» Photos (3)
» KAGE (3)
» Xfce (3)
» ttf2eot (3)
» Licensing (3)
» 3D Renderings
» Flash Animation
» JavaScript
» Fonts
» Metacity
» Tutorials
» RiveScript
» Error Generator
» Tk Calculator
» Terminal Apps
» CyanChat Client
Web Tools
» TTF to EOT
» Text Fader
» Favicons
» Distance Calc
» Azulian Encoder
» XBM Masks
» Shell Scripts
» Linux RPMs
» Rophako CMS
» Kirsle::Nano
» Minecraft Server
¤ Pokemon Fuchsia City
¤ DOS and Windows
¤ Raspberry Pi
¤ Google+
¤ Facebook
¤ Twitter
¤ MySpace
¤ Github
Fan Club
» Log In