Using objdump, how do you check if an .obj is little- or big-endian?
So if you run objdump -d <filename>, you should see at the top of the disassembled code a line that is in this format:
<filename>: file format (string that contains littlearm or bigarm)
I assume that littlearm implies little endian and bigarm implies big endian.
Simple approach is to use the file command that will give you the result what you expect.
$file your_object_file.obj
example output
$firmware.img: Linux jffs2 filesystem data little endian
Related
As a part of a larger program, written in the new Fortran standard, I am interested to write some text on a file that will be read by another program over which I have no control.
Long ago when I learned Fortran an output record generated by a format statement should begin with an LF (linefeed) and end with a CR (carriage return). This means that each output record should be separated by a sequence CRLF.
To my surprise I find that this seems no longer to be true except when I compile and run my program on a Windows computer. When I compile and run my program on a Mac the output records are separated by a single LF. I know this is a Linux standard but I guess I assumed the output from a Fortran program should not depend on the operating system.
The consequence of this is that when I generate the output on Windows my output file can be read by the other program (which only exists on Windows) whereas when I generate the same output on my Mac it fails.
I have no idea how the other program reads the file but I assume it is a standard Fortran read.
I have also compared my output file from Windows and Mac using "diff" and that indicates all lines are different. However "diff -w" indicates the files are identical.
I would like to be able to generate output that can be read by the other program independently if I generate the file on a Mac or Windows. I know I can use things like #ifdef to check the OS when I compile but I wonder if there is any other way, are there some option in the Fortran write? I know there are a lot of new things line "noadvance" etc. Any option to force a "CRLF" record separator?
I use GNU Fortran version 5.2 on Windows and what seems to be called version 7.2 on the Mac
According to the documentation, gfortran allows a peculiar flag for the OPEN statement, called CARRIAGECONTROL, as in:
program prg
integer :: u
open (newunit = u, file = 'test.txt', carriagecontrol = 'fortran')
write (u, '(A,I2)') '-', 12
write (u, '(A,I2)') '-', 34
close (u)
end program prg
This option is only supported when the code is compiled with the -fdec switch. The content of the output file is then:
> hexdump -C test.txt
00000000 0a 31 32 0d 0a 33 34 0d |.12..34.|
00000008
which is exactly the format that you described. The minus signs in the I/O lists in the above code are consumed by the compiler runtime library and used to redefine the output format. (Tested with gfortran 9.2.)
I'm wondering if there is a way to read data out of a .hex file at a given address using the srec tool family like srec_cat or srec_info. I know that I could parse the file by myself but there must be a tool out there already. Does anyone have already done something similar?
Today I found a solution using srec_cat to write only part of the hex file to a binary output file.
srec_cat.exe my.hex -intel -crop 0x08010000 0x08010040 -offset -0x08010000 -o out.bin -binary
The datasheet pointed out that is also possible to print the result to std:out. For me this is not working at all. Have no clue why.
Output filename [ format ] This option may be used to specify the
output file to be used. The special file name “−[rq] is understood to
mean the standard output. Output defaults to the standard output if
this option is not used.
What do I have to write to use this functionality:
srec_cat.exe my.hex -intel -crop 0x08010000 0x08010040 -offset -0x08010000 -o -[rq] -binary
Anyway the workaround with the file is working as expected. Without the file step would be a nice add on.
I have a script which is reading some data from one server and storing it in a file. But the file seems somehow corrupt. I can print it to the display, but checking the file with file produces
bash$ file -I filename
filename: text/plain; charset=unknown-8bit
Why is it telling me that the encoding is unknown? The first line of the file displays for me as
“The Galaxy A5 and A3 offer a beautifully crafted full metal unibody
A hex dump reveals that the first three bytes are 0xE2, 0x80, 0x9C followed by the regular ASCII text The Galaxy A5...
What's wrong? Why does file tell me the encoding is unknown, and what is it actually?
Based on the information in the question, the file is a perfectly good UTF-8 file. The first three bytes encode LEFT DOUBLE QUOTATION MARK (U+201C) aka a curly quote.
Maybe your version of file is really old.
You can use iconv to convert the file into the desired charset. E.G.
iconv --from-code=UTF8 --to-code=YOURTARGET
To get a list of supported targets, use the --list flag.
First off, I am not a Unix expert by any stretch, so please forgive a little naiveity in my question.
I have a requirement to list the unencrypted files in a given directory that potentially contains both encryped and unencrypted files.
I cannot reliably identify these files by file extension alone and was hoping someone in the SO community might be able to help me out.
I can run:
file * | egrep -w 'text|XML'
but that will only identify the files that are either text or XML. I could possibly use this if I can't do much better as currently the only other files in the directry are text or XML files but I really wanted to identify all unencrypted files whatever type they may be.
Is this possible in a single line command?
EDIT: the encrypted files are encrypted via openSSL
The command I use to unencrypt the files is:
openssl -d -aes128 -in <encrypted_filename> -out <unencrypted_filename>
Your problem is not a trivial one. The solaris file command uses "magic" - /etc/magic. This is a set of rules to attempt to attempt to determine what flavor a file is. It is not perfect.
If you read the /etc/magic file, note that the last column is verbiage that is in the output of the file command when it recognizes something, some structure in a file.
Basically the file command looks at the first few bytes of a file, just like the exec() family of system calls does. So, #/bin/sh in the very first line of a file, in the first characters of the line, identifies to exec() the "command interpreter" that exec() needs to invoke to "run" the file. file gets the same idea and says "command text" "awk text" etc.
Your issues are that you have to work out what types of files you are going to see as output from file. You need to spend time delving into the non-encrypted files to see what "answers" you can expect from file. Otherwise you can run file over the whole directory tree and sort out all of what you think are correct answers.
find /path/to/files -type f -exec file {} \; | nawk -F':' '!arr[$2]++' > outputfile
This gives you a list of distinct answers about what file thinks you have. Put the ones you like in a file, call it good.txt
find /path/to/files -type f -exec file {} \; > bigfile
nawk -F':' 'FILENAME=="good.txt" {arr$1]++}
FILENAME=="bigfile" {if($2 in arr) {print $1}} ' good.txt bigfile > nonencryptedfiles.txt
THIS IS NOT 100% guaranteed. file can be fooled.
The way to identify encrypted files is by the amount of randomness, or entropy, they contain. Files that are encrypted (or at least files that are encrypted well) should look random in the statistical sense. Files that contain unencrypted information—whether text, graphics, binary data, or machine code—are not statistically random.
A standard way to calculate randomness is with an autocorrelation function. You'd probably need to autocorrelate only the first few hundred bytes of each file, so the process can be fairly quick.
It's a hack, but you might be able to take advantage of one of the properties of compression algorithms: they work by removing randomness from data. Encrypted files cannot be compressed (or again, at least not much), so you might try compressing some portion of each file and comparing the compression ratios.
SO has several other questions about finding randomness or entropy, and many of them have good suggestions, like this one:
How can I determine the statistical randomness of a binary string?
Good luck!
I'm not very familiar using ruby with binary data. I'm using mechanize to download a large number of csv files to my local disk. I then need to search these files for specific strings.
I use the save_as method in mechanize to save the file (which saves the file as binary). The content type of the file (according to mechanize) is:
application/vnd.ms-excel;charset=x-UTF-16LE-BOM
From here, I'm not sure how to read the file. I've tried reading it in as a normal file in ruby, but I just get the binary data. I've also tried just using standard unix tools (strings/grep) to try and search without any luck.
When I run the 'file' command on one of the files, I get:
foo.csv: Little-endian UTF-16 Unicode Pascal program text, with very long lines, with CRLF, CR, LF line terminators
I can see the data just fine with cat or vi. With vi I also see some control characters.
I've also tried both the csv and fastercsv ruby libraries, but I get 'IllegalFormatError' exception for these. I've also tried this solution without any luck.
Any help would be greatly appreciated. Thanks.
You can use the command 'iconv' to conver to UTF-8,
# iconv -f 'UTF-16LE' -t 'UTF-8' bad_file.csv > good_file.csv
There is also a wrapper for iconv in the standard library, you could use that to convert the file after reading it into your program.