Elbox

[cas]

The apparent lameness of Elbox notwithstanding, how is it a surprise that making random modifications to a third party binary, can be dangerous?

If the code in question, became dangerous only after it was modified by the cracker, this is the responsibility of people who use the crack (or the cracker himself). There is no limit to the amount of dangerous code that he might have injected.

Anytime you run a binary from an unknown source, you are putting yourself at risk.

 

[Fushigi]

I agree that anyone using cracked apps is using them at their own risk. I think the difference here is that the dangerous code was in fact put in place by the original vendor and not the cracker.

If a software vendor needs to protect their intellectual property, a disabling mechanism & possibly a reporting mechanism are all that's ncessary. Making the system unbootable & destroying the data is not going to win the vendor any fans or new customers.

- Fushigi

 

[cas]

I think the difference here is that the dangerous code was in fact put in place by the original vendor and not the cracker.

I disagree. It is not clear to me that the manufacturer's code is dangerous at all. What is dangerous, is a different binary released by an anonymous cracker.

Software requires precision. The processor does not try to guess what the programmer meant, or was thinking when he wrote the code in question. There are many code sequences which can be rendered dangerous with the slightest modification.

The author of the derivative code was responsible for ensuring that his changes did not render the sequences dangerous (as is true of any modification, just ask service pack/patch developers). I suspect that the cracker in question did not perform regression testing, nor attempt to maximize code coverage in his tests. Bad things happen, when programmers release poorly tested code.

 

[Tannin]

Elbox? What's that?

 

[Buck]

Check the news article on the Home page of StorageForum.

 

[Tannin]

Ahh, thankyou Buck.

 

[Fushigi]

I think the difference here is that the dangerous code was in fact put in place by the original vendor and not the cracker.

I disagree. It is not clear to me that the manufacturer's code is dangerous at all. What is dangerous, is a different binary released by an anonymous cracker.

From the front page:

P.S. On the second thought, looks like Elboxes PCI libraries include the malicious code as well, not just the USB drivers. That means that pretty much all of their software products carry the "poison pill" - except that this particular one kills the owner's rig instead of the malicios library!
P.P.S. Rebuttal or not, Elbox has immediately released a new version of the offending libraries used in all of their products, that contain no RDB trashing code. And not a word of apology. Time to reconsider open source? ;-)

I am inferring from this that it is clear that the manufacturer included the malicious code.

The author of the derivative code was responsible for ensuring that his changes did not render the sequences dangerous (as is true of any modification, just ask service pack/patch developers). I suspect that the cracker in question did not perform regression testing, nor attempt to maximize code coverage in his tests. Bad things happen, when programmers release poorly tested code.

I agree. My guess would be the cracker made the mod & it worked on their particular combination of hardware, OS, and applications. Once released, some other hw/os/app combination that wasn't tested for triggered the response.

I generally do not approve of cracked software as it is my belief that developers, be they individuals or corporations, are entitled to sell their product and profit from it. However, those same developers have a responsibility to provide applications that are as safe to use & bug free as can reasonably be expected. It is reasonable for a developer to protect their wares by disabling them if suspect use is detected. However, wiping a user's data shows the developers have no concern for anyone beyond themselves. Really, if the application thought it was not a legitimate copy, the very most it should do is send a message to the developer & then delete or disable itself. More important, by deleting other data on the system the developers are opening themselves to liability issues.

- Fushigi

 

[Cliptin]

He certainly did not test well enough. However, as I understand it the problem was in the original code and presented itself when matched with a generic hardware piece.

Caveat Furunculus.

http://catholic.archives.nd.edu/cgi-bin/lookdown.pl?thief

 

[cas]

My guess would be the cracker made the mod & it worked on their particular combination of hardware, OS, and applications. ... However, ... developers have a responsibility to provide applications that are as safe to use & bug free as can reasonably be expected. ... More important, by deleting other data on the system the developers are opening themselves to liability issues.

Indeed, the cracker had better watch out.

