We see these packets being injected in an FTP-DTP channel during a downlink file transfer on Telstra's NEXTG mobile network. We are not sure if these are network level packets, a problem with our 3G modem (HC25 based) or something like our firewall injecting in the stream.
Using a tool we noticed that the PPP framing fails with protocol length errors, so they are mostly likely mobile network packets.
I am hoping someone here can identify the signature of the packets so that I can chase this up with the appropriate vendor.
There is definitely a format to these packets: -
Packet1:
00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 01 10 f4 4e 00 00 40 06 2f 13 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 5d a9 01 f7 0c eb 50 10 ff ff 58 b9 00 00
Packet2:
00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 00 ff 6b 50 00 00 40 06 b8 22 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 7b 82 01 f7 0c eb 50 10 ff ff a3 79 00 00
Packet3:
00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 02 20 5b 50 00 00 40 06 c7 01 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 7c 59 01 f7 0c eb 50 10 ff ff e2 5d 00 00
Packet4:
00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 01 38 d8 52 00 00 40 06 4a e7 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 62 42 f9 01 f7 0c eb 50 10 ff ff 20 91 00 00
Packet5:
00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 00 d0 4d 58 00 00 40 06 d6 49 cb 7a 9d e9 7b d0 71 52 7a ee 04 08 4b fb 0b 8f 03 5d 51 1a 50 10 ff ff e9 88 00 00
I converted your packet trace snippet into a format understood by text2pcap so I could convert them into the pcap format for viewing in Wireshark (a very handy packet capture and analysis tool):
Looks like some sort of IPv4 multicast traffic at a very rough guess. Here's what I got from the first packet (rest came up as malformed):
No. Time Source Destination Protocol Info
1 0.000000 7b:1a:00:90:7f:43 00:00:00_24:c4:b8 0x0fa1 Ethernet II
Frame 1 (31 bytes on wire, 31 bytes captured)
Arrival Time: Dec 1, 2009 00:33:05.000000000
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 31 bytes
Capture Length: 31 bytes
[Frame is marked: False]
[Protocols in frame: eth:data]
Ethernet II, Src: 7b:1a:00:90:7f:43 (7b:1a:00:90:7f:43), Dst: 00:00:00_24:c4:b8 (00:00:00:24:c4:b8)
Destination: 00:00:00_24:c4:b8 (00:00:00:24:c4:b8)
Address: 00:00:00_24:c4:b8 (00:00:00:24:c4:b8)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: 7b:1a:00:90:7f:43 (7b:1a:00:90:7f:43)
Address: 7b:1a:00:90:7f:43 (7b:1a:00:90:7f:43)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Type: Unknown (0x0fa1)
Data (17 bytes)
0000 08 00 45 00 01 10 f4 4e 00 00 40 06 2f 13 cb 7a ..E....N..#./..z
0010 9d .
Data: 080045000110F44E000040062F13CB7A9D
These look like ordinary TCP packets but with two extra 00 bytes tagged on at the front. Not sure why that would happen, but they appear to be from 00-90-7f-43-0f-a1 (Watchguard) to 00-24-c4-b8-7b-1a (Cisco).
IP header is 45 00 01 10 f4 4e 00 00 40 06 2f 13 cb 7a 9d e9 7b d0 71 52
TCP header is 7a ed 04 06 8c 61 5d a9 01 f7 0c eb 50 10 ff ff 58 b9 00 00
So you can get the rest of the details from there.
00:24:c4 is a NIC from Cisco and 00:90:7F is a NIC from WatchGuard.
From the IEEE OUI Registry.
How much help that might be ... don't know. Might therefore be an attempted VPN connection.
As already decoded by others:
first 6+6+2 bytes identifying NIC and Ethernet II.
bytes 0x0800 EtherType telling that it is IP. http://en.wikipedia.org/wiki/EtherType
next octet starting with nibble "4" is IPv4
etc.
Related
I am writing a guest OS on top of Linux (Ubuntu distribution) within a Docker container. The filesystem is implemented as a single file resting inside the host OS, so anytime a file is changed in the guest OS filesystem, the file on the host OS must be opened, the correct block(s) must be overwritten, and the file must be closed.
My partner and I have developed the following recursive helper function to take in a block number and offset to abstract away all details at the block-level for higher level functions:
/**
* Recursive procedure to write n bytes from buf to the
* block specified by block_num. Also updates FAT to
* reflect changes.
*
* #param block_num identifier for block to begin writing
* #param buf buffer to write from
* #param n number of bytes to write
* #param offset number of bytes to start writing from as
* measured from start of file
*
* #returns number of bytes written
*/
int write_bytes(int block_num, const char *buf, int n, int offset) {
BlockTuple red_tup = reduce_block_offset(block_num, offset);
block_num = red_tup.block;
offset = red_tup.offset;
FILE *fp = fopen(fat->fname, "r+");
int bytes_to_write = min(n, fat->block_size - offset);
int write_n = max(bytes_to_write, 0);
fseek(fp, get_block_start(block_num) + offset, SEEK_SET);
fwrite(buf, 1, write_n, fp); // This line is returning 48 bytes written
fclose(fp);
// Check if there are bits remaining
int bytes_left = n - write_n;
if (bytes_left > 0) {
// Recursively write on next block
int next_block = get_free_block();
set_fat_entry(block_num, next_block); // point block to next block
set_fat_entry(next_block, 0xFFFF);
return write_bytes(next_block, buf + write_n, bytes_left, max(0, offset - fat->block_size)) + write_n;
} else {
set_fat_entry(block_num, 0xFFFF); // mark file as terminated
return write_n;
}
}
The issue is that fwrite(3) is reporting 48 bytes written (when n is passed as 48) but hexdumping the file on the host OS reveals no bytes have been changed:
00000000 00 01 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00008000
This is particularly wacky because when my partner runs the code on the exact same commit (with no uncommitted changes), her write goes through and the file on the host OS hexdumps to:
00000000 00 01 ff ff ff ff 00 00 00 00 00 00 00 00 00 00 |................|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 66 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |f1..............|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 00 01 00 00 02 00 01 06 e7 36 75 63 00 00 00 00 |.........6uc....|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 e0 53 f8 88 c0 0d 37 ca 84 1f 19 b0 6c a8 68 7b |.S....7.....l.h{|
00000210 57 83 cf 13 f0 42 21 d3 21 e1 da de d4 8a f1 e6 |W....B!.!.......|
00000220 f0 12 98 fb 1c 30 4c 04 b3 16 1d 96 17 ba d7 5a |.....0L........Z|
00000230 7e f3 8a f5 6a 42 6b ef 58 f6 bc 01 db 0c 02 53 |~...jBk.X......S|
00000240 e5 10 7e f3 4a d5 3f ac 8e 38 82 c3 95 f8 11 8e |..~.J.?..8......|
00000250 a6 82 eb 3b 24 56 9a 75 44 36 8b 25 60 83 4c 04 |...;$V.uD6.%`.L.|
00000260 07 9e 14 99 9c 9f 87 3c 8a d4 c3 e8 17 60 81 0e |.......<.....`..|
00000270 bc eb 1d 35 68 fc d5 be 4f 1c 9d 5e 72 57 65 01 |...5h...O..^rWe.|
00000280 b7 43 54 26 d6 6d ba 51 bf 12 8c a1 03 d5 66 b3 |.CT&.m.Q......f.|
00000290 90 0d 60 b8 95 8d 15 bd 53 9a 70 77 4f 7a 04 1e |..`.....S.pwOz..|
000002a0 9e b2 4c 9a 79 dd de 48 cd fe 1e dc 57 7d d1 7f |..L.y..H....W}..|
000002b0 3f f5 77 96 fa e7 d7 33 33 48 ce 0a 4d 61 ab 96 |?.w....33H..Ma..|
000002c0 5f c4 88 bf c6 3a 09 37 76 c4 b8 db bc 6a 7d c0 |_....:.7v....j}.|
000002d0 c4 89 68 e7 b4 70 f8 a6 a8 00 9d c4 63 da fb 66 |..h..p......c..f|
000002e0 be d2 cd 68 1c d2 ff bf 00 e9 37 ab 6b 1a 3c f2 |...h......7.k.<.|
000002f0 7b c1 a2 c4 46 ae db 93 b4 4f 64 79 14 2a 1a d4 |{...F....Ody.*..|
00000300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00008000
The 48 bytes I'm referring to that don't get written are the bytes written to the directory block running from address 00000100-0000012E (the bytes below that represent the actual file being written, the code seg faults on my end before reaching that write). It's worth noting my container can still format the filesystem file, so all writes aren't broken. This snippet just represents the first write that did not work.
We are both running the code in an identical Docker container. The only difference I could imagine is my computer is a Windows and hers is a Mac. What could possibly be the issue?
The very first thing I believed was that there was some conflict with the host OS that blocked my write, but assigning and printing the return value of fwrite(3) returned that 48 bytes were indeed written on both machines.
I was also expecting that my buffer was simply all 0s (it is initially allocated using calloc(3)), but printing out the first 48 bytes of the buffer proved that theory false.
I finally considered that this was some issue with the higher level interface in <stdio.h> instead of the lower level one in <unistd.h>. I replaced fopen(3), fwrite(3), flseek(3), fclose(3) each with their lower-level equivalents (write(2) etc) and it still turned up 48 bytes written with no actual change to the files.
EDIT:
The guest OS filesystem can be formatted with respect to user parameters. All testing above was performed with a block size of 256 bytes and 128 blocks total. I've attempted the exact same write sequence again with a block size of 1024 bytes and 16384 blocks total, and there was no error. It's still unclear why the code works on my partner's machine for both format configs and not mine, but this may narrow it down.
Running strace reveals the following excerpt around the write:
openat(AT_FDCWD, "minfs", O_RDWR) = 4
newfstatat(4, "", {st_mode=S_IFREG|0777, st_size=32768, ...}, AT_EMPTY_PATH) = 0
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\1\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 256) = 256
write(4, "f1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 48) = 48
close(4)
It again appears the bytes get written, but a hd after the program finishes reveals the same output as above. My thought was perhaps the bytes written in the excerpt are overwritten later on, but the only write after the excerpt above in the strace is:
lseek(4, 0, SEEK_SET) = 0
read(4, "\0\1\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 320) = 320
write(4, "\0", 1) = 1
close(4)
which should be at address 320, squarely after the write at address 256 above.
It turns out the mismatch was due to undefined behavior concerning when changes were synchronized in mmap(2). There was a section of code where a region of memory mapped via mmap(2) was changed and then immediately followed by reads/writes to the file on the host OS containing the mapped region of memory. It seems the Mac would write through the changes before the following section while the Windows wouldn't synchronize until after the fact, resulting in the undefined behavior.
The problem was fixed by making a call to msync(2) immediately after modifying the mapped region from mmap(2) with the MS_SYNC flag forcing the write-through behavior.
Links to documentation here: mmap(2), msync(2).
Currently I'm trying to read the bytes from the IDAT chunk of a PNG image, in C. I am able to get all the other info, including the said array of bytes.
The problem arises whenever I try to decompress said array with zlib's uncompress() method.
[ ... ]
int decompress(Chunk * _chunk, Image * _image)
{
uLongf compressedSize = _chunk->length;
byte * uncompressedData = NULL;
uLongf uncompressedSize = 0;
int ret = uncompress(uncompressedData, &uncompressedSize, _chunk->data, compressedSize);
if(ret != Z_OK)
{
fprintf(stderr, "Error: failed to uncompress IDAT chunk data. ERR CODE: %d\n", ret);
return -1;
}
[ ... ]
}
The chunk struct is defined as such:
typedef struct chunk
{
uint32_t length;
byte chunkType[4];
byte *data;
} Chunk;
The byte type is just an unsigned char, and the image struct is defined as follows:
typedef struct image
{
uint32_t width;
uint32_t height;
byte bitDepth;
byte colorType;
byte compression;
byte filter;
byte interlace;
} Image;
The test image's HEX representation is:
89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52
00 00 00 11 00 00 00 12 04 03 00 00 00 4F D7 28
67 00 00 00 30 50 4C 54 45 00 00 00 80 00 00 00
80 00 80 80 00 00 00 80 80 00 80 00 80 80 80 80
80 C0 C0 C0 FF 00 00 00 FF 00 FF FF 00 00 00 FF
FF 00 FF 00 FF FF FF FF FF 7B 1F B1 C4 00 00 00
09 70 48 59 73 00 00 0E C4 00 00 0E C4 01 95 2B
0E 1B 00 00 00 28 49 44 41 54 08 D7 63 D8 0D 05
1B 18 36 30 00 01 FF FF FF 24 B1 FE FF FF C0 C0
40 0E 6B FF FF FF 20 73 48 60 C1 5D 0A 00 BB 1A
49 27 39 98 BC 6E 00 00 00 00 49 45 4E 44 AE 42
60 82
And the bytes of the IDAT chunk are:
08 D7 63 D8 0D 05 1B 18 36 30 00 01 FF FF FF 24 B1 FE FF FF C0 C0 40 0E 6B FF FF FF 20 73 48 60 C1 5D 0A 00 BB 1A 49 27
It must be noted that I'm not taking the CRC of the chunk as well; from my understanding it shouldn't be a problem.
Any idea as to why the uncompress() method is returning Z_DATA_ERROR?
You're not giving uncompress() anywhere to put the uncompressed data! uncompressedData cannot be NULL.
i wrote a C code which is in an Embedded system. Clients can connect to me but i can't connect servers since they don't reply with syn ack back. In fact, they do nothing at all. Here is the frame(first 5 is the mac of my PC so i replaced them with 00):
00 00 00 00 00 00 12 48 07 06 20 03 08 00 45 00 00 34 E2 44 40
00 80 06 00 00 A9 FE 19 FC A9 FE 19 FE 00 50 1F 90 00 BC 61 4E
00 00 00 00 80 02 FA F0 8A 16 00 00 02 04 FF D7 01 03 03 08 01
01 04 02 //old hex bytes new below
Hi everyone. It is me back again. I ' ve reviewed the comments & answers, as as a result of that i have changed my code. Now i am trying to connect to my pc(server socket HERCULES 8080 port is being listened) my embedded system(client) via router. Also i found out my checksum calculation was wrong. I fixed it according to RFC 1071. I still can't get SYN ACK message after my SYN attempt. I am sharing new ethernet frame below(new answers are after 09.09.2021):
80 fa 5b 90 bf 5c 12 48 07 06 20 03 08 00 45 00
00 34 b4 00 40 00 80 06 00 00 c0 a8 01 6d c0 a8
01 64 00 50 1f 90 87 65 43 21 00 00 00 00 80 02
ff ff 06 64 00 00 02 04 ff d7 01 03 03 08 01 01
04 02
you can decode #: https://hpd.gasmi.net/ gives the same result as wireshark
Your IP is 169.254.25.252 which is within the Automatic Private Internet Protocol Addressing range.
This range is not routed on internet and you'll never get a reply
Salim
I found the solution. Copying hercules SYN frame was a mistake for me. I thought IPv4 header checksum must have been 0. However, when i corrected that frame it works properly now.
UPDATE:
CryptoAuthLib solve the problem. Many thanks #zaph
I'm working on ATSHA204 security chip, where a part of work is to calculate SHA-256 alike the chip does. I'm using
CryptoAuthentication ATSHA204A Development Library 2.0.1 [from hxxp://www.atmel.com/tools/CRYPTOAUTHENTICATIONATSHA204DEVELOPMENTLIBRARY.aspx] Implemented in C.
Well, while try any data >= 64 bytes, everything works fine. But anything < 64 bytes differ with the CHIP's calculation.
Have a look below,
message:
20 4D 56 EF 56 F6 27 71
AD CF D7 07 FC BA BE 21
A8 7D 7C AF F5 54 6F ED
27 2C F9 ED 75 B3 94 C7
1C 04 02 00 EE 01 23 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
0E EA 11 36 8E 89 D2 11
07 C1 1B 64 B6 D0 34 DA
A6 DB 66 0F 14 FB DB C6
26 7D 6A 3A 62 83 47 13
digest from Atmel's algorithm:
8C E2 28 98 6A 21 A3 40
A4 42 97 CE 4C 80 70 DF
87 97 61 B3 FC CD A2 BF
8D F0 89 EE 29 B8 68 BF
And while taking something < 64 length to same implementation,
message:
11 CC 32 8B 30 ED 04 81
73 96 A9 F8 3B F7 9E 72
23 DC 05 29 3C 65 36 70
3A 03 1C E2 C2 2D 99 4E
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 16 00 00
digest from Atmel's algorithm:
40 3D DC C0 93 A6 4B A5
01 36 7D 59 EC 8C C4 59
15 20 6D 52 A7 D5 ED 40
9B 95 31 D3 49 37 F3 F8
What should add with message which less than 64 bytes to get digest alike the CHIP calculation. [unfortunately yet failed any reply from ATMEL community]
I had mounted a fusecompress of directory compressed/ at fusecompress/
I copied a large file (several GB) to the fusecompress directory (ok, I mv'd it).
The compressed file in the directory compressed/ is length 1,221,396,660.
However, I cannot remove/uncompress the file. fusecompress has a memory error: "Cannot allocate memory".
Is there anyway to utilize the lzo library to write a decompress routine for the compressed file?
I tried the following, but got a segmentation fault:
char buffer[OUT_LEN];
char outbuffer[IN_LEN];
int read;
lzo_uint writ;
unsigned long totalWrit = 0;
while( (read = fread( buffer, sizeof(char), OUT_LEN, stdin )) > 0 )
{
r = lzo1x_decompress( buffer, read, outbuffer, &writ, NULL );
fwrite( outbuffer, sizeof(char), writ, stdout );
totalWrit += writ;
}
fprintf( stderr, "\nDone. %d bytes written out.\n\n", totalWrit );
Update:
In response to bill, the first 160 bytes of the file are:
00000000 01 1f 01 5d ff 89 04 00 a2 20 85 04 30 6e ba 48 |...]..... ..0n.H|
00000010 00 00 01 02 00 00 00 00 00 00 11 3c 3c 3c 20 53 |...........<<< S|
00000020 75 6e 20 56 69 72 74 75 61 6c 42 6f 78 20 44 69 |un VirtualBox Di|
00000030 73 6b 20 49 6d 61 67 65 20 3e 3e 3e 0a 00 3b 00 |sk Image >>>..;.|
00000040 00 08 7f 10 da be 01 00 01 00 90 01 00 54 00 3b |.............T.;|
00000050 a8 00 20 c9 70 00 02 02 00 00 00 a2 2d b8 03 6c |.. .p.......-..l|
00000060 02 a9 02 80 a9 01 10 b4 01 00 15 28 00 00 52 08 |...........(..R.|
00000070 00 00 a4 15 30 3e 76 22 73 4c 96 3d bf 8f ca 66 |....0>v"sL.=...f|
00000080 a8 93 2b a6 83 65 44 4d 37 41 a4 02 ca bb 56 4e |..+..eDM7A....VN|
00000090 a9 e9 b0 05 39 14 00 05 04 00 00 ff 00 00 00 3f |....9..........?|
You must look how the file was compressed. Witch Header and additional data are stored in the file.