Showing posts with label windows. Show all posts
Showing posts with label windows. Show all posts

Tuesday, May 17, 2016

The most irritating part of the Windows UI

Its come to my attention that blog has way too much helpful technical information and not nearly enough bitching & complaining. With today's post, I hope to tip the scales a bit.

During the course of the day, I use a variety of operating systems. Most of my desktop computers use Windows, most of my servers use some version of either linux or bsd, and a large number of my customers use Macs (which I know underneath the branding is also linux, but we are talking about UI stuff in this post, and in that department OS X qualifies as its own thing). Over the last 20 or so years I've alternated between which operating system I use most frequently, based on what kind of work I'm doing as well as what is inexpensive, secure and effective at the time.

Lately I've had a series of Windows laptops that I've spent a fair amount of time working with. It is what it is, I don't want to get off topic. This isn't some mouth-breather-y attempt to measure the manhood between the various OS'ses. This post is about bitching.

So Windows, like just about every operating system, is built for multi-tasking. Its designed to let users run more than one application at the same time. That's one of the core ideas behind an operating system. If you didn't need to multi-task, you wouldn't need an operating system at all, you could use other stuff, like embedded circuits, to run the one application you need, kindof like a calculator.

The problem that is bugging me is how Windows handles multi-tasking. So its a biggy. Nearly everytime I use more than one application at the same time on Windows, there the problem is, like an over-excited dog jamming its nose into my crotch after a particularly stressful day.

Specifically, the issue is with how Windows has opted to notify users that an application has completed a task, when that user has gone off to work with another application. For example, let's say I have decided to run an application that needs to perform a very length task that requires no human intervention - like scandisk or a defrag. Such a task could take hours. But, because Windows can *multi-task*, I can go off and do other things while that boring task is being taken care of. I can go check my email, look at cat pictures, whatever I want to do. So far, so good.

The issue occurs when the long boring task completes. So this application has been in the background for hours. I may have forgotten it was running. I may be in the middle of another task. That other task could be critical. I could be about to, I don't know, complete a series of calculations that would let me cure cancer. I've got the numbers allin place. I just need to hit return, and then, just like that, cancer is CURED. But NO. That's when Windows happens.

