# When Open Source Hacking Meets Safe-Cracking – InApps 2022

When Open Source Hacking Meets Safe-Cracking – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn When Open Source Hacking Meets Safe-Cracking – InApps in today’s post !

## Read more about When Open Source Hacking Meets Safe-Cracking – InApps at Wikipedia

You can find content about When Open Source Hacking Meets Safe-Cracking – InApps from the Wikipedia website

Geeks are fascinated by safe-cracking — and the lessons that physical security systems can teach us about virtual systems. But are there new lessons in our age of cheap and open source automation? Or does it simply re-confirm that age-old open source wisdom — that given enough eyeballs, all bugs are shallow.

Our story begins with an engineer at SparkFun whose wife gave him an unusual Christmas gift — a locked safe with no combination. “She knew I was really into puzzles and locks and robotics,” Seidle told WIRED later, and in a blog post this spring he jokingly summarized his methodology. “Step 1) Get a safe that hasn’t been opened. Step 2) Deploy robot army.”

Seidle tracked the position of his safe’s dial with a home-brewed Arduino-powered robot — or at least identified how far the dial turned from its original position — mechanically twisting it through every possible combination. But with three two-digit numbers, there were a million possible combinations — and even trying one every 10 seconds would still have taken almost four months. Fortunately, this particular brand of safe had a built-in margin of error. “If one of the numbers in the combination is 53 then 52 and 54 will also work…” Seidle writes. “This quickly reduces the domain to 33 * 33 * 33 = 35,937 combination.”

And it turns out that that last dial is much easier. If you already have the first two digits, you could simply spin the dial. Safe manufacturers try to make this harder by stopping the spinning with 12 indents — but that actually made things easier. That last ident — for the final number in the combination — is apparently .01 inches narrower. That means it can be identified by the dial-turning robot through a series of careful automated measurements, leaving just 33 x 33 possible combinations — that is, 1089.

Read More:   Meteor Galaxy Containerizes JavaScript Apps for Full-stack Management – InApps Technology 2022

Seidle demonstrated his device on a Las Vegas stage last week at the annual DEFCON security conference. In a triumphant moment, the device beeped, displayed the combination — and ended its search (drawing an enthusiastic round of applause from the audience). “The team joked the safe could have been cracked sooner,” reports the BBC, “but they had to fill their 45-minute time slot.”

The BBC also points out that though some SentrySafe models have an additional lock that’s opened by a key, “the team was able to unlock it by using a Bic pen.”

## Opening Safes with Open Source

What’s interesting is all the parts cost a total of \$200 — and in a fitting nod to our modern era, they were created with a 3-D printer. Seidle’s blog post even includes a “Build Your Own!” section, calling it “the SparkFun Safe Cracker.”

“You’ll need a 3D printer, soldering iron, and the ability to write code and modify 3D files to fit the type of safe you’re trying to open…”

In a four-minute video report, WIRED says the experiment proves “how easy it’s becoming to leverage inexpensive open source hardware and code to crack historically dependable analog security systems.” But Seidel suggests it be viewed as the open source mentality applied to other areas, where the discoveries are shared for the common good.

“Maybe, safe manufacturer, you should know about this, so you can make the safe’s better. That’s sort of the mentality of open source.”

And he predicts security will improve as that open source mentality is embraced. “It’s not about, ‘Hey, check out what I can steal,’ it’s about, ‘Hey, found this thing, and I want to share it with you. I want to point out this issue so that you can make this more secure.’”

Or, as the Denver Post put it, the demo’s goal was “to show the changing nature of physical security, which should prompt vendors and companies to take note and make their own improvements.”

That’s a philosophy echoed in a comment on Hacker News. “The improvement curve of such robots will be interesting to watch over time… especially to the extent that the improvement is partly in the innovative hands of the hacker/maker community as opposed to just a few commercial companies…”

In fact, public-spirited lock-picking is a tradition that dates back at least to Richard Feynman, the Nobel Prize-winning physicist who worked at the Los Alamos Lab that developed America’s first nuclear weapons during World War II. “Los Alamos was a very cooperative place,” Feynman recalled in his autobiographical book Surely You’re Joking, Mr. Feynman, “and we felt it our responsibility to point out things that should be improved.”

