Gemalto IDPrime 930 Cards
For some reason, i really enjoy writing to binary interfaces, like the binary interface for smart cards.
Smart cards communicate devices by sending hex codes (called APDU codes). i have implemented compatibility with a bunch of smart cards but all of them had a published spec for how the interface works. A customer wanted support for smart cards they are using for their Windows PCs. They selected the Gemalto IDPrime 930 smart card because it doesn’t require a separate mini driver in Windows. It isn’t supported on iOS. I’ve added support for other types of cards so I agreed to add support for IDPrime card to Smart Card Utility on iOS. However, the IDPrime cards do not have a publish spec. The cards appear to generally follow the standard ISO 7816 APDU commands with some proprietary commands.
I started by getting a trace of a working smart card session on Windows. Here is the start of a trace:
2026-05-13;09:17:47;Reset
2026-05-13;09:17:48;00 A4 04 00 07 A0 00 00 01 51 00 00
2026-05-13;09:17:48;6A 82
2026-05-13;09:17:48;00 A4 04 00 07 A0 00 00 00 03 00 00
2026-05-13;09:17:48;6A 82
2026-05-13;09:17:48;00 A4 04 00 07 A0 00 00 00 18 43 4D
2026-05-13;09:17:48;61 69
2026-05-13;09:17:48;00 C0 00 00 69
Each APDU command has a instructions, 2 parameters and (optionally) some data. Looking at the example above, the first 2 lines sent return “6A 82” which is like a 404 error in HTTP. Those are good indicators that the driver is probing the card. The third line sent returns a “61 69” which means “Data available of length 69 bytes”. I can then see what data comes back and see if I can recognize it. I know that is a mTLS authentication so I know what generally is needed.
The fun part is once I get the translation layer implemented, it all starts to work in the app to authenticate with the website. I figure out what codes are needed for which operation (certificate reading, PIN validation, hash signing) and like magic, the card starts working with smart card readers and our app. It is like filling in a crossword puzzle to start your car.
Social Rules
good social rules both online and offline:
No well-actually’s No feigned surprise No backseat driving No subtle-isms
The Last Bit
I spent the last couple of months fine tuning DFU Blaster Pro for a large update (DFU Blaster 5). We seeded it out to customer in production, and got some great feedback. I went back in and updated the pieces that needed updating.
Leaving a codebase for a bit and coming back gives a fresh perspective and a bit of joy. Finishing up a release can be hectic and stressful but going back to it is like seeing an old friend.
Productive week. We released Xpsso (enables Platform SSO with Google cloud), XCreds Mobile (cloud auth on iPad) passed QA and DFU Blaster 5 is now feature complete.
I also hired two new people.
Excelsior!
DFU Restore for Mac is now almost 4 times faster!
Big news! The firmware on M4 and M5 Macs supports USB 3 speeds during DFU restores! This will make a huge difference for restoring multiple Mac systems at the same time. Our Erase and Restore system is based on DFU Restores for Apple Silicon Macs and the time to restore 15 Macs has gone from 35 minutes to less than 10 minutes! That is total time, not per device.
If you are already using DFU Blaster with the Acroname Hub3c, you have everything you need! Make sure you are using USB 3 cables and you will see the increased speed when restoring M4 and M5 Macs. We have tested on the M4 MacBook Air, the M5 MacBook Pro and the M4 Mac mini. All of these devices restored at USB 3 speeds and took about 3 minutes to restore a single Mac!
You can mix and match Macs that restore at USB 2 and USB 3 speeds, and can even mix in USB-C iOS devices as well. We haven’t tested the new Mac Neo, but hopefully that will support the new faster speeds as well. We will have the newest Mac in our lab early next week and will know soon!
Here is a photo of our lab with a mix of Apple Silicon Macs and iPads all restoring at the same time:
Tracing USB-PD
It looks like the command to put an iPad (A16) into DFU mode changed. There are some introspection that you can with USB-PD to find out what commands a device supports, but none of them seemed to work. I needed to go deeper and see the actual USB-PD packets. I got a CY4500 EZ-PD Protocol Analyzer from Mouser. It promised to show me the power delivery packets on the wire. I was going to hook it up to a PC when I got home, but when I got it at the office today, the docs said it worked on macOS.
I got it working, but it wasn’t easy:
- The macOS installer package was not signed. I had to allow it from System Settings -> Privacy & Security.
- Once the app was installed, it crashed with a Java error. Looking closer, it couldn’t find libUSB. So I installed it with “brew install libusb”.
- The app launched! Yea! But then it said I had to install a firmware update on the device and told me where it was and how to run it.
- The firmware updater is a macOS app but wouldn’t launch. It had an invalid code signingin signature. I had to sign to code sign it to get it to launch.
Once I did all that, the traces started to work! It seems the issue is the version of the Vendor Defined Message (VDM) packet that is being sent is the only difference and I suspect the new iPads require it. No way to test it yet, but it was pretty cool to do a “man in the middle” trace of USB-PD traffic.
