I am writing a C++ code using winscard. I noticed that, if I send a command with Scardtransmit where only data is sent or only data received, there is no problem. I can send data or get correct response.
However, when the command both sends data and expects a response then I always get 61xx. I know the error code 61xx means there is an xx bytes response where Le is not correct, and checked every possible Le, including the returned value xx, but nothing changes. For example let the Apdu be in the form CLA INS P1 P2 Lc Data Le, and I get 61XX, then I send CLA INS P1 P2 Lc Data XX, again I get 61XX.
I checked the card using java and other tools and verified that there is nothing with the card.
As far as I understand, there is a single byte P3 allocated for Lc and Le. Is there a way to get responses (apart from the SW1SW2) from the DATADATA commands?
When you send a command that has Command Data and the command is expecting Result Data as well, and the communication is made using T=0 protocol, then you need to send two APDUs. One for the command itself, and another one to retrieve the result.
61XX is not an error. It is a (successful) Status Word that indicates you have XX bytes of response which you can retrieve using GET RESPONSE (INS=0xC0).
Here is the reference of the command.
Related
enter image description here
I'm new to using I2C and I'm stuck at attempting to read values since most data require several 8 byte data packets to be sent, something that most documentation and examples i've found online do not answer. The specific wording from the datasheet is:
"Two message structures are available to the master; a write command and a read command. The write command is used to initiate an event and the read command returns the result.All commands start with the 7-bit slave address and are followed by thedata bytes.When reading responses, all data bytes should be read out together.Each command has a delay associated with it, this is required to allow the microcontroller time to process each request.During this delay, the correct response may not be returned, and commands sent during the period may be ignored.
For a write command the first data byte will determine the command to be initiated. The second byte contains the parameters associated with that command. For commands which have no specific requirement for a parameter the second data byte should be set to 0x00.
For a read command, the first data byte represents the most significant byte of the result and the second data byte represents the least significant byte."
The command flow is also imaged below.
A command example that the datasheet has is:
"To retrieve the data that represent the status,the command 0x01 should be sent followed by 0x00."
I've been attempting to use this library here: http://blacklib.yigityuce.com/classBlackLib_1_1BlackI2C.html
So how exactly would I implement this code correctly. Unfortunately I won't be able to conduct hardware tests for a while. Would it look like something similar to this?(assuming slave address is already set up)
uint8_t command = 0x01;
unit8_t parameter = 0x00;
uint8_t buffer = {command, parameter}
myi2c.writeLine(buffer,sizeof(buffer));
uint16_t data_output = myi2c.readWord(command);
Is it that simple? Calling on the writeLine function to call to command and data parameter, the using readWord to read the 2 bytes being outputted while calling the 7 bit salve address (command in this case)?
I am new to gRPC framework, and I have created a sample client-server on my PC (referring to this).
In my client-server application I have implemented a simple RPC
service NameStudent {
rpc GetRoll(RollNo) returns (Details) {}
}
The client sends a RollNo and receives his/her details which are name, age, gender, parent name, and roll no.
message RollNo{
int32 roll = 1;
}
message Details {
string name = 1;
string gender = 2;
int32 age = 3;
string parent = 4;
RollNo rollid = 5;
}
The actual server and client codes are adaptation of the sample code explained here
Now my server is able to listen to "0.0.0.0:50051(address:port)" and client is able to send the roll no on "localhost:50051" and receive the details.
I want to see the actual binary data that is transferred between client and server. i have tried using Wireshark, but I don't understand what I am seeing here.
Here is the screenshot of wireshark capture
And here are the details of highlighted entry from above screenshot.
Need help in understanding wireshark here, Or any other way that can be used to see the binary data.
Wireshark uses the port to determine how to decode the communication, and it doesn't know any protocol associated with 50051. So you need to configure it to treat this as HTTP.
Right click on a row and select "Decode As..." in the context menu.
Then set "Current" to "HTTP" or "HTTP2" (HTTP will generally auto-detect HTTP2) and hit "OK".
Then the HTTP/2 frames should be decoded. And if using a recent version of Wireshark, you may also see the gRPC frames decoded.
The whole idea of grpc is to HIDE that. Let's say we ignore that and you know what you're doing.
Look at https://en.wikipedia.org/wiki/Protocol_Buffers. gRPC uses Protocol Buffers for it's data representation. You might get a hint at the data you're seeing.
Two good starting points for a reverse engineer exercise are:
Start simple: compile a program that sends an integer. Understand it. Sniff it. Then compile a program that sends a string. Try several values. Once you understand it, pass to tacke the problem of understanding how's google sending your structure.
Use known data and do small variations: knowing what 505249... means is easier if you start knowing the data you're sending (as an example, send "Hello world" string; then change it to "Hella world"; see what changes on the coded sniff; also check that sending several times the same data produces the same sniffed output). Apply prior point: start simple, first empty string, then " ", then "a", then "b", etc. and then pass to complex and larger strings. Don't be affraid to start simple.
Message format to send to server side as below :
package test;
message Test {
required int32 id = 1;
required string name = 2;
}
Server.cpp to do encoding :
string buffer;
test::Test original;
original.set_id(0);
original.set_name("original");
original.AppendToString(&buffer);
send(acceptfd,buffer.c_str(), buffer.size(),0);
By this send function it will send the data to client,i hope and i am not getting any error also for this particular code.
But my concern is like below:
How to decode using Google Protocol buffer for the above message in
the client side
So that i can see/print the message.
You should send more than just the protobuf message to be able to decode it on the client side.
A simple solution would be to send the value of buffer.size() over the socket as a 4-byte integer using network byte order, and the send the buffer itself.
The client should first read the buffer's size from the socket and convert it from network to host byte order. Let's denote the resulting value s. The client must then preallocate a buffer of size s and read s bytes from the socket into it. After that, just use MessageLite::ParseFromString to reconstruct your protobuf.
See here for more info on protobuf message methods.
Also, this document discourages the usage of required:
You should be very careful about marking fields as required. If at
some point you wish to stop writing or sending a required field, it
will be problematic to change the field to an optional field – old
readers will consider messages without this field to be incomplete and
may reject or drop them unintentionally. You should consider writing
application-specific custom validation routines for your buffers
instead. Some engineers at Google have come to the conclusion that
using required does more harm than good; they prefer to use only
optional and repeated. However, this view is not universal.
I am currently working on a project for school and have ran into an issue with a large amount of data being sent via Telnet. If I send a message less than 10KB it is fine. However if I send a message that is above 10KB, I receive the following error "501 Syntax error - line too long" after a few minutes of it running.
Does anyone know of a better way to implement what I am trying to accomplish, that will preferably work with the send()? The data being sent is 5 pages (in Word) of an image in base64.
Thank you, any help is greatly appreciated.
Here is the code portions that I am currently using, which work, with small amounts of data.
char *MailContents = new char[20000000];
std::ifstream in("C:\\test.txt");
std::string MailData((std::istreambuf_iterator<char(in)),std::istreambuf_iterator<char>());
//The following streams in the data into MailData() from a .txt file.
memcpy(MailContents, MailData.c_str(), MailData.length()); //This takes the data and copies it to MailContents
strcat(MailContents, "\r\n");
send(Connection, MailContents, strlen(MailContents), 0); //The following line will take the data in MailContents and echo it to the Telnet data section to be sent.
send(Connection, ".\r\n", strlen(".\r\n"), 0); //This line terminates the data entry and sends it.
I want to implement an progress bar in my C++ windows application when downloading a file using WinHTTP. Any idea how to do this? It looks as though the WinHttpSetStatusCallback is what I want to use, but I don't see what notification to look for... or how to get the "percent downloaded"...
Help!
Thanks!
Per the docs:
WINHTTP_CALLBACK_STATUS_DATA_AVAILABLE
Data is available to be retrieved with
WinHttpReadData. The
lpvStatusInformation parameter points
to a DWORD that contains the number of
bytes of data available. The
dwStatusInformationLength parameter
itself is 4 (the size of a DWORD).
and
WINHTTP_CALLBACK_STATUS_READ_COMPLETE
Data was successfully read from the
server. The lpvStatusInformation
parameter contains a pointer to the
buffer specified in the call to
WinHttpReadData. The
dwStatusInformationLength parameter
contains the number of bytes read.
There may be other relevant notifications, but these two seem to be the key ones. Getting "percent" is not necessarily trivial because you may not know how much data you're getting (not all downloads have content-length set...); you can get the headers with:
WINHTTP_CALLBACK_STATUS_HEADERS_AVAILABLE
The response header has been received
and is available with
WinHttpQueryHeaders. The
lpvStatusInformation parameter is
NULL.
and if Content-Length IS available then the percentage can be computed by keeping track of the total number of bytes at each "data available" notification, otherwise your guess is as good as mine;-).