r3dux.org

I love Linux, but sometimes you have to wonder just what was going through the minds of some of the developers. Take, for example the following error message that appeared when I (for all intents and purposes) clicked on my DVD drive:

Can you figure out what the problem was? No? Neither could I. And then I looked at the DVD drive, which was open…

Ah.

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution – and I can see that it’s trying (it’s trying real hard) – but I really still would have preferred “No disc in drive. Please insert a disc.”

Check out this creative-commons licensed dark electronica from Indigo78 off his free to download The Autumn EP.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

MNice! =D If you like it, give your mates a copy & spread the word!

I ripped some DVDs I own the other day as I wanted to create a back-up for the kids travel DVD players (so the originals don’t get scratched and trashed on the road), only the DVDs themselves were DVD-9′s (so single-sided dual-layer with a capacity of up to 8.54GB) while I can only write DVD-5′s (single-sided single layer with a capacity of up to 4.7GB) – this isn’t a big problem as I compressed them down to fit using Handbrake and elements of Shetboy’s meticulously crafted AVI to DVD technique. However, both Brasero and GnomeBaker would flat out refuse to burn Video projects – they’d just choke on the folder containing the AUDIO_TS and VIDEO_TS folders – so why not covert the directory including the *_TS folders to an ISO and burn that? No reason why not! Let’s get it done! =P

Making the ISO

Once you’ve got a folder structure containing the AUDIO_TS folder (which is empty) and the VIDEO_TS folder (which contains your .BUP, .IFO and .VOB files), just run the following command to generate your ISO:

mkisofs -o ISO_FILENAME -V LABEL -r SOURCE_DIRECTORY

So, for example, you might use the following command to create an ISO of the directory containing the *_TS folders for the film Avatar:

mkisofs -o ~/AvatarDVD.iso -V Avatar -r ~/dvdprep/Avatar/

Once you hit return, you’ll see something like the following output:

I: -input-charset not specified, using utf-8 (detected in locale settings)
  0.22% done, estimate finish Wed Jul 27 12:30:27 2011
 
..... all the rest ......
 
 99.96% done, estimate finish Wed Jul 27 12:27:58 2011
Total translation table size: 0
Total rockridge attributes bytes: 1353
Total directory bytes: 4096
Path table size(bytes): 42
Max brk space used 21000
2275896 extents written (4445 MB)

Measure Twice, Cut Once

If you wanted to make sure you got it right, as in, you ONLY have the *_TS folders in the iso, not the top level folder containing those two folders also, then just open the created iso file with Archive Manager and take a look, or mount it to a folder with:

mkdir test
sudo mount -o loop -t iso9660 ./AvatarDVD.iso ./test
ls test
 
[ which should show "AUDIO_TS  VIDEO_TS" ]
 
sudo umount ./test

When you’re happy with the iso, burn it with your burning software of choice and you’re all sorted!

Cheers!

While reading around on how to break into Linux accounts the other day I stumbled across the interesting tidbit of information that the password hashes stored in the /etc/shadow file can be hashed using different methods, some more preferable than others.

Here’s an extract from my shadow file:

root:!:15097:0:99999:7:::
kernoops:*:15089:0:99999:7:::
pulse:*:15089:0:99999:7:::
saned:*:15089:0:99999:7:::
kdm:*:15174:0:99999:7:::
test:$6$lAlAzXs6$kooivqlkaHwH5jFYZ2a3SGUim8w9Ib4XeEjffgbuqjVjwh/gqEdb7zPSTHHL/eRvvhtqv7UzR9Np3J3T29/8l0:15179:0:99999:7:::

From looking at the information in man shadow, there are 9 fields in the following format:

• Account name,
• Password hash. A value of ! or * indicates the account cannot be logged in with, but may still be used by processes, and !! means the account has expired
• Date of last password change (expressed as the number of days since Jan 1, 1970),
• Minimum password age before change (minimum days before you can change the password),
• Maximum password age before change (maximum days before you must change the password),
• Password warning period (how many days before the password expires should the user be warned their password will expire soon),
• Password inactivity period (the number of days an account may still change their password after expiry)
• Account expiration date (expressed as the number of days since Jan 1, 1970), and finally,
• A reserved field

So, taking the pulseaudio account pulse as an example, pulse:*:15089:0:99999:7::: means:

• Account name = pulse,
• Account may be used but cannot log in,
• Password set 15089 days since 01/01/1970 (which will be around May 2011),
• 0 days must elapse before password change,
• 99999 days (so roughly 273 years) may elapse before password change,
• 7 day password warning period,
• No password inactivity period,
• No account expiration date,
• No data in the reserved field.

All fair enough – but now take another look at the test user account:

test:$6$lAlAzXs6$kooivqlkaHwH5jFYZ2a3SGUim8w9Ib4XeEjffgbuqjVjwh/gqEdb7zPSTHHL/eRvvhtqv7UzR9Np3J3T29/8l0:15179:0:99999:7:::

The password field has a stored password hash (which in this case is a SHA-512 hash of the phrase thisisstupid2) – and the first three characters are $6$. This is where the strong hashing comes in…

Choose Your Hashing Algorithm Wisely

There are a number of first-three-character combos which mean different things, and some are definitely better than others:

• $1$ – password is hashed with MD5,
• $2$ or $2a$ – password is hashed with a blowfish variant,
• $5$ – password is hashed with 256 bit SHA-2 bit resulting in 32-byte output, and
• $6$ – password is hashed with 512 bit SHA-2 resulting in 64-byte output.

MD5 is broken, by which I mean it can be manipulated to give the same hash for different sources. SHA-256 and SHA-512 on the other hand are significantly stronger and to the best of my knowledge do not currently have working attacks, so they’re definitely the way to go. There’s a great article on shadowed passwords by Aaron Toponce over at GuruLabs which will tell you pretty much anything you might want to know, and which can be found here.

Going back to my own experience with this, when I checked some accounts on my VPS (which runs this site) the other day, I found that some of the hashes started with $1$, so were hashed with MD5. The fix for this? Simply reset the password and the newer, stronger hashing algorithms will be used.

You can reset the password for any account by issuing the following command and then providing a new password:

passwd <account-name>

For example:

passwd root

After this, check your shadow file to ensure your hashes start with the desired prefix. Once they do your machine will be a little bit more secure, and it isn’t that much of an ordeal to achieve.

Cheers!

In the final week of the ActionScript intro we get into using sounds with ActionScript, and play audio which is external to our flash file(s), embedded within our flash files as well as covering topics like offsetting and repeating. We also create our own custom pause function (because weirdly, the functionality isn’t natively available).

This wraps up all the ActionScript stuff I taught over a brief course about a year ago, and I’ve got to say, I didn’t mind ActionScript 3 as a language at all. You can do a lot of nice bits and pieces with it which can be embedded directly on the web, or you can use it for some quick prototyping (although if you were prototyping some serious effects, you’d probably be more likely to do so in the processing language), so yeah. Glad I spent a month or so getting my head around it.

Download link: An Introduction to ActionScript 3.0 – Week 9
Audience: Beginners who know a little about variables, functions, objects and how to perform some basic programming math.
Format: PDF
Content License: The document, its contents and the provided source code are released under a creative commons non-commercial attribution share-alike 3.0 license by me (r3dux) and comes with no guarantee of correctness, fitness for purpose or anything of the sort. The audio samples used are the property of their respective owners and are used under a fair-use type of deal.

If you’ve followed the series of posts over time, or just stumbled across one week’s worth of notes and found it useful, then I’m happy I went to the effort – and if you’ve learnt something from them then even better

Cheers!