Read More:   Make a GitOps Workflow Using InfluxDB Templates – InApps Technology 2022

Feynman first demonstrated that he could successfully remove files from several locked cabinets. New combination locks were promptly installed — which Feynman took as just another challenge. “I love puzzles,” Feynman remembered in his book. “One guy tries to make something to keep another guy out; there must be a way to beat it!” He soon discovered the same thing that would be exploited 70 years later by SparkFun’s robot — that the combination locks were lenient. In Feynman’s case, if the correct number was 69, it would actually open for any number within two — so, 71, 70, 69, 68, or 67 and “With twenty such numbers on a wheel of 100, that was 8,000 possibilities instead of the 1,000,000 you would get if you had to try every single number.”

Feynman also employed other safe-cracking techniques that are still in use today in our digital world — like guessing which combinations were most likely to have been chosen. And about 20% of the safes in his building were even still using the original factory-default combination.

Safe-cracking continues to be a popular topic among geeks of today. Seidle’s blog post this spring also referenced a 2011 DEFCON talk on safe-cracking which reminds viewers of this generation’s newest tool. “Robots are very good at repetitive tasks,” says presenter Eric Schmiedl, “and nothing is more repetitive than trying every combination on the dial.”

In fact, Seidle’s project is ultimately just the latest in a long line of homemade safe-cracking robots. Someone on Reddit cited the enterprising young man who built the LockRacker after “past experiences of forgetting all of my locker combinations and having to buy new locks.” In 2015 GadgetReview was also describing a device named the LockCracker developed by students at Franklin W. Olin College of Engineering in Needham, Massachusetts. And several years ago two MIT students even built a laptop-controlled robot that could open high-security safes.

But maybe there’s ultimately some larger lessons to be learned. One geek who was particularly interested in the safety of real-world locks was Matt Blaze, the creator of the original Cryptographic Filesystem (CFS) for Linux. Cryptographer Gus Simmons (born in 1930) once gave a dual-key Abloy cylinder to Blaze, which became one of his most valued possessions. And in 2004 Blaze wrote a book called Safecracking for the Computer Scientist, delving into some specific lessons about security that safe-makers have learned with “the luxury of generations of hindsight.”

Read More:   JavaScript Framework Unpoly and the HTML Over-the-Wire Trend – InApps 2022

Blaze writes that “when compared against their counterparts in information security, the mechanisms that protect safes are remarkably successful. Few weaknesses in physical security admit the kinds of catastrophic failures common in computers and networks, in which a low-risk, low-cost attack can yield a high-value and easily replicated benefit.

“Even the most sophisticated attacks against safes, whether involving force or lock manipulation, almost always entail at least some risk of exposure. Relatively accurate estimates of the time and other resources required for various kinds of attacks make it possible to tightly optimize effective physical security systems and to coordinate complementary security mechanisms.”

Blaze adds fairly that “Physical security has been studied for far longer than information security, of course, and the trade-offs between resistance to attack and the cost of protection are relatively well understood.” But another (and perhaps more important) advantage is a “relatively stable technological base,” which allows safe-makers to create precise definitions of the kind of attacks they’re expected to deter. Safe-makers can consider the “time for successful attack” — which is much more difficult to gauge for computer security. “The usual design principles of computer and communications security consider a system to be secure only when the work factor is so large to make any possibility of attack completely infeasible (e.g., requiring turning every molecule in the solar system into a supercomputer).”

So where does that leave us now?

Some suggest that the best stance is a critical eye to our illusions of security. Shortly before taking the stage at DEFCON, Seidle shared a similarly pessimistic conclusion about physical safes. “No matter how much money you spend on a safe, nothing is impervious,” he told the BBC, prompting Mashable to conclude glumly that “essentially, nothing can be kept out of reach from a dedicated hacker. Not your computer, not your cell phone, and definitely not whatever it is you keep in your safe at home.

“Consider yourself warned.”

Source: InApps.net

Rate this post
Content writer

### Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

## How Low-Code Development Platform Helps Enterprises

October 31, 2022 by Tram Ly

## 5 Cases you don’t need a JavaScript Framework

`Success. Downloading...`