Note

I do NOT understand NCMC/EMV fully. Please don’t keep your hopes high while asking questions. A local LLM was used to rephrase this content. Certain sections were fully written via LLM becuase I’m 🤏 this close to losing my mind. There’s a lot acronymns and a lot of new concepts. I had a LLM write me a lookup table which I’ve added at the end of this blog.

Disclaimer

• This post is for educational purposes only. Nothing here is an invitation to tamper with payment systems you don’t own. Card payment networks are monitored infrastructure, and messing with other people’s cards or accounts is a crime. Don’t.
• Everything here was done on my own cards, my own accounts, or cards friends handed me with permission. I never read, replayed, or modified anyone else’s card, and I never touched anyone else’s funds.
• I am not affiliated with, endorsed by, or speaking for NPCI, RuPay, EMVCo, Airtel, PineLabs/BharatYatra, ISG, Uvik, DMRC, KMRL, Axis Bank, or any issuer/acquirer mentioned. All names and trademarks belong to their respective owners.
• This is reverse engineering, not official documentation. My reading of decompiled code and captures may be incomplete or flat-out wrong. Cross-check anything important against the sources in the footnotes.
• If you represent any of the companies above and believe something here shouldn’t be public, reach out and I’ll consider taking it down.

Note

Just here for the app? Go here - https://tangled.org/nkmason.dev/OpenNCMC.

via GIPHY

I’ve always found NCMC interesting. The name is an abbreviation of National Common Mobility Card, and it belongs to the RuPay family¹. It was initially called RuPay qSPARC, but this name has been seeing less daylight on NPCI’s website, which is a damn shame because qSPARC is a hot name.

What is NCMC? #

My understanding is that NCMC is a specification built on top of the EMV protocol. NCMC vendors are supposed to use the RuPay EMV Kernel to enable RuPay transactions via tap and pay. An offline wallet exists to enable quick transit gate transactions. RuPay is a smartcard, both contact and contactless. This brings in the need for KYC. KYC threw me off at the start of the NCMC era because I don’t wish to give away my personal data for another transit card when my older (non-KYC) card just works fine. But recently, Bengaluru’s BMRCL started accepting PineLabs’ BharatYatra cards. The card itself is widely available on quick ecommerce platforms for INR 50. These cards are promised to be non-KYC –

but they are NOT. I say this because the app still requires you to make an account with your personal phone number, and your card will then be linked to that number. If NCMC is a spec, then basic stuff like reading card vendor information, balance, expiry, etc should be available for free and not behind a phone number wall.

Reconnaissance #

I made an account to take a look around the app and also ordered myself a few fresh BharatYatra cards. A friend of mine donated DMRC’s Airtel NCMC card and another friend let me use their KMRL Axis Bank Kochi One card. The goal is to take any card and its sister app and try to read the balance. Ideally, the solution should work across all these cards.

The BharatYatra app shows your card balance at all times. It’s fair to assume they have a server to keep record of and track the offline wallet balance. The balance read process goes like:

1. You click on check balance.
2. The app asks you to tap the card on the back of your phone (Android only).
3. It takes a couple of seconds and then shows the balance.

The update process is a bit more involved:

1. You add balance in the app.
2. The homescreen starts showing a pending balance underneath the balance it thinks your card has.
3. You click on update balance.
4. The app asks you to tap the card on the back of the phone.
5. It reads something, then asks you to tap the card again after a while.
6. When you tap the card at the second stage, the phone writes the balance to the card.

We can think of some experiments right away. What if we start the recharge process and let it go through the first stage? Before starting stage 2, we fulfill the same recharge on a second phone (both stages), then continue with stage 2 on the first phone. Double money glitch? I haven’t tried it yet at the time of writing, but I plan to in the future.

NCMC Apps #

DMRC has an Airtel NCMC card, and the Airtel Thanks app handles everything related to it. I took apart the Airtel and BharatYatra Android apps and saw a common pattern: the app itself delegates the actual NCMC business to a third party library. BharatYatra delegates to Uvik’s (related to CCAvenue) TapPay SDK, and Airtel hands it over to ISG’s TapToPay SDK. It’s very hard to Frida hook into either of the apps due to rigorous checks². I gave a short talk about it at KochiFOSS (embedded below). Fair warning: it’s unpolished and I apologize for the quality.

After wasting a while, I decided to just look at what the spec actually looks like: MITM the NFC connection when the balance is being read and also when it’s being updated. Initially, I used a Proxmark3³ to do the trace ⁴ and later moved to a two-phone relay setup using NFC Gate⁵ and my server⁶. It’s the same setup as my previous DMRC blog⁷. The relay gave me stable readings, but the readings don’t make sense yet because I don’t know the spec.

Leak? #

Looking for the specification, I found two useful documents. One is a public document by CDAC⁸, the other is a confidential NPCI document leaked twice on Scribd⁹. This confirmed the ecosystem is built on EMV. I also found that atleast one of the SDK implementor had Payhuddle write the kernel¹⁰. The leaked terminal spec is a good source of information but is quite old (look at page 16). The EMV base protocol is defined by EMVCo’s contactless kernel specifications¹¹. The goal: reverse the NCMC app, figure out where the spec is implemented, build my own implementation, and compare it against the leak. Most of the RE’d spec should match.

Finding the implemented specification #

I managed to bypass security restrictions for both apps and the extra checks made by UVik and ISG. UVik has really hardened their app and makes it nearly impossible to test continuously. ISG, on the other hand, is only lightly hardened. The Airtel app doesn’t download the NFC split until the server confirms the user is an NCMC holder¹². I had to force the download by bypassing the checks (which include Talsec²) and calling the download function via Frida¹³ (script attached below).

Before any transaction, the app verifies the device is genuine using Android’s Key Attestation. It generates an EC key pair in the hardware keystore, requests an attestation certificate, and verifies the certificate chain against Google’s root CAs and a revocation list. If the device is rooted, debuggable, or has developer mode on, the transaction is blocked.

1// DeviceSecurityManager.a(Context) — the entry point
2boolean rooted = RootHookDetector.c(context);
3boolean debuggable = DebugFlagChecker.b(context);
4boolean devMode = DeviceFeatureChecks.d(context) || DeviceFeatureChecks.c(context);
5if (!rooted && !debuggable && !devMode) {
6    return true;  // clean device
7}
8SecurePrefsStore.a(context).h();  // wipe session
9return false;

