Just wanted to let you know that I'm writing an emulator for the DCPU-16 architecture. Check out the project on github: here.
Keep tweaking~
0 comments
Thought I'd give you a short introduction to the process of hiding data in plain sight, also called steganography.
First, a bit of theory. The script I'm going to introduce here hides data in a 24-bit uncompressed bitmap image. That sounds awfully specific, but don't worry... it's the most common type of bitmap. The reasons I went with this format are as follows:
So, let's get started. In a 24-bit uncompressed bitmap image, there are two headers (back to back, for a total of 54 bytes). Within these headers are data containing the resolution of the image, the image's filesize in bytes, etc. We're interested in the resolution, but we'll see why later.
After the header is the image data, 24 bits (3 bytes) per pixel. The data is stored in the RGB format, and it's stored in the order blue (1 byte), green (1 byte), and red (1 byte). With a full byte for each color, this allows for extremely subtle, hard to visually detect, variations in shade.
So, since the human eye is not as good as we'd like to think, this actually gives us some wiggle room in terms of how to store data. It turns out that the human eye is far more sensitive to green than red or blue, and in any case, manipulating the least significant bits of this data is almost inperceptible. The idea here, is to turn a 24 bit image into a 16 bit image, giving us 8 bits to store data.
Using the following scheme, we are able to fit a full byte of data per pixel in the image file! If we take the 3 LSB of blue, 2 LSB of green, and 3 LSB of red, we have 8 bits. So now it's simply a matter of bitshifting.
Of course, it's not that simple, but it's close. If we were simply shoving 1 byte per pixel, when decoding, how would we know where to stop? So we need to hide another header, within the data. I propose a 4 byte (therefore 4 pixel) header, which is simply a 32-bit integer signifying how many bytes long the hidden data is. This is stored least significant byte first, to mirror the way that the bitmap format handles data. After this, we have the rest of the file to hide data. When decoding, we read the first 4 hidden bytes, and use that to determine how much further to read. This means that we have `(height*width)-4` bytes of storage within any particular image file.
That's about it, for now. If you'd like to check this out, please go see my example (in Io) on github: io-codejams.
Keep tweaking~
0 comments
I just wanted to quickly introduce my latest project, silica. silica is an extremely domain specific language designed to help develop one's musical intuitions and possibly aid in composition. In silica, the featured data type is a note, leading to a language suitable for melodic modelling. It's a bit hard to explain, but here, check out silica on github.
Keep tweaking~
0 comments
It's been a while again. But I've been up to interesting things!
The book has been placed on hold for the time being, as I have been working on a few other things. I've started a project called io-koans, which is designed to be an interactive way to learn the Io programming language, through fill-in-the-blank puzzles, in the style of 4clojure. I've also worked my way through the entire Seven Languages in Seven Weeks (in significantly fewer than seven weeks...), and I feel I've grown tremendously as a programmer from it. It inspired me, in fact. So much that I've begun probably my most ambitious project to date: the jedi programming language. I'll let the github page speak for itself, but I'm having a lot of fun with it.
That's... that, I suppose. Yeah.
Thanks for reading!
Keep tweaking~
0 comments
Wow, I do seem to go ages between posts, don't I?
Just a few little updates: I've started writing the book in earnest. I have the intro and chapters one and two done in draft form, just awaiting editing from a few friends and a professor. As far as that goes, I've been making awesome progress.
I've decided that at least three days a week, I will try to write a small, interesting program in Io. I'm calling these "mini code jams" and I've already written a few. The past few nights have been cellular automata implementations... I implemented a generic Wolfram code one-dimensional cellular automata on Sunday, and tonight I wrote a simple, inefficient, text-based version of Conway's Game of Life. I'm going to set up a github repo and keep my jams uploaded for the world to see. I'll link back here later.
That's about it, really. Thanks for reading!
Keep tweaking~
EDIT: Code Jam repo is here: https://github.com/gatesphere/io-codejams.
0 comments
Another "quick update post" incoming...
So, my server had a disk failure Sunday morning. That took the entire suspended-chord.info domain offline (except email) for roughly 38 hours. But obviously it's up and running again. It should be back to normal, but I apologize in advance to anyone who happens upon a rogue 404 due to permissions errors. Sorry for the inconvenience.
In other news, I've been having discussions with Steve Dekorte, the progenitor of the Io programming language. He is just an awesome guy. We discussed my iobin project, and he ended up making them official! My binaries are linked on the front page of the Io Language site! Happiness.
As for the rest of life... I'm currently working on some school projects and some small personal endeavors (like a web-based CV), but after that, I can get back to chipping away at the Io book, and preparing for the GREs. And developing an empirical boardgame balance tester. Interesting things, you know.
Anyways, just wanted to share.
Keep tweaking~
0 comments
Just a quick update on things. I've began making some progress on the Io Book, more about that to come. It's not much progress, bit it's a start. I'm on a roll, actually :)
Another Io-related project that I'm much more excited for is the initiation of the iobin collection. More info on that in the top bar, but suffice it to say these few quick words: one click binary installers for Io.
Check it out!
Keep tweaking~
0 comments
Sorry it's been a while. I've been involved in a lot of projects lately, all school related. I was able to finish my honors thesis on algorithmic composition recently, and it is available online for anyone who would like to read it here. It is actually going to end up being an assignment for a class here at SUNY Oswego next year titled Cognitive Musicology, which I am acting as TA for, so I'm kind of pumped.
I've also been working on a sort of paid internship position with a professor here, working with some bleeding edge technology from IBM (sorry, can't disclose any more information about that). That's been exciting and frustrating at the same time, but I'm very happy that I'm able to work with the tech.
Recently, in my concurrency course (taught by the legendary Doug Lea), I had an opportunity to benchmark one of the new concurrent data structures proposed for inclusion in Java 8 - ConcurrentHashMapV8. If you're interested in seeing how this stacks up to the current Java 7 implementation of ConcurrentHashMap, feel free to view the results here. Note the server names... SUNY Oswego's CS department has an interesting collection of personalities, and I think they're all awesome.
As far as programming and development go, I've been working with Prolog a lot lately as a part of my Computational Modelling of Cognitive Processes course, and I find it both beautiful and clunky. But it works, and that's more than you can say about certain other languages. For things like brute-force pattern matching, Prolog can't be beat.
In my spare time, I've endeavored to learn the language Io. It's beautiful. You can read more about it in several other places, but allow me to mention the salient points here: it's purely object-oriented, meaning that everything is an object, including numbers, booleans, and even methods; it's prototype-based, meaning that there is no true distinction between instance and class (e.g. you can have two objects of type "Cat", and have one who has an additional method or slot without creating a subclass); it's a message passing language, allowing the entire core of the syntax to be summed up in 5 basic pieces (statement form, blocking with parens, assignment operators, separating disparate statements in a block with a semicolon, and comments in 3 forms); and it has a Lisp-like representation of data and instruction, meaning that data is stored in the Iovm's working memory identically to the way it is delivered in code, allowing real-time manipulation of any object.
To that end, I have built several simple data structures and even a basic non-reentrant lock in Io (source available below... didn't think I'd mention a new language without providing some code, did you?). Along the way, I've discovered some fascinating things that I never thought of before, such as the way Io handles multiple inheritance. Instead of being statically defined, ancestors are simply references to objects stored in a list, meaning that you can add and remove ancestor ojects dynamically at runtime. That floored me. I can't imagine what that could be used for, but it is incredibly powerful and speaks a lot about the way object-oriented programming is presented. Subtle things like this, mixed with the fact that it is the most elegant object-oriented model I've ever encountered, make me think that Io would be the perfect introductory language for an undergrad computer science major, or even a non-major taking an exploratory course.
That thought, combined with the high I have from finishing my thesis, gave me an idea. My professional goal is to become a college professor, as I find where I am in life to be absolutely fascinating and the best place for me. To help with that goal, I imagine that if I manage to write an introductory programming book focusing on the object-oriented paradigm, it couldn't hurt me any. So, I've started down the road towards writing a book... a lofty goal for an undergrad senior, perhaps, but one I'm excited to tackle. I've run my tentative table of contents by a few professors, and they're all for it, so here's hoping! Io would be a perfect language to use in introducing many situations in object-oriented programming, with very few exceptions which can easily be explained with a small bit of imagination. You can monitor my progress on this blog. I'll update whenever I have a decent chunk written, and post the whole thing online.
That's all I've been doing, really. I say 'all' as if that isn't a lot, but eh. I always feel like I have to be doing more than I am, but that's just who I am, I suppose.
Oh, I promised you some Io code! This code is very verbose, and probably not the 'Io' way of doing things, but it works, it's readable, and it makes sense.
Here's some simple data structures in Io:
Here's an implementation of an L-System in Io:
Here's a potentially dangerous implementation of a non-reentrant style lock in io:
Here's a small sequence of classes designed to figure out functional-style programming in Io:
That's it for me, I have a test or 3 to finish. Thanks for reading!
Keep tweaking~
0 comments
This post should have the subtitle "or, DON'T DO THIS". So, today I was curious about what makes independently developed commercial software licensing work. My target software shall remain unnamed (I'll call it X here), but lets say that it is a drawing tool of some sort, and programmed in Java. Java is relatively easy to decompile, with the right tools, providing next to no security if your validation scheme is embedded in the code itself. But how else is one to check licensing keys? I'll move on to that one later. First, onto the goods.
So, X comes in two versions: free and paid. The free version is more than most people will ever need or use, but the paid version offers some nice functionality. The free version and the paid version are the same executable, simply feature-locked without a valid license key. Hmm...
Decompiling the code was easy. Finding the validation section was even easier (it was clearly labled "VALIDATE CODE"). Finding this section of the code revealed all I needed to know about the license key to craft one myself that would give me a perpetual license to the paid version.
Here's what I found in X's validation section:
The license key must be exactly 16 characters.
All characters in the license key must be numbers.
The sum of the first twelve characters modulo 10 must exactly equal the 14th digit (first checksum).
The sum of the first twelve characters and the first checksum must equal exactly the two digit number formed by the 15th digit*10 + the 16th digit (second checksum).
There is a license expiration date encoded into the above characters, formed by the value of the 3rd digit*1000 + 5th digit*100 + 8th digit*10 + 13th digit.
This expiration date is a 4 digit number that corresponds to a certain number of days from January 1st, 2000.
If this expiration date manages to add up to a number between 7581 inclusive and 7694 inclusive, a perpetual license is granted.
With this in mind, I worked with pencil and paper to generate the following code:
0070600403000020
As you see, the value of X3*1000 + X5*100 + X8*10 + X13 = 7640, a number chosen at random to fall in the perpetual license range. The value of X1 + ... + X12 = 20. 20 % 10 = 0, which equals X14, satisfying the first checksum. 20 + 0 = 20, which is X15*10 + X16, satisfying the second checksum. So, in theory, this should work. And trying it in the software (which doesn't "phone home" except to pull updates) gives a successful update of license, and unlocks the paid version's features. Simple as pie.
But that's not all that reversing X's license did. X happens to be one of a family of software, also containing product Y. The validation code for Y's licenes is essentially the same thing, with the digit order scrambled around. So for Y, the following code grants perpetual paid access:
0070603400200000
You'll notice that the 7640 is embedded in the same location. The checksums have moved, such that X10 is the first checksum and X11*10 + X12 is the second checksum. The sum to compare these against is formed by X1 + ... + X8 + X13 + ... + X16. Like I said, just re-arranging numbers. This code was tested and verified to unlock Y perpetually.
Now, for the bad. THIS IS INCREDIBLY STUPID. Granted, most users won't have the knowhow to do this, but coding a simple verification scheme like this allows those with knowhow to generate licenses on demand with little more than pencil and paper, as well as distribute them to whomever they wish, reducing your profits and dilluting your efforts. Granted, for a software like X (and it's cousin Y), this is simple enough. The target demographic isn't usually the technically minded. X (and to a lesser extent, Y) is a very nicely presented software, and is almost bug free. The free version is way more than what one would expect for a crippled version of a shareware. But, this is still an issue if one is attempting to maintain a strong level of security in their licensing scheme.
What could have been done better? Well, for one, length doesn't typically matter, if you're simply using a checksum or two with embedded data like this. Once the algorithm is figured out, any number of keys can be generated regardless of length. So, short keys like the above are acceptable for this purpose.
Using all numeric characters is also fine, in as much as if your licensing scheme relies upon checksums and encoded data, numbers or not if it is cracked, keys can be generated. The same argument as above applies.
Not phoning home is the lynchpin of safe licensing. Each license should be generated and added to a master database, and checked upon entry for validity against the home server. Each license should also have a limited amount of legal activations before the license no longer unlocks a piece of software. But this is a minor point.
Essentially, the problem with licensed software is that there is nearly always a way to break it. If it is downloadable to the user's own computer, an intrepid cracker will find a way around the registration. If it is a web-service, someone will share a validated account. So, I suppose, the only way to win in software licensing and use-limiting, is to not play at all.
Just my two cents.
Keep tweaking~
0 comments
I wrote up a quick and dirty ELO ratings calculator in Common Lisp. It assumes a K value of 24, but that can be modified by rebinding the *k* symbol.
Code available: here.
In other news, my development efforts have ground to a halt recently, as my father passed away just over a week ago. I'm taking some time to heal and mend, and we'll see where I'm at when I come back to this stuff. Thanks for understanding :)
Keep tweaking~
0 comments