Coder Social home page Coder Social logo

nfcgate / nfcgate Goto Github PK

View Code? Open in Web Editor NEW
921.0 34.0 120.0 3.04 MB

An NFC research toolkit application for Android

License: Apache License 2.0

Java 75.99% C++ 21.74% C 1.04% HTML 0.81% CMake 0.42%
nfc android-nfc security security-audit android relay replay cloning hce hacktoberfest

nfcgate's Introduction

NFCGate

NFCGate is an Android application meant to capture, analyze, or modify NFC traffic. It can be used as a researching tool to reverse engineer protocols or assess the security of protocols against traffic modifications.

Notice

This application was developed for security research purposes by students of the Secure Mobile Networking Lab at TU Darmstadt. Please do not use this application for malicious purposes.

Features

  • On-device capture: Captures NFC traffic sent and received by other applications running on the device.
  • Relay: Relays NFC traffic between two devices using a server. One device operates as a "reader" reading an NFC tag, the other device emulates an NFC tag using the Host Card Emulation (HCE).
  • Replay: Replays previously captured NFC traffic in either "reader" or "tag" mode.
  • Clone: Clones the initial tag information (e.g. ID).
  • pcapng export of captured NFC traffic, readable by Wireshark.

Requirements for specific modes

  • NFC support
  • Android 4.4+ (API level 19+)
  • Xposed-compatible hooking framework (EdXposed, LSPosed with Zygisk or Riru): On-device capture, relay tag mode, replay tag mode, clone mode.
  • ARMv8-A, ARMv7: Relay tag mode, replay tag mode, clone mode.
  • HCE: Relay tag mode, replay tag mode, clone mode.

Usage

Building

  1. Initialize submodules: git submodule update --init
  2. Build using Android Studio or Gradle

Operating Modes

As instructions differ per mode, each mode is described in detail in its own document in doc/mode/:

Pcapng Export

Captured traffic can be exported in or imported from the pcapng file format. For example, Wireshark can be used to further analyze NFC traffic. A detailed description of the import and export functionality is documented in doc/pcapng.md.

Compatibility

NFCGate provides an in-app status check. For further notes on compatibility see the compatibility document.

Known Issues and Caveats

Please consider the following issues and caveats before using the application (and especially before filing a bug report).

NFC Stack

When using modes, that utilize HCE, the phone has to implement the NFC Controller Interface (NCI) specification. Most of the phones should implement this specification when offering HCE support.

Confidentiality of Data Channel (relay)

To ensure confidentiality and integrity, use Transport Layer Security (TLS), which can be enabled in NFCGate settings. You need a CA-issued or self-signed certificate. Certificates from system-trusted CAs are trusted automatically. Self-signed certificates can be trusted by the user on first use ( TOFU).

Compatibility with Cards (relay, replay, clone)

We can only proxy tags supported by Android. For example, Android no longer offers support for MiFare classic chips, so these cards are not supported. When in doubt, use an application like NFC Tag info to find out if your tag is compatible. Also, at the moment, every tag technology supported by Android's HCE is supported (A, B, F), however NFC-B and NFC-F remain untested. NFC-A tags are the most common tags (for example, both the MiFare DESFire and specialized chips like the ones in electronic passports use NFC-A), but you may experience problems if you use other tags.

Compatibility with readers (relay)

This application only works with readers which do not implement additional security measures. One security measure which will prevent our application from working in relay mode is when the reader checks the time it takes the card to respond (or, to use the more general case, if the reader implements "distance bounding"). The network transmission adds a noticeable delay to any transaction, so any secure reader will not accept our proxied replies.
This does not affect other operating modes.

Android NFC limitations (relay, replay)

Some features of NFC are not supported by Android and thus cannot be used with our application. We have experienced cases where the NFC field generated by the phone was not strong enough to properly power more advanced features of some NFC chips (e.g. cryptographic operations). Keep this in mind if you are testing chips we have not experimented with.

Publications and Media