The SDK checks for Frida, Xposed and Substrate framework artifacts in /proc/self/maps, scans installed packages for known root/hook apps, and checks the stack trace for hooking framework class names. TLS connections use a BKS keystore (which is long expired :pepelaugh:) containing the server’s certificate. The keystore password is hardcoded in the APK. All session data, keys, and transaction state are stored in EncryptedSharedPreferences (Android Jetpack Security) with AES-256-GCM, backed by a hardware-backed master key.

  1/*
  2 * Frida script to bypass Airtel Thanks app security checks.
  3 * Usage: frida -U -f com.myairtelapp -l bypass_security.js
  4 */
  5
  6// NATIVE HOOKS
  7(function setupNativeHooks() {
  8    function findExport(name) {
  9        try { var p = Module.findGlobalExportByName(name); if (p) return p; } catch (_) {}
 10        try { var p = Module.findExportByName(null, name); if (p) return p; } catch (_) {}
 11        try { var mod = Process.findModuleByName("libc.so"); if (mod) { var p = mod.findExportByName(name); if (p) return p; } } catch (_) {}
 12        try { var mod = Process.findModuleByName("libc.so"); if (mod) { var e = mod.enumerateExports(); for (var i=0;i<e.length;i++) if (e[i].name===name) return e[i].address; } } catch (_) {}
 13        try { var p = DebugSymbol.findFunctionNamed(name); if (p) return p; } catch (_) {}
 14        return null;
 15    }
 16
 17    function blockNative(name, ret, sig, args) {
 18        var p = findExport(name);
 19        if (!p) { console.log("[-] " + name + " not found"); return; }
 20        try {
 21            Interceptor.replace(p, new NativeCallback(function () {
 22                console.log("[+] BLOCKED " + name + "()");
 23                return ret;
 24            }, sig, args));
 25            console.log("[+] Replaced " + name + " @ " + p);
 26        } catch (e) { console.log("[-] " + name + ": " + e.message); }
 27    }
 28
 29    blockNative("exit",       undefined, 'void', ['int']);
 30    blockNative("_exit",      undefined, 'void', ['int']);
 31    blockNative("abort",      undefined, 'void', []);
 32    blockNative("raise",      0,         'int',  ['int']);
 33    blockNative("kill",       0,         'int',  ['int', 'int']);
 34    blockNative("tgkill",     0,         'int',  ['int', 'int', 'int']);
 35
 36    // Hook syscall to redirect exit/exit_group to getpid
 37    var syscallPtr = findExport("syscall");
 38    if (syscallPtr) {
 39        Interceptor.attach(syscallPtr, {
 40            onEnter: function (args) {
 41                var num = args[0].toInt32();
 42                if (num === 93 || num === 94 || num === 60 || num === 231) {
 43                    console.log("[+] BLOCKED syscall(" + num + ")");
 44                    args[0] = ptr(172); // getpid on arm64
 45                }
 46            }
 47        });
 48        console.log("[+] Hooked syscall");
 49    }
 50
 51    console.log("[*] Native hooks done");
 52})();
 53
 54// JAVA HOOKS
 55Java.perform(function () {
 56    console.log("[*] Airtel security bypass loaded");
 57
 58    // 1. Block security alert trigger
 59    try { Java.use("com.myairtelapp.q").g.overload("com.myairtelapp.k").implementation = function (t) { console.log("[+] Blocked: " + t); }; console.log("[+] q.g()"); } catch (e) {}
 60
 61    // 2. Auto-finish SecurityCheckActivity
 62    try { Java.use("com.myairtelapp.activity.SecurityCheckActivity").onCreate.implementation = function (b) { this.onCreate(b); this.finish(); }; console.log("[+] SecurityCheckActivity"); } catch (e) {}
 63
 64    // 3. Talsec → all false
 65    try {
 66        var h6c = Java.use("h6.c");
 67        ["A","v"].forEach(function(m){ try{h6c[m].implementation=function(){return false;};}catch(_){}});
 68        ["D","w","u","x","I","E","B","z","h"].forEach(function(m){ try{h6c[m].overloads.forEach(function(ov){ov.implementation=function(){return false;};});}catch(_){}});
 69        h6c.F.implementation = function(){ return Java.use("com.airtel.money.dto.TalsecCheckDto").$new(false,"",""); };
 70        h6c.t.overload('android.content.Context').implementation = function(c){return false;};
 71        h6c.G.overload('android.content.Context').implementation = function(c){return false;};
 72        h6c.d.overload('java.lang.String').implementation = function(s){ console.log("[+] Talsec: "+s); };
 73        console.log("[+] h6.c Talsec");
 74    } catch (e) { console.log("[-] h6.c: " + e); }
 75
 76    // 4. RNUtilsAPB
 77    try {
 78        var rn = Java.use("com.reactnative.bridge.RNUtilsAPB");
 79        rn.checkAnyRestrictedAppPresentOnDevice.implementation = function(cb){ cb.invoke(Java.use("java.lang.Boolean").FALSE); };
 80        rn.isNeedToShowBankRootedError.implementation = function(cb){ cb.invoke(Java.use("java.lang.Boolean").FALSE); };
 81        console.log("[+] RNUtilsAPB");
 82    } catch (e) {}
 83
 84    // 5. Block startActivity to SecurityCheckActivity
 85    try { Java.use("android.app.Activity").startActivity.overload('android.content.Intent').implementation = function(i){ var c=i.getComponent(); if(c!==null&&c.getClassName().indexOf("SecurityCheckActivity")!==-1){console.log("[+] Blocked startActivity");return;} this.startActivity(i); }; console.log("[+] startActivity"); } catch (e) {}
 86
 87    // 6. Block ALL Java process termination
 88    try { Java.use("java.lang.System").exit.implementation = function(c){ console.log("[+] BLOCKED System.exit("+c+")"); }; } catch(e){}
 89    try { Java.use("java.lang.Runtime").exit.implementation = function(c){ console.log("[+] BLOCKED Runtime.exit("+c+")"); }; } catch(e){}
 90    try { Java.use("java.lang.Runtime").halt.implementation = function(c){ console.log("[+] BLOCKED Runtime.halt("+c+")"); }; } catch(e){}
 91    try { var P=Java.use("android.os.Process"); P.killProcess.implementation = function(pid){ if(pid===P.myPid()||pid===0){console.log("[+] BLOCKED killProcess("+pid+")");return;} this.killProcess(pid); }; } catch(e){}
 92    try { Java.use("java.lang.Shutdown").exit.implementation = function(c){ console.log("[+] BLOCKED Shutdown.exit("+c+")"); }; } catch(e){}
 93    try { Java.use("dalvik.system.VMRuntime").exit.overload('int').implementation = function(c){ console.log("[+] BLOCKED VMRuntime.exit("+c+")"); }; } catch(e){}
 94    console.log("[+] Java kill hooks");
 95
 96    // 7. Block finishAffinity & finishAndRemoveTask
 97    try { Java.use("android.app.Activity").finishAffinity.implementation = function(){ if(this.getClass().getName().indexOf("SecurityCheck")!==-1){console.log("[+] BLOCKED finishAffinity");return false;} return this.finishAffinity(); }; } catch(e){}
 98    try { Java.use("android.app.ActivityManager$AppTask").finishAndRemoveTask.implementation = function(){ console.log("[+] BLOCKED finishAndRemoveTask"); }; } catch(e){}
 99    console.log("[+] finish hooks");
100
101    // 8. Find and neutralize the crashing native address
102    // The access violation at 0x9d973400 is from Talsec's native lib
103    // Let's identify which module it belongs to
104    setTimeout(function () {
105        try {
106            var addr = ptr("0x9d973400");
107            var mod = Process.findModuleByAddress(addr);
108            if (mod) {
109                console.log("[*] Crash address 0x9d973400 is in: " + mod.name + " @ " + mod.base);
110                // Try to NOP the first few instructions at that address
111                // This is dangerous but might stop the crash loop
112                // Memory.protect(addr, 4096, 'rwx');
113            } else {
114                console.log("[*] Crash address 0x9d973400 not in any loaded module");
115            }
116        } catch (e) {
117            console.log("[-] Module lookup: " + e);
118        }
119
120        // List all loaded native modules that might be Talsec
121        console.log("[*] Searching for Talsec native libs...");
122        Process.enumerateModules().forEach(function(m) {
123            var n = m.name.toLowerCase();
124            if (n.indexOf("talsec") !== -1 || n.indexOf("ahead") !== -1 || n.indexOf("security") !== -1 || n.indexOf("root") !== -1) {
125                console.log("  FOUND: " + m.name + " @ " + m.base + " (" + m.size + " bytes) " + m.path);
126            }
127        });
128    }, 2000);
129
130    console.log("[*] All hooks installed");
131});
132
133// RPC HELPERS
134rpc.exports = {
135    checknfc: function () {
136        return new Promise(function (resolve) { Java.perform(function () {
137            try {
138                var C = Java.use("com.myairtelapp.utils.C1308y1");
139                console.log("[*] pref: " + C.u("nfcModuleInstalled"));
140                var ctx = Java.use("com.myairtelapp.global.App").f21591s.value;
141                var sm = Java.use("io.sentry.config.a").m(ctx);
142                var list = []; var it = sm.c().iterator();
143                while (it.hasNext()) list.push(it.next());
144                console.log("[*] Splits: " + list.join(", "));
145                try { Java.use("com.apb.nfc.NFCImpProvider"); console.log("[*] NFCImpProvider: LOADED"); } catch(_) { console.log("[*] NFCImpProvider: NOT FOUND"); }
146                resolve(list);
147            } catch (e) { console.log("[-] " + e); resolve([]); }
148        });});
149    },
150    downloadnfc: function () {
151        return new Promise(function (resolve) { Java.perform(function () {
152            try {
153                var cb = Java.registerClass({ name:"com.frida.dl1", implements:[Java.use("com.facebook.react.bridge.Callback")], methods:{ invoke:function(){ console.log("[NFC] "+Array.prototype.slice.call(arguments).join(" | ")); } } }).$new();
154                Java.use("O5.b").s(cb);
155                console.log("[*] downloadNFC triggered");
156                resolve("ok");
157            } catch (e) { console.log("[-] "+e+"\n"+e.stack); resolve("err"); }
158        });});
159    },
160    downloadnfcg0: function () {
161        return new Promise(function (resolve) { Java.perform(function () {
162            try {
163                var dm = Java.use("com.myairtelapp.utils.M0").f23696a.value;
164                var cfg = Java.use("jm.c").$new("nfc","NFC","Downloading...","nfcModuleInstalled");
165                var J0=Java.use("com.myairtelapp.utils.J0"), L0=Java.use("com.myairtelapp.utils.L0");
166                var ok=Java.registerClass({name:"com.frida.ok1",implements:[J0],methods:{t:function(){console.log("[NFC] SUCCESS");}}}).$new();
167                var er=Java.registerClass({name:"com.frida.er1",implements:[L0],methods:{t:function(){console.log("[NFC] ERROR");}}}).$new();
168                dm.g(cfg,ok,er);
169                console.log("[*] downloadNFCg0 triggered");
170                resolve("ok");
171            } catch (e) { console.log("[-] "+e+"\n"+e.stack); resolve("err"); }
172        });});
173    },
174    listsplits: function () {
175        return new Promise(function (resolve) { Java.perform(function () {
176            try { var ctx=Java.use("com.myairtelapp.global.App").f21591s.value; var sm=Java.use("io.sentry.config.a").m(ctx); var l=[]; var it=sm.c().iterator(); while(it.hasNext())l.push(it.next()); console.log("[*] "+l.join(", ")); resolve(l); }
177            catch(e){ console.log("[-] "+e); resolve([]); }
178        });});
179    },
180    inspectnfc: function () {
181        return new Promise(function (resolve) { Java.perform(function () {
182            try { var c=Java.use("com.apb.nfc.NFCImpProvider"); console.log("[*] LOADED: "+c); var m=c.class.getDeclaredMethods(); for(var i=0;i<m.length;i++) console.log("  "+m[i]); resolve("loaded"); }
183            catch(e){ console.log("[*] not loaded: "+e); resolve("no"); }
184        });});
185    },
186    // Find the native lib causing crashes and list its exports
187    findtalsec: function () {
188        return new Promise(function (resolve) {
189            console.log("[*] All loaded modules:");
190            Process.enumerateModules().forEach(function(m) {
191                console.log("  " + m.name + " @ " + m.base + " (" + m.size + ")");
192            });
193            resolve("done");
194        });
195    }
196};

