May 2006 Archives

The Indian Tabac Super Fuerte is a box-pressed, aged cigar made of leaves from Nicaragua, Costa Rica, and Honduras.  I'm not sure what size the cigar I reviewed was. It had a torpedo shape with squared sides from being box-pressed.

The Super Fuerte lit easily and gave off an earthy aroma from the start.  The flavor and aroma were consistently earthy.  There was a mild, even peppery note throughout the cigar that picked up slightly near the end.  The age of the cigar was evident in its flavor as well.  These are aged 4 years from the factory, and mine had been sitting in a humidor since 2004, so it was at least 5-6 years old.

The ash was firm, papery, and medium gray in color.

The smoke was a pale gray color and of moderate thickness.

The burn was even right down to the end.  As you can see below, I smoked it right up to the point where my fingers had enough of the heat.  (The bottle cap is there to give some scale.)

An enjoyable cigar all around, but I wouldn't call it spectacular.  It gets a solid 6 out of 10 rating from me.

The Fonseca 5-50 received an 88 rating from Cigar Aficionado and, according to Cigars International, a "Superior" rating from Rudman's guide.

The 5-50 is a 50 ring gauge cigar with a 5 inch length.  The cigars are hand-rolled in the Dominican Republic.  They're made from Dominican long filler, a Dominican/Mexican binder, and a Connecticut shade wrapper.  

The cigar I reviewed lit easily and burned extremely evenly, almost a perfectly straight burn.  It gave off generous amounts of wispy white smoke while lit, even when not being drawn. 

The flavor was very mild but evoked the taste of coffee in my mind, with a light touch of leather to it.  There was a light peppery note that started about half way through the cigar.

The cigar's construction was very firm and sturdy.  The ash was similarly very firm and a light to medium gray color.

It's a very pleasant cigar to smoke.  Nothing spectactular, but I've nothing at all bad to say about it either.  I rate it a 7 out of 10, primarily due to the lack of unpleasant characteristics.  This would make it a "safe" cigar to smoke, or a good one when I'm distracted by something else and can't fully enjoy a more "excellent" and expensive one.

An interesting thing happened today.  I was playing the Da Vinci Code Quest for Eurostar when I reached a puzzle that was based on ciphers.  The puzzle itself wasn't that exciting, but look at the artwork they used in the background behind the puzzle:

Those seemingly cryptic symbols at the top of the image above should look familiar to you.  If they don't, consider the following image from zodiackiller.com of the infamous "340 Cipher":

The topmost visible line in the Eurostar page is approximately the tenth line down in the 340 cipher.

I found it interesting, if not a bit grisly, that the Eurostar folks are using a serial killer's cipher as an illustration for their contest.  Wonder what the Da Vinci Code folks would think if they knew?

A while ago, my wife gave me a Lexar JumpDrive Secure 1.0 512MB USB Flash Memory Drive.  This drive had been given to her by someone else, who had apparently configured it so that about half the drive's storage was in the "secure" zone.

I didn't realize this until the drive had become full.  I noticed that Windows XP saw it as a 256MB FAT32 drive instead of a 512MB drive.  I had wiped the drive when I received it, so I lost the original software.  A visit to Lexar's site got me the "SafeGuard" software Lexar originally shipped with the drive.  I tried to use this to reset the drive but it did not work without the original password used to set up the drive.

Below are pictures of the front and back of the JumpDrive Secure 1.0:

The device in question has a part number of JDS512-04-500C in the 512MB model. Theoretically other models in the same line should unlock this same way.

I did some searches online and found articles from 2004 indicating that it was POSSIBLE to read the password in cleartext from the SafeGuard software while it was running in memory, so I decided to give it a shot.  I figured I had little to lose.  Unfortunately, all of the articles online were very vague as to the precise details.  I would need to discover those myself.  After some time, I figured out what to do.

