Logo




Subscribe:
RSS 2.0 | Atom 1.0
Categories:

Sign In


[Giagnocavo]Michael::Write()

 Wednesday, February 11, 2004
Chinese Hangman in .NET

As I was driving home this morning, I was thinking about localization issues for different situations.  I realised that it must be really hard to have certain word games, like hangman, in some Asian languages like Chinese or Korean (shouldn't be a problem in Japanese, so long you stick to the alphabets).  So, without further ado, I sat down and wrote a very simple Chinese Hangman game.

There is only one word because I'm lazy and wrote this in 20 minutes and didn't feel like putting a real word library in.  Maybe for v1.1.  “Chinese” is somewhat misleading.  In fact, I used Korean to get the characters, since I suck at the Chinese IMEs, and didn't feel like using my digitizer.

Since it's written in .NET, you can play online, just by clicking here (32K)!

Update:  Some of my slower friends have given me feedback that this game is hard, since you have to guess the exact word.  That's the point.  The game is just a joke.  That's all.  Don't actually expect to play it (although it is fully functional!).

Humour
Wednesday, February 11, 2004 4:01:40 PM UTC  #    Comments [0]  |  Trackback

 Saturday, February 07, 2004
Any better ideas?

Everytime the TSA is criticised for their silly airport checks, like removing sandals, some bloke comes along and says “Yea, well, airplane security might not be perfect, but can you think of anything better?”

Does anyone realise how ridiculous this is?  First, if you think that the way the TSA is approaching things is correct, then, well, it's pretty pathetic to have to ask perfect strangers if they have anything better.  Since most people don't know much about security, it's like having a bad designer decorating your house, then, when criticised about the horrible design and colouring outside the lines, your only response is to say “yea, well, YOU go do something better.”

At any rate, there is something better.  The security hole exploited on 9/11 was one that allowed cockpit access.  It had nothing to do with letting people with weapons on.  It's so incredibly easy to get weapons on, that I'd be surprised if anyone with an IQ over 105 couldn't figure out how to get a .22 pistol on board.  So, the answer is to plug the security hole (a cockpit access vulnerability), and ensure that even if 10 people come on with nunchaku, .22 pistols and crowbars that they cannot gain control of the plane.

However, what the TSA is doing is similar to not patching a system, yet enacting all sorts of false security measures.  For instance, lets say a new blaster variant comes out and attacks Windows machines on ports 135 using a new, unpatchable hole.  Since that's somehow related to Windows networking, our fake security advisor says: “Ha!  We'll turn off file and print sharing.  Yea, it'll annoy everyone and make our network useless since that's what we use the network for.  But, we need to be secure!”

Then someone who hasn't been hit by a bus or other any other large, blunt object says “That doesn't solve the problem!  You can still be hacked, and that's a useless measure.  Stop annoying everyone and actually concentrate on real problems.”

Can you imagine that person being told “Well, maybe not, but at least our CEO feels better, and hey, what's your great idea?”  That's pretty much what the DHS and TSA do.  “Sure, we don't know crap.  But we'll be damned if we're actually going to take any decent suggestions.  Now there, please remove your sandals and your watch.”

To the untrained eye, glass can appear as diamond.  Thus, to the security-blind, enacting useless fanfare security measures looks to be genuine.

Security
Saturday, February 07, 2004 1:06:33 AM UTC  #    Comments [0]  |  Trackback

 Friday, February 06, 2004
U.S. government's security cluelessness summarized

I was going to write about the absurdity of www.dhs.gov.  But, that's pretty much been covered many times and I doubt I'd say anything new.  However, while browsing the site, I found a link to www.safteyact.gov which helps companies that make “anti-terrorism” products.  Of course, it's so broad that it could apply to almost anything if you have a shred of creativity.  Hmm, maybe I'll submit our Obfuscator and see if that qualifies.

At any rate, the interesting thing on www.safteyact.gov is that you are immediately redirected to use HTTPS (After some text saying “You are about to be redirected to a secure site”).

Now, why do you suppose they do that?  The site just sends down rather public information.  Anyone can go get it.  There's no sensitive data in transit.  My theory is that some... special... person thought that since the site is remotely related to actual security, why, by golly, they should be using SSL!  Otherwise hackers can get in.  Or terrorists.  Or something like that.

Sounds like the DHS (and its vile child, the TSA) so far.  But then, what's this?  SSL errors.  Revocation list not available.  Ok.  And then we get the nice message that this site's SSL certificate was signed by “DHS Test CA1”.  Yep, that's right ladies and gentlemen, they pulled a cert out of their hats.

This pretty much summarizes U.S. government security.  “We're clueless, but we're gonna do *something*.  That something doesn't have to make any sense, or even be implemented correctly.”

Yes, I know there are some smart people working in the U.S. government.  (At least one is an MVP!)  And the site actually loads, so someone, somewhere, even if it's a subcontractor, has enough sense to figure out how to press a power button and save files.  My guess is that whoever made this site wasn't a moron, but had a conversation like this:

“Hey, web designer, we've got a security exploit.“

“I'm not a web designer.  I'm a server admin. And what exploit are you talking about?“

“Whatever, you work on the Internet.  Our site isn't secure.“

“Yes it is, we've got a firewalls configured correctly, patches, monitoring, and the passwords are managed--“

“But I don't see a lock thingy in the Internet!“

“Right, the lock icon won't appear in your browser since we don't use SSL,  Secure Sockets Layer.  We don't need to because we're not transmitting sensitive information.“

“I don't care!  I wanna see a lock icon thingy 'cause that means our site is secure, right?”

“Well actually, it means that data in transit is encrypted and--”

“Exactly!  Encryption means it's secure.  You should know this.  So, when will we have the lock icon thingy?“

... Can you stand up sir?  I need to get a certificate.”

Security
Friday, February 06, 2004 3:42:13 PM UTC  #    Comments [1]  |  Trackback

 Thursday, February 05, 2004
Finalize and Dispose: Performance

In .NET, some people have found Dispose and Finalize to be a bit confusing, especially in regards to when you need to implement Finalize, and when to Dispose.

To quickly summarize, finalizers in .NET provide a way for the runtime to clean up unmanaged resources that the Garbage Collector knows nothing about.  By providing a finalizer on a class, the runtime puts the object on the finalize queue instead of collecting it the first time around.  Only after the object's finalizer runs can the GC truly free the memory.

The impact of this is that objects that are left to finalize increase memory pressure, since they stick around longer and require a deeper GC to collect.  Obviously this is not really good for performance.

Dispose comes in to the rescue by providing a common way for an object to be deterministically finalized, in the .NET sense (the managed memory is still only freed after the GC).  In a class implementation, Dispose does the real work of cleaning up resources, while Finalize simply calls Dispose. 

However, Dispose can also call the Dispose method of other IDisposable classes.  It's possible that a class that has no direct unmanaged resources might actually be using some unmanaged resources.  Thus, it's important that you call Dispose on every object that supports it, since you never know what the implementation might be.

How big a deal is this?  I wrote a small benchmark that creates a new finalizable object, does some work, and then either lets it fall out of scope, or calls dispose.  It repeats this 10,000,000 times.  The work done is generating a new random number (using a System.Random instance, which is created before the loop).  The finalizer calls dispose, which does nothing (just trying to get the overhead of finalization).

My test machine is a Pentium 4c (HyperThreaded) at 3GHz (533MHz FSB), with 1.5GB of syncronous DDR333 RAM.  When not calling dispose, the average run time is 6.48 seconds.  When calling dispose, the average run time is 3.17.  Calling dispose makes this over twice as fast.  View the code: FinalizeBenchmark.cs.txt (2.08 KB).

Bottom line: Always call dispose if you can, even if the class doesn't have unmanaged resources or a finalizer.

Code
Thursday, February 05, 2004 10:25:20 PM UTC  #    Comments [1]  |  Trackback

 Friday, January 30, 2004
Learning a language: "Total Immersion"

As part of my continued (albiet slow) efforts at learning Korean, I decided I need more immersion.  Living in a Spanish-speaking country isn't exactly conducive to picking up Korean.  Enter the full power of MUIs.

A MUI is a Multilingual User Interface.  This enables corporations to standardize on Windows, Office, and whatever else in English, but allow a user to switch to a localized version.  I've been using a few MUIs for over a month or so, mainly for enhanced alternate input (the IMEs that ship with Windows don't have speech or handwriting recognition).

