I'am new in read binary files, sorry for mistakes. I have a problem with read ELF header with bless editor. First I read first 4 bytes and I do this. First 4 bytes tells it's ELF file or not
and this is ok for me. Next I want read 0x04 address wikipedia says about this address This byte is set to either 1 or 2 to signify 32- or 64-bit format, respectively. and where can I find this address on my screen?
Related
I've been working on an RFID project to produce our own RFID cards to work on our existing timeclocks and readers.
I've got most of the work done, and have been able to successfully write a Hitag2 card using the value of page 4 & 5 from another card (so basically copying the card) then changing the config bit which makes it act like an EM4x02 which allows our readers to read it.
What I'm struggling with is trying to relate the hex code on page4/5 to the output you get when scanning as an EM4x..
The values of the hitag page 4/5 are FF800000/003EDF10. This translates to 0000001EBC when read as an EM4x.
Does anybody have an idea on how this translation is done? I've tried using the methods in RFIDIOT but that doesn't seem to work for this.
I've managed to find how this is done after finding a hitag2 datasheet from 1999 (the only one I could find that explains the bits when hitag is in public mode A)
Firstly, convert the number you want on the EM4 card to hex.
Convert that hex into binary.
Split the binary into 4 bit chunks, then work out the even parity for each section and add it to the end of each chunk. (So you'll end up with 5 bits per chunk)
Then, work out the even parity of each column in the data (i.e first character of all chunks, then second etc. But ignoring the parity bit you added) and add these 4 bytes to the binary string.
Then add the correct amount of zeros at the start to ensure the data section has 50 bits.
Once you have the data section sorted, add 9 bits of 1 to the beginning (header) and a final 0 to the very end of the binary.
Your whole binary string should be 64 bits long.
Convert this to hex and split it in half. You can then write these onto pages 4/5 of a Hitag2 card.
You then need to change the configuration bit to 0x02 for the tag to work in public mode a.
Just thought I would send you the diagram of how this works.Em4X tag data
I've got a bunch of files that from metadata I can tell are supposed to be PDFs. Some of them are indeed complete PDFs. Some of them appear to be the first part of a PDF file, though they lack the %%EOF and other footer values.
Others appear to be the last part of PDF files (they don't have any of a PDF's headers but they do have the %%EOF stuff). Curiously they start with the following 16-byte magic header:
0x50, 0x4B, 0x57, 0x41, 0x52, 0x45, 0x00, 0x00, 0x00, 0x00, 0x00, 0x57, 0x49, 0x4E, 0x33, 0x32 (PKWARE WIN32).
I'm doing a lot of inference which could possibly be misleading, but it doesn't seem to be a compression scheme (the %%EOF stuff is plaintext) and in the few files I've been allowed to look at deeply there's a correlation between starting with this magic and looking like the final segment of a PDF binary.
Does anyone have any hints as to what file format might be at play here?
Update: I've now observed this PKWARE WIN32 happening on non-PDF files as well. Speculation also suggests that these files are split up in a similar manner.
Update 2: It turns out this PKWARE WIN32 header actually occurs in repeating intervals, the location of which can be predicted by some bytes immediately prior to the header.
I've also received some circumstantial hearsay which suggests that these files are compressed and not split into multiple parts, though in 2 out of the 3 cases where I was told the output file sizes my binaries were only negligibly smaller.
The mystery continues.
Okay, so this ended up being a very strange format. Overall it's a compression scheme, but it's applied inconsistently and lightly wrapped in a way that confounded the issue.
The first 8 bytes of any of these files will start with its own magic, and the next 8 bytes can be read as a long to tell us the final size of the output file.
Then there's a 16 byte "section" (four ints) whose first number is just an incremental counter, whose second int represents the number of bytes until the next "section" break, whose third int is a bit of a mystery to me, and whose fourth int is either 0 or 1. If that int is 0, just read the next (however many) bytes as-is. They're payload.
If it's 1 then you'll get one of these PKWARE headers next. I honestly know how to interpret them the least-well other than they start with the magic in the original question and they're 42 bytes long in total.
If you had a PKWARE header, subtract 42 from the number of bytes to read then treat the remaining bytes as compressed using PKWARE's "implode" algorithm. Meaning you can use zlib's "explode" implementation to decompress them.
Iterate through the file taking all these headers into account and cobbling together compressed and uncompressed parts 'til you run out of bytes and you'll end up with your output file.
I have no idea why only parts of files are compressed nor why they've been broken into blocks like this but it seems to work for the limited sample data I have. Perhaps later on I'll find files that actually have been split up along those boundaries or employ some kind of fancy deduplication but at least now I can explain why it looked like I saw partial PDFs -- the files were only partially compressed.
My first exposure to the ELF format binary began less than 2 weeks ago; please excuse the crudeness of my grasp of them (and of course, correction of any misconceptions I display here would be welcome).
The story so far: I have some GCN binaries which I am trying to fully reverse engineer so that I might be able to generate my own with a higher degree of control (i.e. limiting the number of intermediate steps executed by code not my own and not entirely within my understanding). What I've found from some resources online and my own delving is that each binary contains two ELF structures; the first is fairly small, containing three sections (no program headers) named "", ".shstrtab", and ".ddiPipelineHeader".
The ".ddiPipelineHeader" section size is 48 bytes, with the byte 0 being a 1, and bytes 16-19 containing what appears to be a 32bit integer that corresponds to the number of bytes in the binary from the start of the second ELF structure. All the other bytes in this section are 0. A google search of ".ddiPipelineHeader" returned exactly 1 result which I didn't find useful. Before I run off all half-cocked into dangerous, crashy GPU experimentation-land, does this section's structure sound at all familiar? Is there possibly an explanation of what each byte would do (e.g. bytes 4-15 are 0 padding, etc. etc.)?
I also have all the sections contained in the second ELF to ask about, but I figure I'll be able to delve more deeply into those with a better foundation gleaned here, so I'll hold off on that part for now.
Thanks for any insight!
I am creating an AIR app that receives PNG data over the socket and they come in in chunks. How do I know when a byte received is the last byte?
You could decode it as it comes in, continuing until you reach the IEND chunk which marks the end of the png. All you need to do is read the 4 byte length and 4 byte chunk type and then skip ahead length+4 bytes, continuing until the chunk type == IEND. Check out the chunk specification for more info.
http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html
I have an html form in which users upload either binary or ascii stl files. However I want to make sure only valid binary and ascii files are uploaded.Such that if a user changes the extension of say a PDF file to .stl (extension for 3D binary and ascii stl files), the code must detect that its an invalid stl file.
Quoting wikipedia:
An ASCII STL file begins with the line:
`solid name`
where name is an optional string (though if name is omitted there must still be a space after solid).
So, to confirm an ASCII STL, check for '^solid (name)?$' on the first line.
To determine if the file is binary STL, take advantage of the length field at offset 80. It specifies the number of triangles in the file.
So, to confirm a Binary STL file, check for this expression:
filesize == UINT32#80 * 50 + 84
Number 84 here is the total size of binary STL header (80 bytes) and a 4-byte number (number of triangles) following the header.