Many people skip the INT3 "About" page and formulate opinions without understanding what is going on here. Please read that to understand why just because a project is "Open Source hardware" doesn't mean it is any more accessible. INT3 is basically an attempt at a "security research hardware CO-OP" with Xipiter providing the "seed funds" for products and using its staff to help out: fulfilling orders and running the backend.
In computer science, "naming things" is one of the hardest problems. In economics, pricing things is apparently one of the hardest things to do. We had no idea about this until we experienced it first hand. Most of us don't think about what goes into the price of a thing. This became evident in a heated twitter discussion yesterday after work. Here is a PDF of screencaps taken before one of the other folks blocked.
As we all know, economies of scale are a huge part of manufacturing electronics (i.e. the more you order, the cheaper the per-unit cost). This is a simple concept to grasp. What is less simpler (and obvious) is building your "risk" and other variables into your costs.
Many don't know that the assembly cost of electronics (the human labor to run the pick-and-place robots, flying probe testers, etc.) dwarf the cost of actual components. Some EE folks try to use some basic rules, but it isn't perfect. The bright-side is that if your design remains constant (and you have a good relationship with a factory) this cost decreases and then eventually plateaus.
So for INT3 we have to place large orders for product (usually between $2.5k and $7.5k worth of product). Let's assume you've gotten past the stage of worrying if a device will be popular enough to sell and you decide to move forward. So as to not be predatory you stick to your "hacker ideals" and price the product so that you break completely even by the final sale (i.e. no profit). Let's deconstruct this:
Even with this model you are in a constant state of deficit until the products sell. You'd probably find that (like us) you begin to dread when stock gets low because it means you have to prepare another chunk of money to pay for restock. Since INT3 is not financially independent this means paying out of pocket. So let's deconstruct further. Some other things become apparent from your first sales:
The last batch of a product took a few months to "break even". So maybe this time you'd like to "break even" sooner.
As a separate issue, perhaps you'd also like to not be in deficit for restocking new orders of that single product and instead (by the end) have the product pay for part (not all) of the restocking of the next batch.
Perhaps you'd also like sales of regular products to finance (in part) creation of new products.
Keep in mind for all of the above you STILL haven't factored in profit or "what you get to take home". Nor have you factored in reimbursement for other things:
Costs of labor for shipping/fulfillment/email responses
Costs of assisting with launch of a new product (coordination with factories, testing, conference calls, etc.)
Any operating costs (FedEx/UPS/USPS accounts, E-commerce charges, Credit Card processors, boxes/packaging, international shipping paperwork, etc.)
Also, all INT3 products are MADE IN AMERICA. That costs extra. We could ship this work overseas. BUT WE DONT! (It's just cheaper to not have certain ethics.)
You or your staff's time? (How do you quantify that? Have people complete time sheets? If you do time sheets, someone still has to review them and itemize bill rates to quantify cost.)
Let's assume you ignore all of these five points above and instead want to address the first three pricing issues? How would you price a single product? Raw material costs times 1.5? Times two? Times three?
EVERYTHING has a cost (even taking time to regularly publish financials: I write this because we considered this early on as a way to be "transparent", but our accountant was already at wit's end with tracking INT3 financials, and didn't want to add more work for them). It's not just about the cost of the BOM or even the cost of the labor, tooling, and assembly. There is always more to the story.
This is why pricing things is difficult. There is never a perfect formula. And even if you think you've found one and arrived at a perfect price, it may not be compatible with the perceived utility the purchaser feels they are receiving. Even without including profit (BTW: we don't make profit on anything at INT3, we barely break even) there is never a perfect answer.
And to further 'do the right thing', INT3 is set up so that all creators/collaborators of a product on INT3 get visibility into all orders, shipments, and financials by logging directly into our e-commerce backend as a vendor. In fact, they're responsible for pricing their own products. In many cases we have to walk through through the above scenarios with them and (in one case) even talk the price down ;-)
At the end of the day, researchers need tools that they can use to quickly get to work. Embedded and hardware security isn't just a hobby, it's a profession. Folks have real operational needs. Real customers, and real deadlines. At the end of the day we still ask ourselves for every product:
"If INT3 didn't exist, and we needed a tool for a project, would we be willing to pay $__.__ for it to show up ready to use?"
Many of the devices we manufacture and sell here on INT3 are all made to "scratch our own itch" at Xipiter. We figure if we need them then so does the broader information security community. Much the way software developers end up writing their own tools, hardware folks do the same. So during much of the research and services work we perform for our clients at Xipiter the need arises for custom software, firmware, and hardware. Many of these products are the result of that.
So for the next few weeks we'll be showing us applying many of these techniques (some of which we also teach "hands on" in our classes) to consumer devices. From hardware teardowns to firmware reversing and binary exploitation.
A few years back at a conference in Singapore that we were both speaking at, I talked to Travis Goodspeed about his GoodFET and a bit about his future plans for a device that would become the FaceDancer. At the time I'd done very little hardware work (other than some consulting one-offs: like kernel vulnerability research on a popular game console).
Fast-forward a few years and I'd found myself focusing more and more on "hardware enhanced" attack vectors against software having now done this work for a number of manufacturers. I'd also taken to designing my own hardware product on the side.
If I'd told my past-self that this would be the case, I'd have laughed it off as an impossibility. But the fact that I (a not particularly astounding reverser, coder, or exploitation guy) have been able to learn so much in so little time is a testimony to how easily our skills as even average reverse engineers, exploit developers, and coders lend themselves to hardware and how fruitful a few hardware tricks can be. (I talked a little bit about this a few years back when I was just getting started messing around with hardware.) Now that things are shifting to mobile and embedded devices, this even more so. (We discuss this in great detail in the upcoming Android Hacker's Handbook.)
Travis Goodspeed and Dr. Sergey Bratus's work had always been an inspiration to me (amid all its eccentricity ;-), especially when I was "looking for something new" and fascinating to play with. About a year ago while consulting with a large "Point Of Sales" software/hardware manufacturer, the opportunity to poke deeply into into USB implementations arose. We (at Xipiter) bought up a bunch of the TotalPhase hardware devices, some indispensable books, and got up-to-date on all the "USB hacking" prior art out on the web. We were amazed at how complex USB implementations could be, and again surprised at how fruitful some simple hardware tricks coupled with software reverse engineering and exploitation could yield some amazing results.
How could we not do this for such an awesome and unique tool that clearly filled a tools gap?
Fast forward about a half a year and we've sold hundreds of these all over the world...people are releasing complete software packages for it, building 3D-printed enclosures, and realizing that the FaceDancer21 is completely unique USB analysis tool. They are realizing the fragility of USB implementations as they accidentally stumble upon 0-Day....
This morning I realized (as I looked at 3D-printed cases much better than my poorly designed ones) that amid all the divisiveness, competition, and drama in the InfoSec community, the FaceDancer21 is simple example of how we as security researchers still really feed off of one another in positive ways.
Many of us were eager to ostentatiously add "researcher" to our titles to legitimize what began (for most of us) as a silly hobby...but our community really does have an ever-evolving set of capabilities, techniques, and skills much like any other field of research.
No matter how ridiculous you may think it is, our community really does maintain it's own "body of knowledge" with capabilities and core-competencies scattered throughout this weird little cottage industry. The FaceDancer21 no matter how niche, kinda exemplifies this. How?
This (to me) is the infosec research community at its best. The best folks in our community often can't and don't share techniques publicly (and for good reason). But amid all that, the FaceDancer21 is (to me) a cute example of a simple tool that shows that even though we are all growing up and have companies to run, bills to pay, families to feed, and IP to protect, we still all have a little bit of that original spark in us... So to me it's kinda a testimony to the cool stuff we can still accomplish collaboratively by just shaving a few hours a week off our schedules.
Last night we posted to Twitter about "USB Condoms" being available early next week and didn't think much more about it. The following morning, we were flooded with emails. Many emails were from journalists from various parts of the media gestalt who were doing stories, posting on websites, or preparing broadcast news segments. This definitely came as a surprise. We knew USBCondoms filled a gap, but didn't expect this kind of response (~.5 million unique page views in 24 hours).
The USBCondom circuit is as simple as a circuit can get...but I guess there really is something to "simplicity" and marketing...Coca-Cola (for example) in all their sumptuousness and success, ultimately only sells flavored sugar water.
Admittedly, it is nice to receive the media attention for one of the products here on INT3. The FaceDancer21 fills a "tools gap" and has consequently been a popular sale with security researchers and now, USBCondoms also "fills a gap" and seems to be a simple and popular idea for folks.
We've been laboring away in obscurity for the last year to build (what we believe to be) a new and exciting consumer product we'll be launching in the next few weeks, we hope it is equally as well received when we release the videos, animations, and product details. It is a product that also fills a "gap" for average consumers, giving them new and powerful capabilities all from their smartphones. We're excited about the release and the new ways folks will think to apply it to their lives in ways we haven't foreseen.
In the spirit of this website, we hope to continue to help bring simple and useful ideas to fruition. Thanks for showing interest in our stuff! USBCondoms will go on sale this coming week!
Here is a summary of some of the press that the USBCondoms received:
The first bundle of orders has shipped! You should receive your printed invoice in the packaging and the tracking information via email. Also, the first bundle of orders will get the case pictured below.
This is a simple terminal trace to show how simple it is to flash the FaceDancer. First plug the Facedancer into your computer connecting it to the "HOST" side of the FaceDancer21. COMMENTS ARE IN RED.
s7s-MacBook-Pro:$ dmesg //RUN DMESG TO BE SURE THE FTDI DRIVER DETECTED THE DEVICE.
FTDIUSBSerialDriver: 0 4036001 start - ok // I'D ALREADY INSTALLED THE FTDI DRIVER, YOU MIGHT NEED TO DO THIS FIRST
s7s-MacBook-Pro:$ svn co https://goodfet.svn.sourceforge.net/svnroot/goodfet //DOWNLOAD THE SOURCE
s7s-MacBook-Pro:client s7$ board=facedancer21 goodfet.bsl --fromweb //DOWNLOAD THE FIRMWARE IMAGE VIA THE BSL TOOL
MSP430 Bootstrap Loader Version: 1.39-goodfet-8 Use -h for help Use --fromweb to upgrade a GoodFET. Mass Erase... Transmit default password ... Invoking BSL... Transmit default password ... Current bootstrap loader version: 2.13 (Device ID: f26f)
The --fromweb feature is temporarily disabled, pending a rewrite. Please grab a copy of the appropriate .hex from http://goodfet.sf.net/dist/ and flash it like so:
goodfet.bsl -e -p foo.hex
s7s-MacBook-Pro:client s7$ curl -O http://goodfet.sourceforge.net/dist/facedancer21.hex //MANUALLY DOWNLOAD OUR FIRMWARE IMAGE % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 13915 100 13915 0 0 26144 0 --:--:-- --:--:-- --:--:-- 143k s7s-MacBook-Pro:client s7$ board=facedancer21 goodfet.bsl -e -p facedancer21.hex//FLASH THE FACEDANCER MSP430 Bootstrap Loader Version: 1.39-goodfet-8 Mass Erase... Transmit default password ... Invoking BSL... Transmit default password ... Current bootstrap loader version: 2.13 (Device ID: f26f) Program ... 4932 bytes programmed. s7s-MacBook-Pro:client s7$ board=facedancer21 goodfet.monitor test //RUN THE SELF TEST
See the GoodFET FAQ about missing info flash. Performing monitor self-test.
Self-test complete. //THIS WILL RUN FOR SEVERAL MINUTES. YOU SHOULD SEE A YELLOW LIGHT FLASHING ON THE DEVICE
s7s-MacBook-Pro:client$
And that's it. During and after the monitor self-test your FaceDancer21 is ready to work and will probably look like this with a solid yellow light:
One of the guys here took some time out of his day (much to our chagrin) to quickly mockup a stand/case thingy for the FaceDancer21 so that you don't have to handle it directly and potentially ESD it like a clumsy Gambit. We'll try to get the 3D model (STL file) committed to the main GoodFET/FaceDancer svn repo, but in the meantime you can download it here and print it yourself if you have a 3D printer. (Note: It is a large download because it also includes the 123D Design files, compiled Makerbot X3G file, and all high rez photos and screenshots.) We may also print up a bunch of these and include them in a few orders.
We were off to a rocky start with Paypal breaking our credit card processing (our fault, we messed up on the business verification forms). Regardless of that however, it seems there really are people in our community that understand what we are trying to do here.
This is not a "business" venture it is a "community" venture. We are still in the red and will probably be for quite some time...(if we ever break even). The over-arching goal here is to "take one for the team" and help get our tools into our hands a bit easier. So thanks to everyone who understood that and supported it!
From that support, we now have enough orders to drop the price of the FaceDancer about 25%. Those of you who ordered at the first price will get a refund for the difference...Thanks again for the support.
Thought:...and this may be how this ends up working: We'll front the money for a manufacturing run. Early supporters pay a small premium to help us out...and then we refund those early supporters when the volume allows for us to drop the price. I really don't know. We'll see. We're still figuring this out.
Anyway, now that the Paypal/Shopify confusion is fixed, we are now accepting all major credit cards using Paypal as a payment processor! (Note: For credit card orders, the amount will just be captured. You wont be charged until we've shipped/"fulfilled" the order through Shopify). You can also still use your paypal account if you'd like.
Many people skip the INT3 "About" page and formulate opinions without understanding what is going on here. Please read that to understand why just because a project is "Open Source hardware" doesn't mean...
The blog system on this e-commerce platform is awful. This blogpost has been prettified and moved to Xipiter's main blog here:
http://www.xipiter.com/musings/using-the-shikra-to-attack-embedded-systems-getting-started
A few years back 
"looking for something new" and fascinating to play with. About a year ago while consulting with a large "Point Of Sales" software/hardware manufacturer, the opportunity to poke deeply into into USB implementations arose. We (
