1. NFC開發（一）——HCE基於主機的卡模擬簡述
許多提供NFC功能的基於android的設備已經支持NFC卡模擬。在大多數情況下，該卡由設備中的單獨晶元模擬，稱為 安全元件(Secure Element) 。無線運營商提供的許多SIM卡還包含安全元件(Secure Element)。
Android 4.4引入了另一種卡模擬方法，它不涉及SE，稱為 基於主機的租芹卡模擬 。這允許任何Android應用程序模擬卡並直接與NFC讀卡器通話。本文檔描述了基於主機的卡肢型裂模擬（HCE）如何在Android上工作，以及如何使用此技術開發模擬NFC卡的應用程序。
當使用安全元件(Secure Element)提供NFC卡模擬時，將通過Android應用程序將要模擬的卡提供到設備上的安全元件(Secure Element)中。然後，當用戶通過NFC終端握住設備時，設備中的NFC控制器將來自讀卡器(NFC Reader)的所有數據直接路由到安全元件(Secure Element)。圖1說明了這個概念。
安全元件(Secure Element)本身執行與NFC終端的通信，並且完全不涉及Android應用。交易完成後，Android應用程序可以直接查詢SE的交易狀態並通知用戶。
當使用基於主機的卡模擬來模擬NFC卡時，數據將被路由到直接運行Android應用程序的主機CPU，而不是將NFC協議幀路由到SE。圖2展示了基於主機的卡模擬如何工作。
NFC標准提供對許多不同協議的支持，並且可以模擬不同類型的卡。
Android 4.4支持當今市場上常見的幾種協議。許多現有的非接觸式卡已經基於這些協議，例如非接觸式支付卡。這些協議也得到了當今市場上眾多NFC讀卡器的支持，其中包括Android NFC設備可以自己作為讀卡器（請參見 IsoDep 課程）。這使您可以僅使用基於Android的設備在HCE周圍構建和部署端到端NFC解決方案。
具體而言，Android 4.4支持基於NFC-Forum ISO-DEP規范（基於ISO / IEC 14443-4）的模擬卡，並處理ISO / IEC 7816-4規范中定義的應用協議數據歷閉單元（APDU）。Android只強制在Nfc-A（ISO / IEC 14443-3 Type A）技術之上模擬ISO-DEP。支持Nfc-B（ISO / IEC 14443-4 Type B）技術是可選的。所有這些規格的分層如圖3所示。
Android中的HCE體系結構基於Android Service 組件（稱為「HCE服務」）。服務的一個關鍵優勢是它可以在沒有任何用戶界面的情況下在後台運行。這對於許多HCE應用程序來說非常合適，例如會員卡或公交卡，用戶不需要啟動應用程序即可使用它。相反，通過NFC讀卡器輕敲設備將啟動正確的服務（如果尚未運行）並在後台執行該事務。當然，如果有意義的話，您可以自由地從您的服務中啟動額外的UI（例如用戶通知）。
當用戶將設備連接到NFC讀取器時，Android系統需要知道NFC讀取器實際想要與哪個HCE服務通話。這就是ISO / IEC 7816-4規范的出處：它定義了一種選擇應用程序的方式，以應用程序ID（AID）為中心。一個AID最多由16個位元組組成。如果您正在模擬現有NFC讀卡器基礎架構的卡片，那麼這些讀卡器所尋找的AID通常是眾所周知的並且是公開注冊的（例如Visa和MasterCard等支付網路的AID）。
如果您想為自己的應用程序部署新的讀卡器基礎結構，則需要注冊您自己的AID。AID的注冊程序在ISO / IEC 7816-5規范中定義。如果您要為Android部署HCE應用程序，Google建議按照7816-5注冊AID，因為它可以避免與其他應用程序發生沖突。
在某些情況下，HCE服務可能需要注冊多個AID才能實現某個應用程序，並且需要確保它是所有這些AID的默認處理程序（而不是組中的某些AID轉到其他服務） 。
一個AID組是應該被OS視為一起歸屬的AID列表。對於AID組中的所有AID，Android會保證以下其中一項：
換句話說，沒有中間狀態，組中的一些AID可以路由到一個HCE服務，另一些AID可路由到另一個。
每個AID組都可以與一個類別關聯。這允許Android按類別將HCE服務組合在一起，並且反過來又允許用戶在類別的級別而不是AID級別設置默認值。通常，避免在應用程序的任何面向用戶的部分提及AID：它們對普通用戶沒有任何意義。
Android 4.4支持兩種類別: CATEGORY_PAYMENT （涵蓋行業標准支付應用程序）和 CATEGORY_OTHER （對於所有其他HCE應用程序）。
要使用基於主機的卡模擬來模擬NFC卡，您需要創建一個 Service 處理NFC事務的組件。
您的應用程序可以通過檢查 FEATURE_NFC_HOST_CARD_EMULATION 功能來檢查設備是否支持HCE 。您應該 <uses-feature> 在應用程序清單中使用該標記來聲明您的應用程序使用HCE功能，以及該應用程序是否需要運行。
Android 4.4帶有一個便利的 Service 類，可以作為實現HCE服務的基礎： HostApService 類。
因此，第一步要擴大 HostApService 。
HostApService 聲明了兩個需要重寫和實現的抽象方法。
processCommandAp() 只要NFC讀卡器將應用協議數據單元（APDU）發送到您的服務，就會調用它。APDU也在ISO / IEC 7816-4規范中定義。APDU是在NFC讀卡器和您的HCE服務之間交換的應用級數據包。該應用級協議是半雙工的：NFC讀卡器會向您發送命令APDU，並等待您發送響應APDU作為回報。
如前所述，Android使用AID來確定讀者想要與哪個HCE服務交談。通常，NFC讀卡器向您的設備發送的第一個APDU是「SELECT AID」APDU; 這個APDU包含讀卡器想與之交談的AID。Android從APDU中提取AID，將其解析為HCE服務，然後將該APDU轉發給已解析的服務。
您可以通過返回響應APDU的位元組來發送響應APDU [processCommandAp()]( https://developer.android.com/reference/android/nfc/cardemulation/HostApService.html#processCommandAp(byte[] , android.os.Bundle))。請注意，此方法將在應用程序的主線程中調用，該線程不應被阻止。所以如果你不能立即計算並返回一個響應APDU，那麼返回null。然後，您可以在另一個線程上完成必要的工作，並 sendResponseAp() 在完成後使用 HostApService 該類中定義的方法發送響應。
Android會繼續將新的APDU從讀取器轉發到您的服務，直到：
在這兩種情況下，你的類的 onDeactivated() 實現都是通過一個參數來調用的，這個參數指出了兩者中的哪一個發生了。
如果您正在使用現有的讀卡器基礎架構，則需要實現讀卡器在您的HCE服務中期望的現有應用程序級協議。
如果您正在部署您控制的新讀卡器基礎架構，則可以定義自己的協議和APDU序列。通常，嘗試限制APDU數量和需要交換的數據大小：這樣可以確保用戶只需將設備通過NFC讀取器持續一段時間即可。合理的上限約為1KB的數據，通常可以在 300ms 內交換。
您的服務必須像往常一樣在清單中聲明，但還必須在服務聲明中添加一些附加件。
首先，為了告訴平台它是一個實現 HostApService 介面的HCE服務 ，你的服務聲明必須包含一個 SERVICE_INTERFACE 動作的 Intent Filter 。
另外，為了告知平台哪個AIDs組被這個服務請求，一個 SERVICE_META_DATA <meta-data> 標簽必須包含在服務的聲明中，指向一個XML資源和關於HCE服務的附加信息。
最後，您必須將該 android:exported 屬性設置為true，並且 "android.permission.BIND_NFC_SERVICE" 在服務聲明中要求許可權。前者確保服務可以被外部應用程序綁定。後者然後強制只有擁有該 "android.permission.BIND_NFC_SERVICE" 許可權的外部應用程序 才能綁定到您的服務。既然 "android.permission.BIND_NFC_SERVICE" 是一個系統許可權，這有效地強制只有Android OS可以綁定到你的服務。
這是一個 HostApService 清單聲明的例子：
這個元數據標簽指向一個 apservice.xml 文件。下面顯示了具有包含兩個專有AID的單個AID組聲明的此類文件的示例：
該 <host-ap-service> 標簽需要包含一個 <android:description> 屬性，該屬性包含可能在UI中顯示的用戶友好的服務描述。該 requireDeviceUnlock 屬性可用於指定在調用此服務來處理APDU之前必須先解鎖設備。
在 <host-ap-service> 必須包含一個或多個 <aid-group> 標簽。每個 <aid-group> 標簽都需要：
最後，您的應用程序還需要擁有 NFC 可以注冊為HCE服務的 許可權。
多個 HostApService 組件可以安裝在單個設備上，並且可以由多個服務注冊相同的AID。Android平台根據AID屬於哪個類別來解決AID沖突。每個類別可能有不同的沖突解決策略。
例如，對於某些類別（如付款），用戶可能能夠在Android設置UI中選擇默認服務。對於其他類別，策略可能總是要求用戶在沖突情況下調用哪個服務。要查詢特定類別的沖突解決策略，請參閱 getSelectionModeForCategory() 。
應用程序可以使用[isDefaultServiceForCategory(ComponentName, String)]( https://developer.android.com/reference/android/nfc/cardemulation/CardEmulation.html#isDefaultServiceForCategory(android.content.ComponentName , java.lang.String))API 檢查其HCE服務是否是某個類別的默認服務。
如果您的服務不是默認設置，則可以請求將其設置為默認設置。看 ACTION_CHANGE_DEFAULT 。
Android會將AID組為「payment」的類別，聲明的HCE服務視為支付應用程序。Android 4.4版本包含一個名為「tap＆pay」的top-level設置菜單條目，它列舉了所有這些支付應用程序。在此設置菜單中，用戶可以選擇在點按付款終端時將調用的默認支付應用程序。
為了提供更具視覺吸引力的用戶體驗，HCE支付應用程序需要為其服務提供額外的resource：所謂的服務標記。
這個asset的大小應該是260x96 dp，並且可以在元數據(meta-data)XML文件中通過添加指向drawable resource android:apServiceBanner 的 <host-ap-service> 標簽的屬性來指定 。一個例子如下所示：
當設備的屏幕關閉時，當前的Android實施將NFC控制器和應用程序處理器完全關閉。因此，當屏幕關閉時，HCE服務將無法工作。
然而，HCE服務可以從鎖定屏幕中起作用：這由HCE服務標記中的 android:requireDeviceUnlock 屬性控制 <host-ap-service> 。默認情況下，不需要設備解鎖，即使設備被鎖定，您的服務也會被調用。
如果您將 android:requireDeviceUnlock HCE服務的屬性設置為「true」，Android會提示用戶在您靠近NFC讀卡器時解鎖設備，NFC讀卡器會選擇已解析為您的服務的AID。解鎖後，Android會顯示一個對話框，提示用戶再次點擊以完成交易。這是必要的，因為用戶可能已經將設備從NFC讀卡器移開以便解鎖它。
本部分對於已經部署依賴SE進行卡模擬的應用程序的開發人員很感興趣。Android的HCE實現旨在與其他實現卡模擬的方法並行工作，包括使用SE。
這種共存基於一種稱為「AID路由」的原則：NFC控制器保留一個由（有限）路由規則列表組成的路由表。每個路由規則都包含一個AID和一個目的地。目標可以是主機CPU（Android應用程序正在運行的地方），也可以是連接的SE。
當NFC讀卡器發送具有「SELECT AID」的APDU時，NFC控制器解析它並檢查AID是否與其路由表中的任何AID匹配。如果匹配，那麼APDU和其後的所有APDU將被發送到與AID相關聯的目的地，直到收到另一個「SELECT AID」 APDU或NFC鏈路斷開。
圖4說明了這種架構。
NFC控制器通常還包含APDU的默認路由。在路由表中找不到AID時，將使用默認路由。盡管此設置可能因設備而異，但Android設備需要確保您的應用注冊的AID已正確路由到主機。
實現HCE服務或使用SE的Android應用程序不必擔心配置路由表 - 這是由Android自動處理的。Android只需要知道哪些AID可以由HCE服務處理，哪些可以由SE處理。基於哪些服務已安裝，以及哪些用戶已配置為首選服務，路由表會自動配置。
我們已經介紹了如何聲明HCE服務的AID。以下部分說明如何為使用SE進行卡模擬的應用程序聲明AID。
使用SE進行卡模擬的應用程序可以在其清單中聲明所謂的「關閉主機服務」。這種服務的聲明幾乎與宣布HCE服務相同。以下情況例外：
相應 apservice.xml 文件注冊兩個AID 的示例：
該 android:requireDeviceUnlock 屬性不適用於脫離主機服務，因為主機CPU不參與事務，因此無法阻止SE在設備鎖定時執行事務。
該 android:apServiceBanner 屬性必須用於作為支付應用程序的關閉主機服務，以便作為默認支付應用程序進行選擇。
Android本身永遠不會啟動或綁定到聲明為「脫離主機」的服務。這是因為實際交易由SE執行，而不是由Android服務本身執行。服務聲明僅允許應用程序注冊安全元件(Secure Element)上存在的AID。
HCE體系結構本身提供了一個核心安全性：因為您的服務受到 BIND_NFC_SERVICE 系統許可權的保護，所以只有操作系統可以綁定到您的服務並與之通信。這可以確保您收到的任何APDU實際上都是OS從NFC控制器接收到的APDU，並且您發回的任何APDU只會發送到操作系統，而操作系統會直接將APDU轉發給NFC控制器。
剩下的核心部分就是您獲取應用程序發送給NFC讀卡器的數據的位置。這在HCE設計中有意解耦：它不關心數據來自何處，它只是確保將其安全地傳送到NFC控制器並傳送到NFC讀取器。
為了安全地存儲和檢索您希望從HCE服務發送的數據，例如，您可以依靠Android應用程序沙箱，將應用程序的數據與其他應用程序隔離。有關Android安全性的更多詳細信息，請閱讀 安全提示 。
這部分內容對於希望了解HCE設備在NFC協議的防沖突和激活階段使用何種協議參數的開發人員很感興趣。這允許構建與Android HCE設備兼容的讀卡器基礎結構。
作為Nfc-A協議激活的一部分，交換多個幀。
在交換的第一部分，HCE設備將呈現其UID; HCE設備應該被假定為具有隨機的UID。這意味著在每個抽頭中，呈現給讀卡器的UID將是隨機生成的UID。因此，NFC讀卡器不應依賴HCE設備的UID作為身份驗證或身份驗證的一種形式。
NFC讀取器可以隨後通過發送SEL_REQ命令來選擇HCE設備。HCE設備的SEL_RES響應將至少設置第6位（0x20），表示設備支持ISO-DEP。注意，SEL_RES中的其他位也可以被設置，表示例如對NFC-DEP（p2p）協議的支持。由於可以設置其他位，所以想要與HCE設備交互的讀者應該明確檢查第6位，並且<stront style="box-sizing: inherit;">不要將完整的SEL_RES與值0x20進行比較。</stront>
Nfc-A協議激活後，NFC讀取器啟動ISO-DEP協議激活。它發送一個「RATS」（請求選擇應答）命令。RATS響應（ATS）完全由NFC控制器生成，不能由HCE服務配置。然而，HCE實現需要滿足NFC論壇對ATS響應的要求，因此NFC讀卡器可以根據NFC論壇對任何HCE設備的要求設置這些參數。
以下部分提供了有關NFC控制器在HCE設備上提供的ATS響應的各個位元組的更多詳細信息：
請注意，許多HCE設備可能符合EMVCo聯合的支付網路在其「非接觸式通信協議」規范中指定的協議要求。尤其是：
如前所述，HCE實現僅支持單個邏輯通道。嘗試在不同的邏輯通道上選擇應用程序將不適用於HCE設備。
本文 翻譯自 谷歌開發者文檔，已由本人仔細校對。如有錯誤，請聯系我，以便修改。
2. 感應式讀卡器，復制你的門禁卡、購物卡、飯卡，你的卡還安全么
看了這個，你的飯卡還安全嗎？
僅供測試，請勿模仿。
//NFC是什麼，肯德基嗎，，，不。。。
近場通信（Near Field Communication，簡稱NFC），是一種新興的技術，使用了NFC技術的設備
（例如行動電話）可以在彼此靠近的情況下進行數據交換，是由非接觸式射頻識別（RFID）及 互連 互通技術整合演變而來的，通過在單一晶元上集成感應式讀卡器、感應式卡片和點對點通信的功能，利用移動終端實現移動支付、電子票務、門禁、移動身份識別、防偽等應用。由飛利浦公司和索尼公司共同開發的一種非接觸式識別和互聯技術，可以在移動設備、消費類電子產品、PC和智能控制項工具間進行近距離無線通信。NFC功能提供了一種簡單、觸控式的解決方案，可以讓消費者簡單直觀地交換信息、訪問內容與服務。
藉助CM9 rom的nfc讀寫標簽功能，實現軟體卡模擬。（之前的版本都沒有，google官方版本沒有開放此功能，目前從android 5.0起google開放了其他nfc api以進行卡模擬操作，）。
手機或手環等帶有NFC功能的設備通過模擬IC卡的操作，把像小區門禁卡、飯卡等IC卡的數據復制到手機的NFC晶元上面，以後就可以用手機的NFC功能進行刷卡。
可以截獲安卓手機支持的13.56hz nfc無線通訊協議的所有標簽數據，nfc非接觸黑盒測試一直沒有太好的方案，要麼太高端（需要專業的設備），要麼不好用（proxmark3也不便宜，監聽無線的方式導致截獲數據不穩定，也沒有現成兒的解決方案，操作的便捷性和交互性也好差）nfcproxy給我們這些偶爾用一用的測試狗提供了一種低成本高效率的解決方案，支持各種nfc標簽，iso 14443標准，ap數據也是完整穩定的，基於安卓app源碼的二次開發也非常簡單，會java的隨便改改基本都不是問題。基於這個 app可以以軟體方式衍生出多種測試方式
1、 卡和終端之間數據的嗅探
2、 交互過程中的數據修改
3、 模擬卡
最關鍵的還是簡單，買倆一百來塊錢一個的二手手機就可以了。
硬體需求：
兩個帶nfc功能的android手機（咸魚最便宜300塊錢以內可以搞定）一個帶非接觸功能的POS或者讀卡器（有個pos最省事，我有一個支持銀聯閃付的pos）自己的銀行卡，支持非接觸支付的，有銀聯quick pass標志的都可以
1、基於支持CM9 rom的安卓手機一個
我用的是谷歌親兒子一代 nexus s,ROM是slim 4.3 build 2-OFFICIAL-1332 一個基於cm的定製版本
android版本 4.3.1。我買得早，略貴，現在閑魚買二手的話沒有必要買這個，後面幾代也都便宜了，二兒子三兒子四兒子什麼的，都可以考慮，一加一也可以考慮，略貴。理論上支持CM9的都可以，但由於
CM官網已經黃了老版本的rom不好找，所以盡量要先找到手機對應的老版本的rom再決定買啥。 2、帶nfc功能的安卓手機一個（最好也支持cm9）
我用的是 三星 GALAXY S2的T版SGH-T989大力神，CM版本是11-20160815-NIGHTLY-hercules，
android版本4.4.4 ，cm11好像已經去掉軟體卡模擬的功能了，我也沒有去降rom版本，有一個能用行了。只要不是太奇葩的定製rom，理論上都可以。建議還是選擇支持cm的，比較保險。硬體選擇同上軟體需求：
有完整的功能實現，大家可以直接打包使用我基於自己用著方
便，整合了emv-bertlv庫，可以直接在app里把交互數據拆包。大家可以用著試試我的github地址：
本地app包下載：
使用方法
兩個手機都安裝nfcproxy都打開NFC功能連接到同一個wifi，兩個手機之間可以相互訪問
1、 proxy端設置
在支持cm9卡模擬的手機（我得是nexus s），打開nfcproxy軟體，點設置，取消 relay mode 單選框IP 地址填另一個手機的wifi ip埠 填另一個手機的nfcproxy監聽埠，默認9999encrypt
communications 不需要選，自己玩不用加密always keep screen on 隨便debug logging 勾上，可以顯示出卡號。然後退出設置。
2、 relay端的設置
在另外一個手機（我得是t989），打開nfcproxy軟體，點設置，勾選 relay mode 單選框IP 地址 不用填
埠 填剛剛在另一個手機設置的nfcproxy監聽埠，默認9999，兩邊一樣就行encrypt
communications 不需要選，自己玩不用加密always keep screen on 隨便debug logging 勾上，可以顯示出卡號。然後退出設置。
3、 測試
1、 將用於relay端的手機，nfcproxy軟體打開貼到銀行卡上，這時status窗口應該提示
TechList:android.nfc.tech.IsoDepandroid.nfc.tech.NfcA，如果沒反應請檢查nfc是否打開，手機
NFC功能是否正常
2、 將POS機弄到選擇消費，輸入金額後，提示請刷卡的界面
3、 將用於proxy端的手機，nfcproxy軟體打開，去貼到POS機上執行非接刷卡動作。
正常情況貼上去後nfcproxy的data窗口會提示：Reader
TAG:Tech[android.nfc.tech.Iso.PcdA]Connecting to NFCRelayConnected to NFCRelayTransaction
Complete!這說明已經已經連上了貼卡那台手機，POS機的請求已經轉發到卡上了，並且卡的應答已經轉發回來了，交易成了。這時候POS應該顯示請輸入密碼了，輸入密碼交易成功。再看replay端的 nfcproxy的data窗口，就可以看到交互的數據了在數據上長按可以選擇最右面的三個豎點，export to file將截取的數據保存到內部存儲的/NfcProxy目錄中
注1：如果帖POS的手機沒反應，需要檢查nfc功能是否正常
注2：status 提示 connection to NFCRelay failed 需要檢查兩台手機wifi是否聯通，配置的ip和埠是否正常
祝好運。
btw： 這個方案15年我就在用，只是工作測試pos需要，偶爾用到感覺很方便，最近又用了一次，下決心整理一下。之前都看大神的文章，自己也為社區貢獻一次。軟體本身還有很大潛力可以挖，比如動態修改交互數據什麼的。。。。。。 你們懂的，不要亂來哦，會查水表的。 另外也發現有一些終端讀卡會採用一些奇怪的模式，導致軟體報錯，這時候只能再用proxmark3暴力監聽了，但這個mitm的方式比 proxmark方便多了，也便宜的多了哈。最後附一張ppt里的圖，我簡單畫了一下，方便大家理解
在復制IC卡這一塊，我把IC卡分為加密卡和非加密卡兩類，非加密卡請直接嘗試復制，不行的話參照加密卡的教程。
工具：
1.硬體：PN532(初學者建議購買這個，某寶賣30RMB左右，一般的半加密卡用這個就能破解了，全加密卡需要用到PM3)，USB轉ttl線，小米手環NFC版（3代4代隨意），cuid卡
2.軟體：PN532的驅動（自己問賣家要，找對應的驅動，或看看我鏈接里的驅動適不適合）、winhex、
MifareOneTool（簡稱M1T）、NFC_READER_crack。
首先把USB轉ttl線與PN532連接好（線序定義：黑GND, 紅VCC,白SDA,綠SCL）。然後在電腦安裝好
PN532的驅動，PN532連接到電腦，然後查看設備管理器，COM口那有設備證明已經成功安裝好驅動了。
打開M1T軟體，點擊檢測連接然後一鍵解原卡，有密鑰的會嘗試破解，破解成功後會導出一個.mp文件，我們把它保存。
用winhex打開該.mp文件，把AB密鑰用FF填充，填充好了之後我們另存為一份，順便把開頭的卡號記下來（8位）
之後我們再次打開M1t，選擇高級操作模式，打開Hex編輯器，把剛剛找的八位卡號復制下來，再打開工具，修改UID，把剛才復制的八位卡號粘貼到裡面，點確定，然後點文件-另存為一個.mfd文件。
高級模式里選擇cuid寫，把剛剛的.mfd文件寫入cuid卡裡面，如果沒寫滿64個塊就再寫一次。
小米手環選擇門卡模擬，把剛剛寫入了.mfd文件的cuid卡模擬到小米手環上，之後打開
NFC_READER_crack這個軟體，選擇寫普通M1卡，把填充好密鑰的飯卡數據寫入手環中。如果只寫入63個塊，那也沒關系，去試試能不能用。
然後就大功告成啦！！
本教程切勿用於非法用途，復制飯卡余額都是一樣的，不存在修改余額這一說。飯卡原本余額是多少的，你用什麼來打飯余額都是一樣。復制到手環里只是為了方便打飯。
Q：為什麼到了最後把數據寫入手環時不用原來的M1T而是用NFC_READER_crack呢？
A：因為用M1T寫入數據到手環會出現玄♂學問題，就是寫不到63個塊，用NFC_READER_crack就沒有問題。如果是用cuid卡來復制門禁卡的話可以嘗試用M1T。
Q：那如何復制門禁卡？
A：門禁卡如果是半加密卡的話可以參照本文來復制，如果是非加密卡的話試試直接模擬可不可以，如果不行的話按照讀出數據（保存）–生成一個帶有卡號的.mfd文件–復制到cuid卡–手環模擬該cuid卡–手環寫入門禁卡數據這一步驟來復制。
生活中不乏其他案例，黑客破解NFC公交卡，可無限次乘車，甚至可以劫持帶有NFC功能的手機，所以安全問題顯而易見，畢竟防人之心不可無。