Upon getting the NFC split, I loaded it into JADX¹⁴ and started looking for where the spec lives. I found the kernel (possibly the Payhuddle one mentioned above) information:

 1package com.isg.kernel.rupay.objects;
 2
 3import com.isg.taptopay.StringBuilderHelper;
 4
 5/* JADX INFO: loaded from: classes.dex */
 6public final class RupayKernelInformation {
 7    public static RupayKernelInformation d;
 8    public String a = "3.0.0.0";
 9    public String b = "Release";
10    public String c = "Built-in NFC Controller";
11
12    public static final RupayKernelInformation getInstance() {
13        if (d == null) {
14            d = new RupayKernelInformation();
15        }
16        return d;
17    }
18
19    public final String toString() {
20        StringBuilder sb = new StringBuilder("Genius-ISG Rupay Contactless Kernel \n");
21        StringBuilder sbA = StringBuilderHelper.a("Version:");
22        sbA.append(this.a);
23        sbA.append(" \n");
24        sb.append(sbA.toString());
25        sb.append("Build:" + this.b + " \n");
26        sb.append("Active Card Communication Channel: " + this.c + "\n");
27        return sb.toString();
28    }
29}

If the version string follows the NCMC specification version, it confirms that this implementation does not follow the leaked document.

com.isg.taptopay defines TapToPayConfig, the top-level config for this SDK, which also populates the EMV kernel config. The configuration lives in the assets folder as KernelConfig.json:

 1{
 2  "contactlessLimit": "5000",
 3  "schemes": [
 4    {
 5      "name": "RUPAY",
 6      "assets": "rupayjson/",
 7      "transactionType": ["PURCHASE","MONEY_ADD","BALANCE_UPDATE","BALANCE_ENQUIRY","DIRECT_SELECTION"]
 8    }
 9  ]
10}

Straightforward: contactlessLimit is INR 5000 and schemes[0].transactionType tells the SDK what operations it supports. The assets folder also tells me the supported Application IDs (AIDs) for the EMV card in a file called (you won’t believe it) SupportedAid.json. Next, I looked for the transceive function that implements something related to IsoDep and worked backwards from there. All SDK config is managed by com.isg.taptopay.q7, which handles logging, resource providing, the communication interface, response listener, and more. It’s essentially a dataclass:

 1package com.isg.taptopay;
 2
 3import com.isg.kernel.rupay.doubletap.file.FileWriter;
 4import com.isg.kernel.rupay.exception.KernelConfigurationException;
 5import com.isg.kernel.rupay.listeners.RCardCommunicationInterface;
 6import com.isg.kernel.rupay.listeners.RupayKernelConfigurationInterface;
 7import com.isg.kernel.rupay.listeners.RupayKernelLogger;
 8import com.isg.kernel.rupay.listeners.RupayReaderResponseListener;
 9import com.isg.kernel.rupay.listeners.RupayResourceProvider;
