Reply To: Switching MiFare Plus to S3

Forum MIFARE SDK Switching MiFare Plus to S3 Reply To: Switching MiFare Plus to S3

Re: Switching MiFare Plus to S3

14. October 2020 at 11:29
Hi there. This topic is pretty old, but I encountered the same issue. I am using latest Android TapLinx 1.7. Calling IPlusSL1.switchToSL3(keyData) causes this output (I also enabled TapLinx debug output to get extra info if it is useful):

D/TapLinxDebug: KeyFactory DIV KEY : 0xA50D36A70FF24D190C810CD50E05B6D7
D/TapLinxDebug: AbstractPlus send to card : 70039000
D/TapLinxDebug: AbstractPlusSL1 0x0270039000
D/TapLinxDebug: AbstractPlusSL1 0x029077B875E8078F6DDD8C77B8422E0A
D/TapLinxDebug: AbstractPlus Recv from Card : 9077B875E8078F6DDD8C77B8422E0A
D/TapLinxDebug: AbstractPlus Recv from card without response code: 77B875E8078F6DDD8C77B8422E0A
D/TapLinxDebug: AbstractPlus IV : 00000000000000000000000000000000
D/TapLinxDebug: AbstractPlus PICC-to->PCD E(Kx, RNDB) : 77B875E8078F6DDD8C77B8422E0A
E/NxpNfcLibException: Error processing card
com.nxp.nfclib.exceptions.SecurityException: error:1e00006a:Cipher functions:OPENSSL_internal:DATA_NOT_MULTIPLE_OF_BLOCK_LENGTH
at com.nxp.nfclib.defaultimpl.if.decrypt(:186)

As you may see, the latest message "PICC-to->PCD E" contains some value with 28 hex symbols, so it is 14 bytes long instead of probably expected 16 bytes long, which may be the source of this issue. According to the code above that, this value is received from the card as 15 bytes, then first byte is removed because it probably contains some 'response code'.
This value comes somewhere from the depths of 'trancieve' functions, but everything there is pretty much obfuscated and hard to understand. Maybe some wrong truncation happens there.

Any clues about how to workaround this issue?
+ 0  |  - 0