A half dozen full spools of PLA was discovered in the garage, and they were all out of sealed packaging. Here in the Pacific Northwest, that is no good for hygroscopic filament like PLA and PETG. When printed, it was an inconsistent stringy mess. It had a tell-tale popping like crispy bacon as it extruded, and it refused to adhere correctly. The popping and adhesion problems I had with my tripod printer may have been caused by water-logged filament. Clearly this is a chronic problem. I'd read about filament dryers, but the cheapest were over $40. Rather than splurge, I went the DIY route with the jank turned up to 11.
OfferUp had a few used food dehydrators, and I picked a Nesco model with a few trays for $20. The simplest models are not much more than a hair dryer blowing into a big chamber made up of a bunch of trays. In my case, I wanted a single big changer into which I could put the filament spool(s). After seeing people make plexiglass versions online, I landed on an even simpler solution: $2 posterboard, doubled over and taped together into a cylinder. This gave me a big comfortable chamber in which to dry several spools if I wanted. Now to test it.
I reused the thermostat from my sous vide for clove tincture in a Huckleberry cocktail. Placing the probe into the bottom of the chamber, I tested that an empty dryer would hold the right temp (based on this fantastic article about from Prusa). And I ran it for about an hour while I tweaked the alignment and tape seals with one spool. The improvised chamber wall held, luckily, and the green tape I used does not lose stickiness at these lower temps of up to 45C/115F. I'll update this post if the PETG drying at 55C/131F has a different result.
If this system were to break in any place, it would be on the on/off duty cycle I added to maintain a constant temp. Dehydrators are meant to run for hours without stopping. Getting the fan and heating element up cranked up takes work and wears parts out, and the constant-on model I purchased second-hand was probably not designed for this. The fan was a lot noisier than the rice cooker as it cycled on and off every 30 seconds as well, so it was very annoying. By playing with the thermostat settings, I was able to change the temperature range in which it would trigger the relay while still keeping the chamber between 40-45C/104-115F. This meant it took longer breaks and cycled less often. A win for longevity.
With the preliminary tests done, the only thing left to do was run it all night. As this thing was noisy, we put it in the farthest reaches of the house, but the center of the garage would probably have been smarter. An unknown appliance procured second-hand should be run supervised or in a fire-proof area in case it decides to melt down or short. Nothing happened, but it had me up all night checking it. In the morning, it had run for 8 hours, and I caught it at a cooling cycle at 43C/109F. The filament itself was pliable and felt much lighter. It had a rough texture like a dry sponge.It printed nicely as well with less stringing and no popping. The $20 dryer has hopefully saved more than a hundred dollars in filament from the garbage dump. A resounding success!
I'll weigh the next spool before and after to see how much water we're really taking off. And I'll hopefully be able to test it with PETG as well.
During the DEF CON 26 DC101 Panel, someone (probably highwiz) asked one of the n00bs they brought on-stage, "What makes you a hacker?" In the past, it has been used by bad actors as an aggressive question. Thoughtful types and artists have used it as a prompt. But here it was dripping with curiosity. "Why do you go to DEF CON?"
I'm more than a year out from a move that took me far from my hometown of Las Vegas to an adventure into the Pacific Northwest. Budgets, family and time being what they are, I too had to ask myself, "What makes you a hacker? Why should you go to DEF CON, again?" Obviously, moving two states makes it harder to go. Plane tickets are cheap enough in cattle-class, and I'm lucky to have family and friends in town upon which I can rely for lodging. But family illness and obligation are also considerations, and this feeling in the pit of my stomach topped it all off: the idea that I no longer belonged.
Ironically, this security-focused community is affected by deep insecurities. Concerns of legitimacy, competence, and belonging haunt us collectively, as do public examples of snake oil, burnout, and depression. Discussions of Impostor's Syndrome are almost cliche in their frequency. As is the mouth-agape disbelief following one of our rock stars admitting they second-guess themselves. This loose band of social misfits and punks emerged from in our cocoon of BBSes and IRC to be famously dysfunctional. We have had to exorcise #MeToodemons, and our unhealthy relationship with alcohol keeps many away for fear of their own safety. As a late-comer to DEF CON, I have not been personally affected by loss of friends in the community, but there's a reason Amber Baldet gave a talk on Suicide Interventions at DC21. Hackers in my cohort are maturing as well. Some of us are on their third career since the demoscene, and it has veered wildly away from any Information Security role. There has to be something that keeps us coming back to the desert in August. It sure ain't the unmistakable fragrance of Sunday morning talks.
It is a bit of a balancing act to maintain a conference that keeps drawing more and more people. As of this writing, DC28 is scheduled to use almost 400,000 sq. ft. of conference space in a brand new facility. Almost 30 villages with both broad and niche topics have formed, and each is a mini-con in and of itself. Along with this widening scope, there were public and repeated attempts by The Dark Tangent to reestablish DEF CON as a Hacker event and set it apart from the Information Security industry where so many of its attendees find employment. In the past, DT has publicly disinvited the Feds, and the run-up to DC27 saw another public clarification that while individual villages arrange their own sponsorship, DEF CON maintains no corporate sponsors. You can see the push and pull of "What makes you a hacker?" at the highest levels.
And so we approach a new year and a new DEF CON. Since DC19, I've grown with the conference. I started managing Toxic BBQ with the help of friends and this will be our fifth consecutive kick-off barbecue. People just show up to create an inviting space from scratch for anyone that can find it. I won a Black Badge with my son at DC 26 by solving crypto puzzles and have tried to contribute in equal measure since then. And yet there's this nagging feeling...
Ultimately, I've decided the gate-keeping question is not an important one to answer. What I give to and get from DEF CON keeps me going. I'm comes down to a desire to think things I have never thought before. I may not be able to show off like some, but I can gawk with the best of them at the Hacker Carnival. DC28's theme, Discovery!, is right out of my high school years when the internet promised the sum-total of human knowledge at our fingertips and all that we could do once those barriers dropped. Maybe we can celebrate by shedding our insecurities. Just for the weekend.
One part of a tiki flight, I was recommended to try this this based on the raspberries.
While the recipe as written requires a pacojet, I don't have $5000 just to get deliciously drunk. I tried an ice cream maker to make the slush instead with fantastic results. The instructions say to freeze the mix and rum separately and process together, but a spin in the ice cream maker brought it to just enough slush for a small batch.
The real winner here is the recommended rum. My first "drink until you hurl" experience was with coconut rum, and I've avoided the spirit ever since. The Zaya Gran Reserva aged rum has really caught me by the nose, however. It has just enough molasses to be delicious, and the aging has mellowed it considerably compared to its frat-boy cousin. I'll definitely be stocking this as a rum of choice (unless the book turns up something even better).
Three years ago in July, I completed Dan Boneh's online cryptography course with distinction through Coursera's Cryptography 1. Since then, I've had the opportunity to use and test cryptographic systems at work and for hobbies. Here are a few lessons learned when testing encryption.
I have found my fair share of bugs in the crypto we chose to use at work. I've gotten into a routine when testing encryption used for message authentication:
Test the same plaintext multiple times. Does it need to be different each time? How much of the MAC is different each time? It might help to explore the data your hashing function spits out as it can tell you how your hash function does what it does.
Replay it. How can a user abuse identical MAC'd data if they replay it at a later date? For a different user? Can you add items to the plaintext that will allow you to validate not only the data but the source or timeframe as well?
Ensure your hashes are detecting changes. Is your MAC rejected if you change the data at various places within the message?
Rotate the key. Do you need a hash to survive a key change? Usually you can just regenerate the data and re-MAC it, so figure out if you really need to use MACs over long lifetimes. They're easy to compute.
Generate a bunch at once. Is performance an issue with the service? Most hashes are built for speed, but is yours?
For each of these failure modes, I'm looking mostly for hints of weakness. I'm expecting pseudo-random noise, but how does my brain distinguish that from almost random noise?
There are many times when you need to generate a unique but random value but don't have the space to use a GUID. To evaluate if a solution will be "unique enough", check out the Birthday problem wikipedia page, and this table of probabilities in particular. Find out how many possible values exist (9 numeric digits = 10^9 ~= 2^30). Compare on the table with that value as the hash space size versus the number of times you'll be setting this value. This will tell you if the algorithm you want to use is sufficient. If you are making long-term IDs that can only be created once, you obviously want the probability of collision to be extremely low. If you can recover from a collision by creating a new transaction fairly readily, you might not need as much assurance. Ive used this to help drive a decision to increase unique token size from 13 to 40 characters, guide switching from SQL auto-numbers to random digits to hide transaction volumes, and ensure internal transaction IDs are unique enough to guide troubleshooting and reporting.
Time and again, the past three years have taught me that cryptography must be easy for it to be used widely. I've stayed with Signal for text messaging because it just works. I can invite friends and not be embarrassed at its user interface. It doesn't tick all the boxes (anonymity is an issue being a centralized solution), but it has enough features to be useful and few shortcomings. This is the key to widespread adoption of encryption for securing communications. Since Snowden revealed the extent of the NSA's data collection capability, sites everywhere have switched on HTTPS through Let's Encrypt. Learning more about each implementation of SSH and TLS in the course was both informative and daunting. I was anxious to get HTTPS enabled without rehosting the site on my own. Early 2018, Blogger added the ability to do just that through Let's Encrypt. It requires zero configuration once I toggle it on. I can't sing its praises enough. The content of this blog isn't exactly revolutionary, but this little move toward a private and authentic web helps us all.
Dan Boneh's Cryptography course continues to inform my testing. The core lesson still applies: "Never roll your own cryptography." And the second is how fragile these constructs are. Randomness is only random enough given the time constraints. Secure is only secure enough for this defined application. Every proof in the course is only as good as our understanding of the math, and every implementation is vulnerable at the hardware, software, and user layers. In spite of this, it continues to work because we test it and prove it hasn't broken yet. I'm looking forward to another three years of picking it apart.
A friend returned from San Diego Comic Con 2018 with an RFID bracelet used to track users in the Amazon Fire TV experience (on Twitter, #FireTVSDCC). This is a teardown of the bracelet after the event. At this time, I was unable to read from the bracelet.
The bracelet is fairly simple with a cloth band and plastic/paper tab threaded through. The closure is plastic and one-way. It bites into and mangles the cloth band if you attempt to remove, but you could probably shim it with tools and practice. Might be a fun thing for the Tamper Evident Village if it turned out events were trying to use this for access control like plastic self-destructing wristbands.
The back contains a serial number. I would like to see if this serial number would match the data read off the tag.
Separating the badge by prying them apart, I spot the prize: an adhesive RFID tag placed between the glossy plastic covers. It appears to have a model number of "CXJ-040" in the center of the tag. It uses a circular antenna. CXJ is the initials of Shenzen manufacturer Chuangxinjia. Their product pages show manysimilarwristbands in a few different frequencies.
The tag didn't respond to my Android phone, so it is not a Mifare or similar. Hopefully I can find a reader at the local Hackerspace or DEF CON 26.
Above is Dan Kaminsky's keynote at the inaugural DEF CON China. It was nominally about Spectre and Meltdown, and I thought it was immediately applicable to testing at all levels. Here are some moments that jumped out at me:
On Context:
"There's a problem where we talk about hacking in terms of only software...What does hacking look like when it has nothing to do with software." 1:55
"But let's keep digging." Throughout, but especially 5:40
"Actual physics encourages 60 frames per second. I did not expect to find anything close to this when I started digging into the number 60...This might be correct, this might not be. And that is a part of hacking too." 6:10
"Stay intellectually honest as go through these deep dives. Understand really you are operating from ignorance. That's actually your strong point. You don't know why the thing is doing what it is doing...Have some humility as you explore, but also explore." 7:40
"We really really do not like having microprocessor flaws...and so we make sure where the right bits come in, the right bits come out. Time has not been part of the equation...Security [re: Specter/Meltdown] has been made to depend on an undefined element. Context matters." 15:00
"Are two computers doing the same thing?...There is not a right answer to that. There is no one context. A huge amount of what we do in hacking...is we play contexts of one another." 17:50
[Re: Spectre and Meltdown] "These attackers changed time which in this context is not defined to exist...Fast and slow...means nothing to the chip but it means everything to the users, to the administrators, to the security models..." 21:00
"Look for things people think don't matter. Look for the flawed assumptions...between how people think the system works and how it actually does." 35:00
"People think bug finding is purely a technical task. It is not because you are playing with people's assumptions...Understand the source and you'll find the destination." 37:05
"Our hardest problems in Security require alignment between how we build systems, and how we verify them. And our best solutions in technology require understanding the past, how we got here." 59:50
On Faulty Assumptions:
"[Example of clocks running slow because power was not 60Hz] You could get cheap, and just use whatever is coming out of the wall, and assume it will never change. Just because you can doesn't mean you should...We'll just get it from the upstream." 4:15
"[Re: Spectre and Meltdown] We turned a stability boundary into a security boundary and hoped it would work. Spoiler alert: it did not work." 18:40
"We hope the design of our interesting architectures mean when we switch from one context to another, nothing is left over...[but] if you want two security domains, get two computers. You can do that. Computers are small now. [Extensive geeking out about tiny computers]" 23:10
"[RIM] made a really compelling argument that the iPhone was totally impossible, and their argument was incredibly compelling until the moment that Steve Jobs dropped an iPhone on the table..." 25:50
"If you don't care if your work affects the [other people working on the system], you're going to crash." 37:30
"What happens when you define your constraints incorrectly?... Vulnerabilities. ...At best, you get the wrong answer. Most commonly, you get undefined behavior which in the presence of hacking becomes redefinable behavior." 41:35
"It's important to realize that we are loosening the assumption that the developer knows what the system is supposed to do...Everyone who touches the computer is a little bit ignorant." 45:20
On Heuristics
"When you say the same thing, but you say it in a different time, sometimes you're not saying the same thing." 9:10
"Hackers are actually pretty well-behaved. When hackers crash code...it does really controlled things...changing smaller things from the computer's perspective that are bigger things from a human's perspective." 20:25
"Bugs aren't random because their sources aren't random." 35:25
"Hackers aren't modeling code...hackers are modeling the developers and thinking, 'What did [they] screw up?' [I would ask a team to] tell me how you think your system works...I would listen to what they didn't talk about. That was always where my first bugs came from." 35:45
On Bug Advocacy
"In twenty years...I have never seen stupid moralization fix anything...We're engineers. Sometimes things are going to fail." 10:30
"We have patched everything in case there's a security boundary. That doesn't actually mean there's a security boundary." 28:10
"Build your boundaries to what the actual security model is...Security that doesn't care about the rest of IT, is security that grows increasingly irrelevant." 33:20
"We're not, as hackers, able to break things. We're able to redefine them so they can't be broken in the first place." 59:25
On Automation
"The theorem provers didn't fail when they showed no leakage of information between contexts because the right bits went to the right places They just weren't being asked to prove these particular elements." 18:25
"All of our tools are incomplete. All of our tools are blind" 46:20
"Having kind of a fakey root environment seems weird, but it's kind of what we're doing with VMs, it's what we're doing with containers." 53:20
On Testing in the SDLC
"We do have cultural elements that block the integration of forward and reverse [engineering], and the primary thing we seem to do wrong is that we have aggressively separated development and testing, and it's biting us." 38:20
"[Re Penetration Testing]: Testing is the important part of that phrase. We are a specific branch of testers that gets on cooler stages...Testing shouldn't be split off, but it kinda has been." 38:50
Ctd. "Testing shouldn't be split off, but it kinda has to have been because people, when they write code, tend to see that code for what it's supposed to be. And as a tester, you're trying to see it for what it really is. These are two different things." 39:05
"[D]evelopers, who already have a problem psychologically of only seeing what their code is supposed do, are also isolated from all the software that would tell them [otherwise]. Anything that's too testy goes to the test people." 39:30
"[Re: PyAnnotate by @Dropbox] 'This is the thing you don't do. Only the developer is allowed to touch the code.' That is an unnecessary constraint." 43:25
"If I'm using an open source platform, why can't I see the source every time something crashes? ...show me the source code that's crashing...It's lovely." 47:20
"We should not be separating Development and Testing... Computers are capable of magic, and we're just trying to make them our magic..." 59:35
Misc
"Branch Prediction: because we didn't have the words Machine Learning yet. Prediction and learning, of course they're linked. Kind of obvious in retrospect." 27:55
"Usually when you give people who are just learning computing root access, the first thing they do is totally destroy their computer." 53:40 #DontHaveKids
"You can have a talent bar for users (N.B.: sliding scale of computer capability) or you can make it really easy to fix stuff." 55:10 #HelpDesk
"[Re: Ransomware] Why is it possible to have all our data deleted all at once? Who is this a feature for?!... We have too many people able to break stuff." 58:25
I took Ethan to the event run in parallel with DEF CON, R00tz Asylum. I think he had a blast as they covered a lot of traditional hacker topics at multiple levels of complexity. The highlights are below.
Structure
The event was held in the Crown Theater at the Rio. It was about a 10 minute walk from DEF CON proper. The separation was nice as it made for a more quiet and contained experience. The stage was occupied by a speaker almost all the time. Spread around the perimeter (mezzanine?) were tables with activities that changed every day. Kids could choose to listen, play or work on challenges. Most activities stayed the entire day, though some were more transient.
This setup was advantageous for my son. He has little ability to focus on any one thing for an extended period of time, so the variety of activities was nice. Much like its parent conference, R00tz Asylum did well when it focused on hands-on learning. Toool, Google and Wickr held contests and learning opportunities that pushed attendees and their parents to participate together. In particular, Ethan loved the puzzles, and I finally got him to solder something. He did a bang-up job.
Speakers
The speaker experience was less than optimal with a few notable exceptions. The stand-outs were Gene Bransfield's hilarious "Weaponizing your Pets" and Meredith Patterson's engaging activity "The Telephone Game" about Man-in-the-Middle attacks. Special mention goes to @muffenboy and Esau Kang for being kid attendees and speakers. For the rest, it would be good to learn that speaking to children is not the same as speaking to hackers, and most talks were too technical, lacked a hands-on component, and thus ended up being torture for the little ones. From speaking with the organizers, I can tell this is something they are trying to focus on next year.
The Gift
R00tz Asylum is the opposite of DEF CON in one respect: it relies on sponsors to add pizzazz and to make ends meet. One of those traditions that may or may not hold in coming years is the gift of a hackable piece of technology to attendees. This year brought ASUS Chromebooks care of Google. My son was enthralled, and I spent most of the conference convincing him to get off the Chromebook and out to the activities. By the end of the conference, we had Linux in addition to Chrome, and we were running Wireshark thanks to perseverance by Joe and Chris, a father/son team. This effort won Chris a trophy, even. My son begged me to put Minecraft on there, but then quickly forgot how to get back to it and reformatted his Chromebook undoing all our hard work. Hats off to Google, and congrats to Chris on the win.
Hardware Hacking
By far, my favorite part of the conference was the Hardware Hacking table. Not only did the goodie bag include a HakTeam Throwing Star LAN Tap, but a table full of old equipment was available from which attendees could rip apart and salvage components. The LAN Taps were used in an activity that taught wireshark and packet sniffing. The hardware component salvage table was exploited for speakers, LEDs, gears and motors for all sorts of toys. I am definitely bringing projects for Ethan next year. I already recommended the salvage table to the official DEF CON Hardware Hacking Village. Las Vegas thrift shops may see a run on their printers, VCRs and routers before next year's conference.
Lock picking
The one talk and table I was surprised that Ethan was interested in was from Toool. Their interactive 101 talk caught his attention, and we worked on a lock at their companion activity table. Though he ended up losing interest before successfully opening a lock, it gave me a clue of the type of activity he could do on his own between conferences.
Going Forward
I would definitely recommend any hacker parent to bring their child to R00tz Asylum. Its expanding and evolving to be a great summer camp weekend that dovetails with the DEF CON experience. As the organizers ger more experienced, I expect the content to grow and change to fit the kids and their interests. We all started somewhere, and I hope R00tz is that start for the next generation. I started a subreddit for R00tz, though it hasn't taken off.
As for Ethan and I, we are preparing a talk on how to hack Skylanders figures. We hope it will be a fun combination of encryption, hardware hacking and games that will draw the attention of attendees and inspire them to really dig in and explore the technology that is used around them every day.
This post is part of a series about building electro-mechnical PIN-cracking robots, R2B2 and C3BO.
This is a proof of concept for @JustinEngler's C3BO (https://github.com/justinengler/C3BO) using transistor controlled relays. It was prototyped by modifying Blink from the Arduino sample project.
In the video, You'll notice I've replaced the touchpad for your finger with a wire to the headphone jack's ground as the circuit ground. The two pieces of copper tape were no longer sticky enough to stay by themselves, so I am holding them down. They press two and 5 with about 8 key presses per second.
Note: This is part of the Project Write-up for OFBC: One Fluorescent Beer Coaster
Circuit Design
I began the search for parts to fit the Instructable, and I realized I had a lot to learn about each part. To match the circuit, we searched Frys, Radio Shack, ebay, Mouser and many others online. For an unproven design, going with an unknown module and supplier wasn't an option. Instead, we found all the components we needed on Adafruit.
Lithium Ion batteries must be matched to their charger to avoid dangerous heat and combustion incidents. Capacity is determined by the Amp-hours rating. The LEDs I was targeting were a max of 350mAh, so I looked for batteries had to be over 1000mAh to get the targeted 3 hour run time.
The charger choice was mostly driven by battery choice. We didn't feel like we could provide a mounted Micro-B port in the time available, but a charging circuit mounted to a full sized USB plug was a good substitute. With the shell, we would provide an easily removable bottom and 'mouse hole' to allow the charger to live outside the case.
Most LED projects online mention heat at one point or another. To get ahead of this concern, we opted for a heat sink-mounted super bright LED. This same LED bead was seen on ebay without a heat sink, but we didn't want to screw anything up due to inexperience and opted for the more expensive package for the first run.
The Driving Circuit was a simple buy, and the choice also dictated our resistor purchase. The key value from the MOSFET we purchased was Gate Threshold Voltage. The voltage drop across R2 with the battery we bought had to match this value. Using V = IR, R = V/I = 1.5V / 350mAh ~ 4 ohms.
Once the materials were in hand, the breadboard went well. It worked the first time! While we waited for batteries to charge, we used a simple brick of 4xAA batteries. The beauty of the driver we chose is that it can drive LEDs using any voltage source over the target voltage.
Using the breadboard and schematic, we attempted a protoboard version of the circuit. This was a complete mess, and it took us a lot longer than it should have. However, by the end of a single prototyping session, we turned a jumble of components into a working light. One high/low note happened when we wanted to minimize the number of connections but didn't have the right resistor for R2. We twisted two resistors together to get close to R2's 3.5 Ohms and put them through the same hole on the protoboard. Instant parallel resistor!
Conveniently, the whole project fit under a Ziploc Container lid. A little bit of hot glue, another section of protoboard with a hole in the middle, and charged batteries got us our first complete prototype! It was brighter than the equivalent cell phone flash and had excellent diffusion through some purpose-bought Smirnoff Ice.
A friend has a few Elo Touchscreens from a past venture, and I have racked my brain trying to figure out a use for them. After giving up on Android PCs, I took a stab with a Raspberry Pi Model B running the Raspbian image from Noobs. Two obstacles presented themselves:
The Raspberry Pi only outputs HDMI. For now, I'm going to try an HDMI to VGA converter. Better to get this thing off the ground than hem and haw about a 'better' solution.
The touchscreen is inverted. For this, I installed the xinput-calibrator tool per the instructions on the Raspberry Pi forums given by msmithy12 and a helpful config guide:
tar xvzf (downloaded file) cd (downloaded file) ./configure make sudo make install
Then, from the menu: Preferences/Calibrate Touchscreen
Do not immediately follow the instructions given when you run calibration (place the calibration in a /etc/Xll/...). Doing so borked my Raspbian install. Instead, create the file specified in /usr/share/X11/xorg.conf.d/. I ran "sudo leafpad 99-calibration.conf" to create and edit the file. After dropping in the calibration indicated, I restarted and found out it stuck. Woo hoo!
I will update this space with my progress. Currently, the setup is:
Raspberry Pi Model B ($35)
Elo Touchscreen ET1939L (Pre-owned)
BYTECC HM-VGA005 HDMI-A to VGA Female Adapter/Converter ($20)
1 x WiFi Dongle (Ralink RT5370 chipset) ($10)
Lessons Learned
Single User Mode could have beenused to save my Raspbian install. It can be entered by adding init=/bin/sh to cmdline.txt. I was using Noobs, so holding Shift while the PI boots got me into the editor.
Note: This is part of the Project Write-up for OFBC: One Fluorescent Beer Coaster
The Idea
As night descended at Toxic Barbecue at DEF CON 21, everyone was working through the meat and alcohol they'd consumed much too fast and in much too large a quantity. Rather than move the party somewhere else (Las Vegas' Sunset Park is safe at night, right?), we began to experiment with cell phone screens, then their flashes. The lights were bright, but they were also extremely narrow in focus.
The Liter of Light project gave us an idea to use a liquid to diffuse the light. As there was still copious amounts of alcohol left behind, we started experimenting. This 'research' lead us to decide that Smirnoff Ice was the best diffuser. Filtered beers were awful due to both the dark bottles absorbing light as well as the liquid having no solids to scatter any that was left. Smirnoff had the clear bottle and label as well as a ton of solids from the included fruit juice. As this was a hacker party and not for frat boys, we had plenty left. The misogynists among us named them 'Bitch Lights' after the colloquial term for Smirnoff Ice: Bitch Drinks. We had our product; now we needed to separate it from the phones.
Research
DEF CON 22 planning made us realize that we needed to make good on our promises made while too intoxicated to realize we knew nothing about how LEDs actually work. First stop? The local Hackerspace, of course. SYN Shop is in downtown Las Vegas. Multiple forum members are lighting and electronics techs on The Strip. They pointed me towards specific packages, drivers and batteries. I took this foundation and boiled it down to specifics. I wanted the light to be composed of the following elements:
Super Bright LED (1W, 100 lumens)
LED driving circuit
Battery (3-4 hours of time)
Charging circuit (USB)
Switch to turn it on
3D Printed Body
Armed with search terms from the forum, I found a wealth of helpful links. I found LEDpackages that fit the "Super Bright" definition all over the web. I learned a ton about batteries and chargers (did you know Sears still exists and has an online store?). The most helpful site was Instructables. There, I found several LED driver circuits that I actually understood. After a trip to Frys left me bewildered with options, I learned to better read datasheets. Finally, I had a working circuit design.
I built a copy of Justin Engler's Delta Bot R2B2. Here's how I did it with a revised parts list.
Inspiration
Justin Engler and his iSEC Partners team presented his PIN punching robot at DEF CON 21. Even though it was, by his own admission, a last resort in cracking phone PINs, it received coverage in Forbes and other outlets.
Build
The 3D prints from my brother's Replicator came out well. The dimensions were correct overall, but I had to do some filing to get the mounting bracket to slot together. The servos I used required me to file out the slots a bit as well. The spokes from my servo mount were a little large, so I filed those down too. Overall, it wasn't too tough to fit everything together. When I build another one, I need to see if my problems were caused by the STL files, how the G-Code was generated or the calibration of the printer itself.
The local RC shop called Hobby People had most of the small and moving parts. Servos, ball joints and such came in at under $30. Lowe's had the right sized all-thread to finish the job. One thing about the construction was that I originally bought 10mm hex cap screws to join the ball joints to the biceps. The way the bicep is built, though, the joint tends to hit the side of the bicep and limit the range of the effector. To solve this, I moved the ball joints outward with small washers. This made the 10mm hex caps too short, so I went with 15's instead. Redesigning the bicep to free up movement might resolve this problem. I slipped a metal stylus pen through a rubber grommet and effector. The stylus was grounded with an alligator clip onto the breadboard.
The rest of the robot (as you can see in the pic) are an Arduino Uno, a small breadboard and a four-legged stand I put together from a 1x2 and some angle braces. The robot is held to the frame by a fender washer through the central hole of the mounting bracket. The sketch had to be modified with the correct measurements on the actual robot. Most everything matched, so that built my confidence. Once I uploaded the sketch, I played around with the machine code and made it dance. This is when I found out the ball joints were binding against the bicep. I also dropped the robot, and the short hex caps made it go eveywhere. D'oh!
I forked and cloned Justin's github to prep for writing some code and tidying up the notes. Rather than cracking phone PINs, I plan to use this to punch card PINs on PIN Pads used in credit card processing. I don't think I'll need the OpenCV code, so I'll have a blind version of R2B2 up in my own repository once I learn enough Python to be dangerous.
Finally, Marginally Clever has a new version of the delta bot that uses laser cut parts. The R2B2 that Justin demoed at SXSW seems to have been made from this version out of acrylic. Snazzy! This comes with its own platen and looks mighty sturdy. I might have to grab one and give it a spin.
Recently helped a friend modify an Obi Wan Kenobi .45 scale light saber into an e-cig. The model is similar to the one in this Ebay listing, and is getting pretty rare. They got the idea from a forum post that did a much less elegant job, but contains a slightly bigger battery. Here are brutal steps for our build:
Get the model disassembled. You should end up with:
An end cap
Chromed plastic 6 spoke pommel cap
A die cast metal shroud
Plastic insert for metal shroud
Belt loop with screw
Red and brass buttons with screw
Die cast fore end
Plastic insert for metal fore end
3x chromed plastic pins that hold the plastic insert inside the metal fore end
Find a battery. We were able to fit a 180mAh long cylindrical 3/8" diameter one into the case. It had a button on one end that fit just right so the fitting just comes to the fore end and a hole can be opened in the plastic insert for the metal fore end to allow access.
Vice the metal fore end by the wider cap (and not the base) into no-mar jaws and drill out the central hole with a 3/8" bit. I would suggest a drill press for this operation, though a hand drill will do in a pinch. A Dremel did not work for this due to hole size. The metal is aluminium, so it shouldn't be too rough to do on most metal bits if you go slow and break your chips. NOTE: we busted the spindly base off the wider fore end and snapped the 3 connecting bars by holding the fore end in the vice by the body of the fore end and not the cap. They went back on with superglue after we matched up the shear patterns, but avoid this if at all possible.
Gently vice the plastic insert to the fore end and drill it out to 3/8" as well. While you have it disassembled, drill the hole for your the button on your battery as well. NOTE: be careful not to deform the plastic insert in the vice.
To reduce rattle inside the case, wrap some electrical tape around the parts of the battery that don't precisely fit (and are hidden in plastic).
Attach a wooden or metal extension on the battery cap and drill it so the belt loop screw can be reinserted. We used wooden dowel screwed onto the plastic cap at the end of the battery, then epoxied in place. The belt loop screw holds the metal shroud and plastic fitting to the battery in the same manner as the fitting and battery button hold the fore end tight to the battery.
A hackable iOS App used to teach the OWASP Top Ten Mobile App Vulnerabilities. Great tool to catch up with mobile security and secure application design.
Thanks to SYN Shop, the Las Vegas Hackerspace, I completed a bench top power supply. I took a class that helped me build one from a kit. The kit itself produced a 5v out and a configurable out that I ended up making 8.5 for Arduino.
One of the challenges of the class was to take that kit and enhance it. I removed the resistor on the configurable channel and replaced it with a 10K Ohm potentiometer from Radio Shack. This allows me to configure it for between 2 and 14.5 volts!
Some time later, I got tired of the alligator clips I used to connect to the two rails. I replaced them with a barrel connector and switch. My initial schematic was woefully flawed, however. If I had completed it, I would have shorted the rails to ground through the switch, blown the fuse, and possibly smoked the voltage regulators. Yeesh.
Thanks again to SYN Shop and Javid, the teacher who's kit made this possible.
