# KDE Mover-Sizer 2.9

There has been a small update to KDE Mover-Sizer

You can now choose to hide the tray icon, if required. That's it!

All the other awesomeness remains the same!

;o) Cor

# checksum 1.5.3.0

Another Beta release of checksum is available.

NOTE: to get version update notifications for beta releases, you need to enable the beta_channel preference.

New features..

 +  Task Scheduler..

You can now create basic tasks for your system scheduler, to perform
checksum jobs on a schedule. Handy for hashing your morning torrent

and so on, and then pop open the options dialog (create or verify,
depending on the task), where you can set your options for the scheduled

+  You can now get to the "Edit Prefs (ini)" tray menu option when checksum
is started with nothing to do.

Full details in the itstory.

You can grab this latest checksum (and simple checksum) beta from the usual place.

for now.

;o) Cor

# ip checker fun..

Or.. "How my IP checker revealed gaping security holes all over the web as well as some highly dubious ISP practices.."

My external ip checker script..

http://corz.org/ip

..is pretty handy. Whenever you need your external IP Address, there it is. And in plain text, so you can insert it into scripts, whatever you like. I've had it running for years, providing a free service to anyone who needs it.

On a hunch (looking for some missing bandwidth), I decided to add a basic logging capability, suspecting that some were using it more than others. It's such a simple script that it doesn't call the usual site initialization or any such thing, simply spits out your IP, so misses out on the usual site logging. Just as well..

Sure, I suspected that it was getting used a fair bit but really, I had NO IDEA! In the first minute of logging, it racked up over 2000 hits. That's right, TWO THOUSAND PER MINUTE! Holy Sheeite! On the plus side, I can now tell folk that I have a page on site that gets three million hits a day!

I left it logging overnight while I slept and six hours later I checked again - almost 100MB of log. Oh man! Also, I suspect the hits are simply coming in so fast that the logger doesn't have enough time to lock/write/unlock the log file quickly enough to catch them all! Crazy!

The first thing I've done is to enable some simple throttling to the ip checker. You can now check no more than once every minute. The first time you attempt to check your IP within this time, you get a message to this effect. Thereafter nada, until you back off for a minute and try again.

That's the technical bit out of the way, now for the fun..

So I have a list of a zillion IP addresses and noticed that about half a zillion of them are from the same IP block, one "VNPT", aka. "VIETNAM POSTS AND TELECOMMUNICATIONS". Interesting. It looks very like they have plugged the URL of my IP checker into their firmware somewhere! To be called every 13 seconds!

So I picked one of the IP addresses at random and popped it into my browser. Auth login prompt. Hmmm.

#### I got root!

And here I am, browsing their router admin interface and laughing, shaking my head. Of course, I'm no stranger to this sort of malarkey. Before I started the whole BT Voyager section oh so many years ago, this sort of thing was commonplace. I've seen hundreds of router admin pages but, being a generally straight-up guy, haven't done anything nefarious whilst browsing around their personal settings (back in the day I would rename their WiFi SSID to "ChangeYourGatewayPassword" or some such fun. Slightly irritating for them, but a lot better than the alternative. I have no intention of attempting this with thousands of VNPT routers!).

