Let's assume that I have 512-byte packets plus a 16-bit CRC at the end. I would like to determine what the CRC parameters are.
It's a Fujitsu chip, where I'm writing the the flash with a programmer, the programmer calculates the CRC for me, and I read out the CRC with an oscilloscope. I have the ability to check every possible combination.
My test messages are 512 zeros except for one byte that I set to the values 0 to 17 in decimal. The one byte is one of the first four or last two in the packet. Here are the resulting CRCs in hexadecimal, where the rows are the value of the byte, and the columns are which byte is set:
00 01 02 03 510 511
00 00 00 00 00 00 00
01 0x8108 0x0100 0x3020 0xC6B0 0xF1F0 0x8108
02 0x8318 0x0200 0x6040 0x0C68 0x62E8 0x8318
03 0x0210 0x0300 0x5060 0xCAD8 0x9318 0x0210
04 0x8738 0x0400 0xC080 0x18D0 0xC5D0 0x8738
05 0x0630 0x0500 0xF0A0 0xDE60 0x3420 0x0630
06 0x0420 0x0600 0xA0C0 0x14B8 0xA738 0x0420
07 0x8528 0x0700 0x90E0 0xD208 0x56C8 0x8528
08 0x8F78 0x0800 0x0008 0x31A0 0x0AA8 0x8F78
09 0x0E70 0x0900 0x3028 0xF710 0xFB58 0x0E70
10 0x0C60 0x0A00 0x6048 0x3DC8 0x6840 0x0C60
11 0x8D68 0x0B00 0x5068 0xFB78 0x99B0 0x8D68
12 0x0840 0x0C00 0xC088 0x2970 0xCF78 0x0840
13 0x8948 0x0D00 0xF0A8 0xEFC0 0x3E88 0x8948
14 0x8B58 0x0E00 0xA0C8 0x2518 0xAD90 0x8B58
15 0x0A50 0x0F00 0x90E8 0xE3A8 0x5C60 0x0A50
16 0x9FF8 0x1000 0x0010 0x6340 0x1550 0x9FF8
17 0x1EF0 0x1100 0x3030 0xA5F0 0xE4A0 0x1EF0
As you can see the first and last bytes give the same value. I tried several variations of CRC-16, but without much luck. The closet one was CRC-16 with polynomial 0x1021 and initial value 0.
The fact that every single CRC ends in 0 or 8 strongly suggests that it is not a 16-bit CRC, but rather a 13-bit CRC. Indeed, all of the sequences check against a 13-bit CRC with polynomial 0x1021 not reflected, initial value zero, and final exclusive-or zero.
We can't be sure about the initial value and final exclusive-or unless you can provide at least one packet with a length other than 512. With only examples of a single length, there are 8,191 other combinations of initial values and final exclusive-ors that would produce the exact same CRCs.
I'm trying to understand the algorithm used for compression value = 1 with the Epson ESCP2 print command, "ESC-i". I have a hex dump of a raw print file which looks, in part, like the hexdump below (note little-endian format issues).
000006a 1b ( U 05 00 08 08 08 40 0b
units; (page1=08), (vt1=08), (hz1=08), (base2=40 0b=0xb40=2880)
...
00000c0 691b 0112 6802 0101 de00
esc i 12 01 02 68 01 01 00
print color1, compress1, bits1, bytes2, lines2, data...
color1 = 0x12 = 18 = light cyan
compress1 = 1
bits1 (bits/pixel) = 0x2 = 2
bytes2 is ??? = 0x0168 = 360
lines2 is # lines to print = 0x0001 = 1
00000c9 de 1200 9a05 6959
00000d0 5999 a565 5999 6566 5996 9695 655a fd56
00000e0 1f66 9a59 6656 6566 5996 9665 9659 6666
00000f0 6559 9999 9565 6695 9965 a665 6666 6969
0000100 5566 95fe 9919 6596 5996 5696 9666 665a
0000110 5956 6669 0456 1044 0041 4110 0040 8140
0000120 9000 0d00
1b0c 1b40 5228 0008 5200 4d45
FF esc # esc ( R 00 REMOTE1
The difficulty I'm having is how to decode the data, starting at 00000c9, given 2 bits/pixel and the count of 360. It's my understanding this is some form of tiff or rle encoding, but I can't decode it in a way that makes sense. The output was produced by gutenprint plugin for GIMP.
Any help would be much appreciated.
The byte count is not a count of the bytes in the input stream; it is a count of the bytes in the input stream as expanded to an uncompressed form. So when expanded, there should be a total of 360 bytes. The input bytes are interpreted as either a count of bytes to follow, if positive, in which case the count is the byte value +1; and if negative the count is a count of the number of times the immediately following byte should be expanded, again, +1. The 0D at the end is a terminating carriage return for the line as a whole.
The input stream is only considered as a string of whole bytes, despite the fact that the individual pixel/nozzle controls are only 2 bits each. So it is not really possible to use a repeat count for something like a 3-nozzle sequence; a repeat count must always specify a full byte 4-nozzle combination.
The above example then specifies:
0xde00 => repeat 0x00 35 times
0x12 => use the next 19 bytes as is
0xfd66 => repeat 0x66 4 times
0x1f => use the next 32 bytes as is
etc.
Trying to deconstruct this TCPdump BPF style filter, and need some help:
'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'
Its taken from here
Steps that have taken to better understand what is going on:
1. Lets convert the 0x47455420 to ascii
===> GET
===> tcp[((tcp[12:1] & 0xf0) >> 2):4] = GET
2. Examine the inner tcp filter: (tcp[12:1] & 0xf0)
===> the 0xf0 == 0000 0000 1111 0000 ===> I suppose it is save to discard the upper zeros so I can write 1111 0000
===> tcp[12:1] == 08 (start filtering from byte 13 (0 based indexing, so you could also say start with the byte that has index 12) for 1 byte, so only 13th byte);
===> 08 == 0000 1000
===> 0000 1000 & 1111 0000 == 0000 (bitwise and = if both are 1 then end result is one)
This is where I got confused. The explanation in the hyperlink I provided above is saying
multiply it by four ( (tcp[12:1] & 0xf0)>>2 ) which should give the tcp header length
Impossible if it is zero. Please:
help me find the mistake in my calculations (maybe I'm mixing TCP and IP headers?);
provide some guidance whether my logic is correct.
This is the packet:
19:10:30.091065 IP (tos 0x0, ttl 63, id 40127, offset 0, flags [DF], proto TCP (6), length 2786)
10.240.35.81.47856 > 172.17.13.201.8080: Flags [P.], cksum 0xf2ef (incorrect -> 0xb8f8), seq 2263020471:2263023205, ack 4187927811, win 28, options [nop,nop,TS val 1906863883 ecr 214445688], length 2734
0x0000: 1a17 8e8a a3a0 026d 627d 049c 0800 4500 .......mb}....E.
0,1 2,3 ... ... ... ... 12,13 ... <=== byte indexes
1,2 3,4 ... ... ... ... 13,14 ... <=== counting how many bytes
0x0010: 0ae2 9cbf 4000 3f06 ac3b 0af0 2351 ac11 ....#.?..;..#Q.. <=== 0x0010 number correctly identifies that the first two diggits are the 16th byte
16,17 ... ...
0x0020: 0dc9 baf0 1f90 86e2 f3b7 f99e b503 8018 ................
0x0030: 001c f2ef 0000 0101 080a 71a8 6f0b 0cc8 ..........q.o...
0x0040: 2e78 4745 5420 2f69 636f 6e73 2f75 6e6b .xGET./icons/unk
0x0050: 6e6f 776e 2e67 6966 2048 5454 502f 312e nown.gif.HTTP/1.
0x0060: 310d 0a68 6f73 743a 2070 6870 2d6d 696e 1..host:.php-min
tcp[12:1] is the byte at an offset of 12 bytes from the beginning of the TCP header; the 12 is not the offset from the beginning of the packet, it's the offset from the beginning of the TCP header (it's tcp[12:1], not ether[12:1] or something such as that). The "1" is the number of bytes being referred to.
According to RFC 793, which is the specification for TCP, the byte at an offset of 12 bytes from the beginning of the TCP header contains the data offset in the upper 4 bits and the lower 4 bits are reserved bits. The data offset is "The number of 32 bit words in the TCP Header", which "indicates where the data begins".
The data in the packet is being displayed as a sequence of byte pairs. It's a bit easier to understand if presented as a sequence of individual bytes, so:
0x0000: 1a 17 8e 8a a3 a0 02 6d 62 7d 04 9c 08 00 45 00
eth dest eth src etype IP hdr
The first 6 bytes of the packet are the Ethernet destination address.
The next 6 bytes of the packet are the Ethernet source address.
The 2 bytes after that are the Ethernet type value; it's big-endian, so its value is 0x0800, which is the Ethernet type value for IPv4.
The next 2 bytes are the first 2 bytes of the IPv4 header. According to RFC 791, which is the specification for IPv4, the first byte of the IPv4 header contains the IP version in the upper 4 bits and the header length in the lower 4 bits. That byte has a value of 0x45, so the IP version is 4 (as it should be, for IPv4) and the header length is 5. The header length "is the length of the internet header in 32 bit words", so that's 5 32-bit words, or 20 bytes.
So, for now, let's skip the IPv4 header and go to the TCP header:
0x0020: 0d c9 ba f0 1f 90 86 e2 f3 b7 f9 9e b5 03 80 18
TCP header 12 13
So byte 12 of the TCP header is 0x80. 0x80 & 0xf0 is 0x80, and 0x80 >> 2 is 0x20, which is 32; this is consistent with the upper 4 bits of that byte being the data offset, in 32-bit words, as 8*4 = 32.
tcp[((tcp[12:1] & 0xf0) >> 2):4] is thus, for this packet, tcp[32:4], i.e. the 4 bytes at an offset of 32 from the beginning of the TCP header.
32 bytes from the beginning of the TCP header is:
0x0040: 2e78 4745 5420 2f69 636f 6e73 2f75 6e6b
^
there, and that's the "GET" header of the HTTP request, beginning at the beginning of the TCP segment data. Te 4 bytes in question are "GET ".
So the 12 in tcp[12:1] is not the offset from the beginning of the packet, it's the offset from the beginning of the TCP header (it's tcp[12:1], not ether[12:1] or something such as that).
And, in answer to the questions about the bytes of the packet and what they are:
0x0000: 1a 17 8e 8a a3 a0: Ethernet destination
02 6d 62 7d 04 9c: Ethernet source
08 00: Ethernet type/length field - 0x0800 = IPv4
So the first 14 (0x000e) bytes of the packet are the Ethernet header.
In this packet, the Ethernet type/length field is 0x0800, so the Ethernet payload, following the Ethernet header, is an IPv4 packet, beginning with an IPv4 header:
45: IPv4 version/header length
00: IPv4 Type of Service/Differentiated Service
0x0010: 0a e2: IPv4 total length
9c bf: IPv4 identification
40 00: IPv4 flags/fragment offset
3f: IPv4 time-to-live
06: IPv4 (next) protocol - 6 = TCP
ac 3b: IPv4 header checksum
0a f0 23 51: IPv4 source address
ac 11: first 2 bytes of IPv4 destination address
0x0020: 0d c9: second 2 bytes of IPv4 destination address
The IPv4 header length is 5, so the IPv4 header is 20 bytes. That's the minimum IPv4 header length; it can't be smaller, but it can be larger, if there are IPv4 options after the fixed-length part of the header. There aren't any, in this case.
As the protocol field has the value 6, the IPv4 payload is a TCP packet:
ba f0: TCP source port (47856)
1f 90: TCP destination port (8080)
86 e2 f3 b7: TCP sequence number
f9 9e b5 03: TCP acknowledgment number
80: TCP data offset + reserved bits
18: reserved bits + TCP flags
0x0030: 00 1c: TCP window
f2 ef: TCP checksum
00 00: TCP urgent pointer
That's the 20-byte fixed-length portion of the TCP header; however, the TCP header length is 32 bytes, so there are an additional 12 bytes of TCP options in the header:
01: TCP No-Operation option
01: TCP No-Operation option
08 0a 71 a8 6f 0b 0c c8: first 8 bytes of TCP Timestamp option
0x0040: 2e 78: last 2 bytes of TCP Timestamp option
A TCP header's length must be a multiple of 32 bits, i.e. a multiple of 4 bytes; TCP options might not be a multiple of 4 in length - the TCP Timestamp option is 10 bytes long - so the No-Operation option is used for padding.
So those 32 bytes were the TCP header; what follows is the TCP payload. Apparently, this is on an HTTP connection (the packet is being sent to port 8080, which is an alternate HTTP port), and this is the beginning of an HTTP GET request:
47 45 54 20 2f 69 63 6f 6e 73 2f 75 6e 6b
0x0050: 6e 6f 77 6e 2e 67 69 66 20 48 54 54 50 2f 31 2e
0x0060: 31 0d 0a 68 6f 73 74 3a 20 70 68 70 2d 6d 69 6e
So:
as this was captured either on an Ethernet or on a Wi-Fi network when not in monitor mode (or on some other type of network that either uses Ethernet headers or on which the adapter or driver supplies "fake Ethernet" headers, as with Wi-Fi), the packet will start with an Ethernet header;
as the Ethernet type value is 0x0800, it's followed by an IPv4 header;
as the IPv4 protocol value is 6, it's followed by a TCP header;
as one of the TCP port numbers is a port number typically used by HTTP (8080), it's probably followed by HTTP data of some sort (this isn't guaranteed, however - TCP port numbers are more like hints).
For ARP over the same network, you'll again have an Ethernet header (the ffff ffff is the Ethernet broadcast address, so the packet is being broadcast, as ARP requests usually are), with an Ethernet type of 0x0806, which is the Ethernet type value for ARP.
For ICMP over the same network, you'll again have an Ethernet header, and you'll also have an IPv4 header, so the Ethernet type will be 0x0800. The value in the protocol field in the IPv4 header will be 1, for ICMP.
I'm trying to have a USIM perform call forwarding (a.k.a call redirection) using the proactive command SEND SS (TS 31.111 sections: 6.4.11, 8.14, etc.). Unfortunately I keep getting an error from the network which I can't understand.
I'm trying the following sequence:
ME->USIM: 8012000018 (FETCH from the ME toward UICC)
USIM->ME: 12 (procedure byte)
USIM->ME: D01681030411008202818305000909FFAA120A25556777B49000
D0 (proactive command) 16 (length)
81 (command details) 03 (length) 04 (command number) 11 (SEND SS) 00 (RFU)
82 (device identities) 02 (length) 81 (UICC) 83 (network)
05 (alpha identifier) 00 (length)
909FFAA120A25556777B4 (SS String = **21*0525576774#)
9000 (OK)
ME->USIM: 801400000D (Terminal response of size 0x0D)
USIM->ME: 14 (procedure byte)
ME->USIM: 81030411000202828103023424
81 (command details) 03 (length) 04 (command number) 11 (SEND SS) 00 (RFU)
02 (device identities) 02 (length) 82 (ME) 81 (UICC)
03 (Result) 02 (length) 34 (SS Return Error) 24 (???)
I can't figure out what '24' means.
Just to make sure I'm using a correct SS string, I activated CALL CONTROL on the USIM and dialed **21*0525576774# in the keypad. The result was as follows:
ME->UICC: 80C200001C (Envelope of length 0x1C)
UICC->ME: C2 (procedure byte)
ME->UICC: D41A020282810909FFAA120A25556777B4130924F51027D078CF0013
D4 (envelope) 1A (length)
02 (device identities) 02 (length) 82 (ME) 81 (UICC)
09 (send ss) 09 (length) FFAA120A25556777B4 (SS string)
13 (location information) 09 (length) 24F51027D078CF0013 (not relevant)
USIM->ME: 9000 (OK)
As you can see, the SS string is identical. When the ME sends it it seems to work (call forwarding is activated) yet when I try to send it from the UICC to the network I get the error '3424'.
I've searched through the specs (TS 31.111, TS 22.030 and even TS 24.080) but didn't find even the tiniest lead as to what I'm doing wrong.
Any help will be appreciated :)
Cheers,
Nir.
I think the problem occurs due to timer management(Action in contradiction with the current timer state) becouse
0x34-> Means SS Return Error
0x24-> Means Action in contradiction with the current timer state.
I examined some MPEG-4 video headers and saw some byte arrays like below at the beginning:
00 00 01 B0 01 00 00 01 B5 89 13
I know 00 00 01 parts but what exactly B0 B1 and B5 89 13 parts mean? Actually, if I put this byte array infront of an MPEG-4 stream, it works fine.
But I don't know if those values works with different mpeg-4 stream sources ?
0x000001B0 -> Visual Object Sequence Start (VOSS) Code
0x000001B5 -> Visual Object Start (VOS) Code
You can find the complete MPEG-4 elementary video header details at "ISO/IEC 14496-2" documentation. Here are the details you asked for.
Visual Object Sequence Start (VOSS) Code
-> 4 bytes visual object sequence start code = long hex value of 0x000001B0
-> 8 bits profile/level indicator = 1 byte unsigned number
Visual Object Start (VOS) Code
-> 4 bytes visual object start code = long hex value of 0x000001B5
-> 1 bit has id marker flag = 1/4 nibble flag
_ID_Marker_Section_
-> 4 bits version id = 1 nibble unsigned value - only if marker is true
- version id types are ISO 14496-2 = 1
-> 3 bits visual object priority = 3/4 nibble unsigned value - only if marker is true
- priorities are 1 through to 7
-> 4 bits visual object type = 1 nibble unsigned value
- types are video = 1 ; still texture = 2 ; mesh = 3 ; face = 4
-> 1 bit video signal type = 1/4 nibble flag
- NOTE: if this is false Y has a sample range of 16 through to 235