This application was presented at the 14th USENIX Workshop on Offensive Technologies (WOOT '20). An arXiv preprint can be found here.

An early version of this application was presented at WiSec 2015. The extended Abstract and poster can be found on the website of one of the authors. It was also presented in a brief Lightning Talk at the Chaos Communication Camp 2015.

Reference our Project

Any use of this project which results in an academic publication or other publication which includes a bibliography should include a citation to NFCGate:

@inproceedings {Klee2020Nfcgate,
    author = {Steffen Klee and Alexandros Roussos and Max Maass and Matthias Hollick},
    title = {NFCGate: Opening the Door for {NFC} Security Research with a Smartphone-Based Toolkit},
    booktitle = {14th {USENIX} Workshop on Offensive Technologies ({WOOT} 20)},
    year = {2020},
    url = {https://www.usenix.org/conference/woot20/presentation/klee},
    publisher = {{USENIX} Association},
    month = aug,
}

The initial NFCGate paper describing the first version of NFCGate can be cited as follows:

@inproceedings{Maass2015Nfcgate,
  title={DEMO: NFCGate: an NFC relay application for Android},
  author={Max Maass and Uwe M{\"u}ller and Tom Schons and Daniel Wegemer and Matthias Schulz},
  booktitle={Proceedings of the 8th ACM Conference on Security \& Privacy in Wireless and Mobile Networks},
  year={2015}
}

License

   Copyright 2015-2024 NFCGate Team

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.

Contact

Used Libraries

Credits

  • ADBI: ARM and THUMB inline hooking

nfcgate's People

Contributors

danielaw avatar haxxproxx avatar kleest avatar malexmave avatar roussosalex avatar thoelze1 avatar uwem avatar weebl2000 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nfcgate's Issues

Compatibility with Nexus 4 as reader

The code from the networking-refactoring branch works with a Nexus S as the reader and a Nexus 4 running our native code as an emulator, but a nexus 4 (even an unpatched one) cannot function as a reader right now.

This is appearently due to this bug in android. We need to find a workaround. :/

Assigning @UweM for now, because he knows what he is doing with native code. 👍

Infinite error message loop upon connection loss

This happens if the connection suddenly dies. I thought I had fixed it, but was wrong, appearently. Will deal with it later, creating issue to remind myself. (The error messages just keep on scrolling)

03-13 13:28:29.783    7678-8260/tud.seemuh.nfcgate E/tud.seemuh.nfcgate.network.LowLevelTCPHandler$CommunicationThread﹕ Error no postive number of bytes: 0
03-13 13:28:29.783    7678-8260/tud.seemuh.nfcgate I/tud.seemuh.nfcgate.network.LowLevelTCPHandler$CommunicationThread﹕ Reading bytes of length:0

Choose a license

We need to talk to our advisor and afterwards choose a license for our software, if possible.

Prepare GUI for proper networking sessions

What we need:

  • Button for "Create Session"
  • Button for "Join Session"
  • Some sort of field to enter the session secret into
  • Some sort of status field that shows the current status of the connection (connected, session active, session ended, disconnected, ...). A text field that we can update is probably enough for now.
  • Another (or the same) field to display the status of the other device in the session (no other device connected, card / reader connected, ...). Again, a text field is probably enough for now.

If we need more screen real estate, we could remove the "Please hold your device next to an NFC tag / reader" message field and replace it. Also, the "Your own ID is:" field does nothing at the moment, so we can probably do something useful with that space as well :).

Assigning @haxxproxx again because he's our GUI guru. I'll work with him on the networking side to decide on and implement the details.

General issue (sort of a brain-dump) on what is still to do ;)

  • Write an email to the coordinator to check what documentation must be provided on 12-03-2015?
    See: PDF "lab-exercise rules" (Slide 18): ~20 pages, project description, SW-documentation, and “user manual”
  • Write an email to the coordinator to check when we will have the final presentation?
  • General code cleanup (removing silly comments, etc.)
  • Re-factor code to be more human readable
  • Check for ToDos still left in the code section
  • Test if the latency could be improved by using Internet over USB (see Stackoverflow) on the Android phones and the Server should be connected via Ethernet
  • insert here whatever is still left to do & not yet assigned to anyone
  • Write test cases (haha as if)
  • Stop threads gracefully on button "Abort" or "Reset"?
  • Add option to disable native code (we problably mess something up with our code, the user should at least got the option to disable it 😉)

Landscape mode

Either disable landscape mode or make sure that it works properly.
604122783_36233

Basic GUI

Write a basic GUI, featuring debugging output and possibly a few buttons to establish a connection et cetera.

Networking keepalive thread

We have keepalive messages in the protocol, but we aren't using them right now. Maybe we should implement a thread for that.

Include basic parsers

Once the sink infrastructure is in place (#47), it should be comparatively easy to include a basic NFC protocol parser, if we choose to do so. We already have some existing python code for a DESFire parser in the misc repository, maybe something similar could be included here?

Add Cryptographic protection to network messages

Once we have targeted sessions (see #10), we should also think about cryptographically protecting the contents of the messages. Something like a diffie-hellmann at the beginning of the session would probably work.

Networking housekeeping

Terminate network connections properly when the user clicks "Disconnect", handle connection losses gracefully (retry connection or stop the thread), stuff like that.

Related to #10, #15, #19

Basic Networking

At least one working network channel that does not freeze the application.

Forge ISO 14443-4 FWT negotiation

According to this paper, ISO 14443-4 specifies a Frame Waiting Time which is negotiated between the reader and card. It is not used by many readers, but for those that use it, we could set the FWT as high as 5 seconds to give us some breathing room, at least as long as we can actually influence that negotiation and it does not happen in the firmware of the NFC chip.

On Startup, check if NFC is enabled

As discussed in #22, we should check if NFC is enabled on startup and if not, display a message saying "Hey, you need to enable NFC", with a button to go to the settings. That way, we can get rid of the "NFC Settings" point in the settings menu.

UID Clone mode

Not sure if this should be in this app or a seperate one, but a clone mode would be pretty cool. That would allow you to mess with readers that authenticate based solely on the UID. However, for that we would need to introduce a new Activity and some sort of navigation between modes, as that will not fit on the already-too-crowded MainActivity screen.

An option would be a Swipe View with one tab containing our standard interface, and another tab containing a clone mode where we could:

  • Manually enter anticollision values to be loaded into the card
  • Clone the anticol values from a card by holding it against the phone
  • Optionally, load anticol values from older sessions if we ever implement a session log

Refactor NFC interactions into their own class

Right now, the networking code directly interacts with the NFC implementations. We should probably have an abstraction layer in-between to make it easier to implement new networking technologies without intimate knowledge about how the NFC code works.

Investigate influence of findSelectAid-patch on HCE sessions

It may be possible that our patch to findSelectAid results in a new HCE session being created for every command. This is inefficient and also messes with the displayed state of the HCE phone at the other end. We should check if this is the case, and if we can do anything about it.

Display compatibility on app start screen

A small indicator of which technologies are supported on the current device would come in handy.

  • NFC: Yes
  • Reader Emulation: Yes
  • Card Emulation (HCE): No

This could be done with colored text or checkmarks or whatever, as long as we can clearly see what should work and what not.

Readermode settings not persistent

If we enable readermode, after the app is reinstalled, readermode stays enabled in the settings, but is not used by the app. You have to manually deactivate and reactivate it in the settings.

Pinging @haxxproxx, as this is probably related to the way settings are set and retrieved. Can you take a look?

Dump NFC Traffic to file

For research purposes, it would be good if we were able to dump NFC conversations to a text file in order to take a look at them later.

Change networking code

Get away from the broadcast system and towards targeted sessions between two devices. This allows for more parallel sessions and more privacy (who wants to broadcast their NFC cards to god-knows-who?).

Add Protobuf message for anticollision messages

This message type needs to contain the following information:

  • UID
  • Historical Byte
  • ATQA
  • SAK

This message is sent from the phone talking to the card to the one talking to the reader. It needs to be sent before the other phone is held against the reader. It needs to be supported in all code bases (server and clients).

Check and display status of TCP connection

Currently, we do not check the status of the TCP connection to the server. It may break down due to server restarts / connection problems and we will not realize it until we try to send something, at which point we will probably get an exception and crash.

Some sort of heartbeat would probably be handy. May be something to keep in mind for #10.

Rule-based replacement of NFC commands

We could log all NFC commands and display them in a list. Then, we could let the user create rules to change these requests on the fly (e.g. replace certain bytes, drop messages, ...) to see what happens and try to find holes in the protocols.

There is obviously a certain risk of bricking a card with that, but it would be worth a try, IMO. Somewhat related to #38.

Basic NFC Emulator functionality

Get the NFC Emulator to work without throwing exceptions (looked pretty good last time we checked, but I'll create this issue anyway).

Support more protocols (DESFire etc)

At the moment, we can only emulate certain cards and only if we register the relevant AID before installing the app. It would be great if we could just support all NFC cards. This requires changes to the native code, which we will probably do using hooks with substrate. Alternatively, one could compile a custom CyanogenMod, but the build process keeps failing on me. :/

few GUI Issues

  • The new buttons give no feedback to the user if they are pressed or not
  • The Settings dialogue should close if "Save Settings" is pressed
  • instead of HCE enabled it should just be called "available"

App crashes on reset button press while not connected

Relevant Stacktrace:

 Caused by: java.lang.NullPointerException
        at tud.seemuh.nfcgate.network.NetHandler.disconnectCommon(NetHandler.java:323)
        at tud.seemuh.nfcgate.network.NetHandler.disconnect(NetHandler.java:298)
        at tud.seemuh.nfcgate.MainActivity.ButtonResetClicked(MainActivity.java:316)

Deal with "Connection refused" error in a better way

Right now, a "connection refused" results in a caught exception and not much else (the program hangs at "Creating session" / "Joining session"). We should notify the user that the connection failed instead of doing nothing.

Develop alternate native patch method for Android 5 / ART

Substrate does not support Android 5 / ART. We should think about how we could provide the required native code patches without Substrate.

The current ideas are:

  • Ship our own compiled libnfc and switch it out when the app becomes active
  • Ship our own compiled libnfc parts, exporting all symbols, and forward unmodified symbols to original libnfc
  • Ship our own compiled libnfc, export only modified symbols and shadow existing symbols with them
  • Try injectso again

Appearently, XPosed works with Android 5, but, right now, only if you manually flash it (can't just install via the Play Store). If that changes, we could consider using it for the Java patch, but if this stays the same, we may have to find another way to fool the java findSelectAid function.

Switch to using Maven for Protobuf dependency

Right now, we have the whole source code for Protobuf in our repository. This is bad practise, we should switch to using maven to manage that. Maven is integrated into Android Studio, so it's no additional dependency in itself. No reason not to use it.

More communication channels

Add more communication channels (Bluetooth / WiFi direct, for example). This may or may not help circumvent the timing checks of certain readers.

UpdateUI from another thread

It should be possible to update a textview from another thread. There should be a possibility to either:

  • append Text or
  • setText?

Attaching an NFC tag more than once to the phone results in exception

Steps to Reproduce:

  • Start the App (ReaderMode on or off doesn't matter)
  • Attach the phone to an NFC Tag, one should see Discovered tag with intent: [...] in the log
  • remove tag from phone
  • attach it again and we get:

02-27 16:56:39.564 7859-7859/tud.seemuh.nfcgate E/NFC﹕ NFC service dead - attempting to recover
android.os.DeadObjectException
at android.os.BinderProxy.transact(Native Method)
at android.nfc.INfcAdapter$Stub$Proxy.setForegroundDispatch(INfcAdapter.java:395)
at android.nfc.NfcAdapter.disableForegroundDispatchInternal(NfcAdapter.java:1180)
at android.nfc.NfcAdapter$1.onPaused(NfcAdapter.java:1174)
at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3063)
at android.app.ActivityThread.performPauseActivity(ActivityThread.java:3003)
at android.app.ActivityThread.handlePauseActivity(ActivityThread.java:2981)
at android.app.ActivityThread.access$1000(ActivityThread.java:135)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1207)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5001)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
at de.robv.android.xposed.XposedBridge.main(Native Method)
at dalvik.system.NativeStart.main(Native Method)
02-27 16:56:41.434 7859-7859/tud.seemuh.nfcgate I/DEBUG﹕ onResume(): intent: tud.seemuh.nfcgate.main
02-27 16:56:41.434 7859-7859/tud.seemuh.nfcgate E/NFC﹕ NFC service dead - attempting to recover
android.os.DeadObjectException
at android.os.BinderProxy.transact(Native Method)
at android.nfc.INfcAdapter$Stub$Proxy.getState(INfcAdapter.java:278)
at android.nfc.NfcAdapter.isEnabled(NfcAdapter.java:599)
at tud.seemuh.nfcgate.MainActivity.onResume(MainActivity.java:131)
at android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1192)
at android.app.Activity.performResume(Activity.java:5310)
at android.app.ActivityThread.performResumeActivity(ActivityThread.java:2764)
at android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2803)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1238)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5001)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601)
at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:132)
at de.robv.android.xposed.XposedBridge.main(Native Method)
at dalvik.system.NativeStart.main(Native Method)
02-27 16:56:41.434 7859-7859/tud.seemuh.nfcgate E/NFC﹕ could not retrieve NFC service during service recovery

An/Ausschalter für Native Patch

Wir benötigen noch ein An/Ausschalter für alles, was wir im NFC Daemon rumpatchen.
Das Modul selbst wird immer beim Booten geladen, aber es sollte während es in Aktion ist irgendwie überprüfen, ob es überhaupt etwas tun soll. Momentan stört es andere NFC-Kommunikation.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.