I have made android app that reads truck driver card (from tachograph) via otg smart card reader.
I can read all files on card from tree structure on image bellow.
But when I compare data that I read, and from some other public application, I have noticed that some files are fallowed by something that might be a key or signature
I do not know what underlined part represents nor how to read or generate it.
Without those "signatures" all data that I have is useless, but if I hard code those underlined parts (from other apps) in my ddd file, everything works fine
The most I have found is that
05 04 - Current usage Data
01 - means there is still a signature (gen 1)
00 80 - 0x0080 = 128 dec
Also I have read card certificate and ca certificate from card but didn't find is there any correlation with underlined part of problem.
Thanks to #nvf I found explication and solution in document
Part of responses .ddd that start with "01 00 80" represent digital signature of hash value on previously selected file.
To get digital signature you should select file, execute command to perform hash of file, and then execute command to get 128 bytes digital signature.
I used cantools python package to decode canbus message. I used a dbc file created by me for testing. I copied a sample file. When I use can id like 419358976, I get error. But for smaller can ids like 350, it works. Does cantools fail for extended frame ids? how do I get this working?
my code which is failing for extended id's is as follows:
db = cantools.database.load_file('.\\src\\test\\resources\\j1939.dbc')
print(db.decode_message(419358976,b'\xff\xff\xff\xc0\x0c\xff\xff\xff'))
error: cantools.database.errors.Error: Standard frame id 0x18fee900 is more than 11 bits in message EEC1.
I found the answer for my question. The can id like 419358976 is an extended id. So to map that id to the id in the dbc file, I need to add another 32 bit hex number 8000 0000 to the hex can id. Then convert that result hex number to decimal and use it as the id field in the dbc file. It works perfectly after. The above error message is gone after
why the length of Location Information is different? when I ask location info using PROVIDE LOCAL INFORMATION, the length of Location Information is 7 sometimes, and it is 9 sometimes. like this:
//Terminal Response
8014000015810301260002028281030106130764F01010D9286C; SW=910B
//Terminal Response
8014000017810301260002028281030106130964F010A05D3C49006D; SW=9000
can anyone tell me which spec to check?
ETSI TS 102 223 defines the Provide Local Information components. It mentions that the location information portion will be "Access technology specific" in section 8.19.
If we look at 3GPP TS 31.111 we see again in section 8.19 that location information could have length "09", "07", "05", "00". The note describe under which circumstances the different lengths are found.
Note 1
The Extended Cell Identity Value is not available in GERAN. When in GERAN,
this field shall not be present and the length field shall be set to ‘07’.
I believe when you are executing the provide local information query, you could at times be in a GSM, EDGE, UMTS or LTE zones and for each access technology the information is different.
Kind Regards,
I'm using this guide to the VEX prefix: http://wiki.osdev.org/X86-64_Instruction_Encoding#REX_prefix
I'm lost on how to encode actual VEX instructions though. The ADDPD instruction (Intel x64 page 459) Opcode looks like this: VEX.NDS.128.66.0F.WIG 58 /r
Ummm what?? The VEX guide doesn't say anything about 'NDS' or 'WIG'. What am I missing?
You're missing section 3.1.1.2 "Opcode Column in the Instruction Summary Table (Instructions with VEX prefix)" (page 64 in the manual I have on my PC, probably slightly different in other versions)
For this instance, the important parts are:
VEX (obviously) means there is a VEX prefix.
NDS, the VEX.vvvv field specifies a register (it doesn't always, sometimes it is unused and must be set to all ones) and that it is a read-only first source operand.
128 fairly obvious, it's the 128bit wide version
55, it doesn't say that, it says 66 or at least it should. Other choices are F2, F3, and "nothing". Indicates what the values of the VEX.pp field should be, corresponds to mandatory prefix in the old encoding.
0F, opcode map specifier, corresponds to 0F prefix in the old encoding (there are also 0F3A and 0F38)
WIG (other options are W1 and W0), means the VEX.W field is ignored (W0 and W1 mean the W bit must be respectively 0 or 1)
I am trying to understand the EXIF header portion of a jpeg file (in hex) and how to understand it so I can extract data, specifically GPS information. For better or worse, I am using VB.Net 2008 (sorry, it is what I can grasp right now). I have extracted the first 64K of a jpg to a byte array and have a vague idea of how the data is arranged. Using the EXIF specification documents, version 2.2 and 2.3, I see that there are tags, that are supposed to correspond to actual byte sequences in the file. I see that there is a “GPS IFD” that has a value of 8825 (in hex). I search for the hex string 8825 in the file (which I understand to be two bytes 88 and 25) and then I believe that there is a sequence of bytes following the 8825. I suspect that those subsequent bytes denote where in the file, by way of an offset, the GPS data would be located. For example, I have the following hex bytes, starting with 88 25: 88 25 00 04 00 00 00 01 00 00 05 9A 00 00 07 14. Is the string that I am looking for longer than 16 bytes? I get the impression that in this string of data, it should be telling me where to find the actual GPS data in the file.
Looking at http://search.cpan.org/~bettelli/Image-MetaData-JPEG-0.153/lib/Image/MetaData/JPEG/Structures.pod#Exif_and_DCT, halfway down the page, it talks about “Each IFD block is a structured sequence of records, called, in the Exif jargon, Interoperability arrays. The beginning of the 0th IFD is given by the 'IFD0_Pointer' value. The structure of an IFD is the following:”
So, what is an IFD0_Pointer? Does it have to do with an offset? I presume an offset is so many bytes from a beginning point. If that is true, where is that beginning point?
Thanks for any responses.
Dale
I suggest you to read The Exif Specification (PDF); it is clear and quite easy to follow. For a short primer, here is the summary of an article I wrote:
A JPEG/Exif file starts with the start of the image marker (SOI). The SOI consists of two magic bytes 0xFF 0xD8, identifying the file as a JPEG file. Following the SOI, there are a number of Application Marker sections (APP0, APP1, APP2, APP3, ...) typically including metadata.
Application Marker Sections
Each APPn section starts with a marker. For the APP0 section, the marker is 0xFF 0xE0, for the APP1 section 0xFF 0xE1, and so on. Marker bytes are followed by two bytes for the size of the section (excluding the marker, including the size bytes). The length field is followed by variable size application data. APPn sections are sequential, so that you can skip entire sections (by using the section size) until you reach the one you are interested in. Contents of APPn sections vary, the following is for the Exif APP1 section only.
The Exif APP1 Section
Exif metadata is stored in an APP1 section (there may be more than one APP1 section). The application data in an Exif APP1 section consists of the Exif marker 0x45 0x78 0x69 0x66 0x00 0x00 ("Exif\0\0"), the TIFF header and a number of Image File Directory (IFD) sections.
The TIFF Header
The TIFF header contains information about the byte-order of IFD sections and a pointer to the 0th IFD. The first two bytes are 0x49 0x49 (II for Intel) if the byte-order is little-endian or 0x4D 0x4D (MM for Motorola) for big-endian. The following two bytes are magic bytes 0x00 0x2A (42 ;)). And the following four important bytes will tell you the offset to the 0th IFD from the start of the TIFF header.
Important: The JPEG file itself (what you have been reading until now) will always be in big-endian format. However, the byte-order of IFD subsections may be different, and need to be converted (you know the byte-order from the TIFF header above).
Image File Directories
Once you get this far, you have your pointer to the 0th IFD section and you are ready to read actual metadata. The remaining IFDs are referenced in different places. The offset to the Exif IFD and the GPS IFD are given in the 0th IFD fields. The offset to the first IFD is given after the 0th IFD fields. The offset to the Interoperability IFD is given in the Exif IFD.
IFDs are simply sequential records of metadata fields. The field count is given in the first two bytes of the IFD. Following the field count are 12-byte fields. Following the fields, there is a 4 byte offset from the start of the TIFF header to the start of the first IFD. This value is meaningful for only the 0th IFD. Following this, there is the IFD data section.
IFD Fields
Fields are 12-byte subsections of IFD sections. The first two-bytes of each field give the tag ID as defined in the Exif standard. The next two bytes give the type of the field data. You will have 1 for byte, 2 for ascii, 3 for short (uint16), 4 for long (uint32), etc. Check the Exif Specification for the complete list.
The following four bytes may be a little confusing. For byte arrays (ascii and undefined types), the byte length of the array is given. For example, for the Ascii string: "Exif", the count will be 5 including the null terminator. For other types, this is the number of field components (eg. 4 shorts, 3 rationals).
Following the count, we have the 4-byte field value. However, if the length of the field data exceeds 4 bytes, it will be stored in the IFD Data section instead. In this case, this value will be the offset from the start of the TIFF header to the start of the field data. For example, for a long (uint32, 4 bytes), this will be the field value. For a rational (2 x uint32, 8 bytes), this will be an offset to the 8-byte field data.
This is basically how metadata is arranged in a JPEG/Exif file. There are a few caveats to keep in mind (remember to convert the byte-order as needed, offsets are from the start of TIFF header, jump to data sections to read long fields, ...) but the format is quite easy to read. Following is the color-coded HEX view of a JPEG/Exif file. The blue block represents the SOI, orange is the TIFF header, green is the IFD size and offset bytes, light purple blocks are IFD fields and dark purple blocks are field data.
Here is a php script I wrote to modify exif headers.
<?php
$full_image_string=file_get_contents("torby.jpg");
$filename="torby.jpg";
if (isset($_REQUEST['filename'])){$filename=$_REQUEST['filename'];}
if (array_key_exists('file', $_REQUEST)) {
$thumb_image = exif_thumbnail($_REQUEST['file'], $width, $height, $type);
} else {
$thumb_image = exif_thumbnail($filename, $width, $height, $type);
}
if ($thumb_image!==false) {
echo $thumb_image;
$thumblen=strlen($thumb_image);
echo substr_count($full_image_string,$thumb_image);
$filler=str_pad("%%%THUMB%%%", $thumblen);
$full_image_string=str_replace($thumb_image,$filler,$full_image_string);
file_put_contents("torby.jpg",$full_image_string);
exit;
} else {
// no thumbnail available, handle the error here
echo 'No thumbnail available';
}
?>