The opcodes for my x86 disk utility, may map to utter destruction on a Palm device.

As I understand it, the code in question is useful, and harmless when used in the proper way.

If a crack has been developed which is dangerous, then the developer of the crack is responsible.

 

[HellDiver]

The majority of the comments in this thread are somewhat irrelevant (the whole "regression testing" and "testing in general" lines) - just try to follow some of the links I provided. But that's besides the point, since the discussion veered somewhat off course as a whole - at least off course I had in mind when I queried for comments.

And that course is not "how do you feel about crackers and how much regression testing should they put into software piracy tools", but rather how do you feel about software companies taking highly agressive steps against software piracy in general, and how do you feel about using a software which you KNOW contains portions of code that could DELIBERATELY render your rig inoperable on a whim as soon as it ASSUMES is has been tampered with?

It is not clear to me that the manufacturer's code is dangerous at all.

BTW, how would you feel, cas, if one of those fine sunny mornings your rig would go tits up because your NAV's "Bloodhound" heuristics engine decided that some particular piece of code in your USB driver contained a virus, and decided to auto-"clean" it? Needless to say your MBR would be lost on the spot. So, was Symantec's code dangerous? Was Elboxes code dangerous? Was your Ghost backup handy? Or should the question be : "Did you even know what MBR is, what Ghost is, and did you have a clue that your computer has a USB, much less a driver for it?" to begin with?

So, wha'd'ya say folks?

N.B. :
1. For starters, the case is purely hypothetical, Elbox is in Amiga business. But that's not the point - we're talking principles here.
2. I have no doubt cas knows what MBR is, but I do have doubt whether his mom does - you get the point.

 

[Cliptin]

Helldiver, Your questions all still speak to interoperability testing. The only difference between this problem and problems before it is the severity of the results of a conflict.

This is indeed troubling. But no more troubling than what Partition Magic does. You ask about Grandma accidently constructing a self detructive system. In any case, developers should always include a way to reverse course when trouble arrises.

 

[cas]

In your hypothetical example, I am using NAV in the way it was intended to be used (which has flagged my code BTW). Until the Elbox code is shown to be destructive, even once, when properly used, it is a different question entirely.

 

[HellDiver]

BTW, how would you feel, cas, if one of those fine sunny mornings your rig would go tits up because your NAV's "Bloodhound" heuristics engine decided that some particular piece of code in your USB driver contained a virus, and decided to auto-"clean" it? Needless to say your MBR would be lost on the spot.

In your hypothetical example, I am using NAV in the way it was intended to be used (which has flagged my code BTW). Until the Elbox code is shown to be destructive, even once, when properly used, it is a different question entirely.

Either I misunderstood you cas, or you misunderstood me. The example above is the case when Elbox code is shown to be destructive when properly used! NAV acted by design by auto-cleaning up a piece of code that is employed in some newly discovered virus (which if you ask me is indeed a possibility, as code included in Elboxes USB driver - destruction of MBR - is indeed more appropriate to viruses than to USB drivers!). Elboxes hypothetical USB driver acted by design by trashing the MBR once driver's code was touch by NAV. What do we get as a result? 2 pieces of code acting by design, one rig with a lost HDD, and one completely screwed user that did absolutely nothing to deserve that.

BTW, that's very different from your example, Cliptin, because in my example it wasn't user that made a dumb choice screwing his own system up. It was Elboxes elaborate code deliberately and "by design" trashing the HDD. Not quite the same thing, methinks...

 

[cas]

Say what? If NAV changes any binary (through auto-clean, or any other mechanism), those changes are the responsibility of NAV. They are not the responsibility of the binary that was changed.

If NAV were to modify ntoskrnl.exe, terrible things could happen. This is not the fault of ntoskrnl.exe.

This point has already been made. It is still true.

 

[HellDiver]

Why, thank you, cas! I just wanted to make sure we were on the same page here. See, I didn't rise this topic to argue about it - just to see how people would feel about the cliché "black helicopters" showing up outside their window.

I thank you for your feedback.