You see, Windows has decided that when a background application completes a task, it needs to let you know about it immediately. And by immediately, I mean it will take you out of your current Window and force you back into this other window that's been running in the background. So far, kind of maybe annoying, but no big deal, right? Well, it gets worse. You see, Windows doesn't care if you are in the middle of typing when this switcheroo occurs. And the background application that has just completed its operation may just present you with an option. Going back to my example where I am curing cancer (you're welcome), I was just about to press return when I am forced back to that background application. That background application presents a prompt:

        Would you like to format drive C?
        Press [ENTER] to continue, [ESC] to cancel

And with that carriage return press, my cure for cancer is gone for good.

This is a silly example, but similar things have happened to me regularly because of this stupid, stupid UI decision. I've deleted important files. I've screwed up installations. And when none of those things have happened, the work I was doing in my active application when this notification occurred was disrupted. It stops me in the middle of writing a new line of code, or a new line in this blog for that matter. No matter what I am doing, it interrupts me, usually to inform me that, wow, my antivirus signatures have been updated successfully or some other useless rubbish.

I hate it.

Its very possible that the other operating systems do exactly the same thing. But I don't spend a lot of time in linux outside of the command line, and the only time I am using a Mac is when I am fixing one that belongs to somebody else. It doesn't matter though. Even if this "feature" is considered to be god's own gift to computer science, it's dumb and I hope it dies.

That's all for now.

Monday, February 8, 2016

PuTTY hack keeps SSH session data out of Windows registry

A lot of people connect to Linux machines from a Windows desktop computer. Despite the number of people that have to do this for one reason or another, there are hardly any SSH clients for Windows. Basically there's three - Bitvise, Dameware and PuTTY. I've almost always used PuTTY.

There are problems with all of these clients, including PuTTY. One of the smaller issues with PuTTY that I've nonetheless always found annoying is that it is not quite as portable as it appears to be. Installing the client is usually as simple as downloading and running the EXE file, but vital information about saved sessions as well as seed data gets stored in the Windows registry, where it can be forgotten about. Or where someone else can grab it.

That's not really the fault of the developer; if I was making PuTTY today I doubt I would do anything differently. Its a garbage collection thing. The problem is that PuTTY information can be valuable to attackers. Just about everyone who uses an SSH client saves sessions on it; especially if they have to contend with multiple machines, all with different passwords and certificate files. It would be nice to store that sort of valuable information in a more secure medium - like a separate encrypted disk. PuTTY doesn't let you do that, but there is a hack from PuTTY's documentation that let's you do it. I've published that hack on GitHub - its very bare-bones right now, but as time permits I will make it a bit fancier and more useful.

The hack start of as three files - a .BAT file and two registry keys, but grows to five files once it pulls your session & seed data from the registry. It will export all your existing session information and random seed data to files and delete their corresponding registry information. The hack part is that whenever you use PuTTY, the script will reload your session information into the registry until PuTTY is closed. This approach doesn't resolve all of the security issues - for example, if you are using PuTTY on a computer that is part of an Active Directory domain, or that has the Remote Registry service enabled, then someone can probably record the registry modifications when PuTTY is run and grab the session data that way (-cough- use LDAP -cough). Its not perfect, but its a step in the right direction toward keeping your SSH session data away from prying eyes.

Thursday, February 4, 2016

SmartDraw installs adware as part of demo program

When I'm not writing about computers for free on the internet, I actually work with computers (for money). Most of what I do involves doing stuff with computers directly, but sometimes I have to talk to people before I can start with the computer-stuff. That can involve convincing people that my colleagues and I actually know what we are doing or planning projects with other people. With both of these tasks I've found that drawing pictures can be very helpful.

These are special types of pictures - called work flows or network typologies. Here's a really basic example:
Tree Topology, by Tsingha02
The idea is taking some very complicated ideas about the relationships between computers and applications and putting them into very basic visual representations. Particularly for projects involving large numbers of servers, this sort of visualization is critical to understand what is going on.

Despite how critical this sort of thing is to working with computers, there is a fairly short list of applications that are available to produce these sorts of images. The big name in the market is Visio, which has been part of Microsoft's Office utility suite for years now. The problem with Visio is its price. These sorts of programs don't require anything advanced - they are just a specialized clip-art program that lets you copy & paste little pictures of computers with lines in between them. It seems a bit much to pay $300 for a few icons and a limited version of Paint, but lots of people do.

Among the other options is a program called SmartDraw, which starts off at around the same $200-$300 price range as Visio. I recently tried the software out by downloading a demo version from their site. For the most part, I liked it - although the demo software attempts to make it impossible to export images by embedding watermarks, a less-than-ethical user of the demo software could take a screen-shot of a SmartDraw image to replicate the export function without the watermarks.

The watermarks are lame, but pretty standard. What I was surprised to find was SmartDraw installing an adware application on my computer that randomly launches windows advertising SmartDraw -when the imaging software is not running. This results in this unsightly window popping up for what seems like absolutely no reason:

This behavior was encountered with the 1/31/2016 64 bit version of SmartDraw for Windows, using the installer package smartdraw_XG_13IGGR_setup.exe from the SmartDraw website. By default, this package installs into the directory C:\SmartDraw CI\ while this adware window is run from this application: C:\SmartDraw CI\Messages\SDNotify.exe. The adware contains several configuration files inside of that \Messages\ folder. It looks like this:

As you can see, the files other than the SDNotify.exe adware executable include several configuration files, some HTML files, an image and a log file. The image file is used for a notification bubble that appears in the bottom-left-hand corner of a users screen. Here's what it looks like:

The text that goes into that screen is based on the content of SDNI.ini, which also determines the location the window appears in a user's screen. The contents of that file are fairly self-evident:

PromptArea=4 32 220 47
PromptClose=206 7 12 12


prompt=Need Help? Give us a call. Really... we mean it!
prompt=You're Using the Best Diagramming Software There Is. Period.
prompt=Three More Ways SmartDraw Can Help You Go Home Earlier Today.
prompt=Don't Let Your SmartDraw Trial Expire

The adware script is executed with the following syntax:

Take note of the remote connection that is being established to - this sort of behavior is specifically reprehensible when users are not notified. I tried to scrape the file, messagecheck.aspx, that is referenced by the adware notification, but attempts to retrieve the file with wget simply cause a ErrorMsg=NoParamsPassed response and nothing else. Getting a better idea of the server-side of this script will require a bit of effort - I will update this post with further information as it becomes available.

What about the local HTML files? They handle the more complex formatting of the advertisement. There are five of them - 1.html, 2.html, etc. There is some basic logic in SDNotify.exe to keep track of SmartDraw demo's license, so the advertisement is based on how much longer there is to go until the demo license key expires.

How does SmartDraw run this delightful little script? Variables such as the installation time used to determine the veracity of the license key are stored in the registry at:  HKEY_CURRENT_USER\Software\\ (The installation time variable is HKEY_CURRENT_USER\Software\\Messaging\Local\InstallTime - you could probably extend a demo license key forever but futzing with this registry key). The registry also contains data on the last time the adware established a connection with SmartDraw's remote server.

The script is executed as a pair of Scheduled Tasks - SDMsgUpdate (TE) and SDMsgUpdate (Local). The arguments for each of the task is slightly different. Each task runs the adware script, but the TE task uses the arguments "-PTE -V22000000 -SSDU.ini -A -M -D0 -T -N -X" whereas the Local task uses the arguments "-PLocal -V22000000 -SSDNI.ini -A -M -D0 -T -N -L". Disabling the scheduled tasks should prevent further instances of the adware from running on your computer. However, I haven't checked if there is any logic outside of the SmartDraw installer that enables these tasks. SmartDraw does not install a service or run any startup scripts at boot time, but running the regular SmartDraw program might re-enable the adware.

I hope this is helpful to those interested in making network topologies without having their computer become a free advertising platform for SmartDraw. If SmartDraw is reading this, there is nothing wrong with telling users that their license is running out or provide sales information, but you should do so within the confines of your own program. Remind them when they boot your program, not when they are checking their email or looking at cat pictures. Don't install stuff on people's computers that they didn't ask for.

Monday, November 10, 2014

How To Enable CLR on a Microsoft SQL 2005 Server

A while back I worked for a small hosting firm that focused on Microsoft products. As part of my responsibilities I wrote a great deal of documentation for them for a variety of tasks - some basic, some more advanced and problematic.

Anyway I was pleased to see today that these tutorials are still published on their site. Follow this link, for instance, to read an instructional guide on how to enable CLR with MSSQL 2005.

Sunday, January 6, 2013

Pidgin Instant Messenger Log Data Location

Pidgin is a popular IM client. I've been using it for years, mostly because of its simplicity when used within alternate operating systems. I need a non-browser based IM client that I can use in Fedora and Windows with the ability to easily transfer log data between the two. My only complaint is that the log search function is not very great, and Pidgin does not provide you with the ability to locate or change the log file path within the application. For those of you who need to find Pidgin logs, here are the paths for both Linux and Windows.

Installations include an actual 
pidgeon. Rabies sold separately.
Linux-based operating systems store log data within the root directory like so: ~/.purple/logs

Windows XP stores your logs here: 
C:\Documents and Settings\username\Application Data\.purple\logs

Windows Vista and Windows 7 store your logs here:

When running Pidgin within Windows, Pidgin uses the PURPLEHOME environment variable to establish the log data location. You can easily modify this variable to establish a better log file location through the Control Panel.

Select System --> Advanced --> Environment Variables, find PURPLEHOME and adjust its path to your requirements.

Extra information can be found on Pidgin's Developer website.

Saturday, May 19, 2012

MySQL root Grants Broken Following a phpmyadmin Install in Windows

So this is a weird one. I recently installed phpmyadmin 3.5.1 in a MySQL 5.1 / IIS 7.5 environment. Everything was going well until I realized that following the installation (which was fully functional) I could not login to MySQL (from the CLI) without referencing the hostname (-h flag). I figured that maybe the .sql script included with the installer messed with my grants, but a quick show grants revealed I still had the same permissions granted to root as when I started. So I figured that I would update the grants on root to what was displayed in show grants just in case. This produced an insufficient permissions error even though root had "full" privileges.

To resolve this I added skip-grant-tables to my.ini, restarted the mysql service, logged in as root, flushed privileges, and again updated grants to what was displayed in "show grants". I then removed skip-grant-tables and restarted, and I was again able to login locally. I'm still not certain what caused this and there was of course no relevant data in the logs. If anyone has any ideas I would definitely appreciate feedback in the comments!

Tuesday, May 8, 2012

.NET Debugging Tutorials

Do you know who Tess Ferrandez is? If not, you are missing out on the author of what I consider the most lucid series of articles on the topic of debugging .NET. Check out her series of demos on how to fixxit all things .NET. The most useful post I have seen so far is her piece on how to capture dumps on 32 bit process within 64 bit systems (without needing to DL procdump). +1 nerd points to Ms Ferrandez for making my job of learning all things Windows a bit less painful.

RAT Bastard

Earlier this week, several servers I maintain were targeted by automated attempts to upload a remote access trojan (RAT). The RAT is a simpl...