Also, for those who have trouble remembering their metric units and conversions, a kilo of water (at room temperature) is 1 liter (1000 cm3) - slightly more than a quart. With serious rationing, humans can live on as little as 3 or so liters a day, but in your everyday life you probably use at least 50 (and that's if you shower quickly and use low-volume toilets).
This is why recycling water is so vital on spacecraft and space stations, and is also part of why being able to extract water is nearly essential to any even somewhat self-sufficient extraterrestrial base (never mind colony or town) we want to establish.
I really wish snprintf was available on my C implementation.
Leaving aside the question of what implementation of C *doesn't* have the safer string functions, there are a still lots of better ways to do that.
For starters, you could implement your own snprintf(). It's not a trivial function, but if you use it that much... if your library is LGPL-compatible, you could also use the implementation in glibc. Alternatively, if you have the other safe string functions, such as strncat(), you could use them. It's a couple extra lines of code, but I'm pretty sure it actually takes less time to execute if you're worried about that. Finally, you could just bounds-check the arguments, using strlen() or similar.
I relaize this is a story about the terrible hacks we've all used from time to time, but please, there's no valid excuse for trivially-exploitable buffer overflow vulnerabilities.
ActiveX is just a binary plugin API, much like the Netscape plugin API used by all other browsers (this is how Flash and Java applets are supported).
The problem with ActiveX historically was that sites could install ActiveX controls too easily. This has been fixed for years now. The problem with ActiveX today is when a website has an exploit for a pre-installed plug-in (allowing the site to change stuff on the system). This also happens with Flash and Java on Firefox/Opera/Safari/Konquror/random_other_browser_using_nsplugin_api. Such is the life.
Windows ships both PAE and non-PAE kernels, just like most Linux distros. The bootloader selects which binary to run at boot time.
If you use PAE mode, the motherboard can potentially remap that "hidden" RAM to a higher physical address, so that you can use it.
The issue here is that the driver for that re-mapped RAM must support 64-bit pointers (well, technically it must support 36-bit pointers, but practically speaking 64-bit addresses are used and the high 28 bits are ignored). Many legacy Windows drivers (and some legacy Linux drivers) don't support this, and will crash when a pointer overwrites the memory following its 32-bit expected width.Driver crashes are a Bad Thing, so to avoid the danger, client versions of Windows use 32-bit pointers even in PAE mode. This means the (not-even-quite) 4GB limit is still in force, but means you can use legacy drivers. Server editions of Windows permit you to use the full address width (it's a different HAL, I believe)on the assumption that any driver you use on a server will be well-coded and adhere to the guidelines that allow PAE to work.
Client versions of Win32 will enable PAE to get the NX bit, but the HAL will block access above 4GB. This is because many drivers used on consumer (client) versions of Windows are not designed to be able to handle 64-bit pointers (even though PAE addresses are only 36 bits, pointers are 64 bits wide anyhow). The way to support this is to compile your driver such that all pointers are *assumed* to be 64 bits wide, and let the high 32 bits go to waste on a non-PAE system. This behavior is required for Microsoft driver signing on newer versions of Windows, but there are a lot of older Windows drivers out there which lack this assumption. Those drivers will explode in an ugly manner if the memory manager hands then a 64-bit address, so only 32-bit addresses are used.
Out of curiosity, what apps are those (that "are not yet compatible")? Unless it needs a kernel-mode driver for some reason, a 32-bit application shouldn't even know if it's on a 32-bit or 64-bit OS unless it specifically checks for whatever reason. True, 64-bit programs can't use 32-bit libraries (and vice versa), but that's why Windows ships with 32-bit versions of all the public DLLs.
Also, WHQL (driver certification) for Vista requires 64-bit drivers, not just Server 2008.
Completely incorrect. Very few 32-bit (user-space) apps will care. Some software (such as antivirus) includes drivers, and those do care (kernel-mode code has to be the same number of bits as the kernel itself) but outside of that extreme minority (most of which have been ported to x64 anyhow) user-mode software is fine. Windows x64 includes both 32-bit and 64-bit libraries, 32-bit programs can invoke 64-bit programs and vice-versa, and for plug-ins that are 32-bit only (Adobe Flash being a well-known example - no 64-bit version for Windows yet) Microsoft includes 32-bit versions of many programs (such as IE).
Of the 30-odd standard user (not System) processes running on my Windows 7 x64 machine right now, the majority (75%-ish) have the "*32" in Task Manager, indicating a 32-bit process. Exclude those programs that are from Microsoft (such as cmd.exe) and that percentage rises to nearly 100% - the only 64-bit third party apps I'm running are for my video driver and printer (no AV installed). I play 32-bit games, run 32-bit software development tools, browse the web with 32-bit Firefox, Opera, Chrome, and such (with 32-bit Flash and Foxit Reader), IM/video chat using 32-bit Pidgin, Skype, and Google Talk, connect to *nix boxes using a 32-bit ssh client and forward the remote programs to my 32-bit X11 server, run scripts on 32-bit perl and python binaries... you get the picture.
It's true that 16-bit programs won't run, but that's about it. For those, you can either emulate a 16-bit CPU (DOSbox) or virtualize a 32-bit OS (such as Win7's "Virtual XP Mode").
Oh, and before you ask, yes I use Linux too (just not at the moment). Plenty of 32-bit on there too, although not as much (since somebody has ported almost every open-source app to 64-bit).
The RPG-style leveling thing wasn't available in SC1 at all - you could only do it by replacing the player unit entirely. Similarly, there was no inventory.
Nothing I've yet heard about SC2 suggests that SC2 will have these elements (which were critical to making DotA what it is). Mind you, I'm unsure how much longer DotA itself will last. Try Heroes of Newerth, for example, and you'll see what you can really do when you have a game/game engine designed from the ground up for DotA-style gaming.
True, and worth mentioning that Win7's handwriting recognition is better than Vista's. It can literally figure out things that I wrote without looking, and that I would have a very difficult time reading if I just looked at it unaided (my handwriting sucks to begin with, but I can usually read my own writing at least).
For classes, and probably for business meetings, OneNote is close to being a killer app for tablets. I'd like to see what they do to it in Office 2010 - the current version is good but could use a bit of work in some places - but I have tons of notes on it already, with hand-drawn diagrams, highlighting, snippets from other programs pasted in, and tons of handwritten annotations (the notes themselves are mostly handwritten too, but occasionally typed). The search feature can index the handwriting and find the stuff I'm looking for, which compared to traditional notebooks is a HUGE boon.
What really surprises me is lack of video over MSN, since Kopete (Konqueror's built-in IM client, which is in many ways comparable to Pidgin) has had MSN video chat for (about?) 2 years now, maybe longer. Both are open source, and while I'm not sure what Kopete's license is, surely they could share specifications even if they can't share code?
To the best of my knowledge, nobody has been getting "special demo machine[s]" with Win7. It's hardware requirements are pretty easily met by any desktop and the vast majority of laptops from the last 2 years, even including many netbooks. You can build a new computer for about $500 that will exceed Win7's requirements in every aspect by at least a factor of 2x, but honestly you probably don't need to. Hell, I've got a severely underpowered (ultra-low voltage, essentially extreme underclocking) tablet PC, and Win7 runs fantastically on it.
Just a tip: you can run (and build) POSIX apps (including bash, ssh/sshd, svn, gcc, and even things like httpd or window managers) in Windows without Cygwin. There's a POSIX-compliant subsystem for the NT kernel (just as the Win32 API that people are used to is implemented as a subsystem on top of NT). It's only available in the higher Windows editions, but it's faster and better integrated than Cygwin, and avoids a lot of Cygwin's silly restrictions (executables needing a.exe or similar extension, for example).
The subsystem is called SUA (Subsustem for UNIX Applications) and is enabled from the "Turn Windows features on or off" window (you can find it using Start search). To use it you'll want to install Interix, a basic operating environment that includes a couple shells, a collection of standard utilities, and a working build toolchain. The link to download this will be in the Start menu after enabling SUA, or you can find it online. Once you've got Interix installed, you can install a package manager and a bunch of pre-compiled binaries (including all the ones listed above, and hundreds more) from http://suacommunity.com/ (you can also get a more detailed version fo these instructions there). It will also offer to install an X server, which is handy if you want to run graphical apps locally or from a server.
For the record, I'm not officially associated with Interix or suacommunity.com in any way aside from being a forum member on the latter, but I've found this little-known feature of Windows to be one well-worth telling people about.
True. Of course, this is also true in Vista... none of the people I've met who say they don't use vista on account of DRM could ever point to anything specific that this supposedly draconian DRM prevented, but they were very insistent about its existence. I don't deny that there is DRM in Vista (and Win7) that XP lacked, but I've yet to have said DRM prevent me from doing something that worked previously. Instead, they just added support for playing the highly DRMed HD video media.
Now, I can't personally speak on subjects like Blu-Ray or such (aside from that fact that you'll probably never be able to legally play them on XP in the USA), but Vista (and Win7) quite happily play CDs, DVDs, ripped MP3 and WMA (and in Win7's case, it ships with AAC/M4A codecs and mpeg4/MOV codecs as well, which is a welcome change). I don't personally rip DVDs but folks I know who do have shown that playing them works just fine too. Media Center is great for recording and timeshifting TV shows, and they can also be placed on compatibile personal media players to take with you on the go. I've never noticed video or audio degradation, and everything that I expect to be able to do still works just fine.
Regarding drivers, nVidia's drivers were the only part of my Vista system (RC1 to nearly 6 months after RTM) that were anything but rock-solid stable. They crashed (fortunately Vista could restart them without bringing down the OS, but still) and that was after a number of the features were intentionally disabled. Granted, this was on a laptop, but their desktop drivers were almost as bad.
By comparison, at Vista's beta 2, their drivers were already completely solid and provided all the features I expected. Sure, wayyyy back in the day ATi drivers were crap, but on a modern system I'd much prefer ATi drivers over nVidia. Hell, even today on my Win7 RC system, the nVidia driver *claims* to support PhysX, but it doesn't actually *work* when software tries to use it. I'm afraid nVidia has lost all claim to the "superior drivers" card in my book.
Java and.NET are both just-in-time compiled to native code. The per-machine optimizations this permits means that the resulting code is actually sometimes faster than a generic i386 (or generic ARM) binary produced by the best optimizing compiler in the world. JIT compilation takes a moment when the program first starts, but then (at least in the case of.NET) the native binary is stored for future use. In the case of a background service, you wouldn't even notice the difference.
Oh, and "fake login screen" is a relativley easy one to deal with, that's why Windows used to require Ctrl-Alt-Delete before login. It's also difficult to script the creation of really convincing login screen without relying on having Admin privileges, although I'll admit I haven't really tried (some of the registry keys that I'm pretty sure you'd need aren't available to non-Administrators).
Not all people can afford even a $200 laptop, yet schools even 10 years ago required that some assignments be done using a computer. There are libraries and such, but realistically speaking, if you have a computer and your kid needs it "for school" you (the average parent) are going to let him or her use it.
THere's also the Encrypting File System (although I think it's not available on Home versions of Windows, which is too bad). Right-click a file or folder, select Encrypt, and no other user account (even other Administrators, unless the system is configured to allow this when the files were encrypted) will be able to read them. Of course, you ahve to make sure that your kids aren't running LimeWire on your account... but then, frankly you should brobably just be making sure that your kids aren't doing anything (with LimeWire or any otehr software) that's going to get you in *any* kind of trouble.*
* Yes, I realize the average parent isn't competant to do this. That's a problem that, aside from education, I'm not sure how to solve - the only other approach I can imagine is some kind of Internet license that, like a driver's license, you must be a certain age and have demonstrated a certain competancy to posess (and if you're found using the system without a license, you go to prison). Since I really doubt the second system is going to fly, something should be done about fixing the root of the problem.
I thought most US-based distros already don't include DeCSS libraries in their official repos. Most of them will make it pretty easy for you to get the libs ("Want to play DVDs? Click here to find out how you can"), but you have to get them from some third-party repository yourself.
Not sure... CSS consists of rules which are applied based on tags in the document. This patent seems to apply to rules which are based on locations (offsets or pointers) into a document (where the document contains only the text and possibly other "pure content").
Yes and no. The way you work around string formatting bugs (aside from not passing a user-supplied string to the format parameter of printf, which is simply a bonehead mistake) is to verify the number of parameters before outputting anything. You can actually do this in C, but most C libraries don't seem to bother - they assume that however many parameters the format string calls for are there, and will happily work their way down the stack until the format string ends or they try to read/write somewhere impossible and get a memory violation. Most higher-level languages do in fact check for this, and will throw an exception if the format string and number of parameters don't match.
You can also take the MS libc approach, and disable %n (the only extremely dangerous, and coincidentally very rarely used, format token) by default. If you want to use it, there's a compiler option to re-enable it, but by default you're... less unsafe than, for example, glibc.
Try some other printf tokens, like %d or %s. If they're really passing the SMS text to printf as the format string, these should produce interesting output.
Out of curiosity, do you know what the bug is? It's pretty obvious - %n is a printf format symbol that says "treat the next parameter as int*, and write the number of characters printed thus far to that location." Because of the way most C libraries work, this will work even if there *is* no next parameter. The next thing on the stack (or in the next argument register, depending on platform and calling convention) might be something highly valuable, like the function's stored return address. Even if it's nothing at all - a NULL, for example - this is still exploitable. Simply put a %d in the SMS before your %n, and you'll skip over that parameter until you get to a juicier one.
Depending upon the implementation, you can even use this to overwrite a single byte of memory, rather than a full word. SMS has a character limit, but if it's really parsing printf symbols, you can take advantage of that to cause the program to print a fairly arbitrary number of characters - certainly far above the 256 needed to write any value into a memory location. With that kind of control and a little assembly knowledge, you probably write directly into the program's memory space. Exploiting that is trivial.
Yes, I've done this. Not with SMS and not maliciously, but as a university project where we were given a shellcode and a program that contained a printf where the user could influence the format string. It was the work of maybe 3 hours to override a couple of key bytes in memory and trigger execution of the shellcode. If you want to use printf with a user-supplied string, the format string must always be "%s" and the user-supplied string should be the next parameter. Parsing user input *as* the format string will just get you exploited.
That said, MS disables the %n format code by default - if you want to use it legitimately in their C compiler, there's an option you need to set.
Slashdot Mirror
Also, for those who have trouble remembering their metric units and conversions, a kilo of water (at room temperature) is 1 liter (1000 cm3) - slightly more than a quart. With serious rationing, humans can live on as little as 3 or so liters a day, but in your everyday life you probably use at least 50 (and that's if you shower quickly and use low-volume toilets).
This is why recycling water is so vital on spacecraft and space stations, and is also part of why being able to extract water is nearly essential to any even somewhat self-sufficient extraterrestrial base (never mind colony or town) we want to establish.
Eh, MS still gets money for the licenses of those virtualized systems. I doubt they're *too* upset over it.
A NT filesystem driver more recent that EXT2 would be nice, for a start.
Leaving aside the question of what implementation of C *doesn't* have the safer string functions, there are a still lots of better ways to do that.
For starters, you could implement your own snprintf(). It's not a trivial function, but if you use it that much... if your library is LGPL-compatible, you could also use the implementation in glibc.
Alternatively, if you have the other safe string functions, such as strncat(), you could use them. It's a couple extra lines of code, but I'm pretty sure it actually takes less time to execute if you're worried about that.
Finally, you could just bounds-check the arguments, using strlen() or similar.
I relaize this is a story about the terrible hacks we've all used from time to time, but please, there's no valid excuse for trivially-exploitable buffer overflow vulnerabilities.
ActiveX is just a binary plugin API, much like the Netscape plugin API used by all other browsers (this is how Flash and Java applets are supported).
The problem with ActiveX historically was that sites could install ActiveX controls too easily. This has been fixed for years now.
The problem with ActiveX today is when a website has an exploit for a pre-installed plug-in (allowing the site to change stuff on the system). This also happens with Flash and Java on Firefox/Opera/Safari/Konquror/random_other_browser_using_nsplugin_api. Such is the life.
Good post. Two quick points, though:
Windows ships both PAE and non-PAE kernels, just like most Linux distros. The bootloader selects which binary to run at boot time.
The issue here is that the driver for that re-mapped RAM must support 64-bit pointers (well, technically it must support 36-bit pointers, but practically speaking 64-bit addresses are used and the high 28 bits are ignored). Many legacy Windows drivers (and some legacy Linux drivers) don't support this, and will crash when a pointer overwrites the memory following its 32-bit expected width.Driver crashes are a Bad Thing, so to avoid the danger, client versions of Windows use 32-bit pointers even in PAE mode. This means the (not-even-quite) 4GB limit is still in force, but means you can use legacy drivers. Server editions of Windows permit you to use the full address width (it's a different HAL, I believe)on the assumption that any driver you use on a server will be well-coded and adhere to the guidelines that allow PAE to work.
Client versions of Win32 will enable PAE to get the NX bit, but the HAL will block access above 4GB. This is because many drivers used on consumer (client) versions of Windows are not designed to be able to handle 64-bit pointers (even though PAE addresses are only 36 bits, pointers are 64 bits wide anyhow). The way to support this is to compile your driver such that all pointers are *assumed* to be 64 bits wide, and let the high 32 bits go to waste on a non-PAE system. This behavior is required for Microsoft driver signing on newer versions of Windows, but there are a lot of older Windows drivers out there which lack this assumption. Those drivers will explode in an ugly manner if the memory manager hands then a 64-bit address, so only 32-bit addresses are used.
Out of curiosity, what apps are those (that "are not yet compatible")? Unless it needs a kernel-mode driver for some reason, a 32-bit application shouldn't even know if it's on a 32-bit or 64-bit OS unless it specifically checks for whatever reason. True, 64-bit programs can't use 32-bit libraries (and vice versa), but that's why Windows ships with 32-bit versions of all the public DLLs.
Also, WHQL (driver certification) for Vista requires 64-bit drivers, not just Server 2008.
Completely incorrect. Very few 32-bit (user-space) apps will care. Some software (such as antivirus) includes drivers, and those do care (kernel-mode code has to be the same number of bits as the kernel itself) but outside of that extreme minority (most of which have been ported to x64 anyhow) user-mode software is fine. Windows x64 includes both 32-bit and 64-bit libraries, 32-bit programs can invoke 64-bit programs and vice-versa, and for plug-ins that are 32-bit only (Adobe Flash being a well-known example - no 64-bit version for Windows yet) Microsoft includes 32-bit versions of many programs (such as IE).
Of the 30-odd standard user (not System) processes running on my Windows 7 x64 machine right now, the majority (75%-ish) have the "*32" in Task Manager, indicating a 32-bit process. Exclude those programs that are from Microsoft (such as cmd.exe) and that percentage rises to nearly 100% - the only 64-bit third party apps I'm running are for my video driver and printer (no AV installed). I play 32-bit games, run 32-bit software development tools, browse the web with 32-bit Firefox, Opera, Chrome, and such (with 32-bit Flash and Foxit Reader), IM/video chat using 32-bit Pidgin, Skype, and Google Talk, connect to *nix boxes using a 32-bit ssh client and forward the remote programs to my 32-bit X11 server, run scripts on 32-bit perl and python binaries... you get the picture.
It's true that 16-bit programs won't run, but that's about it. For those, you can either emulate a 16-bit CPU (DOSbox) or virtualize a 32-bit OS (such as Win7's "Virtual XP Mode").
Oh, and before you ask, yes I use Linux too (just not at the moment). Plenty of 32-bit on there too, although not as much (since somebody has ported almost every open-source app to 64-bit).
The RPG-style leveling thing wasn't available in SC1 at all - you could only do it by replacing the player unit entirely. Similarly, there was no inventory.
Nothing I've yet heard about SC2 suggests that SC2 will have these elements (which were critical to making DotA what it is). Mind you, I'm unsure how much longer DotA itself will last. Try Heroes of Newerth, for example, and you'll see what you can really do when you have a game/game engine designed from the ground up for DotA-style gaming.
True, and worth mentioning that Win7's handwriting recognition is better than Vista's. It can literally figure out things that I wrote without looking, and that I would have a very difficult time reading if I just looked at it unaided (my handwriting sucks to begin with, but I can usually read my own writing at least).
For classes, and probably for business meetings, OneNote is close to being a killer app for tablets. I'd like to see what they do to it in Office 2010 - the current version is good but could use a bit of work in some places - but I have tons of notes on it already, with hand-drawn diagrams, highlighting, snippets from other programs pasted in, and tons of handwritten annotations (the notes themselves are mostly handwritten too, but occasionally typed). The search feature can index the handwriting and find the stuff I'm looking for, which compared to traditional notebooks is a HUGE boon.
What really surprises me is lack of video over MSN, since Kopete (Konqueror's built-in IM client, which is in many ways comparable to Pidgin) has had MSN video chat for (about?) 2 years now, maybe longer. Both are open source, and while I'm not sure what Kopete's license is, surely they could share specifications even if they can't share code?
To the best of my knowledge, nobody has been getting "special demo machine[s]" with Win7. It's hardware requirements are pretty easily met by any desktop and the vast majority of laptops from the last 2 years, even including many netbooks. You can build a new computer for about $500 that will exceed Win7's requirements in every aspect by at least a factor of 2x, but honestly you probably don't need to. Hell, I've got a severely underpowered (ultra-low voltage, essentially extreme underclocking) tablet PC, and Win7 runs fantastically on it.
Just a tip: you can run (and build) POSIX apps (including bash, ssh/sshd, svn, gcc, and even things like httpd or window managers) in Windows without Cygwin. There's a POSIX-compliant subsystem for the NT kernel (just as the Win32 API that people are used to is implemented as a subsystem on top of NT). It's only available in the higher Windows editions, but it's faster and better integrated than Cygwin, and avoids a lot of Cygwin's silly restrictions (executables needing a .exe or similar extension, for example).
The subsystem is called SUA (Subsustem for UNIX Applications) and is enabled from the "Turn Windows features on or off" window (you can find it using Start search).
To use it you'll want to install Interix, a basic operating environment that includes a couple shells, a collection of standard utilities, and a working build toolchain. The link to download this will be in the Start menu after enabling SUA, or you can find it online.
Once you've got Interix installed, you can install a package manager and a bunch of pre-compiled binaries (including all the ones listed above, and hundreds more) from http://suacommunity.com/ (you can also get a more detailed version fo these instructions there). It will also offer to install an X server, which is handy if you want to run graphical apps locally or from a server.
For the record, I'm not officially associated with Interix or suacommunity.com in any way aside from being a forum member on the latter, but I've found this little-known feature of Windows to be one well-worth telling people about.
True. Of course, this is also true in Vista... none of the people I've met who say they don't use vista on account of DRM could ever point to anything specific that this supposedly draconian DRM prevented, but they were very insistent about its existence. I don't deny that there is DRM in Vista (and Win7) that XP lacked, but I've yet to have said DRM prevent me from doing something that worked previously. Instead, they just added support for playing the highly DRMed HD video media.
Now, I can't personally speak on subjects like Blu-Ray or such (aside from that fact that you'll probably never be able to legally play them on XP in the USA), but Vista (and Win7) quite happily play CDs, DVDs, ripped MP3 and WMA (and in Win7's case, it ships with AAC/M4A codecs and mpeg4/MOV codecs as well, which is a welcome change). I don't personally rip DVDs but folks I know who do have shown that playing them works just fine too. Media Center is great for recording and timeshifting TV shows, and they can also be placed on compatibile personal media players to take with you on the go. I've never noticed video or audio degradation, and everything that I expect to be able to do still works just fine.
Regarding drivers, nVidia's drivers were the only part of my Vista system (RC1 to nearly 6 months after RTM) that were anything but rock-solid stable. They crashed (fortunately Vista could restart them without bringing down the OS, but still) and that was after a number of the features were intentionally disabled. Granted, this was on a laptop, but their desktop drivers were almost as bad.
By comparison, at Vista's beta 2, their drivers were already completely solid and provided all the features I expected. Sure, wayyyy back in the day ATi drivers were crap, but on a modern system I'd much prefer ATi drivers over nVidia. Hell, even today on my Win7 RC system, the nVidia driver *claims* to support PhysX, but it doesn't actually *work* when software tries to use it. I'm afraid nVidia has lost all claim to the "superior drivers" card in my book.
Java and .NET are both just-in-time compiled to native code. The per-machine optimizations this permits means that the resulting code is actually sometimes faster than a generic i386 (or generic ARM) binary produced by the best optimizing compiler in the world. JIT compilation takes a moment when the program first starts, but then (at least in the case of .NET) the native binary is stored for future use. In the case of a background service, you wouldn't even notice the difference.
Oh, and "fake login screen" is a relativley easy one to deal with, that's why Windows used to require Ctrl-Alt-Delete before login. It's also difficult to script the creation of really convincing login screen without relying on having Admin privileges, although I'll admit I haven't really tried (some of the registry keys that I'm pretty sure you'd need aren't available to non-Administrators).
Sorry for the double-post.
Not all people can afford even a $200 laptop, yet schools even 10 years ago required that some assignments be done using a computer. There are libraries and such, but realistically speaking, if you have a computer and your kid needs it "for school" you (the average parent) are going to let him or her use it.
THere's also the Encrypting File System (although I think it's not available on Home versions of Windows, which is too bad). Right-click a file or folder, select Encrypt, and no other user account (even other Administrators, unless the system is configured to allow this when the files were encrypted) will be able to read them. Of course, you ahve to make sure that your kids aren't running LimeWire on your account... but then, frankly you should brobably just be making sure that your kids aren't doing anything (with LimeWire or any otehr software) that's going to get you in *any* kind of trouble.*
* Yes, I realize the average parent isn't competant to do this. That's a problem that, aside from education, I'm not sure how to solve - the only other approach I can imagine is some kind of Internet license that, like a driver's license, you must be a certain age and have demonstrated a certain competancy to posess (and if you're found using the system without a license, you go to prison). Since I really doubt the second system is going to fly, something should be done about fixing the root of the problem.
I thought most US-based distros already don't include DeCSS libraries in their official repos. Most of them will make it pretty easy for you to get the libs ("Want to play DVDs? Click here to find out how you can"), but you have to get them from some third-party repository yourself.
Not sure... CSS consists of rules which are applied based on tags in the document. This patent seems to apply to rules which are based on locations (offsets or pointers) into a document (where the document contains only the text and possibly other "pure content").
Yes and no. The way you work around string formatting bugs (aside from not passing a user-supplied string to the format parameter of printf, which is simply a bonehead mistake) is to verify the number of parameters before outputting anything. You can actually do this in C, but most C libraries don't seem to bother - they assume that however many parameters the format string calls for are there, and will happily work their way down the stack until the format string ends or they try to read/write somewhere impossible and get a memory violation. Most higher-level languages do in fact check for this, and will throw an exception if the format string and number of parameters don't match.
You can also take the MS libc approach, and disable %n (the only extremely dangerous, and coincidentally very rarely used, format token) by default. If you want to use it, there's a compiler option to re-enable it, but by default you're... less unsafe than, for example, glibc.
Try some other printf tokens, like %d or %s. If they're really passing the SMS text to printf as the format string, these should produce interesting output.
Out of curiosity, do you know what the bug is? It's pretty obvious - %n is a printf format symbol that says "treat the next parameter as int*, and write the number of characters printed thus far to that location." Because of the way most C libraries work, this will work even if there *is* no next parameter. The next thing on the stack (or in the next argument register, depending on platform and calling convention) might be something highly valuable, like the function's stored return address. Even if it's nothing at all - a NULL, for example - this is still exploitable. Simply put a %d in the SMS before your %n, and you'll skip over that parameter until you get to a juicier one.
Depending upon the implementation, you can even use this to overwrite a single byte of memory, rather than a full word. SMS has a character limit, but if it's really parsing printf symbols, you can take advantage of that to cause the program to print a fairly arbitrary number of characters - certainly far above the 256 needed to write any value into a memory location. With that kind of control and a little assembly knowledge, you probably write directly into the program's memory space. Exploiting that is trivial.
Yes, I've done this. Not with SMS and not maliciously, but as a university project where we were given a shellcode and a program that contained a printf where the user could influence the format string. It was the work of maybe 3 hours to override a couple of key bytes in memory and trigger execution of the shellcode. If you want to use printf with a user-supplied string, the format string must always be "%s" and the user-supplied string should be the next parameter. Parsing user input *as* the format string will just get you exploited.
That said, MS disables the %n format code by default - if you want to use it legitimately in their C compiler, there's an option you need to set.