#Advanced MIFARE attacks on the FZ

2236 messages · Page 3 of 3 (latest)

regal storm
#

oh shit, you're right

#

they are FM11RF08

harsh cobalt
#

I mean if it replies to the backdoor auth but isn't one of the 3 known keys that would be very interesting to know

regal storm
regal storm
#

it's shocking how many cards work with both the v1 and v3 backdoors

#

v1/v2 nonce collection works now, speeding up backdoor detection and alerting us on unknown keys

regal storm
#

Everything remaining until PR 3822 is final (and re-opened) on my end. I'll be keeping this list up to date:

https://github.com/flipperdevices/flipperzero-firmware/pull/3822#issuecomment-2344097107

Post PR open:

  • MFKey 3.0 (minor changes required from 2.7)
  • FlipperNestedRecovery ported to Flipper Labs and apps

The goal is still OFW 1.1.0, which is the goal Flipper Devices has for the NFC app MFKey flow too. If I finish on time (around Sept 25) it can likely release all at once.

steady geyserBOT
#

message 1283277709157597194 pinned

oak granite
regal storm
#

AVX intrinsics if I had to guess

oak granite
#

it works near fine on arm

regal storm
oak granite
#

and flippernestedrecovery doesn't use any SIMD, so avx definitely out of reasons

regal storm
#

performance of the FZ MFC dict attack is lowered due to counting the keys in the dictionary at the beginning of the attack, as well as reinitializing the poller every time a plugin is run

regal storm
#

I was able to get around 5750 keys per second by using up a few extra kb of flash, which is ~40 times faster than the Proxmark checks keys

#

but it's not worth it since the current speed (3500 keys per second) is fast enough

#

