search

nfc-tools / mfoc

Mifare Classic Offline Cracker
GNU General Public License v2.0
1.21k stars 267 forks source link

Hardnested attack support #60

Closed vk496 closed 4 years ago

vk496 commented 5 years ago

Proxmark3 implementation, adapted and integrated into mfoc.

Right now, the support for non-Intel architectures is broken. See https://github.com/vk496/mfoc/issues/1

Salu2

alvgalrus commented 5 years ago

Nice job with this PR. Just making a point here, several Intel architectures don't support those instruction sets. It's not actually about non-Intel archs.

vk496 commented 5 years ago

Thnks for the remark.

Hope someone could help with the automake and port this patch to arm-based archs too (https://github.com/vk496/mfoc/issues/1).

Salu2

samueloph commented 4 years ago

@neomilium It seems that the non-intel issue was fixed, could you take a look at this PR? Seems like some people are interested in this feature.

Thanks

vk496 commented 4 years ago

Hi,

Before merging this PR, other bugs should be fixed:

BR, Valentín

15 mar. 2020 0:32:08 Samuel Henrique notifications@github.com:

@neomilium [https://github.com/neomilium] It seems that the non-intel issue was fixed, could you take a look at this PR? Seems like some people are interested in this feature.

Thanks

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [https://github.com/nfc-tools/mfoc/pull/60#issuecomment-599147618] , or unsubscribe [https://github.com/notifications/unsubscribe-auth/ABJ7L242INZX52OF5RZZ773RHQHXPANCNFSM4GJN637Q] . [https://github.com/notifications/beacon/ABJ7L27UX5R4ZKIUX3RFBYLRHQHXPA5CNFSM4GJN6372YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEO3EIYQ.gif]

samueloph commented 4 years ago

@vk496 thanks for the details, I pinged this because there's currently a request on Debian[0], coming from Kali[1], to package the hardnested branch instead of the main project here.

I don't have plans of doing so, since there's no intention of creating a fork, your update helps with understanding what's still missing for the PR to get merged.

Regards,

[0]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952513 [1]https://bugs.kali.org/view.php?id=6127

iceman1001 commented 4 years ago

@doegox you could most likely close this with the new repo out.

doegox commented 4 years ago

Indeed, I never saw this PR before, my bad.

So now we have https://github.com/nfc-tools/mfoc-hardnested that can be packaged if some want to, cc @samueloph

BTW @vk496 you got an invitation to get RW access to it, see https://github.com/nfc-tools/mfoc-hardnested/invitations

samueloph commented 4 years ago

@doegox @iceman1001 Thanks for the heads up,

May I ask why a fork was created? I was thinking that the feature would be added to the main project but a fork suggests that there is some incompatibility related to it.

Thanks,

doegox commented 4 years ago

Well this is a massive change in the code and in the intend of the code. We had mfoc = one specific attack, along with hardnested, mfcuk,... and mylazycracker is a kind of "autopwn", to follow the proxmark terminology. With this PR, the intend of the tool shifts more along something that could become itself the "autopwn", while there are still reasons to have the "old" mfoc available somehow without having to dig into git history. So a new repo seemed adequate. And this should satisfy kali maintainers willing to package this variant rather than the original mfoc.

iceman1001 commented 4 years ago

I think I understand where @doegox is coming from. NFC-tools is a collection of dedicated tools which solves certain functionality. To uphold that, I think it is understandable and fair decision. With it, you also allow for a autopwn styled tool to exist naturally with in the nfc-tools concept.

samueloph commented 4 years ago

Thanks @iceman1001 and @doegox,

I was mainly concerned about missing functionality from the hardnested fork, but from your responses I understand that the difference is that the scope of the hardnested project is bigger, while keeping the same functionality of the original project.

What are your thoughts on using mfoc-hardnested as a replacement for mfoc? Should both be packaged under their own names (packages mfoc and mfoc-hardnested) or should mfoc-hardnested be provided under the mfoc package?

doegox commented 4 years ago

I would package both but that's just my opinion. Packaging mfoc-hardnested as mfoc sounds confusing imho.

vk496 commented 4 years ago

Hi,

I will write more elaborate answer within next days (sorry, really busy).

How about calling it mfoch?

PS: I tried the fork and the hardnested attack fail at the beggining (the device disconnects)

26 jun. 2020 23:49:57 Philippe Teuwen notifications@github.com:

I would package both but that's just my opinion. Packaging mfoc-hardnested as mfoc sounds confusing imho.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub[https://github.com/nfc-tools/mfoc/pull/60#issuecomment-650418834], or unsubscribe[https://github.com/notifications/unsubscribe-auth/ABJ7L23XBDCKION4TKCPF23RYUJYLANCNFSM4GJN637Q]. [https://github.com/notifications/beacon/ABJ7L25GGTXYPGJBFVFADRTRYUJYLA5CNFSM4GJN6372YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOE3CJVEQ.gif]

iceman1001 commented 4 years ago

Hey @vk496
I am curious on your memory optimizations. Something that should be back ported to proxmark repo?

vk496 commented 4 years ago

Hello @iceman1001. Thank you for your great work!

I would love to backport support for low memory devices. Right now I successfully implemented a dynamic allocation of bitflip_bitarrays structure. But is not enough (RAM usage still over 1.2G, before was 1.6)

The main problem is related with nonce memory (https://github.com/vk496/mfoc/blob/abd0be28a0f89632c3be51adede993d46d3b6e3e/src/cmdhfmfhard.c#L587). I've noticed that value of 256 is hardcoded in the code for the nonces structure. Do you know if it would be possible to play with that value? In my first attempt, I've got Segfaults...

If the attack really depends of that amount, I only can think about using the HDD (temporal directory) as storage. Any other idea?

iceman1001 commented 3 years ago

The only one who can answer that question is @pwpivi , its his code. Well, @aczid might have some interesting suggestions aswell.

The 1.6gb > 1.2gb solution is good. I am looking forward to your PR ;)