Strange .C file - c

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!

Related

Weird behavior of hexdump on MacOS

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).

How do you write the hexdump -C function in C?

The first block of code below is an example of how I want my output to look like when I run my hexdump command in C. Atm, I don't know how to get the 3 columns of double spaces and I don't know how to add the ASCII representation and "." for non-ASCII of the bytes on the right.
hexdump -C /etc/passwd
00000000 72 6f 6f 74 3a 78 3a 30 3a 30 3a 72 6f 6f 74 3a |root:x:0:0:root:|
00000010 2f 72 6f 6f 74 3a 2f 62 69 6e 2f 62 61 73 68 0a |/root:/bin/bash.|
00000020 64 61 65 6d 6f 6e 3a 78 3a 31 3a 31 3a 64 61 65 |daemon:x:1:1:dae|
00000030 6d 6f 6e 3a 2f 75 73 72 2f 73 62 69 6e 3a 2f 62 |mon:/usr/sbin:/b|
00000040 69 6e 2f 73 68 0a 62 69 6e 3a 78 3a 32 3a 32 3a |in/sh.bin:x:2:2:|
00000050 62 69 6e 3a 2f 62 69 6e 3a 2f 62 69 6e 2f 73 68 |bin:/bin:/bin/sh|
This is my actual output:
00000000 2f 2a 20 68 65 6c 6c 6f 2e 63 20 2a 2f a. a. 23
00000010 69 6e 63 6c 75 64 65 20 3c 73 74 64 69 6f 2e 68
00000020 3e a. a. 69 6e 74 20 6d 61 69 6e 28 69 6e 74 20
00000030 61 72 67 63 2c 20 63 68 61 72 20 2a 61 72 67 76
00000040 5b 5d 29 a. 7b a. 20 20 70 75 74 73 28 22 48 65
00000050 6c 6c 6f 20 77 6f 72 6c 64 21 5c 6e 22 29 3b a.
00000060 20 20 72 65 74 75 72 6e 20 30 3b a. 7d a.
0000006e
thanks
I don't know how to get the 3 columns of double spaces
Just emit an extra space in the appropriate place.
The first one (between the offset and the first octet) is always there.
The second one is emitted before the 8th octet if there is one.
The third one is also always there.
You can either build them into a format string or bake them into your octet-formatting loop.
I don't know how to add the ASCII representation and "." for non-ASCII of the bytes on the right
Roughly, by using isprint() and then printing toprint instead of the raw character
char toprint = isprint(raw) ? raw : '.';

The first letter is being repeated of the first word

