Design for hackability

Hi,

For folks designing *consumer* kit...

What, if any, considerations are given to encouraging, discouraging, facilitating or *preventing* the "hacking/repurposing" of your products?

And, the reasons behind this "philosophy"? I.e., the source of it.

Finally, how well has this worked in achieving your presumed goals?

Thx,

--don

Reply to
D Yuniskis
Loading thread data ...

For the encouraging, facilitating bits, Andrew Huang (aka bunnie of Xbox hacking fame) has written several posts on his blog on what he added to the Chumby devices for precisely those reasons.

Jeri Ellsworth's C64DTV was also designed to be hackable, but IIRC that was done in secret from her employers which got her into trouble until they figured out how much it added to the sales at which point they started pretending it had been their idea all along.

-a

Reply to
Anders.Montonen

But these are exceptions -- consequences of particular individuals with philosophical issues.

I'm interested in how (*if*) consumer kit designers address these issues. I.e., do they even COME UP when discussing a design or implementation?

For example, in some of the markets that I have addressed, I can

*freely* design "self-configuring systems" without concern for the user bypassing me in that reconfiguration (e.g., "I'll BUY the 1X version and then replace the FRAJISTAT with a 10X device I purchased over-the-counter -- rather than pay Don's price for that 10X version"). If, for example, the device malfunctions and "I" (client) refuse to service it because it has been "tampered with". Or, if it results in someone's death/injury and "I" (client) can stand up in court and point to the modifications made by the user (and attendant assumption of liability)...

Philosophically, I (personally) also believe in pricing things fairly to discourage even the *appearance* of "gouging". I.e., if the APPARENT difference between A and B is "3G of memory" (e.g., 1G vs. 4G version), then the *price* difference should reflect the *cost* of that additional memory -- not some artificial HIGH multiplier thereof. (and, certainly not 4X the price of the 1G *device*).

"Don't screw your customer"

Reply to
D Yuniskis

Since designing a hackable device takes more effort than not thinking about it, I believe it takes someone with the philosophical conviction to see it through (eg. limit your choice of SoC to ones that don't require an NDA for documentation). Conversely, protecting against hacking requires a considerable effort but there is usually an economic incentive behind it.

-a

Reply to
Anders.Montonen

This depends on the device. E.g. for PS3 Sony makes most of the money with games, so there is a good reason to protect it with a complex supervisor concept from hacking and playing cracked games. So far only hardware solutions are known to hack it for accessing all of the hardware, most interesting the GPU. Of course, they screwed it up by allowing full access with an USB service stick, but at least in theory the concept is secure :-)

But for my Buffalo NAS the company makes money by selling the NAS, not additional software, so it is no problem for the company if I install a full Debian system on it and use it as a small Linux server.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

But you don't have to explicitly *design* a device to BE hackable and yet still end up with a hackable design!

Agreed. What I am trying to get at is whether this issue is even *addressed* in the (typical) design process.

As I mentioned, I *tend* (instinctively) to design so that I can defer alot of implementation choices to the very end of the design cycle. For example, I *size* (verb) memory (i.e., have a routine that figures out how much memory is available in the device) instead of *defining* it (e.g., as a manifest constant). Then, adapt the device's functionality to the memory available.

This allows the actual capabilities of the device to be formally defined at the last possible instant. Of course, unless the device "knows" that it has already "been manufactured", it also lets a user *hack* the device after the sale.

In the markets I've served, that wasn't important -- either because of the types of users (purchasers) *or* the application domain.

But, when selling to The Public at Large, there is more potential and opportunity for "hacking" (repurposing, etc.)

Reply to
D Yuniskis

Understood. Sony talks out of both sides of its mouth when it comes to their game systems -- *claiming* they aren't trying to "lock it up" yet always releasing upgrades that always seem to go out of their way to do exactly that each time an exploit is uncovered.

This, however, I consider to be a different issue. They are trying to protect their market (e.g., force people to buy "tangible instances" of games instead of "virtual copies").

A better example would be offering a PS3 with different amounts of internal memory -- then deliberately using some unobtainable type of memory to force people to buy it from them. Or, using generic memory but requiring a new MASKED ROM for the system to be able to use it...

Let me twist that example around... they don't (AFAIK) do anything to *prevent* you from buying a 160G device and upgrading the disk to a 1T drive "after the sale" (?).

E.g., I did that with my Snap Server (NAS) -- not "straight forward" but not *prohibited*, either! (I've not looked at doing the same with my Buffalo LinkStation but that's mainly because I haven't sorted out how to open the case -- without breaking the mirror on the front :-/ ).

At the other extreme, upgrading the drives in my NAS200 is simply a matter of installing new drives and telling it to "initialize" them. (the Snap Server stores the OS on the disk so upgrading the disk is a bit trickier; the NAS 200 apparently stores everything in FLASH).

So, the NAS200 does nothing to actively discourage hacking and can be seen as actually FACILITATING it (they have obviously decided that they aren't in the disk drive business so don't care if you opt to buy your disks from someone else). It's hard to know for sure if the Snap Server folks are trying to discourage hacking (since they haven't done a good job of PREVENTING it). Or, if they are just not going out of their way to *facilitate* it (i.e., by making a mechanism for you to initialize a virgin disk DEVOID of software).