10import com.isg.kernel.rupay.listeners.RupayTransactionInterface;
11import com.isg.kernel.rupay.listeners.TerminalStatusProvider;
12import com.isg.kernel.rupay.model.enums.TerminalStatus;
13import java.util.HashMap;
14import java.util.List;
15
16/* JADX INFO: renamed from: com.isg.taptopay.q7 */
17/* JADX INFO: loaded from: classes.dex */
18public final class RupayKernelConfig implements RupayKernelConfigurationInterface {
19    public static RupayKernelConfig i;
20    public RupayKernelLogger a;
21    public RupayResourceProvider b;
22    public RCardCommunicationInterface c;
23    public RupayReaderResponseListener d;
24    public FileWriter e;
25    public TerminalStatusProvider f;
26    public RupayResourceLoader g;
27    public RupayTerminalData h;
28
29    @Override // com.isg.kernel.rupay.listeners.RupayKernelConfigurationInterface
30    public final RupayTransactionInterface initialiseConfiguration() throws KernelConfigurationException {
31        this.h = new RupayTerminalData();
32        if (this.c == null) {
33            throw new KernelConfigurationException("ConfigurationException : Implement CardCommunicationInterface");
34        }
35        if (this.d == null) {
36            throw new KernelConfigurationException("ConfigurationException : Implement ReaderResponseListener");
37        }
38        RupayResourceProvider rupayResourceProvider = this.b;
39        if (rupayResourceProvider == null) {
40            throw new KernelConfigurationException("ConfigurationException : Implement RupayResourceProvider");
41        }
42        try {
43            this.g = new RupayResourceLoader(rupayResourceProvider);
44            if (this.e == null) {
45                throw new KernelConfigurationException("ConfigurationException : Implement FileWriter");
46            }
47            a(TerminalStatus.IDLE);
48            return new RupayTransactionProcessor();
49        } catch (Exception unused) {
50            throw new KernelConfigurationException("ConfigurationException : Invalid RupayResourceProvider");
51        }
52    }
53}

Following the RCardCommunicationInterface variable, we find the IsoDep transceiver in class com.isg.taptopay.d6:

 1package com.isg.taptopay;
 2
 3import com.isg.kernel.rupay.exception.CommunicationException;
 4import com.isg.kernel.rupay.listeners.RCardCommunicationInterface;
 5import com.isg.kernel.rupay.utils.BytesUtils;
 6
 7/* JADX INFO: renamed from: com.isg.taptopay.d6 */
 8/* JADX INFO: loaded from: classes.dex */
 9public final class CardChannel implements ICardChannel {
10    public static KernelLoggerWrapper b = new KernelLoggerWrapper(CardChannel.class.getName());
11    public RCardCommunicationInterface a = RupayKernelConfig.c().a();
12
13    public final byte[] a(byte[] bArr) throws CommunicationException {
14        byte[] bArrTransceive = this.a.transceive(bArr);
15        b.e(BytesUtils.bytesToString(bArrTransceive).replace(" ", ""));
16        return bArrTransceive;
17    }
18}

We can backtrack further to find where APDU command building and mapping happens. This snippet shows the builder:

 1// ...
 2public ApduCommand(int i2, int i3, int i4) {
 3    this.a = 0;
 4    this.b = 0;
 5    this.c = 0;
 6    this.d = 0;
 7    this.e = 0;
 8    this.f = new byte[0];
 9    this.g = 0;
10    this.h = true;
11    StringBuilder sb = new StringBuilder();
12    StringBuilder sbA = StringBuilderHelper.a("\n CLA: ");
13    sbA.append(BytesUtils.prettyPrintHex(BytesUtils.intToHex(ApduBytes.a(2))));
14    sb.append(sbA.toString());
15    sb.append("\n INS: " + BytesUtils.prettyPrintHex(BytesUtils.intToHex(ApduBytes.b(2))));
16    sb.append("\n P1: " + BytesUtils.prettyPrintHex(BytesUtils.intToHex(i2)));
17    sb.append("\n P2: " + BytesUtils.prettyPrintHex(BytesUtils.intToHex(i3)));
18    sb.append("\n Le: " + BytesUtils.prettyPrintHex(BytesUtils.intToHex(i4)));
19    i.d(sb.toString());
20    this.a = ApduBytes.a(2);
21    this.b = ApduBytes.b(2);
22    this.c = i2;
23    this.d = i3;
24    this.g = i4;
25    this.h = true;
26}
27// ...

The logger output helps decode the variables:

And, now the builder class makes much more sense:

 1// ...
 2public final byte[] build() {
 3    byte[] bArr = this.data;
 4    int length = 4;
 5    int length2 = (bArr == null || bArr.length == 0) ? 4 : bArr.length + 5;
 6    if (this.includeLe) {
 7        length2++;
 8    }
 9    byte[] bArr2 = new byte[length2];
10    bArr2[0] = (byte) this.cla;
11    bArr2[1] = (byte) this.ins;
12    bArr2[2] = (byte) this.p1;
13    bArr2[3] = (byte) this.p2;
14    if (bArr != null && bArr.length != 0) {
15        bArr2[4] = (byte) this.lc;
16        System.arraycopy(bArr, 0, bArr2, 5, bArr.length);
17        length = this.data.length + 5;
18    }
19    if (this.includeLe) {
20        bArr2[length] = (byte) (bArr2[length] + ((byte) this.le));
21    }
22    return bArr2;
23}
24//...

In the second-to-last snippet, those calls to ApduBytes (original name q5) are the command mapper, an if-else chain. Comparing against the sniffed trace, we can map the following:

Now we can form our own APDU to select an AID:

CLA  INS  P1  P2  Lc  Data (AID)              Le
00   A4   04  00  Lc  <AID bytes (5-16)>      00

We know the AID from the JSON file found earlier. Final APDU:

CLA  INS  P1  P2  Lc  Data (AID)            Le
00   A4   04  00  07  A0 00 00 05 24 10 10  00

This AID also appears in the SELECT PPSE response (00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00, which selects the PPSE 2PAY.SYS.DDF01 to discover payment apps):

[CMD] SELECT PPSE: 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
[RSP] SELECT PPSE: 6F 32 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 20 BF 0C 1D 61 1B 4F 07 << A0 00 00 05 24 10 10 >> 50 0D 52 75 50 61 79 20 50 72 65 50 61 69 64 87 01 01 90 00
[CMD] SELECT AID: 00 A4 04 00 07 A0 00 00 05 24 10 10 00
[RSP] SELECT AID: 6F 76 84 07 A0 00 00 05 24 10 10 A5 6B 50 0D 52 75 50 61 79 20 50 72 65 50 61 69 64 87 01 01 9F 38 1D 9F 40 05 DF 3A 05 9F 33 03 9F 09 02 9F 15 02 9A 03 9F 21 03 9F 37 04 DF 16 02 9F 1C 08 5F 2D 02 65 6E 9F 11 01 01 9F 12 0D 52 75 50 61 79 20 50 72 65 50 61 69 64 BF 0C 1D 9F 4D 02 10 0A DF 07 15 01 00 00 81 81 94 25 05 67 28 88 01 14 01 0F 01 0F FF 01 AC 00 90 00

Understanding the Card’s Memory #

With the SELECT and GPO responses decoded, we can now map the card’s internal file system. This matters because the balance is stored in a specific record, and you need to know which record to read.

EMV smart card memory is organized like a standard filesystem. Instead of folders and files, an EMV card uses Dedicated Files (DFs, like folders) and Elementary Files (EFs, like files containing actual records). Each record is identified by a Short File Identifier (SFI), a 5-bit number (1-30) that goes into P2 as (SFI << 3) | 4 during READ RECORD commands, while P1 carries the record number. Data is packaged using BER-TLV (Basic Encoding Rules: Tag-Length-Value) to transmit complex structures efficiently over the lightweight contactless channel. The internal storage follows a strict tree structure.