So I pick another IP at random. Same story. And another. The same. And again. I do this twelve times and EVERY SINGLE IP IS WIDE OPEN! Not only with the WAN interface showing (yes, ISP's should never supply modems with this enabled), but still using the default admin/admin user/pass combination. This is not good.

It looks like VNPT is using old Yes Telecom hardware (Realtek/Zyxel routers), probably shipped with minimal instructions. Ultimately, as ISP's will tell you, the end-user is responsible for ensuring the security of their gateway device. But in order to do this, the average user (not power-user/techie/IT nerd) needs to be informed that it is insecure in the first place (which was the main rational behind the old BT Voyager section). Clearly this ISP like to keep its users in the dark. Perhaps they like the ability to login themselves and change stuff if "required".

I tried some other IPs, too; not VNPT. Six in total, five cameras (two quite private!) and another router (which had no security enabled AT ALL - courtesy of Tata Indicom). And do you know what, EVERY SINGLE DEVICE was setup to use the default username/password combination (except the router, which didn't even ask!). If I were some dubious individual looking to spy on folk, or mess with their life, I could have a field day! Instead, I try to blog some sense into the populace!

What is wrong with these people? I'd wager they don't leave their front door wide open when they go to work. Yet somehow their internet front door is allowed to stay open at all times. It makes no logical sense to set a super-duper 15 character WPA2 WiFi password in an attempt to thwart WiFi sniffers when someone can simply login to your gateway admin page and read it! I mean, come on!

So there you have it. Setup an external IP checker facility, get people using it, and Wham! You've got unlimited root access to thousands of gateway routers, cameras, and other interesting internet-enabled devices. Kinda scary.

for now..

;o) Cor

ps. Your router doesn't have its WAN interface enabled, does it?
pps. Your router/IP camera/whatever wouldn't be using the default user/pass combination, would it?

# checksum 1.5.2.0

There have been a couple of Beta releases since I last posted here.

NOTE: to get version update notifications for beta releases, you need to enable the beta_channel preference (see below).

New features include..

+   Custom Startup Command..

When checksum is launched with nothing to do, rather than have checksum
display the "Nothing to do!" dialog, you can have it do something
/else/. This might be a default checksum command that you use a lot, or
another program, or something else. e.g..

startup_command=simple checksum.exe
startup_command=c:\path\to\some\program.exe /foo /bar
startup_command=c:\some app.exe  c:\some documents\document.txt

For checksum commands, send your regular command-line after a "checksum"
flag; the word "checksum", with a pipe character after it, e.g..

startup_command=checksum|crtbim(movies) "W:\Completed Torrents"

And checksum will launch itself with the specified command-line. Simple.

NOTE: If a DOS command isn't working as expected, use the DOS
compatibility flag "dos", e.g..

startup_command=dos|compact.exe /C "B:\hashes\*.*"

ALSO NOTE: like many prefs, you can use @tokens in this setting.

There is also a special "shellex" flag, which I will now explain..

Normally, a command-line is an executable, optionally with some switches
and parameters required to complete the task. But you may want to launch
something else, for example a document or URL. For this, you can use the
"shellex" flag. The "shellex" flag performs a system "Shell Execute",
which can be used to launch just about any "thing". It goes like this..

startup_command=shellex|Item|Parameters|Verb|Working Dir

Only the "Item" is required. All others are optional, for example..

startup_command=shellex|C:\Users\Cor\Desktop\corz.org.URL

which will launch an internet shortcut I have on my desktop. Using the
"shellex" flag, you could also launch the URL directly..

startup_command=shellex|http://corz.org/

The default verb is whatever your system would normally do with the path
you send, usually "Open". But you can (usually, though not always) use

startup_command=shellex|C:\Users\Cor\Desktop\page.indd||Print

NOTE: the double || because in this example, I don't want to send any
parameters but DO want to send a Verb. In other words, if you want to
skip a previous flag, leave it blank.

The many, many uses for this feature should be obvious. Self-contained
on-disk data checking is but one of them!

+   Added new beta_channel preference. You can set this to true to get
notified when updated betas become available (as well as the major
releases). By default this is set to false, so you only get notified of

beta_channel=true

Major releases supercede all previous beta releases. The beauty of this
setting is that it will survive switching to a major release when /it/
becomes the  latest. As soon as a new beta becomes available, you get a

+   You can now set the string checksum uses to construct names when
creating .hash files from files with no names. By default, this is
"nameless". If you set this to blank, checksum can potentially create
".hash" files, which may become invisible on some systems. This may be
what you want. Though it rarely happens, it is now configurable.

~   Improved relative path handling (again), you can now use .\ and ..\
constructs to checksum the current or parent directory. This is
especially useful when using checksum in a stand-alone mode, e.g.
when burned to a disc for on-disc data checking.

*   checksum will no longer perform a writeability test of the hashing
location where a custom output directory has been set (it will now
properly test the custom output directory). Another upshot of this is
that the original folder's modification time will not change.

*   Fixed an issue where hidden checksum files were not being updated (when
using the w switch during verify).

*   Fixed an issue where portable relative paths on the command-line were
being ignored. This means that you can now easily script self-contained
disk checking mechanisms with checksum on, for example, burned DVDs.

This was possible before, but not without obscure DOS substitutions.

*   Fixed an issue where using braces in the custom output directory would
fail (checksums left on desktop, instead).

Note: You need to put custom output directory switches LAST, after other
bracketed switches, for (complex) example..

cr1qnm(movies)j(my-hashes)d("c:\some (dir) here") "D:\My Movies"

Full details in the itstory.

You can grab this latest checksum (and simple checksum) beta from the usual place.

for now..

;o) Cor

