I am having trouble reading ICC data from an card. I have an AID from an issuer which is A0000007790000. So I am sending an APDU of 00A4040007A0000007790000 to select the application by its AID but I keep getting response of SWA: 62 SWB: 83. What am I missing, and how can I proceed from there.
I can only do a select PSE using 00A404000E315041592E5359532E444446303100 which is successful and I am getting a response of 6F1A840E315041592E5359532E4444463031A5088801015F2D02656E..
The Other commands like 00B2010C00 are returning that SWA SWB 6283 (Selected file invalidated) response. Any pointers will be greatly appreciated.
The AID Select Command should have additional Le byte.
APDU Command: 00A4040007 A000000779 0000 00
The problem that I had was on the device permissions, I had not realized that the device I was using to read the emv cards had no permissions to read external files, so that did not allow me to read any data from the application files in the chip card
Related
I've got a working local website that takes in HTML form data.
The fields are:
Temperature
Humidity
The server successfully receives the data and spits out a graph updated with the new entries.
Using a browser tool, I was able to capture the actual POST request as follows:
http://127.0.0.1:5000/add_data
Temperature=25.4&Humidity=52.2
Content-Length:30
Now, I want to migrate from using the human interface browser with manual entries to an ESP01 device using AT commands.
According to the ESP AT-commands documentation, a POST request is performed using the following command:
AT+HTTPCPOST=
Find the link below for the full description of the command.
I cannot seem to get this POST request working. The ESP01 device immediately returns an "ERROR" message without any delay, as though it did not even try to send the request, that the syntax might be wrong.
Among many variations, the following is my best attempt:
AT+HTTPCPOST="http://MYIPADDR:5000/add_data",30,2,"Temperature: 25.4","Humidity: 52.2"
With MYIPADDR above replaced with my IP address.
How do I translate a post request into ESP01 AT command format, and are there any prerequisites needed to be in place to perform such a request?
I did connect the ESP01 device to the WiFi network.
Here's the link to the POST AT command description:
https://docs.espressif.com/projects/esp-at/en/release-v2.2.0.0_esp8266/AT_Command_Set/HTTP_AT_Commands.html#cmd-httpcpost
The documentation says:
AT+HTTPCPOST=url,length[,<http_req_header_cnt>][,<http_req_header>..<http_req_header>]
Response:
OK
The symbol > indicates that AT is ready for receiving serial data, and you can enter the data now. When the requirement of message length
determined by the parameter is met, the transmission starts.
...
Parameters
: HTTP URL. : HTTP data length to POST. The maximum
length is equal to the system allocable heap size.
<http_req_header_cnt>: the number of <http_req_header> parameters.
[<http_req_header>]: you can send more than one request header to the
server.
You're sending:
AT+HTTPCPOST="http://MYIPADDR:5000/add_data",30,2,"Temperature: 25.4","Humidity: 52.2"
The length is 30. The problem is that everything after the length is HTTP header fields; you need to send the variables in the body. So the command is:
AT+HTTPCPOST="http://MYIPADDR:5000/add_data",30
followed on the next line by after the ESP-01 send the > character:
Temperature=25.4&Humidity=52.2
Because you passed 30 as the body length, the ESP-01 will read exactly 30 characters after the end of the AT command and send that data as the post body. If the size of that data changes (for instance, maybe the temperature is 2.2, so one digit less), you'll need to send the new length rather than 30.
I was trying to use Seagull as a Diameter server for Cx interface. In response to a MAR request, the script needs to send a MAA response with “Digest-HA1” AVP (part of the grouped SIP-Digest-Authenticate AVP, which in turn is part of the SIP-Auth-Data-Item AVP) that contains H(A1). The Diameter Client(CSM) can use H(A1) to calculate the expected Digest response, according to this challenge.
Based on Seagull Documentation, I tried both ways i.e. SIP authentication and Radius authentication, but couldn’t succeed in getting HA1 calculated as expected.
When I tried the SIP Authentication way as below in my scenario file, it threw “2021-10-21.07:20:19.790|T|E_ACTION_SCEN_SET_VALUE_METHOD_EXTERN: problem when using external method (md5 or AKA)” error.
<set-value name="Digest-HA1" method="authenticationSip"
format="username=alice;password=12345;auth=Digest realm=\"open-ims.test\", algorithm=MD5;method=REGISTER;uri=sip:testuri.com"></set-value>
When I tried the Radius Authentication way as below in my scenario file, I see junk value being set for Digest-HA1 AVP.
<set-value name="Digest-HA1" method="authenticationRadius" message_part="all"
format="shared_secret=9000000009#open-ims.test:open-ims.test:12345"></set-value>
Digest-HA1 AVP filled with junk value in MAA response
AVP: Digest-HA1(121) l=24 f=-M- val=a\024\r\030�,����.�\032��\b
AVP Code: 121 Digest-HA1
AVP Flags: 0x40, Mandatory: Set
AVP Length: 24
Digest-HA1: a\024\r\030�,����.�\032��\b
I tried few combinations like hard coding few/all parameters, reading from previous message with the action “store” etc. but couldn’t succeed. Attaching scenario/dictionary files for your reference.
Can you please suggest if you are aware of any method (like crypto_method_radius for Radius Auth) which I can use to set Digest-HA1 AVP. Thanks in advance.
Downloaded source code and enhanced support for Diameter authentication via external-method functionality similar to SIP/Radius authentication. Seagull by default doesn't have support for Diameter Authentication.
I am not able to received complete responses from my BLE device which I am supposed to receive for the commands written to characteristics using flutter_blue. What I am receiving in response is the command itself which I sent for write. The responses received are being decoded properly.
The commands which I'm trying to write are OBDII protocols which are
AT Z
AT H0
AT H0
AT L0
AT S0
01 0C
Surprisingly the command "AT Z" gives response "ELM 327v1.5" which is correct. This is the only command from which I am receiving the correct response. All other commands are returning the command itself which is partially correct because most of the times the actual responses are received along with the command name.
The response reading and decoding is implemented in the following way
await read_CX.setNotifyValue(true);
read_CX.value.listen((response) {
print(utf8.decode(response));
}
Has anyone faced similar issue of receiving incomplete data? Can anyone please help me out?
Thanks!!
First, add ATE0\r to your init sequence, this will stop the adapter from echoing back what you send.
Then, familiarize yourself with the AT commands provided by the ELM327, e.g. by reading https://www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DS.pdf.
Similar the question I asked before in enter link description here, I also need a Log pcap for MAP_OPEN_REQ and MAP_OPEN_DELIMITER_REQ messages.
As I found pcap files containing MAP/TCAP/SCCP protocols enter link description here and enter link description here, but there is no log Pcap for MAP_OPEN_REQ there.
How can I get that?
You won't find MAP-OPEN and MAP-DELIMITER in the pcaps because they are not sent over the wire.
These are common services/primitives used between the MAP service-user and the MAP service-provider. See 3GPP 29.002 - "7 General on MAP services" and "7.5 General rules for mapping of services onto TC".
The inbound roamer IMSI is sent as a parameter in the MAP send authentication info request message from the VPLMN MSC/VLR to the HPLMN HLR as component portion of TCAP dialogue. Here TCAP is MAP provider to transfer MAP service user data to destination MAP service user which is the HLR. In order to send mentioned MAP operation and receive its response, you need to implement whole SS7 layers; TCAP, SCCP and M3UA. You can not send only MAP message without adding other SS7 layers to route your message to target HLR entity. I would propose using Sigtran Softstack solutions to address all issues at once.
I am using smstools3 for operating an USB-based surf stick for sending SMSes. I am working on querying the balance of a prepaid SIM card. The stick is a ZTE MF112 from China, the provider is eplus from Germany. This seems relevant as the response to a balance query contains an umlaut (ä).
Speaking directly to the modem (via cu /dev/ttyU0.2) I can perform a query:
AT+CUSD=1,"*100#",15
OK
+CUSD: 0,"00490068007200200047007500740068006100620065006E0020006200650074007200E400670074003A00200039002C003900370020002E",72
which response eventually translates to
Ihr Guthaben beträgt: 9,97 .
However, smstools3 has problems whith this. It appears that the encoding (,15) is omitted in the request and I have no way of supplying it.
Question: is there a way of setting the encoding globally in an init command like AT+CSCS?