For high-speed offline payments without waiting for a bank server response, the card reserves isolated storage compartments called Service Compartments. Each compartment holds its own local balance managed by a specific transit or retail operator, separate from the primary global balance managed by the issuing bank. The SFI names came from the RE’d app and were later confirmed against the NPCI document.

flowchart TD
    MF[MF: Master File] --> PPSE[DF: PPSE 2PAY.SYS.DDF01]
    PPSE --> BF0C[Directory Data: Tag BF0C]
    BF0C --> AppEntry[App Entry: Tag 61]
    AppEntry --> AID[AID: A0000005241010]
    AppEntry --> Label[Label: RuPay PrePaid]

    MF --> Rupay[DF: RuPay AID A0000005241010]
    Rupay --> EFs[Elementary Files]

    EFs --> SFI1[SFI 1: Application Data]
    SFI1 --> Rec1_3[Rec 3: PAN, Expiry, CDOL1]

    EFs --> SFI2[SFI 2: System Parameters]
    SFI2 --> Rec2_1[Rec 1: CA Pub Key Index, ICC Exponent]
    SFI2 --> Rec2_2[Rec 2: Currency Code 0356 INR, Service Code]

    EFs --> SFI3[SFI 3: Crypto Certificates]
    SFI3 --> Rec3_7[Rec 7: ICC Public Key Certificate]
    SFI3 --> Rec3_8[Rec 8: Issuer Public Key Certificate]

    EFs --> SFI4[SFI 4: Security Remainder]
    SFI4 --> Rec4_1[Rec 1: ICC Public Key Remainder]

    EFs --> SFI16[SFI 16: Transaction Log]
    SFI16 --> Log[Rec 1-10: Circular Historical Log]

    Rupay --> NCMC[NCMC Service Compartments: Tag DF07]
    NCMC --> SC1[Compartment 1: Service ID 00 31]
    SC1 --> Bal1[SrBalance: Local Wallet]
    SC1 --> Atc1[SrATC: Service Counter]
    SC1 --> Keys1[K_psk: Session Keys]
    NCMC --> SC2[Compartment 2: Service ID 00 32]
    SC2 --> Bal2[SrBalance: Local Wallet]
    SC2 --> Atc2[SrATC: Service Counter]
    SC2 --> Keys2[K_psk: Session Keys]
    NCMC --> SC3[Compartment 3: Service ID 00 33]
    SC3 --> Bal3[SrBalance: Local Wallet]
    SC3 --> Atc3[SrATC: Service Counter]
    SC3 --> Keys3[K_psk: Session Keys]

flowchart TD
    MF[MF: Master File] --> PPSE[DF: PPSE 2PAY.SYS.DDF01]
    PPSE --> BF0C[Directory Data: Tag BF0C]
    BF0C --> AppEntry[App Entry: Tag 61]
    AppEntry --> AID[AID: A0000005241010]
    AppEntry --> Label[Label: RuPay PrePaid]

    MF --> Rupay[DF: RuPay AID A0000005241010]
    Rupay --> EFs[Elementary Files]

    EFs --> SFI1[SFI 1: Application Data]
    SFI1 --> Rec1_3[Rec 3: PAN, Expiry, CDOL1]

    EFs --> SFI2[SFI 2: System Parameters]
    SFI2 --> Rec2_1[Rec 1: CA Pub Key Index, ICC Exponent]
    SFI2 --> Rec2_2[Rec 2: Currency Code 0356 INR, Service Code]

    EFs --> SFI3[SFI 3: Crypto Certificates]
    SFI3 --> Rec3_7[Rec 7: ICC Public Key Certificate]
    SFI3 --> Rec3_8[Rec 8: Issuer Public Key Certificate]

    EFs --> SFI4[SFI 4: Security Remainder]
    SFI4 --> Rec4_1[Rec 1: ICC Public Key Remainder]

    EFs --> SFI16[SFI 16: Transaction Log]
    SFI16 --> Log[Rec 1-10: Circular Historical Log]

    Rupay --> NCMC[NCMC Service Compartments: Tag DF07]
    NCMC --> SC1[Compartment 1: Service ID 00 31]
    SC1 --> Bal1[SrBalance: Local Wallet]
    SC1 --> Atc1[SrATC: Service Counter]
    SC1 --> Keys1[K_psk: Session Keys]
    NCMC --> SC2[Compartment 2: Service ID 00 32]
    SC2 --> Bal2[SrBalance: Local Wallet]
    SC2 --> Atc2[SrATC: Service Counter]
    SC2 --> Keys2[K_psk: Session Keys]
    NCMC --> SC3[Compartment 3: Service ID 00 33]
    SC3 --> Bal3[SrBalance: Local Wallet]
    SC3 --> Atc3[SrATC: Service Counter]
    SC3 --> Keys3[K_psk: Session Keys]

A Quick Primer on EMV, TLV, and Cryptograms #

The sections above covered the memory layout and APDU structure. Before walking through the balance read, I want to explain the cryptographic concepts the rest of this post relies on.

The Cryptogram Types #

When you send GENERATE AC, you specify in P1 which type of cryptogram you want:

The SDK’s AcTypeMapper proves the mapping: command code 1 → P1 0x00, 2 → 0x40, 3 → 0x80, and the double-tap flow requests 0x40 (TC) when the server’s ARC is “00”, 0x00 (AAC) otherwise.

For balance reading, the terminal asks for a cryptogram at zero amount and the card answers with its signed state (CID 0x80 in the trace at the end of this post), which happens to include the balance.

The Chain of Trust #

The card’s signing key is not trusted directly by the terminal. Instead:

CA (Certification Authority) public key
  → signs the Issuer's public key certificate
    → signs the Card's (ICC) public key certificate
      → the card uses its private key to sign transactions

The terminal has the CA public keys baked into its config. It uses them to verify the bank’s certificate, which verifies the card’s certificate, which verifies the card’s signatures. This is called Offline Data Authentication (ODA), and it proves the card is genuine without contacting any server.

How Balance Read Works #

Now the interesting part. Here is the full balance read flow, from React Native (Airtel’s app) callback to final JSON output.

The Setup #

Once NFCCardReaderActivity (the entry activity) determines the card is RuPay (done by parsing the PPSE response for the AID), the CardTxnStartRunnable (com.isg.taptopay.n4) wires up the kernel:

 1// CardTxnStartRunnable.run()
 2cardTxnCoordinator.j.getConfiguration()
 3    .withLogger(kernelLoggerBridge)
 4    .withReaderResponse(new RupayReaderCallback(this.d))          // ← results come back here
 5    .withCardCommunication(new RupayCardCommAdapter(nfcIsoDepChannel))
 6    .withReaderResource(new RupayResourceProviderImpl(..., "rupayjson/"))
 7    .withFileWriter(new RupayFileWriterImpl())
 8    .withTerminalStatus(new TerminalStatusProviderImpl())
 9    .initialiseConfiguration()                                    // → RupayTransactionProcessor
10    .processWithTransaction(inputData, ppseResponse);

RupayReaderCallback (com.isg.taptopay.y3) is the key class. It implements RupayReaderResponseListener and is called by the kernel when the card session completes. Everything the card returned gets delivered to its transactionOutcome() method.

The APDU Session #

