I am using gnu gcc and armcc to compile a few C files. How can I get the information about which compiler compiled which file?
Ex: test.cpp is being compiled by armcc or gnu gcc.
The makefile is very complicated and I am looking out for a command by which I can check which compiler compiled which file.
Any ideas?
Sometimes you can look at the file with a hex editor and tell if the compiler wrote its name into the file.
I'm not sure if there's an easier way, but you can find it embedded in the binary with gcc (at least on my platform):
$ hexdump -C foo | grep -A2 GCC
00001030 00 00 00 00 00 00 00 00 47 43 43 3a 20 28 55 62 |........GCC: (Ub|
00001040 75 6e 74 75 2f 4c 69 6e 61 72 6f 20 34 2e 37 2e |untu/Linaro 4.7.|
00001050 32 2d 32 32 75 62 75 6e 74 75 33 29 20 34 2e 37 |2-22ubuntu3) 4.7|
Some compiler embedd compiler name and version in to the binrary, but not all. We can also embedd whatever information we want into the binary.
gcc -DCOMPILER_DETAILS='"gcc 4.3.3"' temp.c
In temp.c use the macro COMPILER_DETAILS in any place, like just use it in printf. So that this string literal will be embedd in the generated binary file. Dont assign this string to unused variable, compiler will not embedd because of optimization.
Related
I am supposed to recreate the behavior of hexdump in C and now when I (almost) finished the task, the actual hexdump command behaves weird.
When I use:
hexdump -C filename1 notexistingfilename2
the error message for the non existing file appears between the lines of the output of the first file.
like this:
0000c4f0 65 00 64 79 6c 64 5f 73 74 75 62 5f 62 69 6e 64 |e.dyld_stub_bind|
0000c500 65 72 00 5f 5f 64 79 6c 64 5f 70 72 69 76 61 74 |er.__dyld_privat|
hexdump: h: No such file or directory
0000c510 65 00 00 00 00 00 00 00 |e.......|
0000c518
h being the non existing file.
This wasn't the case when I used hexdump earlier today. (System is MacOS and the behavior is the same in Bash aswell as in zsh, also not using the -C flag doesn't make a difference).
I'd like colorize my u-boot bootcmd so it prints a breathtaking error message. Normally I'd just use ANSI escape sequences such as below.
#!/bin/bash
printf '\x1b[31mERROR\33[0m'
#!/usr/bin/env python
print("\x1b[31mERROR\33[0m")
How can get equivalent behavior in u-boot? It seems u-boot will just remove the backslash such as below
# u-boot shell
echo \33[31m # prints "33[31m"
echo \x1b[31m # prints "x1b[31m"
On a bash console you can use CTRL-V to enter a control character verbatim. This is not supported by U-Boot yet. But I have submitted a patch to enable this, cf. https://patchwork.ozlabs.org/project/uboot/list/?series=152686.
U-Boot's echo command does not know '\x' escape sequences but copies an escape character verbatim to the console.
So this is what you can do:
Create a script test.txt with your echo commands which contains the escape sequences.
echo -e 'echo \e[33mError\e[37m\necho \e[32mWarning\e[37m' > test.txt
I show it below in hexadecimal format so it becomes obvious what is in the file:
00000000 65 63 68 6F 20 1B 5B 33 33 6D 45 72 echo .[33mEr
0000000C 72 6F 72 1B 5B 33 37 6D 0A 65 63 68 ror.[37m.ech
00000018 6F 20 1B 5B 33 32 6D 57 61 72 6E 69 o .[32mWarni
00000024 6E 67 1B 5B 33 37 6D 0A ng.[37m.
Convert this to a U-Boot image
mkimage -T script -n 'test' -d test.txt test.scr
In U-Boot load the script. I did this using tFTP:
dhcp $script_addr_r test.scr
Now you can execute the script
source $script_addr_r
When U-Boot is build with CONFIG_DISTRO_DEFAULTS=y it will look for scripts boot.scr.uimg and boot.scr on your boot device. So this is probably where you want to integrate the escape sequences.
As in the subject. I'm wondering if it is possible to get encrypted bytes like below when using AES128 CBC:
7b 22 63 6d 64 22 3a 22 73 65 74 41 70 22 2c 22
73 63 6f 22 2c 22 70 61 00 73 22 3a 22 70 61 73
73 77 6f 72 64 22 7d 00 00 00 00 00 00 00 00 00
Note the NULL byte in the second row.
EDIT: A bit of background behind this question.
I have a C function that takes my buffer and plain text (utf8) after calling it I need to know who much of the buffer was filled up.
Yes, any byte value is possible including 0.
The implied question here is "can I use string handling functions on encrypted data". You cannot because 0 is a valid value. You need to keep track of the number of bytes in the encrypted data.
I've come to work with a strange database file format.
Each DB comes with two files: one is "database.db" and the other is "database.key".
The ".db" file always starts with a 0x78 0x9C binary header, while the ".key" always contains, in a random part of the file, the string "1.00 Peter's B Tree" inside.
Looking online I found that the header 0x78 0x9C could refer to compression Zlib, but have not found any way to view the contents of the database.
Does anyone here know something that could help me with this format ? Thnaks :)
Edit 1:
It appears that the ".db" file contains more than one zlib deflated streams:
The signature 0x78 0x9C is not only present at the beginning of the file but in different parts of it.
Fo example this are some of the streams i can find in one file:
78 9C CB 63 40 07 33 76 5B 6A AF 78 DD 54 23 CE C9 90 C4 78 89 81 89 81 F1 22 86 9A ED 6A D7 44 F6 03 D5 B0 31 30 94 60 91 F6 D4 2A 76 3B 0C 94 E6 63 60 2C 51 B6 63 00 00 22 13 11 57
78 9C CB 63 40 07 2F 53 D7 B8 9F EC 8B B2 E1 7A F1 32 87 F1 12 03 23 03 E3 45 0C 35 4B B7 68 5B CD 90 2E E7 65 67 60 2A 51 B6 63 00 00 A6 E8 0C 5D
By inflating thoose 2 streams i get 2 new uncompressed streams.
What i did then is a C# program that loaded a ".db" file and created a list of byte arrays; a byte array is a deflated stream.
To do this I simply split the file at every 78 9C.
This seems to work with some of the ".db" files but, in other situations it gave me some errors like "Invalid distance code", with this stream
78 9C E2 13 FD 2F 14 9F CD 9B 29 3E 65 9F A0 F8 BC 7C 92 E2 93 EF 29 8A CF B0 A7 29 3E 8D FE 4A F1 B9 F2 0C C5 27 C4 B3 14 EF F5 5B 28 DE B5 B7 52 BC FF 6E A3 78 27 DD 4E F1 9E B8 83 E2 DD 6D 27 C5 FB D4 2E FA F0 6A EE A6 78 EF 78 EE EA 2F AA D3 91 FE 1F 2F 94 78 6C
or "Invalid stored block lenght", with this stream
78 9C 90 35 CE 34 2F 0C 7D FE A5 57 C9 FF D5 2B 47 5B B7 C4 7F 69 EA 3F 0F AC 25 F4 45 49 3D CC FF 00 E5 AE 30 40
Maybe simply splitting the file at each 78 9C is not the correct way of doing it ...
As for the ".key" files: I was able to open them using the library of Peter Graf "PBL".
With the "pblKfGetAbs ()" (http://www.mission-base.com/peter/source/pbl/doc/keyfile.html) I managed to get all records related to each key in the file. These records are of 4-byte values.
Searching for these values on a decompressed ".db" file (In a file that did not give me errors during the inflate process) with an hex editor I was able to get some results but nothing more. I don't understand wat thoose records on the key file means...
Thank you for the help !
Yes, those are very likely zlib streams stored in the database.
There is nothing keeping 78 9c from appearing in the compressed data, so simply searching for that is not a good way to extract the contents of the file. Also 78 9c is not the only valid zlib header. The easiest way to find the valid zlib streams is to simply start decompressing at every byte. zlib will very quickly rule out most as not having a valid zlib header. For the rest you can decompress until it completes or fails. If it completes with a good integrity check (returning Z_STREAM_END), then it is extremely likely that that was an intentional compressed zlib stream.
You are trying to reverse-engineer a data base format with what appears to be relatively little to go on. This is a detective job that stackoverflow can't help with, unless someone here knows the format and recognizes it.
These are zlib magic headers widely used by different utilities (such as Git, Memcached, etc).
To uncompress the file, you can use the following command:
printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" | cat - zlib-file.dump | gunzip
To skip some bytes before, use dd, e.g.
cat <(printf "\x1f\x8b\x08\x00\x00\x00\x00\x00") <(dd skip=100 if=zlib-file.dump bs=1 of=/dev/stdout) | gunzip
If the data got crc/length error, consider as faulty.
the .db files are compressed data , the .key files are key_informations to find the wanted data in those .db (like an index file) after you open them,you may not find string data in those .db files,because they are a runtime databases, these .db files containt hex data like 'packets'and they are compressed as he said
78 9C is the zlib magic headers with Default Compression.
Try Aluigi's offzip commandline tool to extract the data.
Don't ask where and why I got it, but I have a lot of lines like these in .c file:
0005080: 3465 3434 2035 6635 6620 2064 6c65 2e5f 4e44 5f5f dle._
0005090: 5f44 544f 525f 454e 445f 5f0a 3030 3031 _DTOR_END__.0001
00050a0: 3334 303a 2030 3035 6620 3566 3663 2036 340: 005f 5f6c 6
00050b0: 3936 3220 3633 3566 2036 3337 3320 3735 962 635f 6373 75
00050c0: 3566 2036 3936 6520 3639 3734 2020 2e5f 5f 696e 6974 ._
00050d0: 5f6c 6962 635f 6373 755f 696e 6974 0a30 _libc_csu_init.0
What can I do with it? Is this a program?
That's not a C file. That's not a C file at all!
What appears to have happened here is that someone flipped some parameters trying to compile a file; something like gcc -o my_file.c my_file.c, or something to that effect.
If you're on Linux, you can run the file utility to figure out what it is.
Note:
This might well also be a piece of malware: The enterprising would-be attacker sent you the file, hoping you would double-click it in the file manager, causing it to execute and do something nasty.
Edit:
Also, is that the literal content of the file, or the file as seen through xxd? If it's the former, it's more likely a mistake of some kind; but if it's the latter: Beware.
This looks like the output of the hexdump command.
If you have a file temp.c with the following code:
#include<stdio.h>
int main()
{
printf("Hello World!\n");
return 0;
}
Then, hexdump -C temp.c will produce the output as:
00000000 23 69 6e 63 6c 75 64 65 3c 73 74 64 69 6f 2e 68 |#include<stdio.h|
00000010 3e 0a 69 6e 74 20 6d 61 69 6e 28 29 0a 7b 0a 09 |>.int main().{..|
00000020 70 72 69 6e 74 66 28 22 48 65 6c 6c 6f 20 57 6f |printf("Hello Wo|
00000030 72 6c 64 21 5c 6e 22 29 3b 0a 09 72 65 74 75 72 |rld!\n");..retur|
00000040 6e 20 30 3b 0a 7d 0a |n 0;.}.|
00000047
The last few lines of the compiled output file (a.out generally) for the above program reads:
\00__data_start\00__gmon_start__\00__dso_handle\00_IO_stdin_used\00__libc_csu_init\00_end\00_start\00__bss_start\00main\00_Jv_RegisterClasses\00__TMC_END__\00_ITM_registerTMCloneTable\00_init\00
In your case, it looks like the hexdump (or a similar) command was used on an a.out (i.e. object code file) file and those are the last few lines of the output.
Good luck!