They seems to be programmable UHF remote controls, you cannot use pm3 for them.
They usually comes in 3 frequencies: 315, 433.92 and 868.3 MHz but the most common one is 433MHz (you can open it and look at the internal oscillator frequency to be sure).
You need to know how to program them; usually you need to hold 1 or 2 buttons at the same time to "erase" the memory and then keep pressed a button while at the same time pressing the button you want to clone in the originale remote.
You can "analyze" them if you have something like this.
hm, did you change your DI base firmware?!? or do you call it with one of those node.js-usb projects I've seen and tested on Lego?
No. The DI firmware (STM32F102) calculates the key and gives it to the NFC frontend (MFRC630) which handles the MIFARE authentication. I simply attached my own microcontroller (STM32F103) to the SPI bus and wrote a small program that outputs the key via UART.
Very good P.O.C. ! Did you test some STM32F vulnerabilities ? If so can you share them even if they won't work with DI base ?
It probably uses Calypso standard (often used in transport systems) which is proprietary and actually undisclosed to public (for what know you need to be a transport service provider and you must pay to have it). If you want to study/reversing it you need to know the command set; you can get some info sniffing transaction but it will be an hard work.
It seems to be a dual interface smartcard and the data you sniffed are (or seem to be) a smartcard apdu communication transaction (commands that can be send via contact interface embedded inside a rfid commandset); it is good that you managed to sniff.
You should try to sniff the very beginning of the transaction and see if the byte "E0" comes out.
If you have a smartcart (contact!) reader I can give you some commands to be tested.
You need the correct compiled file for your exact kernel, other versions will not work. You need To compile it yourself if you are not able To find Someone who already compiled it.
Do not try the ones contained in my packet with a kernel different from the ones tested, they will not work.