# PayPal, IPN, Testing..

I never did like the whole PayPal sandbox thingie. I usually end up doing a real transaction + refund. Because, you never know. Unless you have extensive logging and emailing capabilities in your back-end, as I these days do..

PayPal does have a cute tool you can use to test your IPN script0, here. I have started using this, creating a quick "ipn-test.php" copy of my ipn script, setting the use_sandbox to true and go..

It's basic, way more basic than you would expect from a company like PayPal. The first gripe is that it doesn't insert any of your user data (even though login is required to use it). Sounds like a job for greasemonkey, though seriously?

For example, you can get it to use (one of) your own email addresses as the payer, so your IPN script can send you stuff. But you need to enter that manually, every single time. Along with the item name, all the amounts (the most important of which, cannot be edited unless you enable all fields!). They have even disabled the auto-complete features so that your browser won't remember it!

The second gripe is that it's US-only. If you work with a currency not US Dollars, there is no option for your currency in the drop-down. At All. What is even more annoying is that if you edit it in-place, replacing "USD" (both occurrences) with your own currency code (e.g. "GBP"), it works fine.

So rather than some web-bod at PayPal taking five minutes to add the currency codes to the drop-down, thousands of international PayPal users have to individually edit it, for every single test, every single day, using whatever excuse for a code inspector their browser has to offer, though for developers one would hope that would be something substantial, anyway.

It's a disaster of a page that takes twenty times longer to use than required. It won't even remember your previous form inputs. Not really helping with the daily work-flow here, guys! Also..

An actual PayPal request..
[notify_version] => 3.8

A PayPal sandbox request..
[notify_version] => 2.4

They aren't working on it. But it does work.

Which is what I wanted to tell you. The PayPal IPN tester (sorry, "Simulator") is dreadful, but basically it's the only game in town. So don't let its apparent US-onlyness put you off using it, simply switch the currency code1. Yes, okay, for EVERY SINGLE TEST2, but still, a valid IPN request for your IPN listener to chew on.

It's either that or code your own sandbox.domain.com simulator in php. Hmm. Or perhaps code up a form page that sends your own POST request to the simulator front page. Hmmm..

for now..

;o) Cor

references:
0. For those that do not know, the PayPal API has the capability to post a request to a script on your web site. It's called Instant Payment Notification, or IPN, for short. You can use this facility to process orders, issue instant software licenses, etc.. Of course, for security reasons, any half-sensible IPN listening script isn't going to be fooled into accepting requests from any old server, so you need to use PayPal's sandbox capabilities to test if your IPN script is doing what it is supposed to be doing. That or, as I used to, code VERY CAREFULLY.. and wait.

1. Once you get all the parameters correct, and edited, you can then simply refresh the page to resend the same IPN request.

# checksum 1.5

The latest new-and-improved checksum is available!

There are too many changes to list - see the version.nfo.