(the way to get this was to unroll the crypto1 loops and inline them so there's no function call overhead in decrypt_nt_enc)

#

inlining all of the crypto1 functions into decrypt_nt_enc , or optimizing the functions themselves to produce partial states, should get north of 10k keys per second

#

we can play around with it and find what tradeoffs make sense

regal storm
#

hm. I'm not quite sure I understand the bottleneck here

#

generated this with matplotlib

#

it shows nt_enc collection takes longer than anything else, but that is online time. so i optimized the other 3 functions, and got a ~20% performance increase (from ~650 nonces to ~800 nonces in the same time period).

#

it's not like we can auth to the tag faster. 3.5 min per key seems slow? I'm not familiar with how long FlipperNested took but I'm sure it was faster than this

#

also i tried to reduce online time by reauthing nested after a failed nested auth but the tag just halts (verified with a pm3). we can auth after a failed nested auth, but not a nested auth after a failed nested auth.

#

(we usually have to get anywhere between 1600 to 2300 nonces)

regal storm
#

yea I just checked, the proxmark runs almost instantly

#

i need to see how it collects nonces

oak granite
regal storm
#

64.29% of the collection time is spent outside the collection functions, which explains why I wasn't seeing it.

#

as far as I can tell, the Proxmark also needs to collect as many nonces as we do. so this is a matter of poor optimization between my code and the FZ poller.

#

I'm going to see if I can get the poller working correctly, but if I can't I'll take advantage of the fact you don't need to reset the field after a failed auth to accelerate the nonce collection

regal storm
#

I think I know what's going on which causes Mfkey32 to "fail" at certain readers based on the results we had before, and I should be able to reproduce it with a Proxmark (multiple offered keys). Not high up on the list but I will get back to it.

regal storm
#

Details: #738046276138041415 message

harsh cobalt
#

yeah that was my idea on how a reader could "break" mfkey32, randomly change which keys are used, obviously wouldn't help with mfkey64 if you had access to both a card and reader though

regal storm
#

Found the main factor slowing down Hardnested nonce collection in the poller and I'll see if I can get it fixed later when I wake up. This should also speed up the other attacks too.

#

throughput is quadrupled

regal storm
#

So before my power went out yesterday, I found out that it also was affecting the accelerated dictionary attack

#

If you ran the new dictionary attack and thought "this isn't fast enough", I'll have an update available in a few hours

#

Runs in one second, more or less (sub second), against many of my cards.

#

What's affecting the time now are the parsers mainly (NFC plugins)

oak granite
regal storm
#

All of the improvements up until now were with the pause between each nonce. Also I'll have an update hopefully today that brings it up to 4200 keys per second.

odd grail
#

1 million dic wen

regal storm
#

static encrypted tags are working perfectly with my local changes

#

of course, every other attack breaks in the process

regal storm
#

and now we are once again stable. i have a working version of the dev firmware

#

all prior versions had issues with the collected nonces

#

this one I verified on:

  • Weak "Full Nested" (x2)
  • Weak Backdoor 1
  • Weak Backdoor 3 (SEN)
  • Weak (All keys known)
  • Hard
  • Hard (All keys known)
#

there are still minor bugs but overall its working

regal storm
#

snapshot of the current dev if anyone would like to test the speed/stability improvements

regal storm
#

Progress bar is done. It looks less spooky when you can see what it is doing though. sad

regal storm
#

3822 is stable enough to implement MFKey 3.0. I'll see what I can get done today and tomorrow for it. By Friday (or Saturday at the latest) there should be a complete cracking process.

#

This will cover all weak tags (Static/Regular/Static Encrypted). For Hardnested, I'll fork FlipperNestedRecovery until it can be added into the mobile app.

regal storm
#

going to keep the status of all of this organized

steady geyserBOT
#

message 1286035214472187968 pinned

regal storm
#

MFKey 3.0 is working (cracking nested nonces saved by NFC app). Also I have an idea for how to do Mfkey64.

regal storm
#

a complete beginning to end process party party 🎉

#

actually surprised me because it worked immediately after I changed how MFKey loads the nonces on the first test. it just loaded like 20 static nested nonces and they were all cracked within a minute

#

thought they had to be wrong but nope. it was the correct key

#

one key repeated over the entire card

regal storm
#

really slow for static encrypted nonces because of the SPI bottleneck. but it works

hidden nexus
regal storm
#

Not in my repo yet, it's in my fork of good-faps

#

Linked in the PR above

#

damn. it's working but there's a bug that causes it to fail sometimes. I converted the MFKey 3.0 PR back into a draft.

#

the bug is that it only logs the first found key for nested, instead of all of the found keys

#

the latter takes longer but its more accurate

#

3822 plus the current MFKey 3.0 does partially work though. NFC->Read, MFKey, NFC->Read

#

we're so close but I have to do some things irl

regal storm
#

Also we're coming up 5-7 KB short for full speed MFKey. Even if they link it off the NFC app, the saved state of the file browser is making it run at half speed.

hidden nexus
#

daaaamn

regal storm
#

It's specifically the file browser that's eating up the spare RAM

#

The good news is, everything except Hardnested is now running on the Flipper Zero. omg

#

(except NACK/Darkside and Mfkey64)

regal storm
#

update: been sick for days and still sick. annoying this happens right as we're about to cross the finish line with this, i'm going to try and work through it today to deliver MFKey 3 at least. maybe fix calibration too

#

what I'm trying to figure out is, if there are multiple possible keys that nested can return, why not make nonce triples

#

regular nested, not static encrypted

#

anyway i'll get to the bottom of it

regal storm
#

wtf. i found the issue

# 
Sec 0 key A cuid dee0061f nt0 214904f0 ks0 f76b97fb par0 1000 nt1 214904f0 ks1 f76b97fb par1 1000 dist 0
Sec 4 key A cuid dee0061f nt0 214904f0 ks0 f76b97fb par0 1000 nt1 214904f0 ks1 f76b97fb par1 1000 dist 0
Sec 5 key A cuid dee0061f nt0 214904f0 ks0 f76b97fb par0 1000 nt1 214904f0 ks1 f76b97fb par1 1000 dist 0
Sec 6 key A cuid dee0061f nt0 214904f0 ks0 f76b97fb par0 1000 nt1 214904f0 ks1 f76b97fb par1 1000 dist 0
Sec 7 key A cuid dee0061f nt0 214904f0 ks0 f76b97fb par0 1000 nt1 214904f0 ks1 f76b97fb par1 1000 dist 0
Sec 8 key A cuid dee0061f nt0 214904f0 ks0 f76b97fb par0 1000 nt1 214904f0 ks1 f76b97fb par1 1000 dist 0
Sec 9 key A cuid dee0061f nt0 214904f0 ks0 f76b97fb par0 1000 nt1 214904f0 ks1 f76b97fb par1 1000 dist 0
(..)
#

no wonder the nonce pair resulted in 50k+ keys

regal storm
#

issue must stem from 3822 nonce collection

regal storm
#

oh. oops. if the the first nonce collection fails, it collects the same nonce, lol

harsh cobalt
#

Lol that'd do it

regal storm
#

Calibration now discards values over 3 standard deviations away from the median

# 

33657 [E][MfClassicPoller] nt_enc (plain) 8b3db414
33659 [E][MfClassicPoller] dist from nt prev: 5866
33703 [E][MfClassicPoller] nt_enc (plain) e2712948
33705 [E][MfClassicPoller] dist from nt prev: 683
33750 [E][MfClassicPoller] nt_enc (plain) 14e013fb
33752 [E][MfClassicPoller] dist from nt prev: 691
33796 [E][MfClassicPoller] nt_enc (plain) e1e7dad5
33798 [E][MfClassicPoller] dist from nt prev: 683
33842 [E][MfClassicPoller] nt_enc (plain) 16c8510d
33845 [E][MfClassicPoller] dist from nt prev: 691
33888 [E][MfClassicPoller] nt_enc (plain) 4ca97cf3
33891 [E][MfClassicPoller] dist from nt prev: 683
33934 [E][MfClassicPoller] nt_enc (plain) b5d2db82
33937 [E][MfClassicPoller] dist from nt prev: 683
33981 [E][MfClassicPoller] nt_enc (plain) fb34fd36
33983 [E][MfClassicPoller] dist from nt prev: 687
34028 [E][MfClassicPoller] nt_enc (plain) 6bba6fde
34030 [E][MfClassicPoller] dist from nt prev: 693
34075 [E][MfClassicPoller] nt_enc (plain) 6ea3c322
34078 [E][MfClassicPoller] dist from nt prev: 697
34122 [E][MfClassicPoller] nt_enc (plain) 5f10c17e
34125 [E][MfClassicPoller] dist from nt prev: 691
34168 [E][MfClassicPoller] nt_enc (plain) 9ecb5616
34171 [E][MfClassicPoller] dist from nt prev: 687
34215 [E][MfClassicPoller] nt_enc (plain) ed7f144c
34217 [E][MfClassicPoller] dist from nt prev: 687
34262 [E][MfClassicPoller] nt_enc (plain) 8314978b
34264 [E][MfClassicPoller] dist from nt prev: 693
34308 [E][MfClassicPoller] nt_enc (plain) cb577efa
34311 [E][MfClassicPoller] dist from nt prev: 687
34354 [E][MfClassicPoller] nt_enc (plain) 0eb8cc64
34357 [E][MfClassicPoller] dist from nt prev: 685
34401 [E][MfClassicPoller] nt_enc (plain) 335a2805
34403 [E][MfClassicPoller] dist from nt prev: 685
34448 [E][MfClassicPoller] nt_enc (plain) c7044845
34450 [E][MfClassicPoller] dist from nt prev: 693
34495 [E][MfClassicPoller] nt_enc (plain) cf06933f
34497 [E][MfClassicPoller] dist from nt prev: 693
34541 [E][MfClassicPoller] nt_enc (plain) 7aa828d2
34544 [E][MfClassicPoller] dist from nt prev: 689
34552 [E][MfClassicPoller] Calibration completed: min=680 max=700 static=false
#

here, 5866 is discarded because it's an insane distance and we'd never find a disambigious nonce pair

regal storm
#

I'm going to try to reopen the PR today.

regal storm
#

we're one feature away from the PR having all features (NFC app loading UID dict)

#

going to address a few reviews and reopen

harsh cobalt
#

You mentioned plugins were slowing things down, is it a better idea to make a simple JS API for plugins that are just KDFs? Most KDFs are going to be pretty simple after all

regal storm
#

the reason why the plugins create lag is because each one reinitializes the poller and destroys it

#

and reading the length of the dictionary because of the SPI bottleneck, as well as the small read buffer

#

I don't think the KDFs need to destroy the poller every time

#

plugins maybe, since they are more versatile?

harsh cobalt
#

Yeah what I'm thinking was just a "here's a UID, sector, and key number, give keys"

#

Like super simple no actual interaction with the card

#

Maybe expose MAD data perhaps

regal storm
#

ideally the input should be MfClassicData or something

#

reason being you want to know if the card is applicable to the KDF being run

#

well, shouldn't constrain it to just MfClassic

harsh cobalt
#

I mean sure, but you can't have the data without reading the card, which needs keys, and since checking a key is so fast why not just get all keys for the UID and treat it the same as dictionary keys

harsh cobalt
regal storm
harsh cobalt
#

DESFire could do the same with pass in UID and an optional list of AIDs, then return a set of AIDs and keys/algos to try, desfire can be configured to not allow AID enumeration so if the list is empty the KDF would just assume it's present to test for it

#

Picopass could work similarly passing in the CSN and the AIA

#

Could be useful for non iCLASS uses of picopass cards

regal storm
#

mfkey.fap goes under /ext/apps/NFC/mfkey.fap
mfkey_init_plugin.fal goes under /ext/apps_assets/mfkey/plugins/mfkey_init_plugin.fal
but probably easier to just build MFKey from source with ufbt launch because there's some random .assets.signature file in /ext/apps_assets/mfkey/

#

not sure what that is

hidden nexus
#

I am running it right now, found the backdoor
now I opened mfkey and it was ready to start cracking for the remaining unfound keys

regal storm
#

Willy just freed up a bit of memory. We're slightly closer to where we need to be for full speed MFKey

regal storm
#

PR reopened

#

we can do faster static encrypted attacks but I don't see that as a reason to not merge it

#

all of the base functionality is there

regal storm
#

3822 not really seeing the movement we need to get it merged into 1.1. Haven't heard back from OFW devs for 2-3 days

#

We're coming up on when 1.1 would be dropped and I don't see a PR for the NFC app MFKey flow

#

If there's something else they need from us we're going to need to know soon so we can avoid it being pushed back to 1.3

#

I'll try to ping skotopes, maybe that'll help.

regal storm
#

I'm planning a follow-up PR to speed up backdoor reading (we can eliminate 16 auths in backdoor read thanks to an optimization doegox made earlier today, shaving off as much as 200 ms off the attack!) as well as MFKey 3.1 for faster static encrypted nonce attacks.

#

if we have spare time I'll see if I can get the faster backdoor reads into 3822 but for now I'm just going to focus on any of the remaining TODOs and reviews

#

as well as Hardnested for the mobile app

neat kayak
#

Is this time normal?

regal storm
#

That looks like it's static encrypted.

#

it's why I've been mentioning speeding up static encrypted attacks

#

static encrypted tags are more of a proof of concept at the moment, they're being bottlenecked by the SPI write speed

#

on a desktop it runs in under a second. Until we can either buffer candidates or reduce them, it'll take a lot longer than it should

harsh cobalt
#

Wait SPI write speed? To the NFC chip? Can't that do like 10mbit, way faster than the HF air speed

regal storm
#

to the SD card

#

it needs to save tens of thousands of key candidates

harsh cobalt
#

Ooh

regal storm
#

schedule update

#

tldr I'll still work on a few remaining things for 3822 but mainly going to focus on MFUL-C

#

I've been fuzzing commands on MFUL-C cards for the past 2 days and read through the paper

regal storm
#

Used 3822 against a new card I got today and had a full copy of it (cracked the unknown key) within 5 min party

#

all on the Flipper

sweet quartz
regal storm
#

it was mentioned in the paper but unimplemented

#

I'll look to see if there are any properties which don't depend on the other key

regal storm
#

varying key B, keeping initial nt constant

#

100 samples

#

large key A

#

the period is very clear

#

(8)

#

large key A and B

file-LsB3KJEsPtkxI5RhJPdtEwiF.png
regal storm
#

Just about done with the Hardnested recovery script as of this morning. Removed all of the Python and the functionality to connect to the Flipper Zero. It's useful but not for what we're going to do. I'll make a simple driver program later today which loads the .nested.log file until the web version or mobile app version are complete.

#

Which may take a while because the Hardnested source is a dumpster fire.

regal storm
#

working beautifully

#

you need to manually copy over your .nested.log, and the keys back into your user dictionary, but the PC version is just a bridge until the real process is in place

regal storm
#

So I've been thinking about the best way to approach static encrypted cards on the Flipper

#

I think what we do is run MFKey in half speed mode so that we have approximately 50 KB of free RAM

#

then we malloc an array of MfClassicKey that is the total remaining size of the rest of the RAM minus 2-4 KB. then as we find the keys, we write it to the array. once the array is fully populated, we do a batch write to the CUID dictionary

#

this reduces the number of individual file opens and writes from 30-50k to around 6

#

and static encrypted should run in around 10 minutes per key

#

then there's around 7.5 minutes for the Flipper to find the key via online bruteforce. the only way we can reduce this is by reducing the key candidates using the information the chosen nt gives us

regal storm
#

more details on the main GitHub page

#

if you're looking for themes or a custom menu or unlocked SubGHZ restrictions turn back, not planning on adding any of that.

#

at most I'll add a single animation

#

it's just a firmware for anyone who likes OFW, but wants better NFC capabilities and utilities for field use

#

(and I'll be upstreaming code to OFW as often as I can)

barren heath
#

any chance to unlock mifare ultralight password protected cards by now with fz (salto reader)?

lean sundial
barren heath
#

thank you, it's C

regal storm
# regal storm I'm going to keep this custom firmware fork up to date with the features we're i...

So instead of discussing Xero here, I'll just discuss it and its plans on a dedicated server. I linked an invite at the bottom of the firmware repository: https://github.com/noproto/xero-firmware

Making a firmware that I want to provide with newly developed NFC features (like Ultralight C/DESFire dictionary attacks, maybe emulation, Tesla credential protocol, etc.) long term and persistently is not a small undertaking. I want each new feature branch to bring improvements like 3822. To make my own ends meet while I develop the improvements and add new attacks (I'm not Flipper Devices, and I'm not one of the big custom firmware repos), I'm planning to make the "dev/testing/preview" source+builds of new features only available to supporters as well as friends in the community. When the features are both stable and finished, I'll merge feature branches with the public repo and PR them to OFW so everyone gets them.

The amount of R&D I'm doing is unsustainable long-term. I don't want to give up making brand new attacks for the Flipper Zero either. Every custom firmware will immediately pull working code, people will want support, and nobody will donate to fund open source development since nobody will even know it exists. I've tried R&D on the side of my main work for 2.5 yrs but then you have the year-long delays like what happened with all of the features that went into 3822. If you don't want to support my work, that's fine too. It'll be pulled upstream to OFW as soon as it's stable enough to run. Some people will just be upset I'll be asking for donations. I've said no to every donation for years, I would not ask at all if it wasn't necessary to continue.

#

also none of this applies to the current improvements for MIFARE Classic attacks (nested attacks, MFKey, static encrypted attacks, Hardnested). 3822 will be included in OFW 1.1, and refactored for minor performance improvements in 1.2. I've been going back and forth with the OFW developers on several code style improvements before it gets merged with OFW.

odd grail
#

Question regarding MFKey: is it possible/easy to use the iOS and Android app to do the calculations, just like MFKey32 did, instead of running locally on Flipper?

#

I totally respect the decision to have it running on Flipper as that makes it complete. But a few recent sessions I’ve run lasted ~5 hours. Not sure if that’s a normal time frame. It kind of limited the availability of Flipper for doing other things in the mean time and I’m not sure if users usually can maintain access to the same card after several hours.

regal storm
#

The answer is yes, you can.

#

The long answer is why were you waiting 5 hours? The expected runtime of MFKey is 2.5 minutes

#

5 hours sounds like an extreme edge case. If you were trying to recover all of the keys on the card or had a 4K, running at half speed because you were out of RAM, and for some reason found absolutely no keys from any nonces then it would take 5 hours.

#

Unless you're asking about static encrypted, that is a proof of concept which I already know how to speed up significantly

#

Bear in mind three things about static encrypted:

  • It hasn't been optimized at all for the Flipper Zero, it has just ended up working
  • Up until 2 months ago it was impossible, so changes are happening quickly and 5 hours is considered a good result
  • The next gen device should never be low on RAM, and should be an order of magnitude faster for all attacks (seconds instead of minutes). Developing it for the Flipper Zero is an investment that will pay off in several months, and most of the code is already in place to support the next gen device.
odd grail
regal storm
#

MFKey 3.1 will support faster static encrypted nonce solving

odd grail
# regal storm Bear in mind three things about static encrypted: - It hasn't been optimized at...

I understand that it works as a PoC right now. I asked whether it could be run on other devices mainly because I didn’t know how much room is left for optimization. But next gen definitely sounds promising and that would make it unnecessary. I think it’s mostly a trade off between the hassle of bringing out a phone and launching the app or run locally, depending on whether running on a phone can save a few hours or a few minutes.

odd grail
regal storm
#

For static encrypted nonces, the room left for optimization is essentially "all of it". I'm expecting ~10 min per key in 3.1. Then we can use the properties of static encrypted nonces to reduce the number of key candidates even further, bringing it down to the goal of 5 minutes per key. Most cards have 1-2 unknown keys so this is a practical runtime.

odd grail
regal storm
#

The STM32U5 in the next gen has almost 10 times the available RAM and 3 times the base clock speed. There's an optimization that we can get at only 2x the available RAM which makes it run in seconds before you consider the clock speed.

#

oh and also before you consider that we have a dedicated instruction in the next processor for what the program spends 50% or more of its life doing

#

evenparity32

#

So yeah the short-term and long term future is really, really bright. The only attack which must be offloaded, and I could use some help with, is Hardnested @odd grail

odd grail
#

I’m assuming there is a population of MFCs out there that are exclusively crackable by hard nested (card only, of course)?

regal storm
#

About 15% more or less are only solvable with Hardnested since they have an upgraded PRNG

#

this can be run on a phone the same way Mfkey32 runs on a phone. Let the NFC app collect the nonces, and have the mobile app pull them and solve them

#

The first part is already finished. The second runs on a PC today, but we could port it over to the mobile app

odd grail
#

Cool! Is the second part your fork of the FlipperNested or are you referring to some pm3 source code?

regal storm
#

It's all the Proxmark source but yeah, HardnestedRecovery is what we need to run on the mobile app

odd grail
#

thanks for the pointer!

regal storm
#

There are two technical challenges: available RAM and desktop specific optimizations which need to be stripped away or replaced

#

but it should run fine

#

most phones have around 4 GB of RAM

#

I can make example .nested.log files on demand if you want to try porting it into the app.

#

anyway that's all for my 3 AM blog here

regal storm
#

I expect the end of this multi-year project at the end of February or early March. Every attack except EMFI has been tested and implemented on the Flipper, with a few more attacks dropping Jan 20. The EMFI rig has been built and I'm doing the first tests on it this month.

wintry grotto
#

Where can i instal the latest version of your software and every things you there say?

regal storm
wintry grotto
#

Thx bro

#

And how can i put this firmware into my fz

regal storm
#

Or the mobile app, or the Flipper Labs site

#

You use the tgz file to update it

wintry grotto
#

I think i got it. I install the version from your discord community and instal it throught the app of fz from filles

#

Im rookie so

#

thank you

shadow gazelle
#

why are you asking this here? this is a channel for mifare attacks using the FZ, on the FZ discord.

Regardless, you've given us so little info that it's impossible to help you

#

go ask in #nfc , it'll be more relevant there, even if still not relevant for this server

mossy pagoda