I am reading text from a file and outputting it as binary. I have modified the binary conversion as per follows:
Each capital letter shall start with 01 and will be followed by 5 bits.
The 5 bits shall hold the value of the letter.
The letters will have the value as A-2,B-3,C-4,D-5...
For example: HI-> (0101001)(0101010)
My code snippet is as follows:
void printinbits(int n)
{
for (int c = 4; c >= 0; c--)
{
long int k = n >> c;
if (k & 1)
printf("1");
else
printf("0");
}
}
int main()
{
//first letter is being repeated
char check[200];
FILE*fin= fopen("/Users/priya/Desktop/test.txt.rtf","r");
while((fscanf(fin,"%199s",check))==1)
{
for(int i=0;i<strlen(check);++i)
{
if(check[i]>=65&&check[i]<=90)
{
printf("01");
int n=check[i];
n-=63;
printinbits(n);
}
}
}
return 0;
}
My input->
HELLO
My output->
(0101001)(0101001)(0100110)(0101101)(0101101)(0110000)
(As you can see, the first letter H is being repeated)(Various letters are separated by brackets)
Here's a hex dump of a file hello.rtf containing the word HELLO in upper case. It was generated by TextEdit on a Mac.
0x0000: 7B 5C 72 74 66 31 5C 61 6E 73 69 5C 61 6E 73 69 {\rtf1\ansi\ansi
0x0010: 63 70 67 31 32 35 32 5C 63 6F 63 6F 61 72 74 66 cpg1252\cocoartf
0x0020: 31 34 30 34 5C 63 6F 63 6F 61 73 75 62 72 74 66 1404\cocoasubrtf
0x0030: 34 36 30 0A 7B 5C 66 6F 6E 74 74 62 6C 5C 66 30 460.{\fonttbl\f0
0x0040: 5C 66 73 77 69 73 73 5C 66 63 68 61 72 73 65 74 \fswiss\fcharset
0x0050: 30 20 48 65 6C 76 65 74 69 63 61 3B 7D 0A 7B 5C 0 Helvetica;}.{\
0x0060: 63 6F 6C 6F 72 74 62 6C 3B 5C 72 65 64 32 35 35 colortbl;\red255
0x0070: 5C 67 72 65 65 6E 32 35 35 5C 62 6C 75 65 32 35 \green255\blue25
0x0080: 35 3B 7D 0A 5C 6D 61 72 67 6C 31 34 34 30 5C 6D 5;}.\margl1440\m
0x0090: 61 72 67 72 31 34 34 30 5C 76 69 65 77 77 31 30 argr1440\vieww10
0x00A0: 38 30 30 5C 76 69 65 77 68 38 34 30 30 5C 76 69 800\viewh8400\vi
0x00B0: 65 77 6B 69 6E 64 30 0A 5C 70 61 72 64 5C 74 78 ewkind0.\pard\tx
0x00C0: 37 32 30 5C 74 78 31 34 34 30 5C 74 78 32 31 36 720\tx1440\tx216
0x00D0: 30 5C 74 78 32 38 38 30 5C 74 78 33 36 30 30 5C 0\tx2880\tx3600\
0x00E0: 74 78 34 33 32 30 5C 74 78 35 30 34 30 5C 74 78 tx4320\tx5040\tx
0x00F0: 35 37 36 30 5C 74 78 36 34 38 30 5C 74 78 37 32 5760\tx6480\tx72
0x0100: 30 30 5C 74 78 37 39 32 30 5C 74 78 38 36 34 30 00\tx7920\tx8640
0x0110: 5C 70 61 72 64 69 72 6E 61 74 75 72 61 6C 5C 70 \pardirnatural\p
0x0120: 61 72 74 69 67 68 74 65 6E 66 61 63 74 6F 72 30 artightenfactor0
0x0130: 0A 0A 5C 66 30 5C 66 73 32 34 20 5C 63 66 30 20 ..\f0\fs24 \cf0
0x0140: 48 45 4C 4C 4F 7D HELLO}
0x0146:
You may or may not be able to see the H of 'Helvetica' as the only other capital letter in the file — that would account for producing the output for HHELLO. It looks like you might be on a Mac too, so maybe you'd see the same result — or, at least, an equivalent one. (I used a homebrew hex dump program; you'd probably use xxd -g 1 test.txt.rtf, which would produce the hex with lower-case letters, and wouldn't include the final byte count line.)
You could, and should, print the data that your program reads in the loop, at least while debugging it, so that you can see what the program is processing. This is a very basic debugging technique.
In TextEdit, you can switch between rich text and plain text with the 'Make Plain Text' or 'Make Rich Text' option under the Format menu, or using ⇧⌘T (shift command T) to toggle between the two modes. Note how the file name changes as you do that.
Community Wiki since M Oehm pointed out the likely problem.

How can i export file from wireshark to display not in hex format

Im tring to export file from wireshark , so i could search in it.
now every option i try doesn't give simple raw format as the tcp raw view , when i follow
tcp stream .
all it gives me is hex view of the packets and the string in this kind of format breaks and can't be searchable . i want it to export to searchable format.
can it be done ?
this is what im getting now :
0000 48 54 54 50 2f 31 2e 31 20 35 30 30 20 49 6e 74 HTTP/1.1 500 Int
0010 65 72 6e 61 6c 20 53 65 72 76 65 72 20 45 72 72 ernal Server Err
0020 6f 72 0d 0a 44 61 74 65 3a 20 54 68 75 2c 20 31 or..Date: Thu, 1
0030 30 20 4e 6f 76 20 32 30 31 31 20 31 36 3a 33 32 0 Nov 2011 16:32
0040 3a 35 37 20 47 4d 54 0d 0a 50 72 61 67 6d 61 3a :57 GMT..Pragma:
0050 20 6e 6f 2d 63 61 63 68 65 0d 0a 43 6f 6e 74 65 no-cache..Conte
What about using TShark, sed and tr?
tshark -r Clmt_04.pcap -x -R "frame.number<40" | sed 's/^.{56}//' | tr -d '\n' > Clmt-04.txt
tshark -x
add output of hex and ASCII dump (Packet Bytes)
sed 's/^.{56}//'
remove the first 56 characters of each line
tr -d '\n'
remove new line character
Hope this helps
After you identify the tcp stream, you can use the following command with tshark:
tshark -nr <file>.pcapng -q -z follow,tcp,ascii,XXXX
Where XXXX is the tcp stream.

Error when loading valid Windows-1252 document "System error: -2146697210"

