Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
Hardly anyone could have missed that the hardnested attack has made its way into PM3 Master.
Not only that, its a farcry from the PoC that piwi made one year ago, which codebase is found in icemanfork.
So whats the difference? Well, I have done some tests. Below is three runs, all successful.
Remember the 40+k nonces collection? No more.The improved version collects far less nonces, its about 2300nonces in total.
What about time? Look at the first column, its execution time in seconds. 42,25,28 seconds to find three different keys. BAM!
The found key is located a bit hidden in the third column, last row.
Another fun thing is that @aczid's bitsliced BF solver is also included. You can see this below in the output, where it breaks the output pattern. This output will be fixed, I'm sure of.
So it runs way faster, it finds the key, still some memory issues (reported by coverity according to marshmellow), any other downsides?
Well, its a time-memory tradeoff, the improved attack uses precalculated bitflip binary files and they are huge. So the new attack is a memory hog. Minimum 4GB memory on my virtual machines otherwise you get a client crash.
proxmark3> hf mf hard 0 a fc00018778f7 59 a
--target block no: 59, target key type:A, known target key: 0x000000000000 (not set), file action: none, Slow: No, Tests: 0
time | #nonces | Activity | expected to brute force
| | | #states | time
------------------------------------------------------------------------------------------------------
0 | 0 | Start using 4 threads and AVX SIMD core | |
0 | 0 | Brute force benchmark: 402 million (2^28,6) keys/s | 140737488355328 | 4d
1 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 4d
5 | 112 | Apply bit flip properties | 480318193664 | 20min
6 | 223 | Apply bit flip properties | 124444614656 | 5min
7 | 334 | Apply bit flip properties | 78171291648 | 3min
8 | 446 | Apply bit flip properties | 76546646016 | 3min
9 | 558 | Apply bit flip properties | 76328607744 | 3min
10 | 669 | Apply bit flip properties | 74997940224 | 3min
11 | 779 | Apply bit flip properties | 74550116352 | 3min
11 | 888 | Apply bit flip properties | 74550116352 | 3min
12 | 999 | Apply bit flip properties | 74550116352 | 3min
13 | 1110 | Apply bit flip properties | 74550116352 | 3min
13 | 1222 | Apply bit flip properties | 74550116352 | 3min
14 | 1332 | Apply bit flip properties | 74550116352 | 3min
15 | 1443 | Apply bit flip properties | 74550116352 | 3min
16 | 1554 | Apply bit flip properties | 74550116352 | 3min
18 | 1665 | Apply Sum property. Sum(a0) = 192 | 3861664512 | 10s
18 | 1774 | Apply bit flip properties | 2950764544 | 7s
19 | 1883 | Apply bit flip properties | 2950764544 | 7s
20 | 1993 | Apply bit flip properties | 2950764544 | 7s
20 | 1993 | (Ignoring Sum(a8) properties) | 2950764544 | 7s
Number of remaining possible keys: 2733616064 (2^31,3)
42 | 1993 | Brute force phase completed. Key found: 54726176656c | 0 | 0s
proxmark3> hf mf hard 0 a fc00018778f7 59 b
--target block no: 59, target key type:B, known target key: 0x000000000000 (not set), file action: none, Slow: No, Tests: 0
time | #nonces | Activity | expected to brute force
| | | #states | time
------------------------------------------------------------------------------------------------------
0 | 0 | Start using 4 threads and AVX SIMD core | |
0 | 0 | Brute force benchmark: 376 million (2^28,5) keys/s | 140737488355328 | 4d
1 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 4d
5 | 112 | Apply bit flip properties | 78096531456 | 3min
6 | 224 | Apply bit flip properties | 40489848832 | 2min
7 | 335 | Apply bit flip properties | 20404822016 | 54s
8 | 447 | Apply bit flip properties | 20386975744 | 54s
9 | 559 | Apply bit flip properties | 20383420416 | 54s
10 | 668 | Apply bit flip properties | 20383420416 | 54s
11 | 780 | Apply bit flip properties | 20383420416 | 54s
12 | 890 | Apply bit flip properties | 20383420416 | 54s
12 | 1001 | Apply bit flip properties | 20383420416 | 54s
12 | 1112 | Apply bit flip properties | 20383420416 | 54s
13 | 1218 | Apply bit flip properties | 20383420416 | 54s
15 | 1329 | Apply Sum property. Sum(a0) = 96 | 1012257792 | 3s
16 | 1440 | Apply bit flip properties | 1012257792 | 3s
17 | 1550 | Apply bit flip properties | 999213440 | 3s
17 | 1658 | Apply bit flip properties | 999213440 | 3s
18 | 1658 | (1. guess: Sum(a8) = 128) | 999213440 | 3s
24 | 1658 | Apply Sum(a8) and all bytes bitflip properties | 821588800 | 2s
25 | 1658 | Brute force phase completed. Key found: 776974687573 | 0 | 0s
proxmark3> hf mf hard 0 a fc00018778f7 41 b
--target block no: 41, target key type:B, known target key: 0x000000000000 (not set), file action: none, Slow: No, Tests: 0
time | #nonces | Activity | expected to brute force
| | | #states | time
------------------------------------------------------------------------------------------------------
0 | 0 | Start using 4 threads and AVX SIMD core | |
0 | 0 | Brute force benchmark: 296 million (2^28,1) keys/s | 140737488355328 | 5d
1 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 5d
5 | 112 | Apply bit flip properties | 121800687616 | 7min
6 | 222 | Apply bit flip properties | 50380431360 | 3min
7 | 333 | Apply bit flip properties | 48323821568 | 3min
8 | 444 | Apply bit flip properties | 45146742784 | 3min
9 | 556 | Apply bit flip properties | 42914365440 | 2min
10 | 667 | Apply bit flip properties | 42914365440 | 2min
11 | 774 | Apply bit flip properties | 42107375616 | 2min
11 | 885 | Apply bit flip properties | 42107375616 | 2min
12 | 996 | Apply bit flip properties | 42107375616 | 2min
12 | 1107 | Apply bit flip properties | 42107375616 | 2min
13 | 1215 | Apply bit flip properties | 42107375616 | 2min
14 | 1323 | Apply bit flip properties | 42107375616 | 2min
15 | 1431 | Apply bit flip properties | 42107375616 | 2min
16 | 1542 | Apply bit flip properties | 42107375616 | 2min
18 | 1653 | Apply Sum property. Sum(a0) = 160 | 5477574144 | 18s
18 | 1762 | Apply bit flip properties | 5477574144 | 18s
19 | 1872 | Apply bit flip properties | 2544770560 | 9s
20 | 1980 | Apply bit flip properties | 2544770560 | 9s
21 | 2090 | Apply bit flip properties | 1661432704 | 6s
22 | 2198 | Apply bit flip properties | 1661432704 | 6s
22 | 2308 | Apply bit flip properties | 1856208384 | 6s
23 | 2308 | (1. guess: Sum(a8) = 0) | 1856208384 | 6s
23 | 2308 | Apply Sum(a8) and all bytes bitflip properties | 1856200576 | 6s
24 | 2308 | Apply Sum(a8) and all bytes bitflip properties | 4341844992 | 15s
24 | 2308 | (3. guess: Sum(a8) = 128) | 6755933696 | 23s
28 | 2308 | Apply Sum(a8) and all bytes bitflip properties | 5201497088 | 18s
28 | 2308 | Brute force phase completed. Key found: ee0042f88840 | 0 | 0s
proxmark3>
Offline
The increased memory consumption could be a problem on Windows, as my ProxSpace environment is compiling the proxmark client as 32-bit application and therefore it has a 1.5GB limit. However in my tests I didn’t manage to crash it.
Offline
Try interrupt the cmd and then run it again. However, running some gdb on it while doing so would help.
Coverity Scan fixes will help out too.
I'm most concerned about android compilation.
1.5gb limit on 32bit windows is something I never heard before.
[edit] removed sentence about memory limits. See post below for correct memory limits.
Offline
See https://msdn.microsoft.com/en-us/library/aa366778.aspx it is 2GB minimum. I am compiling for 32bit as well.
Not an issue.
The coverity issue is about an index overrun and is a false positive.
When interrupting without exiting (how do you do that?) the allocated memory is not freed. Same amount is then allocated again - that will be too much.
Offline
Cool, I stand corrected, 2gb/3gb limits. Will update my previous post not to spread fudge.
How to reproduce it? Quite easy Some ppl has magic fingers that just breaks code. Kidding, anyway, how to reproduce. start hardnested, after checks and device starts with nonce collecting, press device button, then run hardnested again and bom..
proxmark3> hf mf hard 0 a fc00018778f7 41 b
--target block no: 41, target key type:B, known target key: 0x000000000000 (not set), file action: none, Slow: No, Tests: 0
time | #nonces | Activity | expected to brute force
| | | #states | time
------------------------------------------------------------------------------------------------------
0 | 0 | Start using 4 threads and AVX SIMD core | |
0 | 0 | Brute force benchmark: 342 million (2^28,3) keys/s | 140737488355328 | 5d
1 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 5d
6 | 112 | Apply bit flip properties | 411881734144 | 20min
Button pressed. Aborted.
proxmark3> hf mf hard 0 a fc00018778f7 41 b
--target block no: 41, target key type:B, known target key: 0x000000000000 (not set), file action: none, Slow: No, Tests: 0
time | #nonces | Activity | expected to brute force
| | | #states | time
------------------------------------------------------------------------------------------------------
0 | 0 | Start using 4 threads and AVX SIMD core | |
0 | 0 | Brute force benchmark: 337 million (2^28,3) keys/s | 140737488355328 | 5d
2 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 5d
Out of memory error in init_nonce_memory(). Aborting...
QSocketNotifier: Invalid socket 14 and type 'Read', disabling...
Offline
You are right @piwi there is a 2GB limit, only DirectX application have a 1.5GB limit as 512MB are automatically allocated.
With the hardnested in the iceman fork I did run into an OutOfMemoryException when the nonce collection did take 15+ minutes, the new hardnested might solve this issue.
Offline
the presence hardnested in the main release is impressive. I see lots of changes. I see my PC is quasi frozen, it looks like you have employed the exploiting the computational power of Many-Core- and SS2 technique, like password and wifi hackers used to implement in their tools in the aircrack-ng, JTP (john the ripper), pyrit hashcat before parallel programming
proxmark3> hf mf hardnested 0 A 7a32f440200d 28 A w
--target block no: 28, target key type:A, known target key: 0x000000000000 (not set), file action: write, Slow: No, Test
s: 0
time | #nonces | Activity | expected to brute force
| | | #states | time
------------------------------------------------------------------------------------------------------
0 | 0 | Start using 2 threads and SSE2 SIMD core | |
0 | 0 | Brute force benchmark: 98 million (2^26.5) keys/s | 140737488355328 | 17d
58 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 17d
92 | 0 | Writing acquired nonces to binary file nonces.bin | 140737488355328 | 17d
126 | 112 | Apply bit flip properties | 140737488355328 | 17d
132 | 224 | Apply bit flip properties | 7159442046976 | 20h
136 | 336 | Apply bit flip properties | 7159442046976 | 20h
146 | 446 | Apply bit flip properties | 7159442046976 | 20h
152 | 555 | Apply bit flip properties | 7159442046976 | 20h
165 | 667 | Apply bit flip properties | 2886117359616 | 8h
169 | 779 | Apply bit flip properties | 2886117359616 | 8h
171 | 889 | Apply bit flip properties | 2886117359616 | 8h
177 | 998 | Apply bit flip properties | 1954302525440 | 6h
180 | 1103 | Apply bit flip properties | 1781562212352 | 5h
182 | 1214 | Apply bit flip properties | 1489690427392 | 4h
184 | 1315 | Apply bit flip properties | 1181104734208 | 3h
187 | 1426 | Apply bit flip properties | 818453020672 | 2h
189 | 1538 | Apply bit flip properties | 802178531328 | 2h
191 | 1643 | Apply bit flip properties | 802178531328 | 2h
194 | 1755 | Apply bit flip properties | 802178531328 | 2h
196 | 1858 | Apply bit flip properties | 752199139328 | 2h
198 | 1947 | Apply bit flip properties | 637212360704 | 2h
233 | 2007 | Apply Sum property. Sum(a0) = 128 | 41385787392 | 7min
236 | 2078 | Apply bit flip properties | 41385787392 | 7min
238 | 2190 | Apply bit flip properties | 32406614016 | 6min
244 | 2297 | Apply bit flip properties | 66374496256 | 11min
247 | 2409 | Apply bit flip properties | 39474630656 | 7min
250 | 2493 | Apply bit flip properties | 33419343872 | 6min
254 | 2583 | Apply bit flip properties | 39225376768 | 7min
257 | 2685 | Apply bit flip properties | 39225376768 | 7min
260 | 2788 | Apply bit flip properties | 33497235456 | 6min
263 | 2888 | Apply bit flip properties | 29367965696 | 5min
266 | 2991 | Apply bit flip properties | 26547658752 | 5min
269 | 3095 | Apply bit flip properties | 26547658752 | 5min
272 | 3196 | Apply bit flip properties | 24243628032 | 4min
274 | 3283 | Apply bit flip properties | 22752008192 | 4min
277 | 3395 | Apply bit flip properties | 22752008192 | 4min
280 | 3506 | Apply bit flip properties | 22752008192 | 4min
283 | 3600 | Apply bit flip properties | 21620240384 | 4min
286 | 3665 | Apply bit flip properties | 21620240384 | 4min
289 | 3765 | Apply bit flip properties | 20747180032 | 4min
294 | 3860 | Apply bit flip properties | 21733267456 | 4min
297 | 3860 | (1. guess: Sum(a8) = 256) | 21733267456 | 4min
319 | 3860 | Apply Sum(a8) and all bytes bitflip properties | 21273468928 | 4min
382 | 3860 | Brute force phase completed. Key found: 623985b57f69 | 0 | 0s
proxmark3>
But a little confusion is the interpretation of the command
proxmark3> hf mf hardnested 0 A 7a32f440200d 28 A w
--target block no: 28, target key type:A, known target key: 0x000000000000 (not set), file action: write, Slow: No, Test
s: 0
Why known target key: 0x000000000000 (not set)?
and I have tested many times, average for my cards is 3 to 9 ... minutes/a key.
What has caused the difference? I have Intel celeron dual-core 1.8 Ghz, 2GB ram.
also perhaps the result is dependent on computing power, then we could try a small idea: A switch either to run hardnested with display all details or run in verbose mode, could increase the speed a little, or not? For example in hashcat BF result/status not always being on display, so computer can use all power for doing cracking work
Offline
Second thing I had to be re-taught today. DirectX 1.5gb/ 512mb limits.
The old hardnested version in icemanfork had some issues even if many memory got resolved. This improved version is nice and compact.
With the monster merge, this new code will be integrated with some tweaks for my lua script
The button press issue should be change to free the allocated memory.. would be somewhere near the call to acquire_nonces()
Offline
@ntk, you got 3860 nonces and your rig seems a bit slow. A better cpu and more ram will help. My virtual machines seems faster than yours.
The line known target key... comes from if you know the key you are looking for. For test purposes, to see if the attack finds it I guess.
I doubt those printlines will have any real influence of speed. The BF solver runs between the second last and last line.
Offline
@ntk, you got 3860 nonces and your rig seems a bit slow. A better cpu and more ram will help. My virtual machines seems faster than yours. .
thank you now I understand why it takes so longe. You are very kind with your free assessment.
Offline
Indeed your machine is a bit slow (90 million keys/s compared to iceman's 400). Hardnested tried to partially compensate by collecting more nonces.
And yes, the hardnested command will try to make use of everything your CPU can offer. Your 2GB RAM is low as well. Your machine is likely to start swapping.
Regarding the test modes please see the command's help text. With the t option you can make your CPU busy even without the proxmark connected.
Offline
@piwi, thank you for analyze, I use the tool but have not understood hardnested methode, so I did not know the tool collects more nonces to compensate the fact that my rig is too slow for crunching the password.
i am currently a fascinated student in areas where precision cut is much more counted then speed so I agree my rig needs to be upgraded, but perhaps more towards the end of that study.
Currently for the that study I click and switch between windows alot, but only key-in perhaps 10, or at the most 20 commands a night, and hardly use 1% of my CPU. Most of the time is for still sitting, tracing and observing where it flows and its consequences. Awsome what just an old rig like that can let me see into. I could not imagine able to see thing like that 20 yrs 30 yrs ago.
Thank for the lead me in the secretive world of hardnested. The command help file tells us nothing about the t option. But "hf mf hardnested t" indeed shows me some actions
proxmark3> hf mf hardnested t
--target block no: 0, target key type:A, known target key: 0x000000000000 (not set), file action: none, Sl
: 100
time | #nonces | Activity | expected to brute force
| | | #states | time
------------------------------------------------------------------------------------------------------
0 | 0 | Start using 2 threads and SSE2 SIMD core | |
0 | 0 | Brute force benchmark: 67 million (2^26.0) keys/s | 140737488355328 | 24d
0 | 0 | Starting Test #1 ... | 140737488355328 | 24d
50 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 24d
84 | 0 | Simulating key 1fe095e9ed45, cuid 24f3d282 ... | 140737488355328 | 24d
115 | 113 | Apply bit flip properties | 140737488355328 | 24d
...
195 | 1451 | Apply bit flip properties | 1011459162112 | 4h
198 | 1563 | Apply bit flip properties | 873228402688 | 4h
...
323 | 3943 | Apply bit flip properties | 25409116160 | 6min
326 | 4046 | Apply bit flip properties | 25286670336 | 6min
333 | 4046 | (1. guess: Sum(a8) = 0) | 25286670336 | 6min
338 | 4046 | Apply Sum(a8) and all bytes bitflip properties | 24007342080 | 6min
338 | 4046 | (Test: Key found) | 0 | 0s
342 | 4046 | Brute force phase completed. Key found: 1fe095e9ed45 | 0 | 0s
time | #nonces | Activity | expected to brute force
| | | #states | time
------------------------------------------------------------------------------------------------------
0 | 0 | Start using 2 threads and SSE2 SIMD core | |
0 | 0 | Brute force benchmark: 67 million (2^26.0) keys/s | 140737488355328 | 24d
0 | 0 | Starting Test #2 ... | 140737488355328 | 24d
261 | 0 | Using 235 precalculated bitflip state tables | 140737488355328 | 24d
289 | 0 | Simulating key 003686283f2b, cuid bd56da95 ... | 140737488355328 | 24d
294 | 113 | Apply bit flip properties | 140737488355328 | 24d
...
469 | 1236 | Apply Sum property. Sum(a0) = 128 | 2375822344192 | 10h
479 | 1347 | Apply bit flip properties | 1472275283968 | 6h
...
602 | 3530 | Apply bit flip properties | 382602051584 | 2h
605 | 3636 | Apply bit flip properties | 382602051584 | 2h
608 | 3636 | (Ignoring Sum(a8) properties) | 382602051584 | 2h
668 | 3636 | (Test: Key found) | 0 | 0s
I see it tries to check if the simulated key exists in the sectors of the card with simulated cuid and that in test #1 and test #2 but the time different because we assume one it closer to the begin block, where the second case the key is for block at end of the card hence longer time to check. Is that the logic you want to show me, piwi?
Last edited by ntk (2017-06-09 21:04:26)
Offline
I have adapted my hard_autopwn.lua script. It combines the hardnested attack with checkkeys functionality.
Assuming a key is used on other sectors which usually is the case, a speedup is possible.
Max iterations for hardnested; mifare s50/1k (16 * 2) - 1 = 31times
output: https://pastebin.com/X6vZqBRM
Quite funny, I'll add saving keys to dumpkeys.bin, and a call to "hf mf dump". Life is easy once its done.
Offline
awesum additions
Added write dumpkeys.bin file
Added dump data
Added detection weak vs hardend prng
Offline
Two thumbs up!! Thx Iceman...
Offline
Made another video, showing of current implementation of the hardnested attack and the hard_autopwn lua script
Youtube : https://youtu.be/tUZHtUJerJY
Offline
This looks awesome! Thanks.
Offline
hi ,
where can i found the hard_atopwn.ula ?
Offline
hi ,
where can i found the hard_atopwn.ula ?
found it but its not working ...
Offline
Are you using the firmware to match the version of the client? Mine also did not work, but I am running the latest master firmware, so I have next on my list to flash Iceman's branch firmware and use the corresponding client.
Offline
the hard_autopwn script in my fork is outdated. It might work with the latest source in the fork and it doesn't work with offical PM3 Master...
Offline
I gave it a try with the iceman branch of client and firmware. Got a bunch of errors, later I found I was mixing classic and ultralight.
I'll have to try again tomorrow and report back.
Version detail.
commit 6c4d1560e9936615694259ecf5cf82a67b258b14
Author: iceman1001 <iceman@iuse.se>
Date: Sun Jul 23 10:24:30 2017 +0200
Offline
Hi guys
Any luck on the the hard_autopwn lua script ?
Offline
Someone from Dubai might get it first hand this week or next. Maybe I will get him to comment on it.
Offline
I've begun some work to fix this script. Almost there but am stuck on something that goes over my head a little I think.
Offline
Pages: 1