First, I found the program WinHex 12.9 SR-12 by Stefan Fleischmann on the web.  This program is a free download for evaluation purposes.  I installed it.  Then I went to the Tools menu and selected "Open RAM'.  I then chose the "SafeGuard" process.  I went back to SafeGuard and entered a password that was unlikely to appear in the program's memory (e.g., "mes123").  I got an error indicating that this was the wrong password.

I clicked the "find" icon (binoculars) on the toolbar.  I asked the program to search SafeGuard's memory for the "mes123" password I'd just typed in.  It found that password near the phrase "The password reminder is" in memory.  A few bytes after that, I saw the word "test" sitting all by itself among a bunch of blanks. 

I went back to SafeGuard and entered "test" as the password.  The drive unlocked immediately.  I had found it.

Based on some of the questions I received in my email related to the Da Vinci Code Quest on Google, it sounds like some of you might find this article of interest.  When you're looking for something specific on Google, there are some very simple tips that can greatly increase your chances of finding it.

I was sitting in the den the other night in front of the PC, as I often am, when I heard what very much sounded like someone drumming their fingernails on the window.  I looked outside and no one was there.  I sat back down at my desk and heard the same sound coming from the living room across the hall. I got up and looked out that window and again saw nothing.  Soon, I heard it from the dining room window on the other end of the house.  (These are all consecutive windows going around the house in order, by the way.)

I figured someone was screwing around with me, so quietly crept back to the dining room window where the sound was still being made. I peaked through the wood blinds in time to see "something" disappear.  I still wasn't quite sure what it was, but I was guessing it was now an insect or bird since it was too small to be human.

Later on, the sound came from the den again and this time I saw the source.  It was a small yellow bird that, for no reason I can figure, flies up to the window, latches on, and pecks at it with his beak rapidly.  If anyone approaches, he flies off.  Otherwise he stays and pecks a while.  Here's the little prankster's face:

As you might imagine, this has caught the attention of our two cats, who would very much like for us to open the window and let the little fellow inside where they could "play" with him.  (And given that his pecking woke me up this morning, I'm REALLY tempted to help him inside for them.  My stepdaughter is also, as the bird did the same thing to her today, too.)  Colby, for example, has made a dive at the glass several times now to get to the bird.  Here he is just before one of those attempts:

And here he is just after the bird has flown off:

He REALLY wants to play with that bird.  If I can get any good cat/bird interaction video I'll post it later.

In the last installment, I told you something about the shortcuts and general flow of execution of the custom Visual Basic program I've written to try to crack The Zodiac Killer's thus-far-unbroken cipher known colloquially as "The 340 Cipher".  This time around I'll tell you a bit more about the program itself.

The program makes all of its "deciphering" decisions based on what I'm calling a "gated scoring algorithm" intended to expend the least possible effort determining that a potential "decode" of the message really does look like a decode.  The algorithm works something like this:

• First, the program looks and counts the frequency of letters in the "decoded" message.  If the letters which appear most commonly in normal English writings appear in approximately the right frequency in the message, it generates a base score.  If that base score is too low (i.e., there are not enough of the most-common letters in the message), scoring stips here before too many processor cycles are used.
• If the program finds "approximately" the right frequency of letters in the message, it then gets more granular about the letters it's looking for.  It makes sure that in the decoded message it finds the approximately-correct frequency of As, Bs, Cs, etc.  Each letter that is occurring in approximately the right frequency (+ or - 20% of normal English text) gets a higher score than those which don't.  Any letter appearing "too often" deducts from the total score (e.g., lots of "Zs" would drop the overall score).  If letters appear in the "decoded" message in approximately the right frequency, scoring continues. Otherwise, it stops here before more cycles are wasted.
• If the frequency of individual letters looks good, the program looks at the most common bigraphs in the English language and compares these to the message.  If it finds approximately the right percentage, scoring moves on. Otherwise, it stops.
• If the frequency of bigraphs looks about right, it then looks at a more granular list of bigraphs, trigraphs, and quadgraphs and scores the message based on whether these seem to be appearing in about the right amounts for a normal English text.  If so, the score is increased. If not, it isn't.  If the score isn't sufficiently high enough, no more scoring effort is performed.
• Assuming the breakdown of bigraphs, trigraphs, and quadgraphs is within a reasonable tolerance from "normal" English text, the program then pores through a 20,000-word English dictionary, going from the longest to the shortest words. This dictionary provides a score for each word, with added weight given to those words the killer used often that don't occur normally in English writing (like the killer's tendency to misspell "having" as "haveing").  This part of the scoring process can take several seconds of elapsed time to complete, so it is only done by the program when there is a very good chance of finding lots of English words in the text.

