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).
Related
I was trying to interpret the bytes in a DBus Message as specified in https://dbus.freedesktop.org/doc/dbus-specification.html. This is taken from a pcap while using the Frida tool.
The bytes are
0000 6c 01 00 01 08 00 00 00 01 00 00 00 70 00 00 00
0010 01 01 6f 00 15 00 00 00 2f 72 65 2f 66 72 69 64
0020 61 2f 48 6f 73 74 53 65 73 73 69 6f 6e 00 00 00
0030 02 01 73 00 16 00 00 00 72 65 2e 66 72 69 64 61
0040 2e 48 6f 73 74 53 65 73 73 69 6f 6e 31 35 00 00
0050 08 01 67 00 05 61 7b 73 76 7d 00 00 00 00 00 00
0060 03 01 73 00 17 00 00 00 47 65 74 46 72 6f 6e 74
0070 6d 6f 73 74 41 70 70 6c 69 63 61 74 69 6f 6e 00
0080 00 00 00 00 00 00 00 00
There are some fields which I am uncertain what they mean. Appreciate if anyone can provide some guidance on this.
0x6C: Refers to little endian
0x01: Message Type (Method Call)
0x00: Bitwise of OR flags
0x01: Major Protocol Version
0x08000000: Length of Message Body (Little Endian), starting from end of Header. This should be referring to the eight null bytes at the end?
0x01000000: Serial of this Message (Little Endian)
0x70000000: (Little Endian) Not sure what this represents? This value does correspond to the length of the array of struct, excluding trailing null bytes, that starts from 0x0010 and ends at 0x007F.
0x01: Decimal Code for Object Path
0x01: Not sure what this represents?
0x6F: DBus Type 'o' for Object Path
0x15: Length of the Object Path string
You want to look at the part of the specification that tells you what the message format is.
But to answer your questions:
0x08000000: Length of Message Body (Little Endian), starting from end of Header. This should be referring to the eight null bytes at the end?
Correct.
0x70000000: (Little Endian) Not sure what this represents? This value does correspond to the length of the array of struct, excluding trailing null bytes, that starts from 0x0010 and ends at 0x007F.
That's the length of the array in the header. The DBus header is of a variable size - after the first few bytes, it is an array of struct(byte,variant). As per the documentation, that looks like a(yv) if you were to express this as a DBus type signature.
0x01: Decimal Code for Object Path
0x01: Not sure what this represents?
This is where the parsing gets interesting: in our struct, the signature is yv, so the first 0x01 is telling us that this struct entry is the header field for Object Path, as you have seen. However, we now need to parse what the variant contains inside of it. To marshal a variant, you first marshal a signature, which in this case is 1 byte long: 01 6f 00. Note that signatures can be a max of 255 bytes long, so unlike other strings they only have a 1-byte length at the front. As a string, that is o, which tells us that this variant contains an object path inside of it. Since object paths are strings, we then decode the next bytes as a string(keeping note that the leading 4 bytes are the string length): 15 00 00 00 2f 72 65 2f 66 72 69 64 61 2f 48 6f 73 74 53 65 73 73 69 6f 6e 00
If I've done the conversion correctly, that says /re/frida/HostSession
This is taken from a pcap
If it's a standard pcap (or pcapng) D-Bus capture file, using the LINKTYPE_DBUS link-layer type, then Wireshark should be able to read it and, at least to some degree, interpret the messages (i.e., it has code that understands the message format, as defined by the specification to which #rm5248 referred (and to which the LINKTYPE_DBUS entry in the list of link-layer header types refers), so you might not have to interpret all the bytes by yourself.
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.
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!
The 2006 version of the free offline Chinese sentence dictionary Jukuu contains a collection of 100,000 publicly sourced example sentences in Chinese and English in a .dll file.
The application size is about 80mb, but once installed a 500mb DLL dictionary file is created with the source text. For whatever reason the application doesn't run on my computer, and I'd like to extract all the example sentences so I can do some POS analysis on them.
Opening the 500mb .DLL file is mostly gibberish, except for some fragments of text here and there and references to other resources.
I'm wondering if there is any way I can extract the information in plain text?
The application can be downloaded here: http://www.jukuu.com/down/download.html
Thanks!
Edit: Never-mind, It looks like when viewed in HEX, the file is ordered in a way that is not conducive to sentence mining at all:
00 06 00 02 00 07 03 00 01 00 00 00 FF FE 6E 65 76 65 72 7E 73 74 61
6E 64 20 75 70 0B 00 00 80 00 00 00 00 00 00 00 00 FF FE 33 30 32
32 31 38 32 36 38 2D 00 16 00 06 00 02 00 07 03 00 01 00 00 00 FF
FE 65 78 74 72 65 6D 65 6C 79 7E 63 6C 6F 73 65 0B 00 00 80 00 00
00 00 00 00 00
Something like ÿþnever~stand upÿþ302218268-ÿþextremely~close
Any other ideas on how to mine sentences from the application? Maybe a batch script?
I am trying to stream Olimex A13 encoded data to RTMP server with librtmp and view it on VLC. The problem is I cannot find how to correctly wrap Cedar data to flash container... I have found this example which looks exactly what I would need, but VLC has still problems understanding it -
No suitable decoder module:
VLC does not support the audio or video format "undf". Unfortunately there is no way for you to fix this.
I tried grabbing data through rtmpdump and it appears I cannot disable audio track which VLC is trying to get from the header
Format : Flash Video
File size : 195 KiB
Duration : 1mn 27s
Overall bit rate : 1 464 Kbps
_Server : NGINX RTMP (github.com/arut/nginx-rtmp-module)
_displayWidth : 640.000
_displayHeight : 480.000
_fps : 25.000
Video
Format : AVC
Format/Info : Advanced Video Codec
Codec ID : 7
Duration : 1mn 27s
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 25.000 fps
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.191
Audio
The last line for 'Audio' is what I suspect is causing VLC to err. Moreover I am sure the video data I am trying to send is not correctly wrapped.
From what I understood looking into example is that FLV expects a general stream description which can be flagged for video and audio stream information, other examples I found (including ffmpeg ) use some magic number following onMetaData tag, but I dont think I do that by following an example from above:
STR2AVAL(av, "onMetaData");
enc = AMF_EncodeString(enc, pend, &av);
*enc++ = AMF_ECMA_ARRAY;
enc = AMF_EncodeInt32(enc, pend, 5+5+2); //5 - video 5 - audio
The dump of my rtmp header is:
sending 307 as header
00000000 02 00 0d 40 73 65 74 44 61 74 61 46 72 61 6d 65 ...#setDataFrame
00000010 02 00 0a 6f 6e 4d 65 74 61 44 61 74 61 03 00 06 ...onMetaData...
00000020 61 75 74 68 6f 72 02 00 00 00 09 63 6f 70 79 72 author.....copyr
00000030 69 67 68 74 02 00 00 00 0b 64 65 73 63 72 69 70 ight.....descrip
00000040 74 69 6f 6e 02 00 00 00 08 6b 65 79 77 6f 72 64 tion.....keyword
00000050 73 02 00 00 00 06 72 61 74 69 6e 67 02 00 00 00 s.....rating....
00000060 0a 70 72 65 73 65 74 6e 61 6d 65 02 00 06 43 75 .presetname...Cu
00000070 73 74 6f 6d 00 05 77 69 64 74 68 00 40 84 00 00 stom..width.#...
00000080 00 00 00 00 00 05 77 69 64 74 68 00 40 84 00 00 ......width.#...
00000090 00 00 00 00 00 06 68 65 69 67 68 74 00 40 7e 00 ......height.#~.
000000a0 00 00 00 00 00 00 09 66 72 61 6d 65 72 61 74 65 .......framerate
000000b0 00 40 39 00 00 00 00 00 00 00 0c 76 69 64 65 6f .#9........video
000000c0 63 6f 64 65 63 69 64 02 00 04 61 76 63 31 00 0d codecid...avc1..
000000d0 76 69 64 65 6f 64 61 74 61 72 61 74 65 00 40 96 videodatarate.#.
000000e0 e3 60 00 00 00 00 00 08 61 76 63 6c 65 76 65 6c .`......avclevel
000000f0 00 3f f0 00 00 00 00 00 00 00 0a 61 76 63 70 72 .?.........avcpr
00000100 6f 66 69 6c 65 00 40 50 80 00 00 00 00 00 00 17 ofile.#P........
00000110 76 69 64 65 6f 6b 65 79 66 72 61 6d 65 5f 66 72 videokeyframe_fr
00000120 65 71 75 65 6e 63 79 00 40 20 00 00 00 00 00 00 equency.# ......
00000130 00 00 09 ...
After that application send PSP and SPS data which I am not sure I encode correctly too:
This is what I have in my encoder application
psp struct start
00000000 34 32 30 31 66 00 00 00 00 00 5a 30 49 41 48 2b 4201f.....Z0IAH+
00000010 56 41 55 42 37 49 00 00 00 00 00 00 00 00 00 00 VAUB7I..........
00000020 00 00 00 00 00 00 00 00 61 4f 34 78 45 67 3d 3d ........aO4xEg==
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 ......
psp struct end
And this is what I send to RTMP server:
sending 38 as sps/pps info
00000000 17 00 00 00 00 01 42 c0 15 03 01 00 0d 67 5a 30 ......B......gZ0
00000010 49 41 48 2b 56 41 55 42 37 49 01 00 09 68 61 4f IAH+VAUB7I...haO
00000020 34 78 45 67 3d 3d 4xEg==
info frame sent
So the questions are:
How do you modify the header to explicitly state that its video only?
How does one wrap video data in NAL format and how often do you have to transmit SPS and PPS data?
Are there any online services to inspect the RTMP data to understand whats wrong with it? VLC doesnt help much...