MagSpoof LF RFID implementation

[zacharyweiss]

Description of the feature you're suggesting.

Howdy! Some of you may already be familiar with Samy Kamkar's "MagSpoof" POC (website / GH repo). For those unfamiliar, the TL;DR is one is able to convince magstripe readers a card has been swiped by modulating an electromagnet to reproduce the insertion and removal.

It appears previously, members of the Flipper community discussed an implementation that uses the Flipper's LF RFID coil to achieve this (forum post) and it was implemented in a fork of the official FW but never merged. This seems to be a great candidate to include with Unleashed; there's a number of swipe access cards I'd love to try emulating with a Flipper MagSpoof app.

Anything else?

No response

[zacharyweiss]

From a bit more digging, seems there's additional spots this has been worked on:

• Russian Flipper hackathon which included a magspoof project
• An old commit to Unleashed
• And a more recent attempt by the wetox team

[jluo98]

https://discord.com/channels/937479784148115456/1026058078921166939/1041159629020860506

Thanks for the link! I managed to compile it for the latest firmware. Do you happen to know what type/format of file this reads? I have a couple of raw magnetic stripe info ready, just not sure how to format those so the app can read them.

[zacharyweiss]

https://discord.com/channels/937479784148115456/1026058078921166939/1041159629020860506

Thanks for the link! I managed to compile it for the latest firmware. Do you happen to know what type/format of file this reads? I have a couple of raw magnetic stripe info ready, just not sure how to format those so the app can read them.

From a very quick skim of that code, looks like the file loading is handled in magspoof_device.c. Seems to expect a file in a "magspoof" folder, with ".magspoof" as the extension, and a header that reads "Flipper Magspoof device". Not yet sure how it expects the rest of the data in the file to be formatted.

How did you compile for the most recent FW? I've yet to set up a dev environment for Flipper; any guides you followed?

[jluo98]

How did you compile for the most recent FW? I've yet to set up a dev environment for Flipper; any guides you followed?

The compiling guide is here in the official repo. I did see an error while compiling and the app does run but crashes sometimes. The code probably needs some fixing.

[zacharyweiss]

Appreciate the link! I gave that a go; cloned unleashed, set up fbt, modified the application.fam manifest to designate it as FlipperAppType.EXTERNAL, and built fap_magspoof without errors, but when copied onto the Flipper it still gives me a preload failed error claiming the API version is mismatched, despite my Flipper running unlshd-018. Was there something else you needed to modify, or specify when building the app, for the API versioning to be happy?

(The build logs indicate API v10.1)

EDIT: Scratch that, flashing with fbt solved the API mismatch. I see what you mean about crashing. The inclusion of a read function leaves me wondering if this was written with an external HW module in mind. Will definitely need to run through the code; at minimum if it has a way to generate data files from that read function, you could use that to determine how to format your existing data for testing the emulation.

[zacharyweiss]

