Pages

Monday, August 29, 2011

The Matrix Falling Code, Arduino LOL Shield Style

I got an Arduino over the weekend. I also picked up a LOL Shield from JimmiePRodgers.com. After what seemed like an eternity soldering LEDs, I finally got a chance to try out some code. There is nothing earth shattering here, just a fun little demo. Enjoy!



My code is below:
----------------------------------------------------

// Matrix Falling Code LOL Shield Demo
// Code from Marshal Graham via marshalgraham.com 
// August 29, 2011 - First revision
// This runs on the Arduino with the LOL Shield from JimmiePRodgers.com
/*
  This is free software; you can redistribute it and/or
  modify it under the terms of the GNU Version 3 General Public
  License as published by the Free Software Foundation;
  or (at your option) any later version.

  This code is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General Public
  License along with this library; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/

#include <Charliplexing.h> //Imports the library, which needs to be

// array to store the LED column state
boolean ledState[14];

void setup() 
{
  // Initialize the LOL Shield
  LedSign::Init();
  // seed the random number generator
  randomSeed(analogRead(0));
}

void loop()
{
  // Randomly choose a column
  DropColumn(random(14));
  // Wait a random amount of time up to 50 ms
  delay(random(50));
}

void DropColumn(int col)
{
  // Check the LED column state
  // If it's not lit then light it
  if (ledState[col] == false) {
    // cycle through each LED in the column
    for (byte i=0; i<9; i++){
      LedSign::Set(col,i,1);
      delay(25);
      }
    ledState[col]=true;
  }
  // otherwise shut it off
  else {
    // cycle through each LED in the column
    for (byte i=0; i<9; i++){
      LedSign::Set(col,i,0);
      delay(25);
      }
      ledState[col]=false;
  }
}

Wednesday, August 17, 2011

How Not to Restore Exchange 2007 Mailboxes

As an Exchange 2007 admin, it seems like I am breaking Exchange all the time. This time it was forgetting to move some users mailboxes before I dismounted and removed the storage group. Here's my story of the not-the-best-way to migrate Exchange 2007 mailboxes to new storage.  I would be moving the database and logs to a new storage array. I decided to create a new storage group and database and then move mailboxes. I could have taken the database offline and copied it to the new storage. If I had done that I would not have the privilege of writing this blog post. The mailboxes moves went very smoothly and after I was done I dismounted the storage group. At the end of the day, no one had called so I removed the storage group from Exchange and disconnected the iSCSI disk.

This is where things went terribly wrong. The next morning I realized I did not move the mailboxes of a few users from a child domain. I thought I might be okay since I still had the old database files. I reconnected the iSCSI disk and after a few attempts to mount the database it became obvious that I was going to have to pursue a different method. Of course, I could have just restored the mailboxes from tape but what is the fun in that? Besides I would have lost at least a days worth of mail that way too. I remember Recovery Storage Groups from Exchange 2003 so I thought that would be the way to go. RSG has changed quite a bit in Exchange 2007 but it was pretty easy to get the old database mounted by following the wizard.

This is when the second lightning bolt struck. Remember earlier when I said I removed the storage group? Well, that was a mistake too. Had I just left the storage group in place, I would not have the privilege of writing this blog post. Here's the scenario, I have about 15 Exchange users that still have attributes pointing to the deleted storage group. Simply creating a new storage group with the same name and mounting the old database did not work. The RSG option seems promising but the RSG wizard will only merge mailboxes if it can match attributes. Of course, I can not move messages to a mailbox that does not exist!

So here is the solution I came up with. I removed the mailboxes from the 15 users that did not have mailboxes. After waiting a few minutes to resolve any replication issues, I created new mailboxes for those users and verified that they now had empty mailboxes. For the next step, I switched to the Exchange Management Shell and entered this command all on one line.

Restore-Mailbox -Identity username -RSGDatabase "Recovery Storage Group\Mailbox Database" -RSGMailbox "Firstname Lastname" -TargetFolder "Restored-08152011"

This puts the contents of the old mailbox into a folder named Restored-08152011 in the new mailbox. I had to experiment a little to get the syntax right but this is what worked for me. For the -Identity switch I used the sAMAccountName or cn attribute. For the -RSGMailbox switch I used the display name attribute. You obviously need to substitute the name of your database for the -RSGDatabase switch. I probably could have worked a little more and scripted the whole thing, but I was more than happy to copy and paste this command a few times to get things going again.

The good news is this worked flawlessly. The folder contained all of the old mail. The only caveat is that I had to regenerate the Global Address List after this. I'm not sure why but I could not locate these new-old accounts until I did.

So the next time you bork Exchange, take comfort in knowing you are not alone.

Friday, August 12, 2011

Why Password Reuse is a Bad Idea

Password reuse is an issue that I seem to battle with constantly. Password reuse is, just as the name implies, using the same username and password combination for more than one website. I understand why people are prone to do this but I would like to take a few minutes to explain why it is a bad horrible idea.

It seems logical to reuse your password. After all, passwords are hard to remember and supposed to be kept secret. This logic makes perfect sense except for one scenario: What happens when you lose control of your password?

Imagine for a minute that you have followed my past advice. You have picked your complex, difficult to remember password and committed it to memory. It is 16 characters long and no one is going to guess it because you have mixed case, numerals, and special characters. You feel very comfortable with your uber-secure password and start making the rounds on the Internet. You change your passwords for online banking, email, Facebook, and Amazon.com as well as your work email and user accounts. You make them all the same, after all this is a really good password. You continue on this route, signing up for online forums, webmail, coupons, and a shady shopping site and use the same password. Everything is great, no one is going to hack you! Your password is unguessable!

One day, one of these sites get compromised. It might be a forum, email, or that shady shopping site. It might be the coupon site you signed up for and forgot all about. In any case, your ONE uber-secure password is now out in the open. Did you notice that? I put an emphasis on ONE. I did that for a reason.

It should not be difficult to figure out what happens next. Your information is out and the gig is up. The bad guys now have access everything you secured with that password. Everything! They can drain your bank account and credit cards or impersonate you on Facebook and email. You now have to scramble to change your password on every site. Unfortunately, you probably will not find out you have lost your password until something bad has happened. It could be money missing from your bank account or someone impersonating you through email and Facebook. Had you simply used different passwords for each account then you would be safe, having only lost control of the single compromised account.

Hopefully this post will help you understand why reusing passwords is a bad idea. In a sense, it is even worse than using a simplistic password. As always, comment below if this was helpful.

Wednesday, August 10, 2011

Google, Facebook, and 2FA


Wouldn’t it be great if there was a way to enhance the security of your Facebook and Google accounts? How about a way that makes it much more difficult for your Facebook or Google account to be hacked? What if it was easy to use?

Good news! The answer to all of the questions above is yes!

Recently, Google and Facebook rolled out two-factor authentication (2FA as we geeks like to call it). It’s easy to use and makes it significantly more difficult for your account to become compromised. Who wants to have to explain to their grandma why they sent her a raunchy email or photograph? Not me, that’s why I’m recommending you go enable 2FA on your social media accounts right now. So what is 2FA?

As I said, 2FA stands for two-factor authentication. The normal username/password login sequence we are all familiar with would be considered single factor authentication. You are only asked to provide one secret, a password, in order to access a protected resource. With two-factor authentication, you are asked to provide two secrets in order to access your account. So where does the other secret come from? Your cell phone!

Here is how a 2FA works when logging into your Facebook account. You go to the Facebook login page and enter your username and password as normal.


Next, you are asked to enter a security code. The security code is in a text message sent to your cell phone.


That is all there is to it. You just saw what a 2FA Facebook logon looks like. See, I told you it would be easy. The security code changes each time you login to your account making it more powerful than using only a password. Google account 2FA works almost identically to Facebook.

You can enable 2FA in your Facebook account by going to Account Settings(it’s on the right) and clicking on the Security link (it’s on the left). Look for the Login Approvals option. On your Google account, go to Account Settings and find “Using 2-step verification.”

I hope everyone who reads this starts using 2FA. Leave a comment below if you found this helpful.

Wednesday, August 3, 2011

The Undeletable File and a Bunch of Dots



Error Deleting File or Folder
Cannot delete file: Cannot read from the source file or disk.

This error message does not seem too scary. It looks similar to other error messages that Windows produces. Maybe it could be more descriptive but when I first saw this I had no idea what it would take to delete this file...

The other day I was doing my annual domain account and user directory clean up tasks when I came across a problem. There was one user directory that I could not delete. I have encountered problems like this before so I started by modifying the ownership and permissions. I made my account the owner with full control of the file. Say good bye file, you are toast. Oh no! It didn't work. And I'm still getting the same message.

The next step for me is FileAssassin. If you don't know what FileAssassin is, it is a great little utility from the Malwarebytes people. It will delete a file if it is locked or otherwise unable to be removed. I have used it several times with great results. Hasta la vista, baby. What!?! It's still there? No luck with FileAssassin, this thing is stubborn.
  • Maybe I can just rename the file. Nope.
  • I will try opening fsmgmt.msc and see if the file is locked. Still no.
  • Alright, uncle! I give!

At this point, I thought I better start looking at this more closely. Right away I noticed something strange. The file is named .jpg. (dot-jpg-dot). It starts and ends with a period character.

I thought this was odd but I didn't understand how this would prevent me from removing the file.

After doing some research I discovered that the Win32 API does not allow a file name to end with a dot. NTFS will allow a file to end with a dot but the Win32 API blocks access to this. You can verify this by trying to save a file with the name ending in a dot. Windows will just drop the dot. If you try to save a file named "myfile.", you end up with a file named "myfile" sans ending dot. So how did I end up with this file on my server? Perhaps this file was put there by a Mac or a Linux machine which would not have to honor the Win32 API. I really don't know the answer but that is my best guess.

That is all well and good but what I really want to know is how to get rid of this file. I eventually ended up on this MSDN page. You can read it all if you want, but the short of the story is you can bypass the Win32 API by prefixing the path with "\\?\" which I will demonstrate below.

To delete a file that contains a dot or other illegal character in the name, open a command prompt type the following:

del \\?\C:\demo\.jpg. 



BLAMO!!! The file is gone!

Neat, huh? You will have to substitute your drive letter, path, and file name. If there are spaces in the path then you can wrap it in quotes. I've tried this on Windows Server 2003 R2, Windows Server 2008, Windows XP, and Windows 7. I think it will work on all modern versions of Windows.

While it took me too long to figure it out, it is a handy trick to have in your arsenal. If you want to have some fun with your friends, try running this command:

echo This file cannot be deleted. > \\?\%USERPROFILE%\Desktop\you-cannot-delete-this.

But I don't think you would want to do that...