Somehow, sometimes the code below generates an error when loading valid Windows-1252 XML.
It fails on Windows XP Professional x86 SP3 using MSXML6.
It succeeds on Windows 7 Ultimate x64 SP1 using MSXML6.
Note: the code below is written in Delphi, but equivalent code also fails in other environments.
procedure TXMLEOSErrorTestCase.Test;
var
XmlDocument: IXMLDOMDocument3;
XmlFileName: string;
begin
XmlDocument := CoFreeThreadedDOMDocument60.Create();
XmlFileName := TPath.Combine(TPath.GetDirectoryName(ParamStr(0)), '1-Normal.xml');
if not XmlDocument.load(XmlFileName) then
Parse(XmlDocument.parseError);
end;
This error occurs during the XmlDocument.load method:
reason: System error: -2146697210.
errorCode: -2146697210
url: C:\temp\1-Normal.xml
I trimmed the XML down to the XML found below.
This is the hex dump of the XML file:
000000: 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E 20 3D 20 <?xml version =
000010: 22 31 2E 30 22 20 65 6E 63 6F 64 69 6E 67 3D 22 "1.0" encoding="
000020: 57 69 6E 64 6F 77 73 2D 31 32 35 32 22 3F 3E 3C Windows-1252"?><
000030: 52 4F 57 20 43 69 74 79 3D 22 E0 22 2F 3E 0D 0A ROW City="."/>..
This is the XML:
<?xml version = "1.0" encoding="Windows-1252"?><ROW City="à"/>
Why does the error occur?
(The XML loads perfectly fine in .NET and other environments not using MSXML6, it also works fine on Windows 7 Ultimate x64 SP1).
--jeroen
The behaviour depends on which version of the MSXML6.DLL you have installed.
To reproduce this better, I created another file abnormal.xml, in addition to the normal.xml from the question.
File dump abnormal.xml:
000000: 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E 3D 22 31 <?xml version="1
000010: 2E 30 22 20 73 74 61 6E 64 61 6C 6F 6E 65 3D 22 .0" standalone="
000020: 79 65 73 22 3F 3E 3C 52 4F 57 20 43 69 74 79 3D yes"?><ROW City=
000030: 22 E0 22 2F 3E 0D 0A "."/>..
File abnormal.xml:
<?xml version="1.0" standalone="yes"?><ROW City="à"/>
File dump normal.xml:
000000: 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E 20 3D 20 <?xml version =
000010: 22 31 2E 30 22 20 65 6E 63 6F 64 69 6E 67 3D 22 "1.0" encoding="
000020: 57 69 6E 64 6F 77 73 2D 31 32 35 32 22 3F 3E 3C Windows-1252"?><
000030: 52 4F 57 20 43 69 74 79 3D 22 E0 22 2F 3E 0D 0A ROW City="."/>..
File normal.xml:
<?xml version = "1.0" encoding="Windows-1252"?><ROW City="à"/>
The behaviour I expect is that:
abnormal.xml fails, because it does not specify an encoding, but contains a character with the high-bit set
normal.xml succeeds, as it conains a single-byte encoding supporting high-bit characters, so characters with high-bit set are allowed
These are the observed scenarios:
MSXML6 FAILURE:
reason: System error: -2146697210.
errorCode: -2146697210
url: file:///C:/My%20Dropbox/XMLEOSErrorTest/Abnormal.xml
reason: System error: -2146697210.
errorCode: -2146697210
url: file:///C:/My%20Dropbox/XMLEOSErrorTest/Normal.xml
MSXML6 SUCCESS:
reason: An invalid character was found in text content.
errorCode: -1072896760
url: file:///C:/My%20Dropbox/XMLEOSErrorTest/Abnormal.xml
srcText: <?xml version="1.0" standalone="yes"?><ROW City="
line: 1
linepos: 50
filepos: 49
This is an overview of what versions fail.
The names of the DLL's between parentheses are from their version information.
failure; XP Professional SP3:
msxml6.dll version 6.20.1099.0 (MSXML 6.0 SP2)
msxml6r.dll version 6.0.3883.0 (XML Resources)
success; Windows 7 Ultimate x64 SP1:
msxml6.dll version 6.30.7600.16385 (MSXML 6.0 SP3)
msxml6r.dll version 6.30.7600.16385
msxml6r.dll.mui version 6.30.7600.16385
success; XP Professional SP3:
msxml6.dll version 6.20.1103.0 (MSXML 6.0 SP3)
msxml6r.dll version 6.0.3883.0 (XML Resources)
Observations:
Automatic Windows Update and Microsoft Update will not update MSXML6.DLL to the latest version on Windows XP SP3.
There is no MSXML6 SP3 for Windows XP.
The latest version is in fact 6.20.2003.0 for Windows XP SP2 and can be obtained at http://support.microsoft.com/kb/973686 (it does not install on Windows XP SP3).
The 6.20.1103.0 version of MSXML6.DLL for Windows XP SP3 can be obtained at http://support.microsoft.com/kb/973687 (direct download for XP SP3)
Microsoft has very little information on their site about this: http://www.google.com/search?q=msxml6+%226.20.1099.0%22+%226.20.1103.0%22+site:microsoft.com
Searching only for 6.20.1103.0 does not reveal much more: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=msxml6+%226.20.1103.0%22+site:microsoft.com
This gives the best search results: http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=msxml6+%226.20.1103.0%22#sclient=psy&num=10&hl=en&q=msxml6+%226.20.1099.0%22+%226.20.1103.0%22
So: when doing MSXML6 work, first put in a check that you indeed have the latest MSXML6.DLL for your target Windows version.
--jeroen

Resources