I call this a "gated scoring algorithm" because the potential "decode" of the message must achieve a certain predefined score before it can get through the "gate" into a more time-consuming scoring method.  This method allows the program to "fly" past potential decodes that are worthless (like something that generates nothing but "QZCZQ" type text) and spends the most time on "decodes" that statistically look like English text.

I was reading Wired yesterday when they mentioned a Flash-based game called "Johnny Rocketfingers 2" on Newgrounds.com.  It's a graphic adventure game that's relatively short and a little bit challenging. I finally beat it late last night and thought I'd share the solution here in case anyone gets stuck trying to finish it.  (By the way, in case you didn't know already, the game has very graphic depictions of violence and other objectionable content, so I don't recommend it for anyone under the age of 18 or anyone easily offended.)

Here's a complete walkthrough for the game:

The "original" Johnny Rocketfingers cartoon is quite a bit more crude, not as well drawn and animated, and even more offensive than the second.

As I mentioned in yesterday's article, I am working to crack the "340 cipher" sent to police by the Zodiak Killer, who operated in the 1960s and 1970s in California. I also mentioned the assumptions I've made about the message (which could well be wrong) and the staggering size of the potential solution space. Clearly I needed to shortcut that 100-year process as much as possible since it's very unlikely I'll live to be 140 to see the end of it.

Some of the shortcuts I can take include:

• I know that all of the symbols can't translate to the exact same letter, though it's highly likely that several of them do represent specific letters. Thus, I can (probably) discard any potential message key that has "too many" of the same letter. That reduces the size of the solution space a good bit.
  
  
• I know that when the message is cracked, it's highly likely that there will be a pretty standard breakdown of the letters as seen in typical English texts. By spending a minimal amount of time on any key that generates a "possible solution" of the message whose character breakdown is too much "off" from that breakdown, I can speed up my trip through the solution space.
  
  
• I know that when the message is cracked, it should contain a certain percentage of the most popular bigrams (2-letter combinations) and trigrams (3-letter combinations) found in English texts. By checking a possible solution against those percentages, I can avoid wasting time on "solutions" which are filled with unlikely bigrams (such as "QZ") and trigrams ("QZQ").
  
  
• I know that the message is most likely written in English, so I can build a dictionary of the English language from online sources and compare any possible solution which has the right breakdown of characters, bigrams, and trigrams against that dictionary to see how many real words are in the message. The more words we find in the possible solution we're looking at, the more likely I'll have found the "right" solution.
  
  
• Based on my analysis of the enciphered message, there are some symbols that occur too frequently to be likely to be letters like Z, Q, or X. When trying potential keys, I can discard those which are attempting to replace those symbols with characters they're unlikely to be.

Not being a mathemetician (I blame the lousy Calculus teachers I had at Syracuse University for squelching my confidence in my ability to do math), I have no idea just how much the above will cut down my solution space. Still, I expect it slices the space down pretty handily overall. To implement the above rules, I developed a scoring system that requires a potential solution to pass through a number of "gates" before going on to an analysis that is more thorough or computer time consuming. The scoring method works something like this:

• I generate a possible message key.
  
• I attempt to decrypt the message using that key.
  
• I run the potential solution through a character counter to verify that it has approximately the right number of the "most common" characters. If not, I move on to the next key.
  
• I compare the number of individual characters found against their typical frequencies in English. If there are too many or too few of a given character than expected, I move on to the next key.
  
