nfcgate / nfcgate Goto Github PK

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

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?).

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?

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

• append Text or
• setText?

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

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.

• 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"

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.

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.

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

Maybe it could be useful to have all of that in a single place, to make it easier to get the right versions of the files at all times. Would imply a slight restructuring of this repository, though. Opinions?

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.

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. :/

We need a GUI for sinks, as discussed in #47. Creating a new issue to keep track of progress on this.

At the moment, the first read tends to fail. It would be cool if we could find out why and fix this in our native code.

Before we set this to public, we should clean up the wiki and write some documentation there.

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.

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)

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).

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. 👍

We aren't using WiFi direct, so we may as well remove all references to it and the relevant dead code.

A basic libnfc demo app that reads an NfcA-Tag.

:)

Get the NFC Reader to work without throwing exceptions.

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

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.

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.

At the moment, the app will crash if we try to enter a domain name instead of an IP address. That should be fixed.

Possible ways to reduce latency:

• Bluetooth
• WiFi direct
• Ethernet via USB

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

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

Probably due to the way the TCP connection thread is implemented. Related to #14 and #10.

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.

We're currently targeting API-Level 20. We should see what happens if we target Android 5.1.

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.

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

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.

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

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

When you change the IP in the IP field and put the phone on a card, the activity is relaunched and the modified IP is discarded. This should obviously not happen :).

Assigning @haxxproxx for now as our UI guy, but this is obviously open to anyone.

Android has support for a standard settings interface: https://developer.android.com/guide/topics/ui/settings.html. We should use that, as that is what everyone is supposed to use.

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

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.

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

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.

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.

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?

• 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 😉)

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.

Während Tests ist aufgefallen, dass Android beim Erkennen von nem Tag automatisch einige SELECT Befehle sendet. Passender Stackoverflow Eintrag: http://stackoverflow.com/questions/21121149/bytes-automatically-send-by-android-nfc-to-an-emulated-card
Die Lösung ist da auch schon gesagt: Wir müssen EnableReaderMode benutzen. Tun wir das?