Reader is probably this one (Modulo+, not Modulo): http://www.aztek.lu/en/products/modulo
Software can be found here: http://www.lmcontrol.com/systemes-paiement/lecteur-privatif-mifare/188-soft-modulo.html
Here you can find useful pdf about how to use software: http://www.lmcontrol.com/images/stories/produits/pdf/
Encryption can be managed by reader firmware but maybe can be decoded by the software, if not we are ou of luck.
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.
This forum is getting populated by I-want-to-fraud people (from experience italians to fraud, chinese people to make money) because too many good people here are kind enough to answer almost every question; my help will not be given anymore to them anyway each user is responsible for the help given so, siop, you can try to explain how stuff seems to be going on but you cannot force people not to giving help, you can only "suggest".
Good test tontol1 but even solving that problem there is another one to make it "full raw compatible": the ability to send 7bits commands insted of 8bits. 26 (or 52) is a 7bits command that is part of the mifare standard command set managed by the NXP chip. If you want, for example, "talk" with a magic 1st gen mifare card you must send another 7bits command [it is 40] that is not coded inside NXP chip so even with your method it will be not possible to achieve a full raw.
It is something like SRIX4K support: they are not supported by Android because they are not full ISO14443B and have specific commands not supported by the chipset (at least this is what came out by tests) but maybe with your method this one can be solved because those specific commands (SRIX) are 8bits [the command is exactly 0600 = INITIATE]. Let us know if you find a way (also for ISO14443B commnds) !
In theory the tag should start answering with something like an UID while just entering the magnetic field (if it does not want any specific wake-up command).
The answer must be in ISO14443 format to be shown in pm3; if it is ISO14443A, as iceman said, you need to test all the 256 bytes possibilities using the following commands:
hf 14a raw -p 00
hf 14a raw -p 01
hf 14a raw -p 02
hf 14a raw -p 03
hf 14a raw -p 04
hf 14a raw -p 05
hf 14a raw -p 06
hf 14a raw -p 07
hf 14a raw -p 08
hf 14a raw -p 09
hf 14a raw -p 0A
hf 14a raw -p 0B
hf 14a raw -p 0C
hf 14a raw -p 0D
hf 14a raw -p 0E
hf 14a raw -p 0F
hf 14a raw -p 10
hf 14a raw -p 11
hf 14a raw -p 12
hf 14a raw -p 13
hf 14a raw -p 14
and so on until FF value (=256).
It is supposed to be a modified pm3 hardware with support for offical pm3 firmware (the site is linking to my compiled firmware releases). Version 2.0.0 does not support pcf write but the site it calims it is supported but it is not if you do not update firmare to the latest revision available (that is NOT 2.0.0) so I don't trust sites that says something that is not real (to show better compatibility only) even if the stuff they sell seems to be good.