Arduino autodialler (brute force safe cracker)

Community Jobs and Paid Consultancy
1

Hi everyone!

Let me preface my post by saying that I DO NOT commit any crimes with my skills (or any crimes for any reason for that matter) (NEVER HAVE & NEVER WILL) , nor to I intend to - I work in a job that requires extensive background checking and my job and life/reputation are too important to me to even consider doing anything criminal - not to mention breaching my own ethics. I feel very strongly about theft, and feel that thieves (particularly those who steal from individuals) are the lowest of the low.

I don't have a great deal of experience building Arduino projects, but I do have experience tinkering with locks (as a hobby). I love the challenge of opening a lock - there's something very thrilling about it.

What I would really like to build is a safe auto-dialler/brute force combination cracker/robotic safe dialler - similar to the following:

-ITL2000 Auto Safe Dialer ITL 2000 - YouTube
(commercial version)

-Wayback Machinehttp://web.mit.edu/kvogt/www/safecracker.html#WhatwasInside
(a project undertaken by a couple of MIT students, using a microprocessor and optical encoder and stepper motor (interfaced to the combination lock with a piece of rubber tubing)

My motivation/s - in my town, we have an ex government furniture store that sells all kinds of things, including safes. The ones they know the combination for are very expensive. The ones they've lost the combos for - just the price of scrap metal. I would really like a safe for our house, so I can put our goodies in it when we go away for peace of mind. Secondly, the idea of building such an incredible device is very exciting to me.

I understand what's required from a locksmithing perspective, but don't have enough skills to build the device itself. I'm hoping to collaborate with someone who has the skills to pull of the Arduino side of things.

There are some considerations that will optimise the software, the main being that due to the physical constraints of the locks themselves, a number of combinations can't actually be used due to the physical constraints of the mechanism - these combinations can be excluded (there are a number of calculators to perform this for each type of lock). It would be great to be able to have some form of method of:

-changing the lock type/mechanism to adjust the way in which dial is turned accordingly (e.g. Some locks have 4 'discs', others three
-altering the amount of degrees the stepper motor has to turn to reach each combination (i.e. The distance between each number on the combo dial)
-the degree of error tolerance of the lock (almost every lock will allow a certain amount of error when dialling combinations - e.g. 1-2 numbers 'off' the correct number) - this also allows the number of combinations that have to be run through significantly reduced

From a page describing the project:

"We used a custom stepper motor to rotate the dialler head. The dialler head transmits torque to the dial via a piece of heavy duty surgical tubing. The stepper motor we chose has more than enough resolution to implement our algorithm, but it's not quite as fast as it could be.

The stepper motor shaft is also connected to a high resolution optical encoder for position feedback. The encoder is mainly used to detect when safe is successfully opened. The torque required to open the safe when the correct combination is entered is much higher than the maximum torque of the stepper motor, so the encoder is programmed to report when the position error exceeds a certain threshold. Basically, the stepper motor stalls and the encoder flips out if the safe actually opens."

So - is anyone interested in getting together on this? :slight_smile:

2

Sounds like great fun! I'd be happy to help. I have experience with locks, Arduino, steppers and programming. I probably have much of the necessary hardware in my possession already.

It would be nice if you happen to be in or near Eastern Massachusetts, USA. It is much easier to collaborate in person.

3

how does a typical code looks like? I mean how fast do you expect to find the code.

if the code exists of 4 numbers between 0 and 100 you have 100.000.000 possible combinations.
Checking one combination takes 10 seconds?

==> 1.000.000.000 seconds worst case,
Lets say on average 200.000.000 (because many combinations are not possible)
that's 2000 days ==> 5 years..

not to discourage you, but to make expectations realistic.

4

Thanks for the replies guys!

Unfortunately, I'm all the way down in Australia, so it may be a case of some vidconferencing and emails!

In response to robtillaart - I understand your sentiment mate, but it's actually not beyond the realms of possibility - these devices already exist, and usually it takes 24-48 hours to crack a combo (surprisingly). This figure stands true for both commercial varieties and those made by people like the two guys at MIT. With the appropriate stepper motor, from my research, it takes about 5 seconds to crack a combo.

Most locks have 3 dials, which means 3 numbers in the combo (of between 1-100) e.g. 42-56-88. Taking into consideration that a HUGE number of impossible combinations can also be excluded as well (due to the physical constraints of the locks, they will actually prevent you from setting a combination that uses a part of the disc that is too close to the gate slot).

I understand that worst case, yes - it could take a very long time to crack a combo. But... it really doesn't seem to. I would love to get in contact with Kyle Vogt (the MIT man himself) to see what he thinks about what you have to say - it does seem pretty unfeasible at first thought, doesn't it.

Alternatively, one other thing that could be built is an automatic lock-manipulation assistant (might be more difficult though!) - basically, there are imperfections in almost every safe lock that allow you to determine when the lever (the part that pulls open the bolt (after the fence falls into the gate) is touching either side of the gate. This contact point (you need to find either side of the gate for each wheel/disc) can be detected by several methods - a change in the torque required to turn the dial, a faint clicking sound, or by feeling a 'click' through the dial itself (or a combination of these).

By determining and graphing left and right contact points, basically, you can determine where the 'middle' of the gate sits in relation to the combinations, and hey presto, you have the combination number for each wheel! This method is called 'lock manipulation (real pros can do it by hand).

I would think that some form of sensors could be used to determine these contact points for each wheel, and with the appropriate logic coded, could also calculate the most likely combo number for each wheel/disc in the lock. The most difficult part would be feeding to the board at which number you're actually sitting on (and keeping track of this) - but could probably be done with a servo/stepper with appropriate resolution (or using this to move the safe combo dial, and using a rotary encoder to keep track of the number you're on).

Thoughts?

5

Can you explain how the physical mechanism reduces the number of posibilities?

I expect the first turn has all 100 possibilities,
the second one has about 80 (or so to prevent conflict with position of first lock disk)
The third one has only about 60 (prevent conflict with 2 disks)

100x80x60= 480.000 so about half a million combo's

How fast can one check one combo? (what do you expect)

One has to set the first two numbers and then one could step one position for the 3rd disk (quite fast) at the time.
so most of time is consumed by setting disk 1 and 2 ...

becomes more feasible. :wink:

6

So if human safecracker can detect a difference in safe's lock tumblers clicks , as seen in many movies, how unrealistic is a machine controlled sound detector?
Perhaps little FFT analysis using Arduino as stethoscope?

And yes, there is ready to run code for Arduino FFT somewhere on the web.
FFT speed ? I bet your mechanical stepper interface will not be able to keep up with the FFT analysis.
Cheers
Vaclav

7

Vaclav:
So if human safecracker can detect a difference in safe's lock tumblers clicks , as seen in many movies, how unrealistic is a machine controlled sound detector?
Perhaps little FFT analysis using Arduino as stethoscope?

And yes, there is ready to run code for Arduino FFT somewhere on the web.
FFT speed ? I bet your mechanical stepper interface will not be able to keep up with the FFT analysis.
Cheers
Vaclav

You know, I'd be willing to bet it would destroy the speed of any brute-force cracker. It's not entirely about sound in this case (although in all the movies you see people using a stethoscope to crack safes) - it is just one way in which the imperfections in manufacturing of the discs may 'give away' their secrets.

It's also massively to do with a change in the 'feel' of the combination dialler (which will often present as a change in torque required to operate the dial) - to detect this I'm assuming we'd need a very sensitive rotary encoder.

Normally, this type of software will produce a set of graphs of the left and right contact points, which sometimes requires human analysis to 'make a call' about which is the most likely combo (out of two or three possibilities).

So, I guess what I'm saying is, when calculating the combination from all those detected middle points (i.e. in the centre of the left and right contact points), we would not want to lose all the other 'possibilities' - something like a probability list would be good.

Is it even feasible to get an arduino to create a graph, which can then be printed? The graph shows at what points on each disc the contact points are found (there's one for the left contact points, and one for the right).

8

I am still of the opinion that the "safecracker" should be able to directly identify the code.
What you call graph / data analysis would be replaced with real; numbers on LCD.
I thing adding a torque measurement would also work nice.

9

Robitillaart, I will get back to you shortly when I have time to describe how combos can be excluded.

Vaclav - I don't think that's beyond the realms of possibility (directly identifying the most likely combination by performing the analysis within the program). I do think that it's absolutely necessary to produce a set of the most likely combos from the analysis, though, as it's not always that definitive. For example, there could be a corroded part of the dial that produces a false result by causing a torque change.

So, who's on board? Johnwasser, are you still keen for something like this? :slight_smile: I'm excited!

10

this is interesting, but I'm not sure a stepper motor will be quiet enough to perform any associated acoustic measurements, or smooth enough to perform associated torque sensing, it will essentially vibrate the dial as it rotates the dial step by step, or if you made each rotation a single step, then it would abruptly snap to the next position

it seems like a dc servo motor (not an rc servo) would be required to rotate and stop quietly and smoothly enough to have any hope of measuring such slight torque and acoustic signals on a rotating dial like that, and it would have to be tuned accordingly to minimize PID related overshoot, oscillation, and speed variation during rotation and when stopped, for which a very high resolution encoder would be desirable, for which a dedicated servo driver with a nice digital tuning interface would be desirable

even then, I'm skeptical whether it is possible to impliment sensors sensitive enough to feel and hear the inner workings of a combination lock while turning it with an electric motor, so I'd have to see it to believe it

I might see if I might have a motor and encoder like that, to do some testing/experimenting....

11

Been thinking about the acoustics sensor hardware.
How about hacking off-the-shelf ultrasonic sensor?
It has both transmit and receive hardware.

The TX should be simple to hack.
I have not looked into this is much deeper, but if the generator of sound could be made adjustable in frequency to mask the ambient noise it may work. But it may work “as-is from the box”, maybe.

The FFT would not care if the sound generated is audible, but Arduino may not be fast enough to process ultrasound. Also something to check.
Of course we would not care about the “ping” time return, we would like to analyze the returning waveform.
I assume now the RX just detects the “ping” and sets the “Echo”.

However, sound sensor to get the waveform using electret mike in no rocket science.

I think I'll look for the old bike lock whose combination got lost years ago!
But I REALY do not need another project!
Cheers Vaclav

12

So to all of the people that are saying if he goes about this the brute force way it will take forever and is unfeasible I have some math. Though you are all correct the one thing you are forgetting in your calculations is the fact that all the safes how a tolerance of normally +-2 so that means you would only ever have to check the second number of the combination. I am not the best at math so maybe this video could elaborate what I am trying to say better. Safe Cracking with Feynman - Numberphile - YouTube

13

if the tolerance is +-2 that means that in the sequence 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19, 20 ....

you only have to check:
3 - matches 1..5
8 - matches 6-10
13 - matches 11-15
18 - matches 16-20
etc
So that means on in 5 needs to be tested.

similar if the tolerance is +-1 only one in 3 need to be tested.

If the tolerance is unknown, one could use a "comb-sort alike search" method with decreasing tolerances

that said I think state of mechanics is more than good enough to have tolerances of +-0