• I compare the message against the most common bigrams and trigrams used in English. If those don't occur in approximately the right proportions, I move on to the next key.
  
• I compare the message to a dictionary of 20,000 English words. I weight the scoring in favor of larger words, and heavily in favor of words the killer used most frequently (especially those he liked to misspell). The more words I find and the larger the words are, the higher the "score" I get for the message.
  
• I analyze the percentage of the characters in the solution that are "swallowed up" by the words I found in the message. The higher the percentage of "words to overall characters" the more likely this key is to have broken the message, so the higher the score will be.
  

In the next installment, I'll talk more about the program's logic to try and accomplish the above.

I recently purchased They Might Be Giants' "Venue Songs" album and DVD from their web site.  When I saw Apple's recent ad campaign with the PC vs. Mac theme, I thought to myself, "This is no PC! This is a deranged millionaire!"  No wonder the commercials seem to be filled with half-truths and misinformation...

I've not been posting a lot of new articles into the blog lately, and I thought it was about time I explained why. Aside from the fact that things have gotten busier at the office, and at home, I've also been channeling what little energy I do have into a few projects. First is to publicize my spam-inspired cartoon site, next is to publicize my site to help bloggers find ideas, and finally (which is the point of this little missive) to try and crack a very old cipher written by a serial killer about 30 years ago.

The serial killer in question is the Zodiac Killer, who operated in the San Francisco area in the 1960s and 1970s. He killed an unknown number of people, but took credit for double-digit numbers. In spite of the fact that he taunted police by writing letters to them and to the news media, he was never caught.   The last communication known to be received from him was a 340-character cipher which has never been cracked (at least it isn't publicly believed to have been cracked). I decided to take a crack at it.

I should begin by stating that I am not a cryptographer or any kind of an expert in the subject. I'm a computer geek, to be sure, but have no special training or background in such things. Regardless, I do have a morbid curiosity to know what this cipher says and what it might reveal about the killer. I'm also very curious to see if I can design and write a program which will crack this cipher.

Having read a bit about cryptography, I know that there is a pretty consistent frequency with which letters appear in English texts. I know that there are also certain pairs of letters which tend to appear together ("bigrams") and certain 3-letter combinations which tend to appear more frequently together ("trigrams"). Cryptanalysts uses this information to help them find the key used to decrypt messages. I've found and made use of this same data in the work I've done thus far.

I began by analyzing the known writings of the Zodiac Killer, verifying that his letter frequencies match typical English letter frequencies (they do), that the bigrams and trigrams in his writing occur approximately the same as in normal English texts (they do), and building a list of his "vocabulary" used in previous messages. Armed this this information, I was fairly confident that if in the future I do crack this cipher, any computer program I write should be able to use standard cryptanalysis tactics to identify a break.

The encoded message in question is referred to by analysts of the Zodiac Killer as "the 340 cipher" because it is written as 20 rows of 17 symbols long (20 x 17 = 340). There appear to be 62 individual symbols and/or letters used in the message. It is likely that the Zodiac used the "extra" symbols to make it harder to identify the most commonly used letters in English (e.g., he may have used 4-5 symbols to represent the letter "E" and the letter "T").

Before I could begin instructing a computer to attack this cipher, I had to make some assumptions about it, which I fully recognize could be completely wrong. Still, I had to start somewhere if  I was going to break the thing. My working assumptions at this point are the following:

• The killer's previous ciphers were all simple substitution ciphers (e.g., the killer substituted one letter or symbol for another, and any time he used the same symbol it meant the same letter).
  
• The killer's previous ciphers are all written in English, and thus this cipher is also in English.
  
• The cipher contains an actual message and isn't just random scribbling that the killer sent to annoy the police and cryptanalysts.
  
• When properly deciphered, the message will yield a string of words with no punctuation in them, just like the killer's prior ciphers.

In the next article, I'll discuss the method I used to build a program to try to crack this cipher.