[and I can't comment on the LinkStation -- yet]
Reply to
D Yuniskis

That's the point which comes up during design. Hackability generates support requests. Support requests are expensive. And because people do not buy my product because of its hackability, the design goal is to make sure that it only runs "approved" software.

One of the products I've been involved with had the (semi-unofficial) ability to custom startup screens onto it. Which means that years after production of the item has stopped, we're getting support calls "I want to sell my unit. How do I get rid of the custom startup screen?" The option to do that is right in the same program which makes the startup screens, but the user has long forgotten that this program exists at all.

Not a HIGH multiplier, but a multiplier, please. The mere ability to build a 1G version vs. a 4G version costs development resources which want to be paid, too.

My company is making TV harddisk recorders. Of course the price difference between the 500G model and the 160G model is larger than the difference of the retail prices of 500G and 160G harddisks. But what you get for the price is a working device which is known and tested to support the harddisk. Of course some people swap the harddisks themselves. But if they don't work, or the unit breaks in the process: their problem.

Stefan

Reply to
Stefan Reuther

Buffalo have realized the value of hackable NASes, and sell a specialized version called the Kuro Box that comes with an "open" Linux in a larger flash ROM, but no HDD.

-a

Reply to
Anders.Montonen

That is certainly true. However I would guess that as with your designs, it is just a byproduct of the design techniques than conscious effort.

My own meagre experience is that if the question is raised at all, it is quickly shrugged off (in our case the issue was silkscreened programming header pinouts on the PCB, and the immediate consensus was that if someone wanted to play with the product that was their problem).

Right, one recent example that comes to mind are the Rigol oscilloscopes that could be upgraded to a more expensive and more capable model by issuing some commands over a serial port connection. In this case the hackability was an undesirable feature from the manufacturer's standpoint, and they tried (poorly) to stop it in firmware updates.

-a

Reply to
Anders.Montonen

Ah!

So, there is nothing "preinstalled" on the disk in my LinkStation? I.e., I could DISCARD the disk and install a VIRGIN disk and the device would (after some initialization) function *as if* it was PURCHASED as a "larger model"?

[Hmmm... maybe I'll play with that over the holiday]
Reply to
D Yuniskis

Ah! I hadn't considered that aspect! (I assumed folks hacking on a box *don't* contact the manufacturer as they *wouldn't* expect any help, there! "Hi, I want to steal something from you. Could you please help me do that?")

Understood.

So, now the question is how you respond to that "problem":

- do you remove the "custom capability"?

- do you provide a BUILT IN mechanism that lets them ERASE an existing screen (and possibly support the installation of another "custom" screen)?

I guess it depends on how desirable the "custom screen" is as a feature. I.e., does it *cost* you anything (lost sales) to omit it?

Depends on what you consider "high" :> If, for example, the difference in capacity (1G vs 4G) was just which DISK DRIVE you installed, then the development costs had to be pretty minimal (i.e., no mechanical consequences, power supply is still sized the same, software has two more bits in the size field that are

*used*, etc.).

Understood. But, do you *do* anything to discourage or encourage this? Do you take any measures to minimize your exposure to those "support queries" that aren't related to legitimate issues? (for example, "Hi, could you please provide me with the system identifier [which has a hash of the drive information builtin] so I can open your support ticket?")

Reply to
D Yuniskis

I don't know, but I think there was a flash for the bootloader. I've just followed these instructions, so no need to open the box so far:

formatting link

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss
Reply to
Frank Buss

On regular Linkstations, there is only a bootloader in flash, and the OS is stored on disk. The Kuroboxes are special models sold without a harddrive for hackers/hobbyists.

-a

Reply to
Anders.Montonen
[%X]

Don has highlighted one of the reasons why Hack-ability should always be part of the design/development discussions. That of product liability. I recall that there was some discussion about this when Engine Management Units were starting to be included in production cars. Can't recall if any specific incidents occurred due to unauthorised modification of EMU software like those made to increase speed and performance of the vehicle.

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

"My device is broken. Fix it."

Why tell that you hacked it if you can at least try to get along without telling?

This particular case was a feature introduced to *increase* sales, by selling pre-branded products to resellers. Much like network branding in mobile phones, where a T-Mobile phone comes with a T-Mobile startup screen, not a Nokia screen. I do not know how much return it generated.

Since this was all controlled by a tool, the lesson learned is not to give out such tools too freely.

4G is a nice boundary because it can overflow 32 bits, and your file system must not report "-300 megs free". That aside, supporting different harddisks is probably easy, because (if I remember correctly) harddisks can be asked "how many sectors do you have", and then addressed as "give me sector 0 .. N-1".

I make NAND flash drivers. Of course, it would be possible in theory to query each chip's ONFI block and implement a totally generic driver. But that is way too much testing effort for me, because there are too many variable parameters I'd have to care for. Therefore, my devices support a handful of NAND flash chips (namely, all that I have seen), but none more. This is the minimum amount of work for me.

Likewise, the harddisk guys probably support all reasonable sizes simply because that's the minimum amount of work. They don't have to maintain a database of drives they know and change the software when their supplier opens a new assembly line which generates new serial numbers. But they won't add support for things like 4k sectors just to make it easier for people to add terabyte disks unless they want to use it themselves.

These devices have the usual "Warranty void if removed" seal. I believe they do not have any "pure software" hacking interfaces. But if you swap the harddisk and break a capacitor in the process, that's your problem.

Stefan

Reply to
Stefan Reuther

I am aware of some folks with "genuine" copies of "eyes only" manuals that describe, in detail, the various parameters stored in the ECU (where they are, what they mean). These "folks" routinely tweek those parameters on an engine-by-engine basis to get the last fraction of a percent out of the vehicle. [of course, when I naively *asked* for a copy, the frown that was returned was perhaps the most intense I'd encountered!]

Realizing it would be futile to ask how they came by such a copy, I never pursued that inquiry. But, I have to think this was done, at the very least, with a "wink and a nod" from the engine manufacturer.

I suspect their legal position would be tenuous -- if some catatrophic, engine related event had occurred, the lawyers could claim:

- "you provided the documentation (albeit surreptitiously)"

- "*YOU* modified the ECU"

I imagine what prevents this from happening is the obvious consequence of any such litigation would be the documentation NEVER being available, again (and you could change the software in a heartbeat to invalidate the old documentation).

I know the ECU in question implemented a checksum on the ROM (and data) -- part of the "tweaking" process was to recalculate new checksum. I wonder if, since then, some surreptitious checksum is also made to detect tampering. I.e., let the

*public* checksum report "all is well" yet still note the changes via a "private" checksum.

Rumor had it that the Toyota mess had Toyota buying up all the vehicles of interest with an eye for keeping those ECU's out of lawyers' hands (there was a TV spot in which some engineering types demonstrated how they could cause the ECU to erroneously command full throttle) -- though that would be covering up a factory error, not an aftermarket modification.

Reply to
D Yuniskis

Sure! But, the manufacturer wary of this can put in place a utility like the "system ID" I mentioned that works "almost always" (or, a blinking light that blinks a certain pattern for "legitimate hardware" and another for "hacked hardware", etc.) that can be used to get information from the user that he wouldn't WANT to disclose, otherwise.

This gives the hacker limited recourse: if he learns through the grapevine to report "3 short flashes followed by 2 long" in order to convince the tech support people that he has legitimate hardware (instead of 2 short followed by one long), then he is likely to end up down the "send your device in for service. Of course, if it has been HACKED, we will charge you for that service and NOT reimburse you for your shipping costs... BOTH WAYS!"

Ah, OK. So, it wasn't intended for *me* (end user) to put a screen up that says "I belong to Don" but, rather, "Model XYZ Thingamajig (by GarageCo)".

Have the "problems" come as a result of end users discovering this ability (or having it leaked to them by resellers)? I.e., why does the end user care if his reseller put a particular custom screen on it?

Ah, that suggests the reseller was given the tool and "got cute" with it (trying to add even more "imaginary value") -- hence your problem ("I can put YOUR NAME on this Thingamajig, Don. Wouldn't that be cool???")

Understood. A parallel would be designing a DRAM controller that could handle *any* technology, speed, etc.

But, *within* that set of NAND devices, the "extra" (development) work required to support a 4X difference in capacity is probably not enough to RATIONALLY justify a tiny premium on the cost of the components (unless you are already at the bleeding edge and dealing with customer "ego")

That's the risk anyone takes when "fixing" their own kit. (e.g., replaced the joystick cap on one of my PSP's and snapped the stem off the joystick :< still, easier and cheaper for me to buy a new $2 joystick and replace it myself than scrap the entire PSP)

Reply to
D Yuniskis

Ah. So, I should "image" the existing disk before replacing it with something larger...

Thanks! Else I could have shot myself in the foot on that one...

Reply to
D Yuniskis

IMO, it's stupid to sell a feature that is already present (but crippled) in a product. Customers feel like they are getting screwed.

IIRC, microsoft had a similar "problem" with W2K vs. W2KS -- the latter being a few registry changes to the former. And, their "solution" was equally poor -- have a daemon watch for registry changes for *those* keys and thwart the attempts.

Um, can't you manually change the registry by mounting the drive on a different (virtual) machine, doing the work *there* and then switching back to the W2K(S) machine??

I.e., this is an example of how the "protection" is counterproductive to your business -- you have to do something *extra* to keep folks "out".

Reply to
D Yuniskis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.