This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Hi!

I am using last version of Wireshrk. So, i have a hex dump of one packet (SCCP):

09 81 03 10 1B 0D 12 06 00 72 04 73 21 85 25 03 00 79 24 0B 12 07 00 11 04 53 97 79 10 00 00 46 62 44 48 04 0E 00 03 77 6B 1E 28 1C 06 07 00 11 86 05 01 01 01 A0 11 60 0F 80 02 07 80 A1 09 06 07 04 00 00 01 00 0E 03 6C 80 A1 18 02 01 01 02 01 38 30 10 80 08 42 06 22 03 00 79 24 F5 02 01 01 83 01 00 00 00 00 00 03 65 8B 80 02 73 81 70 00 6E F9 A0 01 7B 2A F8 01 12 FA 18 02 73 81 80 01 13 07 88 04 73 21 85 25 03 00 79 02 73 82 38 00 11 04 53 97 79 10 00 00 46 62 44 48 04 0E 00 03 77 6B 1E 01 1B BE F8 00 00 00 00 01 01 01 A0 11 60 0F 80 02 73 82 20 09 06 07 04 00 00 01 00 0E 03 6C 80 A1 18 02 01 01 02 01 38 30 10 80 08 01 7A D8 80 00 79 24 F5 02 01 01 83 01 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 5E 76 0C 00 00 00 02 02 73 82 30 00 A4 32 5C 02 73 82 30 00 A4 2E 64 03 65 8B 80 00 81 F7 58 00 00 00 00 00 00 00 00 03 65 8B 80 00 A4 2D DC 02 73 82 38 00 A4 2E 08 02 73 82 48 00 81 F7 6C 00 00 00 00 00 00 00 02 02 73 82 58 00 81 F6 C4 00 00 90 32 00 00 00 00 02 73 82 60 00 80 5A E8 02 73 82 70 01 12 F6 C0 00 00

With Text2pcap tool i converted this dump to pcap file (text2pcap -l 142 hd.txt hd.pcap). And all seems ok... I can see SCCP part, TCAP part and GSM MAP Part. All this parts are in first 70 bytes. But how about the rest?.. That all the rest bytes mean?..

I'll be very grateful, if some one could help me to understand this message or to point me to some good direction.

Thanks.

asked 28 Aug '12, 06:21

SerijVeter's gravatar image

SerijVeter
1111
accept rate: 0%

Hello again.

This hex dump was created from incoming message on our audiocodes. With perl help. Something like...

Step 1 - check is it sccp message or not.

my $si = uc(unpack('H*', substr($msg,$si_offset,1))); return if $si !~ /^\d3$/;

Step 2 - Cut off offset = 40

my $sccp = substr($msg,$offset); $pkt->{print} = uc(unpack('H*', $sccp)); $pkt->{print} =~ s/(\w{2})/$1 /g; $pkt->{print} =~ s/\s+$//;

This is not my solution, but it works. After this two steps we have hex dump, similar to dump example in my previous post. So, we cut offset, uses Text2pcap and after that wireshark understands first 70 bytes as sccp message. And appears a clue - that all the rest bytes means.

If you are still interested in this question, i can provide some example of the full hex dump of message on our audiocodes.

Our main problem is that we can't understand there is one packet or two and how to divide them by some sort of concatenation mark.

01 91 FD 54 FF FF 80 E0 00 00 00 01 00 00 00 02 01 0E C1 B8 02 73 80 F0 00 01 0F B8 00 00 00 69 A5 CC 3F 83 B2 D3 EB F4 09 81 03 11 1C 0E 12 06 00 71 04 73 21 85 25 03 00 48 72 01 0B 12 07 00 11 04 23 94 05 00 12 00 40 62 3E 48 04 00 1F 06 F4 6B 1A 28 18 06 07 00 11 86 05 01 01 01 A0 0D 60 0B A1 09 06 07 04 00 00 01 00 0E 03 6C 1A A1 18 02 01 22 02 01 38 30 10 80 08 42 06 22 03 00 48 72 F1 02 01 04 83 01 00 00 00 00 00 00 00 00 03 65 99 80 02 73 81 70 00 69 A5 CC 01 7B 2A F8 01 12 FA 18 02 73 81 80 01 13 07 88 04 73 21 85 25 03 00 48 02 73 82 38 07 00 11 04 23 94 05 00 12 00 40 62 3E 48 04 00 1F 06 F4 6B 01 1B BE F8 00 00 00 00 05 01 01 01 A0 0D 60 0B 02 73 82 20 04 00 00 01 00 0E 03 6C 1A A1 18 02 01 22 02 01 38 30 10 80 08 42 06 22 01 7A D8 80 F1 02 01 04 83 01 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 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 03 5E 68 0C 00 00 00 02 02 73 82 30 00 A4 32 5C 02 73 82 30 00 A4 2E 64 03 65 99 80 00 81 F7 58 00 00 00 00 00 00 00 00 03 65 99 80 00 A4 2D DC 02 73 82 38 00 A4 2E 08 02 73 82 48 00 81 F7 6C 00 00 00 00 00 00 00 02 02 73 82 58 00 81 F6 C4 00 00 90 32 00 00 00 00 02 73 82 60 00 80 5A E8 02 73 82 70 01