Today I'm finally changing the default interfaces for Windows and Office over to Korean.  Sure, I don't understand a lot of the text right now, but I know my way around the products enough get through most dialogs, and I should be able to pick out enough understanding if it's an unfamiliar one.

One interesting side effect of having IE in Korean is that many sites detect this, and thus display fully- or semi-localized versions of a page.

Personal
Friday, January 30, 2004 2:43:11 PM UTC  #    Comments [0]  |  Trackback

 Tuesday, January 13, 2004
Base32 in .NET
I haven't seen any .NET Base32 implementations, but various people have expressed interest in having some simpler way to represent binary data (such as an encrypted keycode).  So, I'm posting a sample Base32 encoding.  Note that this does not conform to the Base32 standard encoding, but uses it's own set of characters (useful for keycodes, where we don't want to have to differentiate between 0 and O.  Thanks to Juan Gabriel for making the code much better :).

Update 2004-2-5: Thanks to Philippe Cheng for fixing a bug that caused extra (harmless) output. (See comments for details).

using System;
using System.Text;
 
public sealed class Base32 {
 
      // the valid chars for the encoding
      private static string ValidChars = "QAZ2WSX3" + "EDC4RFV5" + "TGB6YHN7" + "UJM8K9LP";
 
      /// <summary>
      /// Converts an array of bytes to a Base32-k string.
      /// </summary>
      public static string ToBase32String(byte[] bytes) {
            StringBuilder sb = new StringBuilder();         // holds the base32 chars
            byte index;
            int hi = 5;
            int currentByte = 0;
 
            while (currentByte < bytes.Length) {
                  // do we need to use the next byte?
                  if (hi > 8) {
                        // get the last piece from the current byte, shift it to the right
                        // and increment the byte counter
                        index = (byte)(bytes[currentByte++] >> (hi - 5));
                        if (currentByte != bytes.Length) {
                              // if we are not at the end, get the first piece from
                              // the next byte, clear it and shift it to the left
                              index = (byte)(((byte)(bytes[currentByte] << (16 - hi)) >> 3) | index);
                        }
 
                        hi -= 3;
                  } else if(hi == 8) {
                        index = (byte)(bytes[currentByte++] >> 3);
                        hi -= 3;
                  } else {
 
                        // simply get the stuff from the current byte
                        index = (byte)((byte)(bytes[currentByte] << (8 - hi)) >> 3);
                        hi += 5;
                  }
 
                  sb.Append(ValidChars[index]);
            }
 
            return sb.ToString();
      }
 
 
      /// <summary>
      /// Converts a Base32-k string into an array of bytes.
      /// </summary>
      /// <exception cref="System.ArgumentException">
      /// Input string <paramref name="s">s</paramref> contains invalid Base32-k characters.
      /// </exception>
      public static byte[] FromBase32String(string str) {
            int numBytes = str.Length * 5 / 8;
            byte[] bytes = new Byte[numBytes];
 
            // all UPPERCASE chars
            str = str.ToUpper();
 
            int bit_buffer;
            int currentCharIndex;
            int bits_in_buffer;
 
            if (str.Length < 3) {
                  bytes[0] = (byte)(ValidChars.IndexOf(str[0]) | ValidChars.IndexOf(str[1]) << 5);
                  return bytes;
            }
 
            bit_buffer = (ValidChars.IndexOf(str[0]) | ValidChars.IndexOf(str[1]) << 5);
            bits_in_buffer = 10;
            currentCharIndex = 2;
            for (int i = 0; i < bytes.Length; i++) {
                  bytes[i] = (byte)bit_buffer;
                  bit_buffer >>= 8;
                  bits_in_buffer -= 8;
                  while (bits_in_buffer < 8 && currentCharIndex < str.Length) {
                        bit_buffer |= ValidChars.IndexOf(str[currentCharIndex++]) << bits_in_buffer;
                        bits_in_buffer += 5;
                  }
            }
 
            return bytes;
      }
}

 
Code | Security
Tuesday, January 13, 2004 1:22:46 PM UTC  #    Comments [3]  |  Trackback

