I'm trying to read data from a "MIFARE Classic 4K - emulated (6212 Classic), Nokia" card with an ACS ACR122U reader.
The sector I need to read is number 18, the Key A is A0A1A2A3A4A5 (I can read it with my smartphone).
Nonetheless, I cannot load the key to the reader nor authenticate.
I managed to get the UID, the reader and the ATR. But I'm mysing something when I try to read a sector.
Edit: I managed to read another card with the same code (but another key). With that card I receive 90 00 with the right key, and 63 00 with a wrong one. But with this card... nothing.
Edit 2:
As far as I have read, it may be a problem with automatic protocol activation. How can I set the layer to read MIFARE Classic memory area?
Related
i'm new to Mifare Desfire Cards. My goal is to create a file with data in this Mifare Card. First, i'm just having troubles with authentification process :
1. I sent the command 0x0A | 0x00 to the PICC and the PICC returned a frame with : 0xAF | 8 bytes word (probably random encyphered number B) but after this, I dont understand what I am supposed to do with encryption mecanisms..., what is the next step ? I mean what is the next command I have to send ?
MIFARE DESFire EV1 uses 3-pass mutual authentication protocol for the authentication.
You can refer this for reference.
If you don't wanna smash your head and don't want to get into low level implementation, NXP already provides an Open API TapLinx, which you can simply integrate in your project and make use of all the features just by invoking APIs
eg: desfireObject.authenticate(key);
I am trying to build my own client RTMP library for an app that I am working on. So far everything has gone pretty successfully in that I am able to connect to the RTMP server negotiate the handshake and then send all the necessary packets (FCPublish Publish ETC) then from the server i get the onStatus message of NetStream.Publish.Start which means that I have successfully got the server to allow me to start publishing my live video broadcast. Wireshark also confirms that the information (/Data packetizing) is correct as it shows up correctly there also.
Now for where I am having some trouble is RTMP Chunking, going off the Adobe RTMP Specification on page 17 & 18 shows an example of how a message is chunked. From this example I can see that it is broken down based on the chunk size (128 bytes). For me the chunk size gets negotiated in the initial connect and exchange which is always 4096 bytes. So for when I am exchanging video data that is larger than 4096 bytes I need to chunk the message down sending the RTMP packetHeader combined with the first 4096 bytes of data then sending a small RTMP header which is 0xc4 (0xc0 | packetHeaderType (0x04)) combined with 4096 bytes of video data until the full packet specified by the header has been sent. Then a new frame comes in and the same process is repeated.
By checking other RTMP client example written in different languages this seems to be what they are all doing. Unfortunately the ingest server that I am trying to stream to is not picking up the broadcast video data, they dont close the connection on my they just never show video or any sign that the video is right. Wireshark shows that after the video atom packet is sent most packets sent are Unknown (0x0) for a little bit and then they will switch into Video Data and will sort of flip flop between showing Unknown (0x0) and Video Data. However if I restrict my payload max size to 20000 bytes Wireshark shows everything as Video Data. Obviously the ingest server will not show video in this situation as i am removing chunks of data for it to be only 20k bytes.
Trying to figure out what is going wrong I started another xcode project that allows me to spoof a RTMP server on my Lan so that I can see what the data looks like from libRTMP IOS as it comes into the server. Also with libRTMP I can make it log the packets it sends and they seem to inject the byte 0xc4 even 128 bytes even tho I have sent the Change Chunk size message as the server. When I try to replicate this in my RTMP client Library by just using a 128 chunk size even tho it has been set to 4096 bytes the server will close my connection on me. However if change libRTMP to try to go to the live RTMP server it still prints out within LibRTMP that it is sending packets in a chunk size of 128. And the server seems to be accepting it as video is showing up. When I do look at the data coming in on my RTMP server I can see that it is all their.
Anyone have any idea what could be going on?
While I haven't worked specifically with RTMP, I have worked with RTSP/RTP/RTCP pretty extensively, so, based on that experience and the bruises I picked up along the way, here are some random, possibly-applicable tips that might help/things to look for that might be causing an issue:
Does your video encoding match what you're telling the server? In other words, if your video is encoded as H.264, is that what you're specifying to the server?
Does the data match the container format that the server is expecting? For example, if the server expects to receive an MPEG-4 movie (.m4v) file but you're sending only an encoded MPEG-4 (.mp4) stream, you'll need to encapsulate the MPEG-4 video stream into an MPEG-4 movie container. Conversely, if the server is expecting only a single MPEG-4 video stream but you're sending an encapsulated MPEG-4 Movie, you'll need to de-mux the MPEG-4 stream out of its container and send only that content.
Have you taken into account the MTU of your transmission medium? Regardless of chunk size, getting an MTU mismatch between the client and server can be hard to debug (and is possibly why you're getting some packets listed as "Unknown" type and others as "Video Data" type). Much of this will be taken care of with most OS' built-in Segmentation-and-Reassembly (SAR) infrastructure so long as the MTU is consistent, but in cases where you have to do your own SAR logic it's very easy to get this wrong.
Have you tried capturing traffic in Wireshark with libRTMP iOS and your own client and comparing the packets side by side? Sometimes a "reference" packet trace can be invaluable in finding that one little bit (or many) that didn't originally seem important.
Good luck!
I have been trying for 4 days now to send the hex code 10 80 00 00 00 00 00 00 to a USB device connected to my raspberry pi running debian.
I've tried libusb with c but I have no idea what I am doing. I thought PyUSB would be a better solution but ive found zero documentation for what I need and the tutorial did'nt help.
I can find the device using
import usb.core
dev = usb.core.find(idVendor=0x12BF, idProduct=0xFF03)
But I cant find any information on how to send the above hex code. My device is a usb based relay. It works fine on windows in a vb HID application but I am struggling here. seem to be going round in circles.
Could you please tell us, how is the USB communication with the device? Is it a bulk transfer?
(see this link for more details:
http://www.beyondlogic.org/usbnutshell/usb1.shtml )
For instance, if you are using a bulk communication via an Endpoint you could try something like this (as seen here http://pyusb.sourceforge.net/docs/1.0/tutorial.html):
endpoint.write(endpointnumber, data, interfacenumber)
If you want to send a hex value, let's say 0xFF via the endpoint 2, interface 0, try something like:
endpoint.write(2, '\xFF', 0)
I hope this helps...
For a personal MMO game project I am implementing a homebrew reliable UDP-based protocol in java. Given my current setup I beleive it would be relatively simple for a snooper to hijack a session, so in order to prevent this I am taking the opportunity to learn a little cryptology. Its very interesting.
I can successfully create a shared secret key between the client and server using a Diffie-Hellman key exchange (a very clever concept), but now I need to use this to guarantee the authenticity of the packets. My preliminary testing so far has shown that the couple of different ciphers Ive tried bloat the amount of data a bit, but I would like to keep things as small and fast as possible.
Given that I am only trying to authenticate the packet and not nessecarily conceal the entire payload, I have the idea that I could put an 8 byte session ID generated from the secret key into the packet header, encrypt the whole packet, and hash it back down to 8 bytes. I take the unencrypted packet and put the 8 byte hash into the place of the session ID and then send it off.
Would this be secure? It feels a little inelegant to encrypt the whole packet only to send it unencrypted - is there a better/faster way to achieve my goal? Please note I would like to do this myself since its good experience so Im not so interested in 3rd party libraries or other protocol options.
If both peers have access to a shared secret (which they should, since you're talking about Diffie-Hellman), you could simply store a hash of the datagram in its header. The receiver checks to see if it matches.
As an added security measure, you could also add a "challenge" field to your datagram and use it somewhere in the hashing process to prevent replays.
So this hash should cover:
The shared secret
A challenge
The contents of the datagram
EDIT
The "challenge" is a strictly incrementing number. You add it to your datagram simply to change the hash every time you send a new message. If someone intercepts a message, it cannot resend it: the receiver makes sure it doesn't accept it.
I'd like to start coding against an ELM327 based automotive OBD-II Bluetooth adapter in iOS/Objective-C. Is there a guide/primer on how to get started?
I would imagine the ELM327 adapter is a serial device... I can probably figure out how to establish a Bluetooth connection with the phone, but I haven't any idea where to start with sending/receiving OBD-II messages to/from it.
Is there a pre-existing API for this device?
If you need some OBDKey specific commands let me know. As an example, to access the RPM data, issue the following commands
ATZ\r
ATSP0\r
0100\r
010C\r
These instructions will initialise the OBDKey interface, set the protocol search on to automatic, initialise communcations with the engine managment ECU and send the mode 1 PID 0C command to request engine speed (RPM) data. The value returned in response to the 010C command is actually four time the real engine speed value.
Using sockets and streams in iOS / Objective-C is the best way to set up communications to the OBDKey WLAN (the default IP address is 192.168.0.74, port 23).
The elm327 odb2 device uses AT and ODB commands.
The AT commands are the same as you use on modems, they always start with AT.
When the devices initializes it sends
ELM327 v2.1
>
If you send
ATZ
this will reset device and it will issue "ELM327 v2.1" and > prompt again.
AT commands are used to manage the elm327 device.
ODB commands are in asci hex such as the above example
01 0c
to get the rpm or
01 05
to get coolant temp
At http://www.elmelectronics.com/obdic.html there are data sheet pdf files with more details.
Also you can search ituns for "elm327" and get 2 free books on the subject.
I'm just starting the same project for my generic elm327 wifi device so I dont have any details yet.
I will add comments as soon as I learn anything useful.