(04 Sep '12, 07:06) SerijVeter

That does not explain where the data comes from ($msg in your perl script) and that's the place where the concatenation of several packets most certainly takes place. Can you please be more specific?

(04 Sep '12, 14:32) Kurt Knochner ♦

More specific? Ok. On one side - Huawei GGSN02 node. On other side - Mediant 3000. And all i have for now is perl script that tries to decode incoming messages. All we cant tell for sure is 5 bytes from 36 to 40 - MTP3 header. All the rest mast be the SCCP part. But for now i can't understand first 35 bytes and i can't tell for sure is thee one packet with some garbage, or there are two packets.

(05 Sep '12, 01:41) SerijVeter

O.K., by "specific" I meant something different ;-). How do you get the data into the perl script? Do you read from a pipe, a log file, etc.? Maybe there is a bug in your perl script or the component that provides the data.

(05 Sep '12, 03:06) Kurt Knochner ♦

Sorry. Some misunderstanding :) Script listens a socket, opened to our Mediant, and waits for incoming UDP messages. So it is a pipe.

(05 Sep '12, 03:32) SerijVeter

O.K. then it could be a problem with your perl script. Is it possible to capture that socket with Wireshark in parallel and then compare that with the hexdump delivered by the script?

(05 Sep '12, 03:56) Kurt Knochner ♦

I'll see what can be done. Also i can show your more then one dump. Maybe it generates some more ideas. As i can see that 12 byte is always 00 or 01. Our mediant has two channels. So may be 12 byte indicates channel - first or second. Also bytes 2 and 3 are some sort of counter. Don't know...

(05 Sep '12, 04:09) SerijVeter

40 bytes from the beginning in four variants, one by one:

01 95 29 54 FF FF 00 00 00 00 00 01 00 00 00 02 02 3A 7F 18 02 3A 7F 18 03 65 95 00 00 00 00 6D F2 99 3F 83 B2 D3 EB 44

01 95 2A 54 FF FF 00 00 00 00 00 00 00 00 00 02 02 3A 7F 18 02 3A 7F 18 03 65 95 00 00 00 00 6D 99 F3 3F 83 AF 93 EC 84

01 A6 2B 54 FF FF 00 00 00 00 00 01 00 00 00 02 02 3A 7F 18 02 3A 7F 18 03 65 95 00 00 00 00 7E F2 9A 3F 83 B2 D3 EB F4

01 A6 2C 54 FF FF 00 00 00 00 00 00 00 00 00 02 02 3A 7F 18 02 3A 7F 18 03 65 95 00 00 00 00 7E 9A F4 3F 83 AF 93 EC 94

(05 Sep '12, 04:11) SerijVeter

well, I think it will help more to comapre the wireshark data with the hex dump of the script first. Only if that comparison delivers the same result, I would suggest to digg into the script or to analyze the way data is sent to that socket.

(05 Sep '12, 04:38) Kurt Knochner ♦

First thing that jumped out at me is the TCAP length is 0x64 (70 bytes). Wireshark is being told to find 70 octets after that length field. Look near the beginning of that dump for the string "46 62 44 48 04 0E 00 03 77". That says "70 octets, TCAP BEGIN, 68 octets, OrigTransId, length 4 octets, TID: 0e000377". This appears to be a SendAuthInfo (opcode 0x38). With IMSI: 246022300097425.

Neither I now Wireshark have a clue how to interpret the noise that occurs after the 70 octets.

(07 May '15, 08:34) tiger762
showing 5 of 10 show 5 more comments

Hmmm, well, the SCCP, TCAP, and MAP parts all look fine to me. And you've got a total of 374 octets there which is bigger than a single SCCP message could be (well, okay, an LUDT could be that big but this is not an LUDT). I'd guess that whatever follows the end of the message isn't really part of that message but something else entirely (maybe just junk left by whatever recorded the message).

It does not look to me (based on some rough scanning) that the following bytes are not another SCCP message.

I'd suggest checking with whatever tool recorded the message to see what it thinks those extra octets are.

permanent link

answered 28 Aug '12, 08:35

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k572
accept rate: 27%

Whatever it is, it's probably a concatenation of serveral messages, as serveral byte pattern are repeated in the byte stream. How did you create the hex dump?

TCAP, as displayed in Wireshark

0020  62 44 48 04 0e 00 03 77  6b 1e 28 1c 06 07 00 11   bDH....w k.(.....
0030  86 05 01 01 01 a0 11 60  0f 80 02 07 80 a1 09 06   .......` ........
0040  07 04 00 00 01 00 0e 03  6c 80 a1 18 02 01 01 02   ........ l.......
0050  01 38 30 10 80 08 42 06  22 03 00 79 24 f5 02 01   .80...B. "..y$...
0060  01 83 01 00 00 0

Same byte pattern, later in the byte stream. Could be TCAP as well.

0090                                 62 44 48 04 0e 00             FbDH...
00a0  03 77 6b 1e 01 1b be f8  00 00 00 00 01 01 01 a0   .wk..... ........
00b0  11 60 0f 80 02 73 82 20  09 06 07 04 00 00 01 00   .`...s.  ........
00c0  0e 03 6c 80 a1 18 02 01  01 02 01 38 30 10 80 08   ..l..... ...80...
00d0  01 7a d8 80 00 79 24 f5  02 01 01 83 01 00 00 00   .z...y$. ........

The same for parts of the SCCP message (as displayed in Wireshark)

0000                                 04 73 21 85 25 03   ........ .r.s!.%.
0010  00 79 24 0b 12 07 00 11  04 53 97 79 10 00 00 46   .y$..... .S.y...F

later in the byte stream

0080              04 73 21 85  25 03 00 79 02 73 82 38   .....s!. %..y.s.8
0090  00 11 04 53 97 79 10 00  00 46                     ...S.y.. .FbDH...

Regards
Kurt

permanent link

answered 28 Aug '12, 10:32

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 28 Aug '12, 10:33

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×13

question asked: 28 Aug '12, 06:21

question was seen: 4,255 times

last updated: 07 May '15, 08:34

p​o​w​e​r​e​d by O​S​Q​A