I’ve been toying with a few items the last few months, and now they’re active. The filemanager now crosschecks the files against my stored MD5 hashes, and will report if a file may have become damaged between my upload and the resulting program on my software page.

As a corollary, this does increase the load on the webserver by an insignificant amount. To help combat this; I’ve made my filemanager caching, so it will store the last hit, if within the last few minutes, compare them to what it computes, and if nothing has changed, it will then send the prior page, rather than recreating the entire page and heirachy.

Pretty cool, huh?

[Edit: I’ve changed the way the output is generated; rather than displaying the check mark next to ‘known good’ files, it will alert the end user when they attempt to download the file if it does not match checksums. This is less astetically pleasing – losing a few geek points for a silent dynamic test, but is much easier on the server.]

I’ve integrated download statistics into the software; making it much easier to tell what software’s hot, and, er, what’s not.

Eventually, I’ll add more useful statistics than overall download numbers; perhaps even highlighting the software by search terms for people who find me via Google, and provide alternate means for those who seem dead-set on hotlinking to my files.

At any rate; the statistics are true, and valid, although I’ve only collected the last few month’s worth of data here. It’d be interersting to obtain overall statistics, but I used to use ‘the standard’ way of just pointing an HREF to the files; whereas now, everything’s seemlessly handled by my file manager.

According to Alexia, I’m estimated at a traffic rank of 3,983,704, this means on this great wide internet, I’m number 3,983,704. Oh well. Perhaps I’ll come up with some extremely killer application and the world will beat it’s way to my door… er, webpage. ;)

From MacCentral:

Intego issues Mac OS X Trojan Horse warning By Jim Dalrymple jdalrymple@maccentral.com April 08, 2004 3:10 pm ET

Macintosh security specialists, Intego on Thursday issued a security warning to its customers for the first Trojan horse to affect Mac OS X. Dubbed MP3Concept (MP3Virus.Gen), the Trojan horse exploits a weakness in Mac OS X where applications can appear to be other types of files, according to the company.

Intego told MacCentral today that the code is hidden in the ID3 tag of the MP3 file. The code will only activate when clicked, but once it is, Intego warns the Trojan horse has the potential to delete all of a user’s personal files; send an e-mail message containing a copy of itself to other users; and infect other MP3, JPEG, GIF or QuickTime files.

Intego also said that the same technique could be used to infect .jpg or .gif files, although no such cases have been found. Intego has released updated virus definitions to combat the Trojan horse.

At the time this story was posted, Symantec Corp. had no information on its Web site about the Trojan horse.

A (I know, I know) slashdot followup:

It is a real concept. There is an example of the trojan, or “virus” (sic), here: http://www.scoop.se/~blgl/virus.mp3.sit

However, it seems that this may be at best questionable, as the “proof of concept” is nothing more than a standalone CFM application that has been given a creator type of ‘APPL’ (recognized by Mac OS X as a Carbon application), but with the file extension ’.mp3’, the standard mp3 icon, and the contents of an mp3 (which Mac OS X displays to the user an mp3). While the file does indeed appear at first glance to be an ordinary mp3, what can admittedly be potentially dangerous, it is in fact an application.

Additionally, as a CFM application, the file needs to be transported in such a way as to keep the resource fork intact, massively reducing its utility.

I predict a future security update with disallow this behavior…

This whole ‘issue’ is an incredible amount of misinformation. It’s a program that just has an MP3 icon; relying upon a user’s inability to drag and drop, but their ‘if I double click, it will work’ stupidity – the same way that most Windows email based, file sharing, et al work.

First, show all file extensions. Finder->Preferences->Advanced

Secondly, here’s a simple little program to ‘exploit’ this. It’s quick AppleScript, here’s the code:

Here’s what it looks like with ‘File Info’, after cutting and pasting a standard MP3 icon over the compiled Application:

With “Show all Extensions” on:

What this article IS saying, however, is that the Finder respects the application filetypes over that of the extension. This is the ‘bug’. So, were I to rename the application from .mp3.app to .mp3, it would execute the application. For this example, I renamed ‘NotAnMP3.mp3.app’ to ‘NotAnMP3.mp3’ in the Terminal:

It is shown to be an Application, and if you double-click it, it will run as a program, despite the extension of .mp3, as it has the application (APPL) filetype, and that takes precedence over the filename, itself. I hope this has cleared up a bit of this ‘voodoo’. The way this works is the way any other program works, and has worked on the Mac, for aeons.

Of course, dragging it to iTunes or trying to open manually with iTunes does nothing. If you double click, however:

This has potential for messing up things that you have ownership of, but it does significantly less damage than Apple’s own Installer has the ability to. Apple’s Installer, by default, overwrites symlinks with hard paths. Suppose you have /usr/local symlinked (aliased) to somewhere, and you install the latest and greatest software port, which installs to /usr/local. Hey, where did the libraries and other programs go?

Thankfully, of course, there is a fix for this behavior, but it’s not [yet] the default.

BTWinCap is an alternative Windows WDM driver for those with BrookTree/Conexiant based capture cards. This is a wonderful enhancement to those of us who have either unsupportted, or poorly supported hardware with newer systems (Such as drivers for Windows 98 only).

I’ve discovered that my MediaLand SuperTV is the same as a Prolink PlayTV Pro (model 8E). I would use their given drivers; but they seem to have introduced an intentional bug. This bug causes the card to reset once it gets an open/reopen request; the practical upshot of this is that you can no longer use your card for capturing with software such as VirtualDub.

The BTWinCap driver solves this, by not having these [intentional] problems. Below, find my “BTSpy” formatted file which allows the card to work perfectly well with the TV, SVideo, and Composite components; but the FM radio function does not currently work. I’ll try debugging the issue with the FM tuner in the future.

### BtSpy Report ###

General information: Name:MediaLand SuperTV (ProLink PlayTVPro 8E) Chip: Bt878 , Rev: 0×00 Subsystem: 0×00000000 Vendor: Gammagraphx, Inc. Values to MUTE audio: Mute_GPOE : 0×0000ff Mute_GPDATA: 0×000028 Has TV Tuner: Yes TV_Mux : 2 TV_GPOE : 0×0000ff TV_GPDATA: 0×000021 Number of Composite Ins: 1 Composite in #1 Composite1_Mux : 3 Composite1_GPOE : 0×0000ff Composite1_GPDATA: 0×000024 Has SVideo: Yes SVideo_Mux : 1 SVideo_GPOE : 0×0000ff SVideo_GPDATA: 0×000024 Has Radio: Yes Radio_GPOE : 0×0000ff Radio_GPDATA: 0×000020

This is a working profile for btwincap
with the Medialand SuperTV, AKA Prolink
PlayTV Pro (Series 8E). The video and
audio works perfectly for the TV. Svideo,
and Composite inputs; however the Radio
does not; neither are any BookTree
enhancements available with VirtualDub
or DScaler.