The RupayTransactionProcessor.b() (com.isg.taptopay.f8.b()) method drives the card through four standard EMV commands. Each one is built by ApduCommand and sent over the CardChannel (which wraps IsoDep.transceive()):

 1// 1. SELECT the application by AID
 2//    CLA=00 INS=A4 P1=04 P2=00, data = AID bytes
 3byte[] selectResponse = ApplicationSelection.b(aidBytes, cardChannel);
 4//    Card returns: 6F (FCI) containing 84 (DF Name), A5, PDOL (9F38)
 5
 6// 2. GET PROCESSING OPTIONS
 7//    CLA=80 INS=A8 P1=00 P2=00, data = 83 <len> <PDOL-filled data>
 8byte[] gpoResponse = new GpoProcessor(cardChannel, pdol, txnState).a();
 9//    Card returns: 77 containing 82 (AIP) and 94 (AFL = which records to read)
10
11// 3. READ RECORD — walk the AFL, read each record
12//    CLA=00 INS=B2 P1=recordNumber P2=(SFI<<3)|4 Le=00
13byte[] record = aflRecordReader.a(recordNum, (sfi << 3) | 4, 0);
14//    Card returns: 70 (Record Template) containing 57 (Track2), 5A (PAN),
15//                  8C (CDOL1), 8D (CDOL2), etc.
16
17// 4. GENERATE AC — ask the card to sign the transaction
18//    CLA=80 INS=8C P1=acType (0x40=TC, 0x80=ARQC, 0x00=AAC) P2=00, data = CDOL1-filled buffer
19//    (166 bytes for this card: 17 tags, DF45 alone is 96)
20byte[] genAcResponse = GenerateAcProcessor.a(channel, cdol1Data, acType);
21//    Card returns: 80 <CID(1B) ATC(2B) AC(8B) IAD(variable)>
22 

The GENERATE AC response is where the balance lives. EMV defines two response formats here, and RuPay cards use either. Format 1 (response template tag 80) packs everything into a compact form without TLV tags, just raw bytes:

