(I wrote this back in October of last year, never bothered to post it. I probably had a reason for that, but it’s long forgotten by now, so I might as well post what I had.)

So I wasted a great deal of time trying to get my SHA-256 hashes from a .NET application to match up in a PHP application. It seemed really like it should be straightforward: make sure your string has a known character encoding, SHA-256 digest it, and then base64 encode it. How hard could it be?

Well, after a day of ripping my hair out, I concluded it’s harder than it seems. Here’s what the problem is: the application I’m trying to match encodes the strings as UTF-16 before hashing them. Unbeknownst to me, the double-byte strings are big-endian in one case, and little-endian in the other, even though they’re on the same Intel box. Took longer than it should have to track that down.

Oh, but is that the end of it? No, no, no. No, it’s not.

I also had to decrypt some strings. It was encrypted using the ManagedRijndael class, and I had the key and iv string. Those strings also got encoded into wrong-endian UTF-16, which was easily fixed (once I knew what was going on). But I was still getting gibberish. Well, to make a very long story short, the ManagedRijndael class in .NET and the mcrypt_generic function using Rijndael256 algorithm in cipher-block chaining mode in PHP aren’t exactly compatible. The mighty Google finally pointed me to the solution, which is using the Rijndael128 algorithm. The ManagedRijndael class creates actual AES-256, which mcrypt_generic is using Rijndael, which differ in the length of the initialization vector. Switching to the Rijndael128 but still passing the 32-bit key is equivalent to the AES-256.

What’s all this mean, then? This is all stuff that’s probably pretty obvious to anyone who knows anything. I, however, found this bewildering and confuzzling.

Back a few years ago, I posted a quick’n’dirty tool for generating plausible user data. I had a need for some improvements, so I’m posting the new version here.

The new version supports back-references, composite fields, and SQL output. So, for example, you could do:

./user-data-maker.pl -t id:lname:fname:city:state_code:zip:company -f i:ln:fn:c:s:z:/1+^+[Cars,Trucks,Boats,Planes,Motorcycles,Ships,Trains]+^+of+^+/3 -s -m tbl_dealer -n 5

and get the following output:
-- generated data from ./user-data-maker.pl
INSERT INTO tbl_dealer (id,lname,fname,city,state_code,zip,company) VALUES (0,'Nelson','Leslee','Akron','OH',44311,'Nelson Boats of Akron');
INSERT INTO tbl_dealer (id,lname,fname,city,state_code,zip,company) VALUES (1,'Bowen','Beatriz','Miami','FL',33176,'Bowen Trucks of Miami');
INSERT INTO tbl_dealer (id,lname,fname,city,state_code,zip,company) VALUES (2,'Hammond','Raymond','Ninilchik','AK',99639,'Hammond Motorcycles of Ninilchik');
INSERT INTO tbl_dealer (id,lname,fname,city,state_code,zip,company) VALUES (3,'Kim','Arielle','Columbus','MI',48063,'Kim Ships of Columbus');
INSERT INTO tbl_dealer (id,lname,fname,city,state_code,zip,company) VALUES (4,'Estrada','Warner','Iuka','IL',62849,'Estrada Cars of Iuka');

Nothing earth-shattering, but useful to me. Maybe to you too!

Download it here: user-data-maker.pl.gz

So in the middle of taking a set of pictures, I noticed that my D90 was not actually saving the pictures I took. The mirror would flip up, the shutter would click, but the display would show the same older picture again.

I tried the usual suspects. Turning the camera off and on. Changing the directory on the card where files were supposed to save. Swapping out memory cards. Reformatting memory cards. Doing the two-button reset. Doing the menu reset. Pulling out and then replacing the battery.

I could shoot a picture with a blank memory card installed, and the display would say “Folder contains no images.”

I searched on the internet for this symptom, and found no other reports of it.

Here’s what finally cured it:
* switch into LiveView mode
* take a picture – this will fail
* take another picture – this will succeed
* switch out of LiveView mode

Et voila! Now it works. I don’t know if this is reproducible, nor if I’m just heading down a path toward permanent issues, but I figured it would be worth posting just in case anyone else has the same issue.

Well, the screen issues continue, but at least the missing pixel columns are in designer colors:



Resetting the graphics subsystem sometimes cures it, sometimes just changes the color. Thus far, it’s always cured itself eventually.

So, in the middle of working on something, the balance of luminiferous ether in the universe must have come unhinged, because every other column of pixels on my screen went black:

View at full resolution to see detail

I tried the usual tricks, to no avail. I figured it was a hardware connector issue, so got an appointment at the Apple store. However, to my annoyance and chagrin, the problem has proved intermittent. It “cures itself” and then recurs. This supported my theory that it was a connector issue, or so I thought.

The Apple Genius, however, taught me a trick to reset the graphics subsystem: shift + control + eject

The last time the problem arose, this trick *did* cure it.

So the question is – is my graphics card going south? Is this some bug in recently installed software (Snow Leopard, the new version of iStat Menus, or Final Cut Express)? Could it be entirely due to my attitude? Or was the reset cure also a coincidence? Only time will tell.