You can't hook into the filesystem and hide. If you do, you run the risk of being overwritten. The filesystem HAS to know what is on the disk and where. Yes, you can hook into the filesystem and hide, without being overwritten. Lots of methods: 1) You can mark your blocks as used in the free bitmap but not link to them, and hope the user doesn't run chkdsk (which will 'fix' this problem). 2) You can have the filesystem itself skip over your directory entry when the generic FS layer asks. 3) You can have the filesystem claim the disk is smaller than it is, and use the blocks at the end to store data. 4) etc
Not hard at all. You don't neccecarily even need to do that much - you may not care about being overwritten. If you stick yourself near the end of a huge chunk of free disk space, it may be months or years before that space gets allocated, and if the only reason you're there is to use the machine as a spam zombie or something, then it may not even be worth protecting yourself from being overwritten when that day comes, as hey, just infect the machine again, or rely on the fact that there are plenty more. Even if you do let the FS know about your existence, that doesn't mean it has to report that fact to the generic FS layer when it asks. Disk space allocation is an FS-specific issue and the layers above don't give a damn about it.
All you can do is trick everything above the filesystem layer that you aren't really there. The question I've asked someone else who has raised this, is how the administrative share works on Windows. Does the admin share operate at a lower level than standard "user" shares, and hook straight into the file system? Nope, it's not special at all. Shares ending with a $ cannot be enumerated remotely, and the 'admin' shares cannot be deleted or have their permissions changed via the user interface (though they can still be blown away by tweaking the registry a bit and hoping the Server service doesn't put them back), but are otherwise identical to normal shares. If your rootkit is lying to the OS at the filesystem or kernel level, it will be invisible through these too.
If it uses the API on the remote machine in any way, then my method is clearly flawed. There is no (non-terrifying) way to access the contents of a filesystem of a running Windows instance other than via its filesystem API. Windows will not let you open the disk for raw access while it is mounted (for obvious reasons). You can bypass this by installing a custom device driver but it's easier to just boot BartPE;)
Usermode rootkits cannot do most of these things, and may well be visible over network shares (due to the difference in user account used to access the disk), but any rootkit which is allowed to run as administrator can install itself into kernel memory quite trivially and do all kinds of amusing things. Techniques exist to make the presence of malicious kernel memory modifications effectively invisible (see the last issue of Phrack for one discussion) and there is absolutely no dependable way to scan for them without shutting the machine down and booting into a known-clean, ideally-read-only operating system instance.
One problem. ID (in its best form) does not give any characteristic to the creator(s) other than "intelligent", and perhaps mastery of technology or the laws of the universe. Thus, FSM and God are interchangable, and they are really the same thing as far as ID is concerned. FSM is just a specific variation of the concept.
ID advocates may claim that, in order to attempt to make it look 'sciencey'. But, if you propose a Flying Spaghetti Monster instead of a traditional vaguely Christian god, they will quickly look the other way and come up with reasons why that's preposterous. The FSM serves to demonstrate that ID advocates are not interested in putting forth an alternate scientific theory as to how things came about, but are solely interested in advocating a particular religious doctrine as being truth.
But, what I find interesting is that Windows will use my pagefile WAY sooner and more frequently than Linux (or FreeBSD for that matter) does. And it's not cause I'm out of physical memory in Windows...From just a cursory glance this would make it seem like Windows is more intelligent about putting infrequently used portions of memory into the pagefile while Linux just uses physical memory until it runs out and then switch to the swap space.
Yes, the theory is exactly this. Any NT-based Windows swaps stuff early in order to make room for as big a disk cache as it can manage - it's tunable behaviour, though don't ask me which thousand bajillion obscure registry settings it is;)
The tradeoff between keeping stuff paged in, and enlarging the disk cache, is a hard one to calculate, and Linux and Windows can both be tuned to behave differently. The defaults (and in fact algorithms) differ wildly, which results in the difference you see. Which is 'better' depends on too many factors to give a straight answer - it's probably too hard to directly compare the relevant metrics (page faults vs disk cache misses) because it's hard to reproduce the same load across different OSes.
I've looked into which pages are resident and which aren't in Windows (though I've not done the same in Linux) using the kernel debugger, and it doesn't seem to be making too many stupid choices - my system, under either OS, has quite a lot of stuff loaded that I'm not actually using right this minute. Starting various desktop apps to get the total memory consumption to be vaguely similar, and then seeing how much gets swapped out while I use it (an extremely unscientific test, but hey) shows Windows using a much larger disk cache, i.e. making do with less resident pages, and neither were significantly slow to respond. But, this doesn't really say much, as the conditions were totally uncontrolled.
So, err, what you describe is more or less the defaults, but whether changing it will help or not, or which strategy is superior, I have no idea;)
They do, actually - the 'swipe' section of the cashier's terminal has been augmented with a smartcard reader at the bottom. So, the cashier swipes the card, it reads the magstripe, and when it gets to the bottom of its travel it clicks into place in the smartcard reader. The chip and pin keypad then acts as just a display/keypad, leaving the reading to be done by the cashier's terminal. The cashiers are not supposed to let the customer put the card into the customer-facing terminal (some even have the card slot on that terminal covered). I have absolutely no idea why.
It doesn't really make it much easier to mount a man-in-the-middle attack - if you are determined enough to install something inline in the cable connection, you are probably determined enough to install something inside the customer-facing terminal anyway (as the terminals are not made to be secure against physical intrusion). It still seems stupid, but it's not the end of the world.
Far more pressing problems with chip and pin would be modifying terminals such that they, say, display a different amount on the screen to the amount they are authorising, or that power cycle the card and replay the user's pin to authorise a second transaction.. these attacks are not really made easier by the separation.
This is true, but the quoted speed is not the nominal speed. 100BaseTX uses a 5-bit Manchester code to send 4 bits of information, which means that yes, it only gets 80% of the actual line speed. However, the actual line speed is 125Mbit/s - thus, you really do potentially get 100Mbit/s. With fully switched ethernet, on decent, fast switches, you can attain well over 95% of that speed in actual use. My server hits a sustained 96.5Mbit/s when I pull files off it over ftp, for example.
No, the RSA encryption on the DS is not used to secure the actual wireless communications, but only to secure wireless download play (when you play multiplayer over wifi with only one cartridge between you). The code sent over wifi to multiboot all the DSes that don't have a cartridge is RSA signed, and an unmodified DS will refuse to run multiboot code that does not pass the signature check.
Once the DS has been booted, either by multiboot or by having a cartridge inserted, the 'RSA Secured' is irrelevant, and any security which is then used is only whatever security the game developer has put into their software, usually zero.
The device Nintendo are proposing here basically seems to be nothing more than an access-point mode USB wifi adapter, possibly with some software to configure Windows' connection sharing. It will work just as well with any standard wifi router/access point, as far as anyone can tell (online DS games soon to be released, such as Animal Crossing DS, are being promoted as working at any wifi hotspot, something that wouldn't happen if they used some Nintendo proprietary 'thing').
Speculation: They didn't make a router that connects with a cat5 cable because these days a lot of people have all-in-one wireless router/broadband/everything boxes anyway, and probably most of the people who don't already have some kind of solution to this, integrated or otherwise, only have their broadband connected to a single PC. They could've built this functionality into the Revolution, making it an access point in its own right and giving it an ethernet port, but it's cheaper not to, I guess, especially if my speculation is true.
The DS uses 802.11b, perfectly standard. The Revolution may be 11b or 11g, I don't know, but will also be standard. What's nonstandard is that the DS (and presumably the Revolution when talking to the DS) does not use IP over the top of 802.11b, but a custom layer 3 protocol. When being used for online play, it will use IP, the same as everything else (otherwise it won't be able to talk to the Internet), and there is absolutely no suggestion whatsoever that it will not work with a standard wifi access point. Animal Crossing DS is being marketed as working with any wifi hotspot.
The 'Ni-fi' referred to on DS hacking sites is the layer 3 protocol used by the DS above standard 802.11b, it's not meant to imply that it's not standard wifi.
Actually, you can burn Cube games on standard 8cm DVD-R disks just fine, and they will work perfectly once booted through one of the alternate BIOSes (Cobra/Anaconda/GCOS). You don't even need a modchip; the Action Replay exploit or the PSO exploit can be used to boot Anaconda or GCOS entirely in software.
You can even burn them on ordinary 12cm DVD-Rs if you take the top off the cube so that 12cm ones fit..
The token expiring was a bug, and was fixed months ago; offline mode now lasts forever. The other issue is still present though; you 'lose' offline mode if Steam is able to connect to the servers at all, whether it succeeds in authenticating or not.
I run Windows XP SP2, I download huge amounts of P2P media and warez, have no antivirus or antispyware running permanently, and have no application-level firewall (i.e. all outgoing connections are allowed), though I am behind a Linux firewall (non-NAT, my Windows box has a public IP, but the Linux box filters incoming connections to be to known services only). I occasionally run the latest version of whatever antivirus/spyware tool people seem to be talking about this week, and they don't find anything. There aren't any processes, services, tray icons or toolbars running that I don't specifically recognise, and I've never had to remove anything because it turned out to be malicious.
Don't blame the warez; widely distributed warez is widely distributed because it *works*. A torrent with a high rating on a reg-required torrent site is unlikely to be laden with spyware; files grabbed from the original groups via IRC and compared to published checksums aren't trojanned, because the group would be found out in no time and would lose kudos (and get DoS'ed, probably, but hey).
My parents' machine stopped getting any kind of infection the second I switched them to Firefox and Thunderbird. They've not had a single problem since, even though they use P2P networks to get music, video and software.
Obviously not everyone has this experience, but every computer I've ever used has IE and OE as their sole infection vector of any note.;)
The one that pisses me off more than anything is the use of the word 'mentalist' as a noun form of 'mental', in describing someone who is doing something the speaker considers to be mad. "He's mental" becomes "He's a mentalist". Maybe it's just a UK thing, but it's very common..
It always makes me want to slap them and explain that a mentalist is someone who, perchance, might know WHICH CARD YOU ARE THINKING OF.;)
The author and copyright holder of the software distributes it under the GPL. He's trying to stop someone redistributing it, under the terms of the GPL. Buh.
Which means any application can alter USER.DAT in any way. If this file gets corrupted in certain ways a user may be either completly unable to log in or never get anywhere near having a usable desktop.
No, they can't, it's locked.
This appears to be a horribly complex way of doing what having multiple configuration files would do by default.
It's identical to having a filesystem - in fact, the registry can be regarded as a filesystem. To read a registry key you make a syscall with a path, it does permission checks, then it gives you the data if you're allowed - to read a file, you make a syscall with a path, it does permission checks, then it gives you the data if you're allowed. What's the difference?
Which makes the whole thing vulnerable to the machine being reset, especially a hard reset.
No, it's not vulnerable to that. Both registry hives are stored as transactioned databases - notice the.LOG next to each.DAT. They're written using the standard, safe, recoverable algorithms used by databases since the dawn of time. File-based configuration is only similarly protected if stored on a journalled FS (which admittedly most are these days).
I'm not trying to argue that the registry is better than having configuration files - I was simply pointing out that the original poster's argument was based on false premises. The *real* downsides of the registry are inherited from the downsides of Windows - inadequate access controls. If Windows apps stored their configuration in seperate files, then they'd *still* all be writable by the user (and thus by all the apps the user runs) simply because Windows doesn't have per-process access control. The same problem is reflected in the registry, but it's not having a registry that's causing the issue.
(note that Linux/BSD/Mac OS X/etc don't have per-process access control by default either.. Linux can have it added through the security hooks used by RSBAC/SELinux, or by GRSecurity - I don't know whether the same can be achieved on BSD..etc).
It also could be said that the Firefox 'extention' layer opens the world of spyware/hacks/security holes to lower-skilled script developers.
Unfortunately, yes, you're more or less right; malicious Firefox extensions can do an awful lot to compromise your system. You can execute arbitrary binaries as the user, for a start, though that is of course nonportable... if you'd like a cross-platform exploit, try sending their bookmarks, browsing history, cookies..etc over the 'net (just submit them to a webform somewhere - web browser extensions wouldn't be much use if they didn't have permission to, uhm, connect to web sites).
This is why Firefox, by default, will *not* allow you to install extensions or themes that aren't downloaded from update.mozilla.org - the extensions there are hopefully vetted by enough people that a malicious one would be caught.
Executing arbitrary binaries could be prevented (but is not, because it can be useful - see the IE View extension, for example) but the potential for abuse of the browser's internal API can't, really - removing the features that allow these things (ability to connect to websites, ability to read the user's bookmarks, etc) would pretty much break every single extension that exists;)
All users (and by extension all programs) need read-write access by default to a small number of files that are critical for system functioning: the Windows registry.
The user registry is kept in seperate files, one per user, stored in the user's home directory (their profile). The system registry is certainly not writeable or even readable by users - there are, rather, system calls which will retrieve the value of a key on your behalf, after checking the access control list associated with the registry key you are trying to read. Registry keys are protected by the same ACL system as the filesystem. Even the user registry has entries which are not writeable by the user, only by system components - just because the user can write to the file doesn't mean it will actually work if they try - it's permanently opened and locked by at least one system process if the user is logged on (Winlogon) and thus cannot be opened directly, only accessed via the appropriate API.
The rest of your points are valid, but the registry is not anywhere so vulnerable as you make out.
The AC is right; fewer studios make PC games because there is less money to be made. The number of illegal copies has *nothing to do* with lost profits - the vast majority of those copies are not lost sales as the copiers would not have bought the game.
I'm not justifying copying games and never was; I started the threat by stating that *I*, that is, me personally, would be flattered if something I had written was widely distributed, whether they were paying for it or not. I don't think it shows a lack of respect at all; people *playing* the game is the respect that I would desire. People buying it is simply lining some publisher's wallet even more.
Professional copiers and counterfeiters are making a profit from work they do not own. However, in Western countries, professional copiers and counterfeiters are for this very reason actively persecuted by law enforcement. Convince copyright protection organisations to crack down on for-profit distribution, rather than passing-copies-to-friends or downloading-something-random-online, and the developer's bottom lines will see much more benefit; the profit lost to bootleg sales is far, far more than the profit lost to casual piracy because the people who buy them, contrary to your assertion, typically *don't* realise they are counterfeit and believe they are supporting the developer. If the counterfeit copies were not available, many of them would be content to pay the retail price (or to wait for the second release and pay a reduced price, at least) for a legitimate copy. People who can recognise professionally counterfeited copies usually know where to download the same things for free (I mean, it's not hard), so why would they pay for a copy that's no more legit?
If you still think I'm trying to justify copying games, then I don't have anything more to say to you as you're clearly not listening.
How many game companies have gone out of business or had to downsize significantly for reasons directly traceable to copyright violation? I can't find an example; your statement's premise seems unlikely.
I've bought most of the games I play, even the ones I had downloaded months earlier, but the large majority of people who download games would not have bought it in the first place. Let's be generous and say that a flawless, unbeatable copy protection system would increase your sales by 50% (i.e. those relatively rare people who would get it for free if they could, but are willing to buy it if they can't copy it). Now, I don't know about you, but I'd rather skip the payrise and have ten times as many people playing my game by copying it.
If you can't make enough money because of piracy, then something has gone badly wrong with your business; you are not offering enough value in purchasing the game (give them more cool stuff; concept art prints are always good), or your publisher has set the price much too high (consider self-publishing, and let people copying your game *be* the marketing department), or your game just isn't worth buying in the first place (haha, you suck). None of these are the fault of the customers or the copyright violators.
It's yet another 'success' of the moderation system that my previous comment got modded flamebait. Oh well.
I'd love to see something I've worked on for 50+ hours a week for months on end being freely copied around; it would show that I've achieved something that's really worthwhile.
Nokia's proprietary OS is hard realtime. Symbian 8.[01]b and 9.x are hard realtime. Other manufacturers undoubtedly use them too, I just don't have first-hand experience with them.
Without hardware support it will do stack smash protection for the recompiled system binaries, and it might also make a nonexecutable stack segment using the same trick Solar Designer's Linux implementation does..
No, they don't, unfortunately. XP SP2 only adds NX functionality on AMD64 and Itanium, their marketing material just omits to mention this in order to make it sound more secure;)
Avoiding joint stereo makes quality worse, not better; unlike older encoders, LAME only uses mid/side for frames when it is a genuine benefit. If there is no correlation at all between left and right, LAME will not bother. This only works on LAME - other encoders follow the standard's mechanism for switching between mid/side and full stereo which is buggy;)
The RPOW server keeps a db of used tokens. To validate the token, instead of doing it locally as with the original hashcash system, you send it off to the RPOW server and if it's valid and has not been used before, it will send you back a new token of equivalent worth (which both tells you that the token you were given was valid, and allows you to use that token yourself to, say, send outgoing mail). This has the convenient side effect that people who receive at least as much email as they send (i.e. non-spammer, non-mailing-list-server machines) won't have to generate any tokens themselves, thus avoiding any delays to sending mail.
You can't hook into the filesystem and hide. If you do, you run the risk of being overwritten. The filesystem HAS to know what is on the disk and where.
;)
Yes, you can hook into the filesystem and hide, without being overwritten. Lots of methods:
1) You can mark your blocks as used in the free bitmap but not link to them, and hope the user doesn't run chkdsk (which will 'fix' this problem).
2) You can have the filesystem itself skip over your directory entry when the generic FS layer asks.
3) You can have the filesystem claim the disk is smaller than it is, and use the blocks at the end to store data.
4) etc
Not hard at all. You don't neccecarily even need to do that much - you may not care about being overwritten. If you stick yourself near the end of a huge chunk of free disk space, it may be months or years before that space gets allocated, and if the only reason you're there is to use the machine as a spam zombie or something, then it may not even be worth protecting yourself from being overwritten when that day comes, as hey, just infect the machine again, or rely on the fact that there are plenty more. Even if you do let the FS know about your existence, that doesn't mean it has to report that fact to the generic FS layer when it asks. Disk space allocation is an FS-specific issue and the layers above don't give a damn about it.
All you can do is trick everything above the filesystem layer that you aren't really there. The question I've asked someone else who has raised this, is how the administrative share works on Windows.
Does the admin share operate at a lower level than standard "user" shares, and hook straight into the file system?
Nope, it's not special at all. Shares ending with a $ cannot be enumerated remotely, and the 'admin' shares cannot be deleted or have their permissions changed via the user interface (though they can still be blown away by tweaking the registry a bit and hoping the Server service doesn't put them back), but are otherwise identical to normal shares. If your rootkit is lying to the OS at the filesystem or kernel level, it will be invisible through these too.
If it uses the API on the remote machine in any way, then my method is clearly flawed.
There is no (non-terrifying) way to access the contents of a filesystem of a running Windows instance other than via its filesystem API. Windows will not let you open the disk for raw access while it is mounted (for obvious reasons). You can bypass this by installing a custom device driver but it's easier to just boot BartPE
Usermode rootkits cannot do most of these things, and may well be visible over network shares (due to the difference in user account used to access the disk), but any rootkit which is allowed to run as administrator can install itself into kernel memory quite trivially and do all kinds of amusing things. Techniques exist to make the presence of malicious kernel memory modifications effectively invisible (see the last issue of Phrack for one discussion) and there is absolutely no dependable way to scan for them without shutting the machine down and booting into a known-clean, ideally-read-only operating system instance.
One problem. ID (in its best form) does not give any characteristic to the creator(s) other than "intelligent", and perhaps mastery of technology or the laws of the universe. Thus, FSM and God are interchangable, and they are really the same thing as far as ID is concerned. FSM is just a specific variation of the concept.
ID advocates may claim that, in order to attempt to make it look 'sciencey'. But, if you propose a Flying Spaghetti Monster instead of a traditional vaguely Christian god, they will quickly look the other way and come up with reasons why that's preposterous. The FSM serves to demonstrate that ID advocates are not interested in putting forth an alternate scientific theory as to how things came about, but are solely interested in advocating a particular religious doctrine as being truth.
But, what I find interesting is that Windows will use my pagefile WAY sooner and more frequently than Linux (or FreeBSD for that matter) does. And it's not cause I'm out of physical memory in Windows...From just a cursory glance this would make it seem like Windows is more intelligent about putting infrequently used portions of memory into the pagefile while Linux just uses physical memory until it runs out and then switch to the swap space.
;)
;)
Yes, the theory is exactly this. Any NT-based Windows swaps stuff early in order to make room for as big a disk cache as it can manage - it's tunable behaviour, though don't ask me which thousand bajillion obscure registry settings it is
The tradeoff between keeping stuff paged in, and enlarging the disk cache, is a hard one to calculate, and Linux and Windows can both be tuned to behave differently. The defaults (and in fact algorithms) differ wildly, which results in the difference you see. Which is 'better' depends on too many factors to give a straight answer - it's probably too hard to directly compare the relevant metrics (page faults vs disk cache misses) because it's hard to reproduce the same load across different OSes.
I've looked into which pages are resident and which aren't in Windows (though I've not done the same in Linux) using the kernel debugger, and it doesn't seem to be making too many stupid choices - my system, under either OS, has quite a lot of stuff loaded that I'm not actually using right this minute. Starting various desktop apps to get the total memory consumption to be vaguely similar, and then seeing how much gets swapped out while I use it (an extremely unscientific test, but hey) shows Windows using a much larger disk cache, i.e. making do with less resident pages, and neither were significantly slow to respond. But, this doesn't really say much, as the conditions were totally uncontrolled.
So, err, what you describe is more or less the defaults, but whether changing it will help or not, or which strategy is superior, I have no idea
They do, actually - the 'swipe' section of the cashier's terminal has been augmented with a smartcard reader at the bottom. So, the cashier swipes the card, it reads the magstripe, and when it gets to the bottom of its travel it clicks into place in the smartcard reader. The chip and pin keypad then acts as just a display/keypad, leaving the reading to be done by the cashier's terminal. The cashiers are not supposed to let the customer put the card into the customer-facing terminal (some even have the card slot on that terminal covered). I have absolutely no idea why.
It doesn't really make it much easier to mount a man-in-the-middle attack - if you are determined enough to install something inline in the cable connection, you are probably determined enough to install something inside the customer-facing terminal anyway (as the terminals are not made to be secure against physical intrusion). It still seems stupid, but it's not the end of the world.
Far more pressing problems with chip and pin would be modifying terminals such that they, say, display a different amount on the screen to the amount they are authorising, or that power cycle the card and replay the user's pin to authorise a second transaction.. these attacks are not really made easier by the separation.
This is true, but the quoted speed is not the nominal speed. 100BaseTX uses a 5-bit Manchester code to send 4 bits of information, which means that yes, it only gets 80% of the actual line speed. However, the actual line speed is 125Mbit/s - thus, you really do potentially get 100Mbit/s. With fully switched ethernet, on decent, fast switches, you can attain well over 95% of that speed in actual use. My server hits a sustained 96.5Mbit/s when I pull files off it over ftp, for example.
No, the RSA encryption on the DS is not used to secure the actual wireless communications, but only to secure wireless download play (when you play multiplayer over wifi with only one cartridge between you). The code sent over wifi to multiboot all the DSes that don't have a cartridge is RSA signed, and an unmodified DS will refuse to run multiboot code that does not pass the signature check.
Once the DS has been booted, either by multiboot or by having a cartridge inserted, the 'RSA Secured' is irrelevant, and any security which is then used is only whatever security the game developer has put into their software, usually zero.
The device Nintendo are proposing here basically seems to be nothing more than an access-point mode USB wifi adapter, possibly with some software to configure Windows' connection sharing. It will work just as well with any standard wifi router/access point, as far as anyone can tell (online DS games soon to be released, such as Animal Crossing DS, are being promoted as working at any wifi hotspot, something that wouldn't happen if they used some Nintendo proprietary 'thing').
Speculation: They didn't make a router that connects with a cat5 cable because these days a lot of people have all-in-one wireless router/broadband/everything boxes anyway, and probably most of the people who don't already have some kind of solution to this, integrated or otherwise, only have their broadband connected to a single PC. They could've built this functionality into the Revolution, making it an access point in its own right and giving it an ethernet port, but it's cheaper not to, I guess, especially if my speculation is true.
The DS uses 802.11b, perfectly standard. The Revolution may be 11b or 11g, I don't know, but will also be standard. What's nonstandard is that the DS (and presumably the Revolution when talking to the DS) does not use IP over the top of 802.11b, but a custom layer 3 protocol. When being used for online play, it will use IP, the same as everything else (otherwise it won't be able to talk to the Internet), and there is absolutely no suggestion whatsoever that it will not work with a standard wifi access point. Animal Crossing DS is being marketed as working with any wifi hotspot.
The 'Ni-fi' referred to on DS hacking sites is the layer 3 protocol used by the DS above standard 802.11b, it's not meant to imply that it's not standard wifi.
Actually, you can burn Cube games on standard 8cm DVD-R disks just fine, and they will work perfectly once booted through one of the alternate BIOSes (Cobra/Anaconda/GCOS). You don't even need a modchip; the Action Replay exploit or the PSO exploit can be used to boot Anaconda or GCOS entirely in software.
You can even burn them on ordinary 12cm DVD-Rs if you take the top off the cube so that 12cm ones fit..
The token expiring was a bug, and was fixed months ago; offline mode now lasts forever. The other issue is still present though; you 'lose' offline mode if Steam is able to connect to the servers at all, whether it succeeds in authenticating or not.
I run Windows XP SP2, I download huge amounts of P2P media and warez, have no antivirus or antispyware running permanently, and have no application-level firewall (i.e. all outgoing connections are allowed), though I am behind a Linux firewall (non-NAT, my Windows box has a public IP, but the Linux box filters incoming connections to be to known services only). I occasionally run the latest version of whatever antivirus/spyware tool people seem to be talking about this week, and they don't find anything. There aren't any processes, services, tray icons or toolbars running that I don't specifically recognise, and I've never had to remove anything because it turned out to be malicious.
;)
Don't blame the warez; widely distributed warez is widely distributed because it *works*. A torrent with a high rating on a reg-required torrent site is unlikely to be laden with spyware; files grabbed from the original groups via IRC and compared to published checksums aren't trojanned, because the group would be found out in no time and would lose kudos (and get DoS'ed, probably, but hey).
My parents' machine stopped getting any kind of infection the second I switched them to Firefox and Thunderbird. They've not had a single problem since, even though they use P2P networks to get music, video and software.
Obviously not everyone has this experience, but every computer I've ever used has IE and OE as their sole infection vector of any note.
The one that pisses me off more than anything is the use of the word 'mentalist' as a noun form of 'mental', in describing someone who is doing something the speaker considers to be mad. "He's mental" becomes "He's a mentalist". Maybe it's just a UK thing, but it's very common..
;)
It always makes me want to slap them and explain that a mentalist is someone who, perchance, might know WHICH CARD YOU ARE THINKING OF.
"Are there any capitalists who aren't scumbags, or is a large business automatically evil?"
/. the answer that question is "YES".
/. the most likely answer to a multiple-choice question is indeed "YES", and it's nothing to do with political bias ;)
On
Yup, on
The author and copyright holder of the software distributes it under the GPL. He's trying to stop someone redistributing it, under the terms of the GPL. Buh.
Which means any application can alter USER.DAT in any way. If this file gets corrupted in certain ways a user may be either completly unable to log in or never get anywhere near having a usable desktop.
.LOG next to each .DAT. They're written using the standard, safe, recoverable algorithms used by databases since the dawn of time. File-based configuration is only similarly protected if stored on a journalled FS (which admittedly most are these days).
No, they can't, it's locked.
This appears to be a horribly complex way of doing what having multiple configuration files would do by default.
It's identical to having a filesystem - in fact, the registry can be regarded as a filesystem. To read a registry key you make a syscall with a path, it does permission checks, then it gives you the data if you're allowed - to read a file, you make a syscall with a path, it does permission checks, then it gives you the data if you're allowed. What's the difference?
Which makes the whole thing vulnerable to the machine being reset, especially a hard reset.
No, it's not vulnerable to that. Both registry hives are stored as transactioned databases - notice the
I'm not trying to argue that the registry is better than having configuration files - I was simply pointing out that the original poster's argument was based on false premises. The *real* downsides of the registry are inherited from the downsides of Windows - inadequate access controls. If Windows apps stored their configuration in seperate files, then they'd *still* all be writable by the user (and thus by all the apps the user runs) simply because Windows doesn't have per-process access control. The same problem is reflected in the registry, but it's not having a registry that's causing the issue.
(note that Linux/BSD/Mac OS X/etc don't have per-process access control by default either.. Linux can have it added through the security hooks used by RSBAC/SELinux, or by GRSecurity - I don't know whether the same can be achieved on BSD..etc).
It also could be said that the Firefox 'extention' layer opens the world of spyware/hacks/security holes to lower-skilled script developers.
;)
Unfortunately, yes, you're more or less right; malicious Firefox extensions can do an awful lot to compromise your system. You can execute arbitrary binaries as the user, for a start, though that is of course nonportable... if you'd like a cross-platform exploit, try sending their bookmarks, browsing history, cookies..etc over the 'net (just submit them to a webform somewhere - web browser extensions wouldn't be much use if they didn't have permission to, uhm, connect to web sites).
This is why Firefox, by default, will *not* allow you to install extensions or themes that aren't downloaded from update.mozilla.org - the extensions there are hopefully vetted by enough people that a malicious one would be caught.
Executing arbitrary binaries could be prevented (but is not, because it can be useful - see the IE View extension, for example) but the potential for abuse of the browser's internal API can't, really - removing the features that allow these things (ability to connect to websites, ability to read the user's bookmarks, etc) would pretty much break every single extension that exists
All users (and by extension all programs) need read-write access by default to a small number of files that are critical for system functioning: the Windows registry.
The user registry is kept in seperate files, one per user, stored in the user's home directory (their profile). The system registry is certainly not writeable or even readable by users - there are, rather, system calls which will retrieve the value of a key on your behalf, after checking the access control list associated with the registry key you are trying to read. Registry keys are protected by the same ACL system as the filesystem. Even the user registry has entries which are not writeable by the user, only by system components - just because the user can write to the file doesn't mean it will actually work if they try - it's permanently opened and locked by at least one system process if the user is logged on (Winlogon) and thus cannot be opened directly, only accessed via the appropriate API.
The rest of your points are valid, but the registry is not anywhere so vulnerable as you make out.
The AC is right; fewer studios make PC games because there is less money to be made. The number of illegal copies has *nothing to do* with lost profits - the vast majority of those copies are not lost sales as the copiers would not have bought the game.
I'm not justifying copying games and never was; I started the threat by stating that *I*, that is, me personally, would be flattered if something I had written was widely distributed, whether they were paying for it or not. I don't think it shows a lack of respect at all; people *playing* the game is the respect that I would desire. People buying it is simply lining some publisher's wallet even more.
Professional copiers and counterfeiters are making a profit from work they do not own. However, in Western countries, professional copiers and counterfeiters are for this very reason actively persecuted by law enforcement. Convince copyright protection organisations to crack down on for-profit distribution, rather than passing-copies-to-friends or downloading-something-random-online, and the developer's bottom lines will see much more benefit; the profit lost to bootleg sales is far, far more than the profit lost to casual piracy because the people who buy them, contrary to your assertion, typically *don't* realise they are counterfeit and believe they are supporting the developer. If the counterfeit copies were not available, many of them would be content to pay the retail price (or to wait for the second release and pay a reduced price, at least) for a legitimate copy. People who can recognise professionally counterfeited copies usually know where to download the same things for free (I mean, it's not hard), so why would they pay for a copy that's no more legit?
If you still think I'm trying to justify copying games, then I don't have anything more to say to you as you're clearly not listening.
How many game companies have gone out of business or had to downsize significantly for reasons directly traceable to copyright violation? I can't find an example; your statement's premise seems unlikely.
I've bought most of the games I play, even the ones I had downloaded months earlier, but the large majority of people who download games would not have bought it in the first place. Let's be generous and say that a flawless, unbeatable copy protection system would increase your sales by 50% (i.e. those relatively rare people who would get it for free if they could, but are willing to buy it if they can't copy it). Now, I don't know about you, but I'd rather skip the payrise and have ten times as many people playing my game by copying it.
If you can't make enough money because of piracy, then something has gone badly wrong with your business; you are not offering enough value in purchasing the game (give them more cool stuff; concept art prints are always good), or your publisher has set the price much too high (consider self-publishing, and let people copying your game *be* the marketing department), or your game just isn't worth buying in the first place (haha, you suck). None of these are the fault of the customers or the copyright violators.
It's yet another 'success' of the moderation system that my previous comment got modded flamebait. Oh well.
Information wants to be anthropomorphised.
I'd love to see something I've worked on for 50+ hours a week for months on end being freely copied around; it would show that I've achieved something that's really worthwhile.
Nokia's proprietary OS is hard realtime. Symbian 8.[01]b and 9.x are hard realtime. Other manufacturers undoubtedly use them too, I just don't have first-hand experience with them.
Without hardware support it will do stack smash protection for the recompiled system binaries, and it might also make a nonexecutable stack segment using the same trick Solar Designer's Linux implementation does..
No, they don't, unfortunately. XP SP2 only adds NX functionality on AMD64 and Itanium, their marketing material just omits to mention this in order to make it sound more secure ;)
Avoiding joint stereo makes quality worse, not better; unlike older encoders, LAME only uses mid/side for frames when it is a genuine benefit. If there is no correlation at all between left and right, LAME will not bother. This only works on LAME - other encoders follow the standard's mechanism for switching between mid/side and full stereo which is buggy ;)
The RPOW server keeps a db of used tokens. To validate the token, instead of doing it locally as with the original hashcash system, you send it off to the RPOW server and if it's valid and has not been used before, it will send you back a new token of equivalent worth (which both tells you that the token you were given was valid, and allows you to use that token yourself to, say, send outgoing mail). This has the convenient side effect that people who receive at least as much email as they send (i.e. non-spammer, non-mailing-list-server machines) won't have to generate any tokens themselves, thus avoiding any delays to sending mail.