Byte 0:      CID (Cryptogram Information Data — says "offline approved")
Bytes 1-2:   ATC (Application Transaction Counter — anti-replay counter)
Bytes 3-10:  AC (Application Cryptogram — the card's signature)
Bytes 11+:   IAD (Issuer Application Data — proprietary data, includes balance)

Format 2 (response template tag 77) carries the exact same fields wrapped in TLV instead: 9F27 (CID), 9F36 (ATC), 9F26 (AC), 9F10 (IAD). The card in the annotated trace at the end of this post uses format 2. The SDK parses both; the snippet below shows the format-1 raw-byte path:

The SDK parses this in GenerateAcProcessor.b() (com.isg.taptopay.k6.b()):

1// Extract IAD from the response
2String strE4 = EmvTags.ISSUER_APPLICATION_DATA.e();   // "9F10"
3String iad = BytesUtils.bytesToStringNoSpace(
4    Arrays.copyOfRange(value3, 11, value3.length));    // everything after byte 10
5txnState.b(strE4, iad);                               // store in tag map

Extracting the Balance #

After the APDU session, RupayReaderCallback.transactionOutcome() fires. Its b() method walks the output tag map and pulls the balance out of the Issuer Application Data:

1// RupayReaderCallback.b() — building CardReadDataModel from kernel output
2
3CardTagDef iadTag = CardTagRegistry.s;   // tag 9F10 = Issuer Application Data
4String iad = map.get(iadTag.b());        // hex string of IAD
5this.cardReadData.setmCardAmount(a(b(iad)));

The helper methods:

 1// Picks the balance digits from the IAD hex string
 2public final String b(String str) {
 3    return str.substring(23, 34);    // 11 hex characters, starting at position 23
 4}
 5
 6// Converts to rupees: parse as decimal integer, divide by 100
 7public final String a(String str) {
 8    double d = Double.parseDouble(
 9        Integer.toString(Integer.parseInt(str))) / 100.0d;
10    return String.format(Locale.US, "%.2f", d);
11}

So if the card’s IAD contains 043200 at the right offset, that becomes 43200 paise, which is 432.00 rupees. The offset substring(23, 34) is specific to this card’s IAD layout. The first 23 hex characters are issuer-proprietary header data, and the next 11 encode the balance as a zero-padded decimal number in paise (1/100th of a rupee). Max money can be 99,99,99,999.99, aka ninety nine crore ninety nine lakh ninety nine thousand nine hundred ninety nine rupees and ninety nine paisa.

Full Balance Read Sequence #

sequenceDiagram
    participant JS as React Native
    participant Ops as NfcDynamicSdkOperations
    participant API as TapToPayTransactionApi
    participant Act as NFCCardReaderActivity
    participant Kern as RupayTransactionProcessor
    participant Card as RuPay Card (NFC)
    participant CB as RupayReaderCallback

    JS->>Ops: initiateNFCOperation("balance_enquiry")
    Ops->>API: initiateRupayBalanceEnquiry(activity, tapToPay)
    API->>Act: startActivity(txnType=22)

    Note over Act,Kern: Kernel session begins

    Kern->>Card: SELECT PPSE (2PAY.SYS.DDF01)
    Card-->>Kern: 6F [AID list]
    Kern->>Card: SELECT AID (A0000005241010)
    Card-->>Kern: 6F [FCI with PDOL]
    Kern->>Card: GPO (80 A8, PDOL-filled data)
    Card-->>Kern: 77 [AIP, AFL]
    Kern->>Card: READ RECORD (per AFL, 6 records)
    Card-->>Kern: 70 [PAN, Track2, CDOL1, CDOL2, IACs]
    Kern->>Card: GENERATE AC (80 8C, ARQC, 48-byte data)
    Card-->>Kern: 80/77 [CID, ATC, AC, IAD]

    Note over CB: IAD.substring(23,34)<br/>parseInt / 100 = balance

    Kern-->>CB: transactionOutcome(ReaderOutput)
    CB->>CB: CardReadDataModel.setmCardAmount("432.00")
    CB->>Act: ICardTxnCallback.a(model, status, mode)
    Act-->>JS: transactionResponse(json)

sequenceDiagram
    participant JS as React Native
    participant Ops as NfcDynamicSdkOperations
    participant API as TapToPayTransactionApi
    participant Act as NFCCardReaderActivity
    participant Kern as RupayTransactionProcessor
    participant Card as RuPay Card (NFC)
    participant CB as RupayReaderCallback

    JS->>Ops: initiateNFCOperation("balance_enquiry")
    Ops->>API: initiateRupayBalanceEnquiry(activity, tapToPay)
    API->>Act: startActivity(txnType=22)

    Note over Act,Kern: Kernel session begins

    Kern->>Card: SELECT PPSE (2PAY.SYS.DDF01)
    Card-->>Kern: 6F [AID list]
    Kern->>Card: SELECT AID (A0000005241010)
    Card-->>Kern: 6F [FCI with PDOL]
    Kern->>Card: GPO (80 A8, PDOL-filled data)
    Card-->>Kern: 77 [AIP, AFL]
    Kern->>Card: READ RECORD (per AFL, 6 records)
    Card-->>Kern: 70 [PAN, Track2, CDOL1, CDOL2, IACs]
    Kern->>Card: GENERATE AC (80 8C, ARQC, 48-byte data)
    Card-->>Kern: 80/77 [CID, ATC, AC, IAD]

    Note over CB: IAD.substring(23,34)<br/>parseInt / 100 = balance

    Kern-->>CB: transactionOutcome(ReaderOutput)
    CB->>CB: CardReadDataModel.setmCardAmount("432.00")
    CB->>Act: ICardTxnCallback.a(model, status, mode)
    Act-->>JS: transactionResponse(json)

How Balance Update Works #

Adding money to the card is harder. You cannot just “write a balance” because the card will not accept unsigned changes. The issuer has to authorize the top-up cryptographically, and the card has to verify that authorization. This requires two taps.

Why Two Taps? #

The balance update is a three-party operation: the phone, the server, and the card. The server generates a cryptogram authorizing the top-up. The card must verify this cryptogram using keys it shares with the issuer. But the card can only communicate with the phone, not directly with the server. So:

1. Tap 1: Phone reads the card (SELECT, GPO, records, GENERATE AC). Nothing is written. The kernel ends the session with status ONLINE_REQUEST and hands the whole tag map to RupayReaderCallback, which wraps it into a CardReadDataModel. The phone then ships that metadata to the server (TransactionSubmitJob: DUKPT-encrypted track data, the concatenated TLV blob, PAN, expiry, KSN, all inside an ECDH-encrypted request body). The same tag map is also serialized to terminal_data.txt (DoubleTapFirstTapData: tags + FirstTapStatus) so tap 2 can pick up where tap 1 left off. This can lead to TOCTTOU like bugs because this data will be later used but is in user’s control for the time being.

 1public class CardReadDataModel {
 2    private HashMap<String, String> AllDataRecord;
 3    private String mAid;
 4    private String mCardAmount;
 5    private String mCardApplicationName;
 6    private String mCardExpiry;
 7    private String mCardNumber;
 8    private String mCardType;
 9    private String mICData;
10    private String mPrimaryAccountNo;
11    private String mTrackData;
12}

2. Server: Receives the card state, generates a signed top-up authorization using the issuer’s keys, sends it back to the phone. In the SDK’s model the reply carries exactly two fields that matter: iad (Issuer Authentication Data, tag 91) and arc (Authorisation Response Code, tag 8A). The new balance lives inside that IAD blob, never in plaintext; the app even decodes the top-up amount for its success screen by parsing the last 11 hex chars of the server’s IAD and dividing by 100 (best effort, it bails to an empty string when the parse fails).
3. Tap 2: The activity waits 600 ms, switches the banner to “Please Tap your card Again.” (ttp_doubletap_msg), and re-arms the reader. The server’s IAD and ARC go into RupayDoubleTapInput, which maps them to EMV tags and feeds processWithDoubleTapTransaction. The phone delivers the server’s cryptogram to the card, the card verifies it, updates its balance, and confirms.

The two taps exist because the flow is stateful and synchronous: tap 1 produces a signed state, the server needs network time to turn that into an authorization, and the card session cannot stay open across that wait. The SDK’s answer is to serialize tap 1 to disk, show a “tap again” banner, and start a fresh reader session when the server answers.

Deriving the Session Keys #

Before the phone can construct a valid top-up payload, it needs to derive session keys. Three key fragments come together:

• PRMiss (tag DF47, 32 hex chars): held by the issuer, sent to the phone by the server.
• PRMacq (tag DF48, 16 hex chars): held by the acquirer (in this case, the terminal config file).
• PRMicc (tag DF49, 16 hex chars): the card’s own half, read from the card during the first tap.

The suffix tells you who holds each fragment (iss = issuer, acq = acquirer, icc = the card’s chip). No single party holds the complete control: the issuer keeps PRMiss, the acquirer’s terminal holds PRMacq, and the card stores PRMicc. The phone can only reconstruct the session keys because the server hands it PRMiss straight from the issuer, and the phone combines it with the terminal’s PRMacq and the ICC dynamic number read during tap 1. The card derives its own side of the session keys from PRMicc, so both ends arrive at the same keys without the full key material ever crossing the NFC interface.

Mathematically, the derivation works like this:

Note the direction: the 16-byte concatenation of PRMacq’s first half and the ICC dynamic number is the AES-128 key, and PRMiss is the plaintext being encrypted. If the GPO response carried no service data, this step is skipped entirely and K_derived equals PRMiss directly.

where \(\Vert\) denotes concatenation, \(PR_{Macq}[0..8)\) is the first 8 bytes of PRMacq, and \(\left(\text{PAN} \,\Vert\, \text{PAN\_SEQ}\right)[-8..]\) is the last 8 bytes of the PAN concatenated with the PAN sequence number.

 1// ServiceKeyDeriver.a() — derive the session keys
 2// Step 1: if service data exists, derive a working key from PRMacq + ICC dynamic number
 3if (txnState.n) {  // service data present in GPO response
 4    byte[] macqPart = new byte[8];               // first 8 bytes of PRMacq
 5    System.arraycopy(fromString(PRMacq), 0, macqPart, 0, 8);
 6    String aesKey = hex(macqPart) + hex(txnState.h);   // 16-byte AES key
 7    // RupayCryptoHelper.a(key, data): PRMiss is the DATA here, not the key
 8    derivedKey = RupayCryptoHelper.a(aesKey, PRMiss);
 9} else {
10    derivedKey = PRMiss;  // no service data, use PRMiss directly
11}
12
13// Step 2: derive two 8-byte halves from PAN + PAN-seq + ICC dynamic number
14byte[] panAndSeq = fromString(PAN + PAN_SEQ);
15byte[] last8Bytes = copyOfRange(panAndSeq, length - 8, length);
16byte[] keyMaterial = fromString(
17    RupayCryptoHelper.a(derivedKey, hex(last8Bytes) + hex(iccDynamicNumber)));
18
19txnState.i = copyOfRange(keyMaterial, 0, 8);   // first half
20txnState.j = copyOfRange(keyMaterial, 8, ...); // second half

The AES-128 key for signing is simply PRMacq zero-padded to 16 bytes:

1// ServiceKeyDeriver.b()
2byte[] aesKey = new byte[16];
3System.arraycopy(fromString(PRMacq + "0000000000000000"), 0, aesKey, 0, 16);

Constructing the Service Payload #

With the keys derived, the SDK computes three NCMC-specific data elements that go into the CDOL1.

ServiceTerminalData (tag DF45) is terminal identity data for the card to verify:

1// RupayKernelUtils.e()
2String result = txnState.k           // derived key A (8 bytes)
3    + txnState.l                     // 3-byte check value
4    + PRMacqKeyIndex                 // from config
5    + ServiceBalanceLimit;           // from config
6txnState.b("DF45", result);

ServiceSummary (tag DF22) is a MAC (Message Authentication Code) over the transaction amount and card state:

 1// RupayKernelUtils.d() — simplified
 2String amountString = padTo12Digits(amount + otherAmount);  // "000000010000" for ₹100
 3String atcAndCurrency = txnState.b() + currency + date;
 4String dataToMAC = amountString + atcString;
 5
 6// XOR all 16-byte blocks of ServiceTerminalData together as IV
 7byte[] xorResult = xorAllBlocks(fromString(serviceTerminalData));
 8
 9// AES-encrypt the MAC input
10String encrypted = RupayCryptoHelper.a(dataToMAC, hex(xorResult));
11
12// Then HMAC with the second key half
13String mac = RupayCryptoHelper.a(
14    first5BytesOfKey + atc + arc,
15    encrypted);
16byte[] summary = copyOfRange(fromString(hexOfAES(firstKey, mac)), 0, 8);
17txnState.b("DF22", summary);

ServiceSignature (tag DF23) is a second MAC proving terminal authenticity:

1// RupayKernelUtils.f()
2String input = first6BytesOfICC + atc
3    + last4BytesOfIccDynamicNumber + first4BytesOfIccDynamicNumber;
4String key = serviceKeyDerivationResult + AES(firstKeyHalf, serviceKeyDeriverResult);
5byte[] signature = copyOfRange(
6    fromString(RupayCryptoHelper.a(input, key)), 0, 8);
7txnState.b("DF23", signature);

The actual top-up amount is not sent in plaintext. It is cryptographically bound into the DF22 (Service Summary) blob. The card derives the same session keys on its side from its stored PRMicc, the card’s half of the split key material; and extracts the amount from the decrypted data. If the cryptogram does not match, the card rejects the update.

Sending the Update #

The CDOL1 from the card includes the NCMC service tags. The SDK fills them all via DolTagValueBuilder and sends a standard GENERATE AC:

1// The 17 tags in CDOL1 (from the card, descriptor is 48 bytes):
2// 9F02 (amount), 9F03 (other amount), 9F1A (country), 95 (TVR),
3// 5F2A (currency), 9A (date), 9C (txn type), 9F37 (UN), 9F35 (term type),
4// 9F34 (CVM results), 9F21 (time), 9F1C (terminal ID), 9F4C (ICC dynamic#),
5// DF15 (service mgmt info), DF22 (service summary), DF23 (service signature),
6// DF45 (service terminal data, 96 bytes — 166-byte data field total)
7
8byte[] cdol1Data = GenerateAcProcessor.a(fromString(cdol1Dol), tagMap);
9byte[] response = GenerateAcProcessor.a(channel, cdol1Data, acType);

The phone saves the first tap’s state to a local file (terminal_data.txt via RupayFileWriterImpl) so the second tap can pick up where it left off:

1// DoubleTapStore.a().b.putAll(txnState.q);       // all card tags
2// new DoubleTapFirstTapData(tags, status)
3// fileWriter.writeFile(new Gson().toJson(data)); // persist to disk

Tap 2: Confirmation #

After the server responds with the authorization cryptogram (tag 91 = Issuer Authentication Data) and optional issuer scripts (tag 72), the user re-taps the card. But the SDK does not blindly contact the card. processWithDoubleTapTransaction (a little to complex for jadx, it gives up) runs a decision tree first:

 1// processWithDoubleTapTransaction(DoubleTapInputData) — reconstructed from smali
 2String arc    = paymentData.get(EmvTags.AUTHORISATION_RESPONSE_CODE.e()).trim();  // 8A
 3String iad    = paymentData.get(EmvTags.ISSUER_AUTHENTICATION_DATA.e()).trim();   // 91
 4String script = paymentData.get(EmvTags.ISSUER_SCRIPT_TEMPLATE_2.e()).trim();     // 71
 5
 6// sanitize: non-empty ARC shorter than 2 bytes gets forced to "5A33"
 7if (!arc.isEmpty() && BytesUtils.fromString(arc).length < 2) {
 8    paymentData.put(EmvTags.AUTHORISATION_RESPONSE_CODE.e(), "5A33");
 9}
10
11// merge host response into the tap-1 tag map loaded from terminal_data.txt
12HashMap merged = DoubleTapStore.a().b();
13merged.putAll(input.paymentData);
14
15if (arc.isEmpty() && iad.isEmpty()) {
16    // server said nothing: decide from tap-1's CID, never touch the card
17    int cid = Integer.parseInt(merged.get(EmvTags.CRYPTOGRAM_INFORMATION_DATA.e()), 16);
18    if (cid == 0) { merged.put("8A", "5A31"); a(Status.DECLINE, false, merged); }
19    else          { merged.put("8A", "5A33"); a(Status.REVERSAL, false, merged); }
20    return;
21}
22if (iad.isEmpty()) {
23    // ARC only: report and stop
24    if (hexToAscii(arc).equals("00")) a(Status.ONLINE_REQUEST, true, merged);
25    else                              a(Status.DECLINE, false, merged);
26    return;
27}
28// IAD present: contact the card only if a script exists, or a bit inside the
29// server IAD says so — bytes [4..8) of tag 91, MSB of the second byte
30boolean goTap = !script.isEmpty();
31if (!goTap) {
32    byte[] win = Arrays.copyOfRange(fromString(iad), 4, 8);
33    goTap = BytesUtils.binaryToInt(BytesUtils.toBinaryCharArray(win[1])[0]) == 1;
34}
35if (goTap && cardChannel.connectCard()) {
36    b(merged);   // the actual second tap: SecondTapProcessor flow below
37}

One more subtlety hides in the helper these branches call — RupayTransactionProcessor.a(Status, boolean, HashMap), the same class as the gate itself. The boolean does not choose the status directly, it chooses the source:

 1public final void a(Status status, boolean z, HashMap<String, String> map) {
 2    if (z) {
 3        this.d.setStatus(DoubleTapStore.a().c);   // tap 1's saved status
 4    } else {
 5        this.d.setStatus(status);                  // the argument
 6    }
 7    this.d.setOnlineResponseData(RupayKernelUtils.a(map));
 8    this.d.setAdditionalInfo(RupayKernelUtils.a(DoubleTapStore.a().b()));
 9    DoubleTapStore.a().a.deleteFile();   // terminal_data.txt
10    a();                                 // emit transactionOutcome()
11}

So the a(Status.ONLINE_REQUEST, true, merged) call in the ARC-only branch really means “report whatever tap 1 concluded.”

Once the gate passes, SecondTapProcessor handles the card:

 1// SecondTapProcessor.a(channel, txnState) — re-select the AID
 2// SecondTapProcessor.a(ppseResponse, channel, txnState) — second GPO
 3//   The card's GPO response now includes:
 4//   DF4B (POS Cardholder Interaction Info) — echoes ICC dynamic number
 5//   DF61 (DS Digest H) — proof the card processed the update
 6//   The SDK checks all three: ICC# match, digest present, AIP match
 7
 8// then: "1st Generate AC Command of 2nd Tap" over CDOL1 with acType 0 (ARQC)
 9//   only if that cryptogram checks out does the flow continue to:
10
11// SecondTapProcessor.a(channel, txnState, acType) — second GENERATE AC
12//   Uses CDOL2 (not CDOL1): contains tag 91 (issuer auth data from server)
13//   AC type depends on server's response code (ARC re-read from the tag map):
14//     "00" (success) → type 2 (TC)
15//     anything else  → type 1 (AAC, decline/reversal)
16// 

If the card approves, it returns a TC cryptogram. If it declines (say, because the issuer cryptogram was invalid), the SDK changes the status to REVERSAL, signaling that the balance change must be undone.

After the second GENERATE AC, the SDK runs any issuer scripts the server sent (tag 72):

1// IssuerScriptParser.a() — parse tag 72 into script commands
2List<TLV> commands = TlvUtil.getlistTLV(scriptBytes, EmvTags.ISSUER_SCRIPT_COMMAND);
3// Each 86 (Issuer Script Command) is sent to the card verbatim
4
5// IssuerScriptRunner.a() — execute and record results
6for each command:
7    byte[] response = channel.transceive(fromString(command));
8    boolean success = StatusWordChecker.a(response, StatusWord.SW_9000);
9    txnState.t.put(scriptId, RupayKernelUtils.a(success, cmdIndex, scriptId));