@jluo98 To your earlier question on data format, it's using flipper_format. While I'm still pretty unfamiliar with the these libraries / tools, it seems a data file (magspoof/*.magspoof) would read as follows.

Filetype: Flipper Magspoof device Version: 1 Data: data

Where data is just a string. Seeing as most magstripe readers are just HIDs, perhaps just try whatever the plaintext output of a swipe is? I went to test if this file would load, but attempting the "Saved cards" action causes a repeatable crash for me, failing some furi_assert. I'll need to find that assert, but if you're able to open the "Saved cards" option on yours, do let me know if that format of file is opened/parsed properly.

EDIT: From looking through the scenes, appears the "Saved cards" one is very incomplete, with all options being commented out. That said, the read_card scene seems to have a number of hardcoded functions, including for emulating. It seems to play bits by setting RFID pins 2 and 4, but confusingly also imports and sets iButton, and the comments make reference to an H-bridge. Would love insight from anyone more familiar with the Flipper's RFID system & API.

[jluo98]

@zacharyweiss Very interesting findings. Using the saved card feature did bring up the file browser, but selecting the test file I prepared caused a crash.

AFAIK flipper does not have any onboard sensors to read a magnetic stripes, only emulation is possible with RFID hardware. The read function is probably written for an external module.

[zacharyweiss]

RX is definitely external; seems that's what they're importing the UART library for.

TX is internal. Seems the few confusing comments I was seeing re: H-bridge / motor driver etc were just directly from the original magspoof project (and not indicative of an external module for TX). Most of the code in the read_card scene seems to be directly copied from Samy Kamkar's repo, and just modified slightly to work with the Flipper API and relevant I/O. Leaves me wondering if it wouldn't be easier to start from scratch with Samy's code as the base, rather than fixing this half-finished port.

[zacharyweiss]

So, interestingly it seems the original hackathon project intended for external TX based on this old schematic I found. It seems future passes / iterations have been done with the attempt of using the RFID coil, but it's hard for me to evaluate their effectiveness as the RFID API remains opaque to me.

It seems there's no reason it wouldn't be able to work on just the RFID coil; this guy managed to simplify the hardware to something analogous. Presumably, if we just have an easy way to emit simple OOK signals from the RFID antenna we'd be golden. I've been struggling to understand the RFID API / relevant pins / etc though. Are there any resources or folks who'd be able to offer insight? The FURI HAL code itself isn't well enough commented for me to follow.

[zacharyweiss]

Have been documenting further iterations / attempts / developments in this Discord thread.

[zacharyweiss]

A few quick updates:

• I've been able to pick up a signal on a janky antenna I've made for my oscilloscope. It's weak, but at least indicates I'm able to pull the coil
• Currently rewriting all the boilerplate / scenes / file code as it's exceptionally broken, and easier to just start from scratch
• If the signal remains weak after some more messing with it, next ideas (in no particular order) are adding some kind of subcarrier freq, trying the timer system instead of direct-writing the pins, and trying the NFC coil additionally/instead

[zacharyweiss]

See here for my WIP ground-up rewrite. I'm using the README as very coarse notes on what remains to be done — anyone is welcome to contribute!

[jluo98]

This is awesome! Thanks so much for working on this!

[skynet01]

Any updates on this :) Or for sure we will need an add-on antenna? Btw thanks for taking time and writing WIP in that readme file

[zacharyweiss]

I'll be building in the option for TX over RFID or an external GPIO connected coil. RFID does seem to work, just weaker. Been busy with other work so haven't had much time to dedicate to it this past week. The README in my repo documents all of what remains.

[skynet01]

Woo! Set up a "buy me a beer link", I am sure some of us would be happy to contribute and motivate your efforts :)

[zacharyweiss]

A few updates; reworked the file format and added a variety of emulation config options — you can now TX over RFID or GPIO, change the clock and interpacket durations, and select the track to emulate. I've also included a sample file in assets (add it to the mag folder at the Flipper SD's root) for anyone testing it. Reverse track emulation still yet to be implemented, and much cleanup (especially of saved info displayed, and the add manually process) + tuning + testing remains. Eventually I'll start exploring RX options as well, but I anticipate that'll be a large project.

Also added a buy me a coffee link to the repo! Please don't feel compelled to donate — I'm doing this solely for fun / my own sake — but I won't turn down a drink :)

[skynet01]

Thanks for the updates! Looks like your latest version is now included in the latest RM Firmware (the patreon one) for those who want to try it out without compiling it manually.

As far as RX goes I know you mention square reader, I believe square allows you to use their reader with 3rd party apps so maybe we can use the phone's Flipper companion app to do the reading and then send over the data to flipper itself? Similar to how "NFC Tools" hub app works?

[RogueMaster]

It's also in the GitHub code (the one you compile yourself) and will be on todays GitHub release 😄

[zacharyweiss]

Cool! It's still likely too unfinished for anyone other than fellow developers to mess with yet, but if that gets other folks interested in digging through the code with me -- all the better. One thing though: would you mind including it as a submodule rather than just copying the files? It'll keep things up to date for you, and make it easier for folks to find their way back to my repo.

Re: RX methods, does the Flipper companion app allow "sideloaded" community tools? What's the process by which MFkey32 got included?

[skynet01]

Not sure actually, but there is a thread with no answers on flipper forum here: https://forum.flipperzero.one/t/what-is-the-hub-and-how-can-the-community-interact-with-it/10588 maybe if we all ask them more it will get their attention?

Another idea for getting card info is we can maybe import saved NFC cards (the bank cards that got scanned that have a chip)?

[zacharyweiss]

IIRC NFC-scanned EMV cards don't expose the same data as is on the magstripe (card number is preserved across the two, of course, but you lack critical info like CVV; which one should also note is different from the CVV2 that is physically written on cards). At the end of the day though my primary focus remains access cards; abuse potential/misuse I feel is a larger concern with payment-card-specific functionality.

[RogueMaster]

Cool! It's still likely too unfinished for anyone other than fellow developers to mess with yet, but if that gets other folks interested in digging through the code with me -- all the better. One thing though: would you mind including it as a submodule rather than just copying the files? It'll keep things up to date for you, and make it easier for folks to find their way back to my repo.

Hi, I don't mind manually updating as needed. I prefer it since I also make changes to the code. I don't add any applications as submodules. Hopefully this gets other people digging into it with you, or supporting you further to keep working on it 😄

[zacharyweiss]

Understandable. Would likely be better to fork it in that case, and include your own fork as a submodule — but as long as you're including credit and keeping the license, no worries.

[skynet01]

IIRC NFC-scanned EMV cards don't expose the same data as is on the magstripe (card number is preserved across the two, of course, but you lack critical info like CVV; which one should also note is different from the CVV2 that is physically written on cards). At the end of the day though my primary focus remains access cards; abuse potential/misuse I feel is a larger concern with payment-card-specific functionality.

You might be right, I was just thinking of a faster way to adding my cards to flipper, I know that those saved NFC files are more of a reference since very little is included and its different for each card. Still saves typing that big number :) Thanks for considering it.

[rhysperry111]

Hey- will be getting a Flipper Zero soon and I'm pretty interested in this feature, so I'd love to help in some way.

I have access to a USB magnetic stripe reader, which seems to output card data as ASCII for RX. Not sure how exactly I can get the raw card data from that tough.

Also, another thing that I'm not sure how easy it would be to implement is the direction the emulated card moves. Many room key readers require the card to be inserted and then removed in succession in order for the lock to open.

[rhysperry111]

Finally got my flipper, would be happy to help get this moving again <3

[FatherDivine]

Finally got my flipper, would be happy to help get this moving again <3

any updates?

[RogueMaster]

any updates?

I nominate you as tribute

[FatherDivine]

any updates?

I nominate you as tribute

I just ordered a USB mag reader that will be delivered in a couple of hours the same day (delivered). I already have some old magstripes to test. What are the immediate needs for this project? Also, does the internal (or R.L. Multi Pass) currently work with card readers that you traditionally insert a magstriped card inside?

If a solution is needed for processing multiple raw card data, I can create a PowerShell(or pwsh) script that processes the raw data that would work for *nix and Mac OSX. I could turn it into an Android/IOS app which shouldn't be an issue with the reader I mentioned as it's a "USB emulation keyboard" and no driver is needed. This would be using an OTG cable or USB-A to USB-C adapter to connect a USB-based mag reader to the phone. I also run full Linux on one of my unlocked AOSP-based devices. I figure the bigger picture is having portability (hence having the phone read the data via a small headphone jack/lightning-based Square reader which likely isn't just a simple "USB emulation keyboard" and would take more programming). Being able to read/emulate full magstripes "on the fly" and in the field (and possibly write too).

I am no C programmer, but I'm confident the Square (or USB-based) reader could be connected to the flipper's USB-C and interface with the MagSpoof app to read and save magstripes with the proper coding.

[FatherDivine]

any updates?

I nominate you as tribute

Here is my contribution and update to this project: Magspoof Flipper Card Organizer

it's a WIP, and if it's slow at work today I'll finish the code and documentation today as well.

Basically it's a PowerShell module (that can be ran as individual scripts/functions) that organizes magspoof data. Since it's a module, you can call it anytime you open a PowerShell session and type:

invoke-magspoofcardorganizer

That will load it into a mode of detecting the usb reader input to organize (WIP, not working right yet).

if you wish to load a dump file (from scanning strips to a text file and saving as whatever you wish... I use '.dump') then you would use this cmdlet:

invoke-magspoofcardorganizer -FileName "C:\path\to\mags.dump"

or the alias

magorganizer -File "C:\path\to\mags.dump"

The above 2 cmdlets currently just outputp on the screen.

But again I should have all the rest coded in today. I coded what's there now while falling asleep after a long day.

P.S. @RogueMaster thanks for keeping RM as good as it is! That's my firmware of choice.

3/8/24 Edit: Version 0.1 is officially released and you can get it here.. Please test and provide feedback if it doesn't work as expected or for future improvements/code changes.

Maybe someone can use the template to make it work on the flipper (saw someone say connecting HID-emulation device to flipper native isn't possible, but with another device or likes it can be). Also can turn it into python or any other language. PowerShell is available for mac OSX and linux, but I have not tested it on those platforms only. My testing is Windows 10 and 11 (I'm an IT Systems Administrator so much of my day-to-day job is coding in PowerShell).

Changes coming to Version 0.2:

• Allow users to easily set the path of auto or manual card processing (currently goes into c:\temp\mags, an easy place to get write permissions to). You can change the location in the script (that's in the release notes).
• Add leet ASCII art

[zacharyweiss]

Hey folks! Sorry for largely abandoning the project, work got notably busy and progress petered out on internal coil TX; could get it to produce a weak field, but never strong enough to get picked up by a reader w/o an external GPIO coil. Glad to see y'all have been making strides in my absence and continuing to improve the FAP :)