Learning languages with Office 2003

I'm currently studying Korean.

I just finished downloading all four Office 2003 MUI CDs, and installed Japanese, Korean, and Chinese (Traditional and Simplified) MUIs for XP and Office, complete with speech and handwriting.

It's great!  I use Word a lot now to test spelling/grammar, get simple definitions, find the Hanja (Korean for Chinese character) for a word and vice-versa, and so on.

I'd like to learn Japanese someday, but currently all I know I've learned from watching anime.  Even so, the Japanese IME is easy enough to use that I can type in (not knowing much Hiragana)  something I hear in a movie, and translate from that, right inside Word.  Very interesting.

With a digitizer pad, I can practise my Hangul (Korean alphabet) too.  Probably would have been more useful a while ago, as I can type Korean as fast as I write it now, and I'd imagine I'll soon be typing it much faster than I write (as it should be). 

Personal
Tuesday, January 13, 2004 1:14:54 PM UTC  #    Comments [0]  |  Trackback

 Thursday, January 08, 2004
TSA: Bathroom lines dangerous

http://news.bbc.co.uk/2/hi/asia-pacific/3376459.stm

“passengers are asked not to congregate near the planes' toilets“

TSA spokesperson: "We frequently say security is not a spectator sport... we can't be successful about stopping terrorism without everyone playing a role“

The point he misses is that the role of the passengers shouldn't be to prevent terrorism.  The plane itself should handle that.  If having passengers “congregate” near toilets is a real threat, then the plane has much more serious security problems that need to be dealt with.  Where did they find these people who come up with this nonsense?  TSA == Totally Senile Administration?

Security
Thursday, January 08, 2004 4:29:59 PM UTC  #    Comments [0]  |  Trackback

 Tuesday, December 30, 2003
Secure it? Nah, let's just make it illegal.

Stoplights can be changed to green via an infrared signal.  This is so that police and ambulances can get through traffic faster.  Some people are using it to their own benefit.  So, the US government is trying to make these devices illegal if not authorized.  Hmm, sounds like cell phone companies when responding to the thread of eavesdroppers.  Why bother adding any security measures when we can just make it illegal?  I mean, no one ever breaks the law, right?

http://www.omaha.com/index.php?u_np=0&u_pg=1636&u_sid=958234

Security
Tuesday, December 30, 2003 3:41:18 AM UTC  #    Comments [2]  |  Trackback

The First Post
Hi there.  The obligatory first post.  In this blog, I'm going to talk about .NET programming (couldn't have guessed that from the title eh?) and other interesting items (security) as they come along.  Thanks for reading.
Tuesday, December 30, 2003 3:36:33 AM UTC  #    Comments [1]  |  Trackback