TypeError: 'NoneType' object is not iterable

[pc-coholic]

Apart from the warning-message, there is no obvious problems... According to this bugreport, this shouldn't be a problem though...

martin@felicitas:~/Desktop/EMVConsole$ python main.py 
Failed to load symbol for: SCardCancelTransaction, /lib/x86_64-linux-gnu/libpcsclite.so.1: undefined symbol: SCardCancelTransaction!
[ ] Waiting for card...
[+] Found card:  3B 6E 00 00 80 31 80 66 B0 84 0C 01 6E 01 83 00 90 00
6F 1E 84 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 0C 88 01 01 5F 2D 02 66 72 9F 11 01 01
[!] First PSE Record at:  01
SFI:  [12]
[ ] 1. INTERAC (A0 00 00 02 77 10 10)
[ ] 2.  (43 43 41 54 32)
[?] Which application? 1
 Pin tries left: 3
Traceback (most recent call last):
  File "main.py", line 56, in <module>
    afl = func.getAFL([0x83, 0x04] + pdol_enc)
  File "/home/martin/Desktop/EMVConsole/emvfunctions.py", line 147, in getAFL
    response, sw1, sw2 = self.getProcessingOptions(data)
TypeError: 'NoneType' object is not iterable

This problem occurs with multiple cards I tried - Interac, Master, Visa, Maestro, Vpay. The error persists, even when there is only one application on the card and the "[?] Which application?"-prompt is not displayed.

pyscard version: 1.6.12.1

[blunden]

Yeah, I have confirmed that the undefined symbol error seemingly doesn't cause any problems here.

The issue is likely to be in the getAFL response parsing code. I noticed a similar issue there a few weeks ago too after running the ATC counter to the max on a particular card with atclooper.py. All the code was written based on the responses we got from the cards we had at the time which probably means there are some assumptions in there that doesn't always hold true. The parsing current code isn't very forgiving for that reason.

This code was all written for a specific purpose a few years ago to get some feel for the actual system when investigating some claims made in the statements made by local banks in connection with a particular publicised EMV vulnerability 5-8 years ago. That's also when the decoder code used by https://github.com/blunden/TVRDecoder was written (though we originally wrote it in JavaScript) by the way. Anyway, my point is that I uploaded the code to EMVConsole mostly because I didn't want to lose it as I figured some parts of it might be useful at some point in the future. I guess I forgot to mention in the readme that it is deprecated as far as I'm concerned.

If you want to look into this though, you can check some of the code that has been commented out how to read and output the response as hex, look at the EMV spec on how to interpret it and compare it to what our code expects. I'd happily accept a pull request if you decide to fix it. Since I realize it's more likely that you will move on to a more robust EMV implementation project instead, I'm sorry I wasted your time by not being clear about the current status of the code in the README.

(I mistakenly closed the issue because an mistaken tap on my phone).

[kelvintx2022]

Good job, i had same issue too, looking forward for the patch =)

[blunden]

@kelvintx3 Don't expect any patch from me. I don't spend any time on this project anymore, and haven't really for years. I'd happily accept a pull request though.