The point is, nothing is 100%. The game is to make it sufficiently difficult that the number of people who have the skill and time and interest to crack the protection is small (for a suitable definition of small). Then people will have the choice of either a) lots of effort to steal code which will become obsolete or b) pay for it.
Did you see me arguing that anything was 100%?
Could anyone do it? No way
It only takes the one, who turns around and uploads it.
Is it something that one does in an afternoon? Certainly not. The level of effort to crack this sort of scheme is actually quite high
Sure. But most people I know who've ever done this kind of thing do it for personal entertainment and challenge.
at the end of the day you end up with one version of the product which one will have no support options for, and which will rapidly become obsolete.
Yup. I've taken support calls from people whose serial number matched that of a cracked version of one of our products which floats around being sold by a scam artist. You know what we do? We solve their problem, and then offer to sell them a legit copy at a discount. Having just gotten out of a time-sensitive jam, they're always quite happy to get things straightened out properly. I'd much rather distribute the software for free, and then go the support route. That'd clear off that scam artist, too.
And most of those 35k checks are going to use the same idiom, right? Or did figure out how to make each one sufficiently unique that scanning the assembler code for a fingerprint wouldn't find it.
Did you call a function which performs the check? Patch the function. Did the compiler inline it? Find a few copies of the check, find the common sequence of instructions (or, if you're really clever, the semantic behavior of the instructions, so you don't get twigged by compiler optimizations), and scan the code for that. You look into what a lot of those academic analyzer tools are capable of by this point. Or what ideas you might give to an undergrad looking to make his mark.
As I said, I'm not an expert. These are just the obvious workarounds that come to mind.
I've only ever seen two "deactivate at random" behaviors with the DRM stuff I've used. The first happens when a customer does something stupid like muck around with files under %PROGRAMFILES% and/or %PROGRAMFILES(x86)%. I.e. if you affect the placement of files on the block device (or whatever Windows' equivalent is), you're doing something that a user of the software shouldn't be doing; that's the installer/uninstallers's job. The second was when Windows Vista/7's virtualization of system folders triggered the same catch mechanism as the first; the solution to that was elevating privileges at activation time.
DRM is still bs, IMO, and everyone I work with would like to get rid of it, but it's sometimes explicitly demanded by the customer.
No better than DRM. As far as I know, it all comes down to one of two types of setups:
"Is this authorized? Then do stuff" However the sophisticated the rest of the setup, all a cracker needs to do is identify this if conditional and patch it. In this type of system, the rest is just obfuscation of where that clause is, and how it works.
"Decrypt necessary code or data, then execute." At some point, the encrypted material will be in the clear, at which point it can be snagged. Binary gets patched to use the snagged, unencrypted form rather than need to use the encrypted form.
Now, I'm not an expert; I just develop software. I haven't tried to crack others' protection.
Point. I forgot about ad pulls. Now I'm pondering 'sponsor this app' placement; once-per-month releases, highest bidder gets placement for that revision.
Benefit is that the app's users would know the app's target market and (to an extent) community, which is a particularly nice way to target ad spending.
Those users will be able to stay on their pre-LUA version of MW for a major release or two (upstream doe security and bugfix releases for a while), which should give their vendor time to upgrade, if necessary.
And, yes, I'm sure someone will come up with a MediaWiki extension to implement Lua in pure PHP, and patches will probably be accepted to allow selection of Lua providers in LocalSettings.php. Of course, the reverse is also plausible; upstream might choose to use a pure-PHP solution, and the existing PECL extension might be tied in via a subsequent MediaWiki extension.
To an extent. Shared hosting providers are a dime a dozen, though, so finding a different one is pretty easy. Then there's Wikia and a number of other wiki farms ranging from free to an equivalent to managed hosting. And migrating a MW site isn't all that difficult, and not necessarily even time-consuming; the software is very good about that kind of thing, including cases where you need to upgrade.
Server administration to add that kind of thing is easy, and where a shared hosting provider falls behind, migration to another won't be preventatively difficult for anyone who shouldn't have been using a wiki farm to begin with.
Of course, for people like me who have to run our own server to run MediaWiki on, it's almost a nonissue; typically just a package install to get what we need. And I've been running a reasonably popular MediaWiki install for five years, so things may appear simpler to me than to other people. Point is, administering a website requires a minimum of knowledge, even if that minimum of knowledge is being able to migrate to a different service provider. If they can't do that, they weren't going to get around to upgrading in the future place.
I hope they're going with a PHP extension, and not implementing LUA in PHP. I'd rather have the execution happen in C code than PHP, for execution speed reasons, and I imagine their server operators feel similarly. (Though there's the obvious counterpoint that you're adding a new chunk of less-tested code that has fewer barriers to cross to exploit some vulnerability...)
In any case, I can't say I'm upset at the change--I'm actually a bit giddy. MW templates are a royal PITA.
Apple's reasons for switching had more to do with x86 as a better-invested hardware platform. They wanted all the same hardware capabilities as the burgeoning PC/gamer market, and I guarantee you it wasn't going to be cheap or easy to get the likes of NVidia or ATI to prepare Apple variants of their PC hardware. (You wouldn't just take the latest NVidia card and drop it into an Apple; the video card has a BIOS in x86 machine code, because the PC expects it. Apple hardware was necessarily different, if only because it used a different processor architecture)
I believe some of it was related to the rate of improvement in the x86 processor market as compared to the PowerPC, too. These days, the X-Box 360 and PS3 both have PPC processors, but that doesn't drive a constant evolution in those processors' capabilities; consoles work the way they do because developers expect consistency within a platform.
Might have been a cached data block for a botnet payload. as a DDOS, it doesn't make any sense, because you'd have had to put that TXT record on the retrieved host in the first place.
x86 is CISC when we know RISC is better. Intel/AMD do some tricks to make the core more RISC, but why not just cut out the middle man? Why bother with converting it at all?
Pull up a pillow and have a seat around ol' Grandpa Short Circuit. This may come as a shock to you.
Some programs still being sold and run on desktop computers today were compiled over ten years ago. Some programs still sold and run in x86 embedded environments were compiled twenty to thirty years ago. That's why x86 is still around.
x86 is still around for the same reason Windows is still around. It still runs binaries that are really, really old. In some cases (many, I expect), the source code for these binaries no longer exists, or the toolchain for building it is bitrotted. That's why x86 is still around.
Imagine some sci-fi horror film where everyone's forgotten how to maintain the vast infrastructure of their civilization, they just don't poke it because they don't want it to break. That's why x86 is still around.
Meanwhile, every year there are more long-lived applications built for the existing platform, with very little hope for being updated for newer platforms and processors; their binaries are likely to be running for another five or ten years.
Amusingly, open-source software has a clear advantage over closed source software in this arena. Several distributions are actively keeping software packages portable across CPU archs, and even portable across OS kernels. (Debian and Gentoo both support BSD foundations as well as Linux)
Is he LSC or CT? I've got the book, and interact with LSC on IRC regularly; he's one of the principals behind prgmr.com, of which I'm a customer. (And I've got the book...)
I was amused when I discovered that the Xen hypervisor allows you to emulate a TPM in software. I didn't dig into it enough to find out if there were a way to extract stored data from within the dom0.
You don't know what you're talking about. Seriously.
Starting with Vista, users, even "Power Users" and "Administrators", run least-priviliged to start. For compatibility's sake, writes to %PROGRAMFILES% and friends are virttualized and shunted aside to a per-user store. To get code to run as an Administrator, you need to "Run As Administrator" the program itself, another process (such as cmd or Windows Explorer) tat then launches the program, or you have to code the application to request privilege elevation, which then triggers the UAC dialog.
Slashdot Mirror
The point is, nothing is 100%. The game is to make it sufficiently difficult that the number of people who have the skill and time and interest to crack the protection is small (for a suitable definition of small). Then people will have the choice of either a) lots of effort to steal code which will become obsolete or b) pay for it.
Did you see me arguing that anything was 100%?
Could anyone do it? No way
It only takes the one, who turns around and uploads it.
Is it something that one does in an afternoon? Certainly not. The level of effort to crack this sort of scheme is actually quite high
Sure. But most people I know who've ever done this kind of thing do it for personal entertainment and challenge.
at the end of the day you end up with one version of the product which one will have no support options for, and which will rapidly become obsolete.
Yup. I've taken support calls from people whose serial number matched that of a cracked version of one of our products which floats around being sold by a scam artist. You know what we do? We solve their problem, and then offer to sell them a legit copy at a discount. Having just gotten out of a time-sensitive jam, they're always quite happy to get things straightened out properly. I'd much rather distribute the software for free, and then go the support route. That'd clear off that scam artist, too.
And most of those 35k checks are going to use the same idiom, right? Or did figure out how to make each one sufficiently unique that scanning the assembler code for a fingerprint wouldn't find it.
Did you call a function which performs the check? Patch the function. Did the compiler inline it? Find a few copies of the check, find the common sequence of instructions (or, if you're really clever, the semantic behavior of the instructions, so you don't get twigged by compiler optimizations), and scan the code for that. You look into what a lot of those academic analyzer tools are capable of by this point. Or what ideas you might give to an undergrad looking to make his mark.
As I said, I'm not an expert. These are just the obvious workarounds that come to mind.
That's actually a slick idea. You could even do the dongle as a PCIe accelerator card.
who cares
If Oracle wins, they'll still have a victory under their belt which they could pursue manufacturers of Android devices?
Defrag tools don't trigger it.
I've only ever seen two "deactivate at random" behaviors with the DRM stuff I've used. The first happens when a customer does something stupid like muck around with files under %PROGRAMFILES% and/or %PROGRAMFILES(x86)%. I.e. if you affect the placement of files on the block device (or whatever Windows' equivalent is), you're doing something that a user of the software shouldn't be doing; that's the installer/uninstallers's job. The second was when Windows Vista/7's virtualization of system folders triggered the same catch mechanism as the first; the solution to that was elevating privileges at activation time.
DRM is still bs, IMO, and everyone I work with would like to get rid of it, but it's sometimes explicitly demanded by the customer.
No better than DRM. As far as I know, it all comes down to one of two types of setups:
Now, I'm not an expert; I just develop software. I haven't tried to crack others' protection.
Has that been added as a Golf builtin yet?
Point. I forgot about ad pulls. Now I'm pondering 'sponsor this app' placement; once-per-month releases, highest bidder gets placement for that revision.
Benefit is that the app's users would know the app's target market and (to an extent) community, which is a particularly nice way to target ad spending.
I'd love to know why so many apps require 'full network access' when, near as I can tell, their purpose requires no access.
yeah, I saw that; I googled for it before finishing my original comment. :)
Those users will be able to stay on their pre-LUA version of MW for a major release or two (upstream doe security and bugfix releases for a while), which should give their vendor time to upgrade, if necessary.
And, yes, I'm sure someone will come up with a MediaWiki extension to implement Lua in pure PHP, and patches will probably be accepted to allow selection of Lua providers in LocalSettings.php. Of course, the reverse is also plausible; upstream might choose to use a pure-PHP solution, and the existing PECL extension might be tied in via a subsequent MediaWiki extension.
To an extent. Shared hosting providers are a dime a dozen, though, so finding a different one is pretty easy. Then there's Wikia and a number of other wiki farms ranging from free to an equivalent to managed hosting. And migrating a MW site isn't all that difficult, and not necessarily even time-consuming; the software is very good about that kind of thing, including cases where you need to upgrade.
Server administration to add that kind of thing is easy, and where a shared hosting provider falls behind, migration to another won't be preventatively difficult for anyone who shouldn't have been using a wiki farm to begin with.
Of course, for people like me who have to run our own server to run MediaWiki on, it's almost a nonissue; typically just a package install to get what we need. And I've been running a reasonably popular MediaWiki install for five years, so things may appear simpler to me than to other people. Point is, administering a website requires a minimum of knowledge, even if that minimum of knowledge is being able to migrate to a different service provider. If they can't do that, they weren't going to get around to upgrading in the future place.
I hope they're going with a PHP extension, and not implementing LUA in PHP. I'd rather have the execution happen in C code than PHP, for execution speed reasons, and I imagine their server operators feel similarly. (Though there's the obvious counterpoint that you're adding a new chunk of less-tested code that has fewer barriers to cross to exploit some vulnerability...)
In any case, I can't say I'm upset at the change--I'm actually a bit giddy. MW templates are a royal PITA.
It wasn't that long ago that Slashdot conversations were both rational and coherently written.
Honestly, I think that may be a sign you're growing up.
Apple's reasons for switching had more to do with x86 as a better-invested hardware platform. They wanted all the same hardware capabilities as the burgeoning PC/gamer market, and I guarantee you it wasn't going to be cheap or easy to get the likes of NVidia or ATI to prepare Apple variants of their PC hardware. (You wouldn't just take the latest NVidia card and drop it into an Apple; the video card has a BIOS in x86 machine code, because the PC expects it. Apple hardware was necessarily different, if only because it used a different processor architecture)
I believe some of it was related to the rate of improvement in the x86 processor market as compared to the PowerPC, too. These days, the X-Box 360 and PS3 both have PPC processors, but that doesn't drive a constant evolution in those processors' capabilities; consoles work the way they do because developers expect consistency within a platform.
Might have been a cached data block for a botnet payload. as a DDOS, it doesn't make any sense, because you'd have had to put that TXT record on the retrieved host in the first place.
More likely, the unusual TXT lookups were someone streaming IP over DNS.
x86 is CISC when we know RISC is better. Intel/AMD do some tricks to make the core more RISC, but why not just cut out the middle man? Why bother with converting it at all?
Pull up a pillow and have a seat around ol' Grandpa Short Circuit. This may come as a shock to you.
Some programs still being sold and run on desktop computers today were compiled over ten years ago. Some programs still sold and run in x86 embedded environments were compiled twenty to thirty years ago. That's why x86 is still around.
x86 is still around for the same reason Windows is still around. It still runs binaries that are really, really old. In some cases (many, I expect), the source code for these binaries no longer exists, or the toolchain for building it is bitrotted. That's why x86 is still around.
Imagine some sci-fi horror film where everyone's forgotten how to maintain the vast infrastructure of their civilization, they just don't poke it because they don't want it to break. That's why x86 is still around.
Meanwhile, every year there are more long-lived applications built for the existing platform, with very little hope for being updated for newer platforms and processors; their binaries are likely to be running for another five or ten years.
Amusingly, open-source software has a clear advantage over closed source software in this arena. Several distributions are actively keeping software packages portable across CPU archs, and even portable across OS kernels. (Debian and Gentoo both support BSD foundations as well as Linux)
Is he LSC or CT? I've got the book, and interact with LSC on IRC regularly; he's one of the principals behind prgmr.com, of which I'm a customer. (And I've got the book...)
I was amused when I discovered that the Xen hypervisor allows you to emulate a TPM in software. I didn't dig into it enough to find out if there were a way to extract stored data from within the dom0.
What's that about a secure keystore again?
Check out DroidQuest.
You don't know what you're talking about. Seriously.
Starting with Vista, users, even "Power Users" and "Administrators", run least-priviliged to start. For compatibility's sake, writes to %PROGRAMFILES% and friends are virttualized and shunted aside to a per-user store. To get code to run as an Administrator, you need to "Run As Administrator" the program itself, another process (such as cmd or Windows Explorer) tat then launches the program, or you have to code the application to request privilege elevation, which then triggers the UAC dialog.
slow 300 bps modems
FTFY. I only ever experienced as low as 1200 bps, myself. 300 kbps was either a fractional T1, or came far later with DOCSIS and ADSL.
massive rewrite of history to fit the author's viewpoint.
Isn't that something like 80% of Slashdot articles and comments?