I have a pcap file that contains the sendAuthenticationInfo message.
I try to parse the sccp layer from this packet using tshark
I tried the following:
tshark.exe -r filter.pcap -T fields -e sccp > parse.bin
I know what the result should be from parsing manually in wireshark, the result I get is much shorter and different from expected.
Original packet:
d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00
00 00 00 01 01 00 00 00 f0 52 7a 57 9a d7 00 00
ba 00 00 00 ba 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 08 00 45 00 00 ac 00 00 00 00 10 84
ab cc 7f 00 00 01 7f 00 00 01 0b 58 0b 59 00 00
48 23 01 f3 c7 60 00 03 00 8c 00 00 1f 7a 00 01
00 00 00 00 00 03 01 00 01 01 00 00 00 7c 02 10
00 72 00 00 04 3a 00 00 02 4e 03 02 00 04 09 80
03 0e 19 0b 12 06 00 11 04 79 52 14 02 10 07 0b
12 07 00 12 04 44 87 92 97 01 08 44 62 42 48 04
00 00 00 01 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 1a a1 18 02 01 01 02 01 38 30 10
80 08 24 05 01 77 03 84 35 f8 02 01 01 83 01 00
00 00
expected result:
09 80 03 0e 19 0b 12 06 00 11 04 79 52 14 02 10
07 0b 12 07 00 12 04 44 87 92 97 01 08 44 62 42
48 04 00 00 00 01 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 1a a1 18 02 01 01 02 01 38
30 10 80 08 24 05 01 77 03 84 35 f8 02 01 01 83
01 00
result I got:
73 63 63 70 0d 0a
Related
All values are in hexadecimal number system. On Pentium in protected mode, registers have the following value: LDTR = 06000000, GDTR = 08000000, CR3 = 10000000, DS = 14, CS = 0034 CR0 = 00000001.
If the instruction (e.g. MOV AL, [2A66] accesses the logical address 2A66, what physical address does it access? At what address is the segment descriptor located? Current memory status, looking at absolute addresses is:
........
06000000 CD 20 FF 9F 00 9A EE FE 1D F0 4F 03 22 05 8A 03
06000010 22 05 17 03 22 93 0D 04 01 01 01 00 02 FF FF FF
.........
08000000 CA 20 FF 9F 00 9A E3 FE 1D F2 4F 08 23 05 8A 07
08000010 26 05 19 03 22 05 0D 04 01 02 01 00 02 FF FA FF
.........
10000020 3A 56 21 40 2A 38 42 18 2A 56 42 40 8E 48 42 18
10000030 2A 36 42 40 9A 48 42 18 7A 56 42 20 8E 48 42 18
10000040 23 60 42 40 4E A8 42 18 5A 56 42 40 8E 48 42 18
.........
40426860 C6 06 23 99 00 80 3E 1D 96 00 74 03 E9 99 00 E8
40426870 A6 01 E8 FF 03 75 19 80 3E C4 98 00 34 00 AD 0A
40426880 13 96 00 BA E9 89 75 03 E9 17 01 C6 06 1F 99 01
40426890 B8 00 6C BE 08 98 BB 21
.........
C6011D70 C6 06 23 99 00 80 3E 1D 96 00 74 03 E9 99 00 E8
C6011D80 A6 01 E8 FF 03 75 19 80 3E C4 98 00 34 00 AD 0A
C6011D90 13 96 00 BA E9 89 75 03 E9 17 01 C6 06 1F 99 01
Could you give me some guidelines what is the problem here and what I need to know to solve it? Operating systems and registry is new to me, so I don't know what I'm supposed to do here. I don't know even where should I start.
I'm currently trying to extract the raw payload from an ICMP packet.
I've managed to trim it down to the format I like (without the first 5 characters on each line and without the ....... stuff).
Original format:
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 10 b4 00 00 00 00 50 4b 03 04 14 00 c.........PK....
0030 09 00 08 00 92 ac 88 51 e2 f5 38 a1 6d 70 03 00 .......Q..8.mp..
0040 94 72 03 00 08 00 1c 00 66 6c 61 67 2e 6a 70 67 .r......thing.jpg
0050 55 54 09 00 03 d3 e3 cf 5f e7 UT......_.
Scripts:
awk '{x="";x=substr($0,5,50);gsub(/ +/,"",x);print x}' nontrimmed.txt > raw.txt
tr -d "\n" < raw,txt > newraw.txt
Result:
cafe0000babedead0000beef08004500004c0001000040019b48c0a801c8b9f56302080010b400000000504b030414000900080092ac8851e2f538a16d7003009472030008001c00666c61672e6a70675554090003d3e3cf5fe7cafe0000babedead0000beef08004500004c0001000040019b48c0a801c8b9f5630208005b5000000000e3cf5f75780b000104e803000004e80300003bc....ect
However, I'd like to get a specific number of bytes every x characters - i.e this:
ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00
00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5
63 02 08 00 10 b4 00 00 00 00 50 4b 03 04 14 00
09 00 08 00 92 ac 88 51 e2 f5 38 a1 6d 70 03 00
94 72 03 00 08 00 1c 00 66 6c 61 67 2e 6a 70 67
55 54 09 00 03 d3 e3 cf 5f e7
Would become this:
504b030414000900080092ac8851e2f538a16d7003009472030008001c00666c61672e6a70675554090003d3e3cf5fe7
Instead of this:
cafe0000babedead0000beef08004500004c0001000040019b48c0a801c8b9f56302080010b400000000504b030414000900080092ac8851e2f538a16d7003009472030008001c00666c61672e6a70675554090003d3e3cf5fe7cafe0000babedead0000beef08004500004c0001000040019b48c0a801c8b9f5630208005b5000000000e3cf5f75780b000104e803000004e80300003bc....ect
But for multiple different ones of the same format:
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 10 b4 00 00 00 00 50 4b 03 04 14 00 c.........PK....
0030 09 00 08 00 92 ac 88 51 e2 f5 38 a1 6d 70 03 00 .......Q..8.mp..
0040 94 72 03 00 08 00 1c 00 66 6c 61 67 2e 6a 70 67 .r......flag.jpg
0050 55 54 09 00 03 d3 e3 cf 5f e7 UT......_.
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 5b 50 00 00 00 00 e3 cf 5f 75 78 0b c...[P......_ux.
0030 00 01 04 e8 03 00 00 04 e8 03 00 00 3b c1 7d b7 ............;.}.
0040 30 0b ce 53 1e 99 d2 3a 1b 83 4c 7c be cd ef fa 0..S...:..L|....
0050 54 86 4d 24 19 58 c5 a9 b1 4d T.M$.X...M
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 3e f4 00 00 00 00 dd 56 4c 00 11 bf c...>......VL...
0030 42 22 2a 52 86 75 01 0a e2 90 90 f5 2b ec d0 67 B"*R.u......+..g
0040 74 5a 17 70 05 b6 27 35 21 cf 98 fb a2 5e 82 a8 tZ.p..'5!....^..
0050 56 f9 05 05 3d 3e 80 3f 68 23 V...=>.?h#
Any ideas? Thanks!
Is this what you're trying to do?
$ awk -v OFS= '{$1=$NF=""; x=x $0} END{print substr(x,85)}' file
504b030414000900080092ac8851e2f538a16d7003009472030008001c00666c61672e6a70675554090003d3e3cf5fe7
The above was run against your "Original format" input file:
$ cat file
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 10 b4 00 00 00 00 50 4b 03 04 14 00 c.........PK....
0030 09 00 08 00 92 ac 88 51 e2 f5 38 a1 6d 70 03 00 .......Q..8.mp..
0040 94 72 03 00 08 00 1c 00 66 6c 61 67 2e 6a 70 67 .r......thing.jpg
0050 55 54 09 00 03 d3 e3 cf 5f e7 UT......_.
If your input file can contain multiple records then:
$ awk -v OFS= '{$1=$NF=""; $0=$0; x=x $0} !NF{print substr(x,85); x=""} END{print substr(x,85)}' file
504b030414000900080092ac8851e2f538a16d7003009472030008001c00666c61672e6a70675554090003d3e3cf5fe7
e3cf5f75780b000104e803000004e80300003bc17db7300bce531e99d23a1b834c7cbecdeffa54864d241958c5a9b14d
dd564c0011bf42222a528675010ae29090f52becd067745a177005b6273521cf98fba25e82a856f905053d3e803f6823
That second script was run against the block of 3 records under "But for multiple different ones of the same format:" at the end of your question but you didn't provide the expected output for it so idk if that's the expected output or not:
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 10 b4 00 00 00 00 50 4b 03 04 14 00 c.........PK....
0030 09 00 08 00 92 ac 88 51 e2 f5 38 a1 6d 70 03 00 .......Q..8.mp..
0040 94 72 03 00 08 00 1c 00 66 6c 61 67 2e 6a 70 67 .r......flag.jpg
0050 55 54 09 00 03 d3 e3 cf 5f e7 UT......_.
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 5b 50 00 00 00 00 e3 cf 5f 75 78 0b c...[P......_ux.
0030 00 01 04 e8 03 00 00 04 e8 03 00 00 3b c1 7d b7 ............;.}.
0040 30 0b ce 53 1e 99 d2 3a 1b 83 4c 7c be cd ef fa 0..S...:..L|....
0050 54 86 4d 24 19 58 c5 a9 b1 4d T.M$.X...M
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 3e f4 00 00 00 00 dd 56 4c 00 11 bf c...>......VL...
0030 42 22 2a 52 86 75 01 0a e2 90 90 f5 2b ec d0 67 B"*R.u......+..g
0040 74 5a 17 70 05 b6 27 35 21 cf 98 fb a2 5e 82 a8 tZ.p..'5!....^..
0050 56 f9 05 05 3d 3e 80 3f 68 23 V...=>.?h#
I am trying to use mitmproxy to look at the traffic from my win32 schannel tls client. But when I try to use mitmproxy the following messages throw an "Bad HTTP request line" error with a leading 0 in the binary dump that does not exsist in the data that my client sends (I have checked with a little python server).
"CONNECT www.example.com:443 HTTP/1.0\r\n\r\n"
"HTTP/1.0 200 Connection established\r\n\r\n"
Send Tls Client Hello:
16 03 03 00 AC 01 00 00 A8 03 03 5F 80 1A 2D F6 2A 59 DE 18
69 F0 BB 3C 2D 2B 11 90 F8 8C A7 F9 D7 96 CD DC 32 88 02 22
11 90 6A 00 00 2A C0 2C C0 2B C0 30 C0 2F 00 9F 00 9E C0 24
C0 23 C0 28 C0 27 C0 0A C0 09 C0 14 C0 13 00 9D 00 9C 00 3D
00 3C 00 35 00 2F 00 0A 01 00 00 55 00 00 00 14 00 12 00 00
0F 77 77 77 2E 65 78 61 6D 70 6C 65 2E 63 6F 6D 00 0A 00 08
00 06 00 1D 00 17 00 18 00 0B 00 02 01 00 00 0D 00 1A 00 18
08 04 08 05 08 06 04 01 05 01 02 01 04 03 05 03 02 03 02 02
06 01 06 03 00 23 00 00 00 17 00 00 FF 01 00 01 00
Bad HTTP request line: b"\x00\x16\x03\x03\x00\xac\x01\x00\x00\xa8\x03\x03_\x80\x17\xbd\x1f\xf3\x8fO\xddy\xfb\xaaR\x1c\xeb\xe0sdD\xb7}|\xeb\xbes\xdf$3\xb6\xd9\ry\x00\x00*\xc0,\xc0+\xc00\xc0/\x00\x9f\x00\x9e\xc0$\xc0#\xc0(\xc0'\xc0"
Now my question: Is this just a lack of understanding in how proxys and tls work or an error from mitmproxy?
I'm trying to read a file in matlab using fscanf. The file is the dump of a some memory area in a microcontroller. I export it from the IDE and the encoding is 'ISO-8859-1'.
Here's one line from the file as I open it in matlab:
25 08 00 00 7E 05 00 00 08 08 00 00 85 05 00 00 0D 06 00 00 76 06 00 00 04 0C 00 00 FB 07 00 00
3A 06 00 00 0C 06 00 00 01 06 00 00 0C 06 00 00 C3 05 00 00 EF 05 00 00 05 06 00 00 FF 05 00 00
EF 05 00 00 FB 05 00 00 89 08 00 00 74 06 00 00 0D 06 00 00 FC 05 00 00 10 06 00 00 C3 05 00 00
C5 05 00 00 F2 05 00 00 81 05 00 00 1C 06 00 00 85 05 00 00 F0 05 00 00 C2 05 00 00 5F 05 00 00
(here the complete file)
And this is correct: same numbers I see in the IDE.
What I do is:
fileID = fopen('testdataadc.txt','r','n','ISO-8859-1');
% Read all characters excluding white spaces.
vecDump = fscanf(fileID, '%s' ,[25 Inf]);
fclose(fileID);
Where 'n' is for native endiannes: Your system byte ordering (default).
And now the first column in vecDump (which is a 25x64 char variable):
25060000F5080000F8070000F0050000E5050000FC060000EF06000000070000
The format is the one I expected, but values are wrong.
For example:
25 08 00 00 becomes 25 06 00 00
7E 05 00 00 becomes F5 08 00 00
What am I doing wrong here?
The output of fscanf is a 25x64 char matrix. The data from the file fills this matrix column-wise. If you look along the first column, you will see: "250800007E05", etc. Because the file has 64 non-space characters along each row, you should read the file into a 64xN matrix, and then transpose it:
vecDump = fscanf(fileID, '%s', [64,Inf]).'
Now vecDump will look like your file, but without the spaces.
My managed process is suspected to have caused a BSOD at a client site. I received a full memory dump (i.e.: including kernel, physical pages only) - but still am not able to inspect my process' stacks.
After switching to my process context -
.process /p /r <MyProcAddress>
I see only -
1: kd> k
# ChildEBP RetAddr
00 b56e3b70 81f2aa5d nt!KeBugCheckEx+0x1e
01 b56e3b94 81e7b68d nt!PspCatchCriticalBreak+0x71
02 b56e3bc4 81e6dfd1 nt!PspTerminateAllThreads+0x2d
03 b56e3bf8 8d48159a nt!NtTerminateProcess+0xcd
WARNING: Stack unwind information not available. Following frames may be wrong.
04 b56e3c24 81c845e4 klif+0x7559a
05 b56e3c24 77da6bb4 nt!KiSystemServicePostCall
06 0262f34c 00220065 ntdll!KiFastSystemCallRet
07 0262f390 003e0022 0x220065
08 0262f394 0073003c 0x3e0022
09 0262f398 00730079 0x73003c
0a 0262f39c 006e003a 0x730079
0b 0262f3a0 006d0061 0x6e003a
0c 0262f3a4 00200065 0x6d0061
0d 0262f3a8 00610076 0x200065
0e 0262f3ac 0075006c 0x610076
0f 0262f3b0 003d0065 0x75006c
10 0262f3b4 00770022 0x3d0065
11 0262f3b8 006e0069 0x770022
12 0262f3bc 006f0077 0x6e0069
13 0262f3c0 00640072 0x6f0077
14 0262f3c4 00200022 0x640072
...
Which is natural for managed process. SOS extension does not work for kernel dumps.
Is there anything I can do to view the throwing managed stack? It was previously said to be 'much more difficult', but hopefully not impossible.
PS.
I'm aware of the presence of Kaspersky driver kilf.sys in the stack, and this is my personal suspect. But the question is more general - hopefully there's a way to understand what my process was doing at the time.
the stack as you posted is not correct
it appears to be overwritten or is a result of some other artefact
with such a stack details you will have a hard time deciphering
anything useful at all
the contents of stack converted to a printable range in english looks like this
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 00 3E 00 22 00 22 00 65 00 73 00 3C 00 3E 00 22 .>.".".e.s.<.>."
00000010 00 73 00 79 00 73 00 3C 00 6E 00 3A 00 73 00 79 .s.y.s.<.n.:.s.y
00000020 00 6D 00 61 00 6E 00 3A 00 20 00 65 00 6D 00 61 .m.a.n.:. .e.m.a
00000030 00 61 00 76 00 20 00 65 00 75 00 6C 00 61 00 76 .a.v. .e.u.l.a.v
00000040 00 3D 00 65 00 75 00 6C 00 77 00 22 00 3D 00 65 .=.e.u.l.w.".=.e
00000050 00 6E 00 69 00 77 00 22 00 6F 00 77 00 6E 00 69 .n.i.w.".o.w.n.i
00000060 00 64 00 72 00 6F 00 77 00 20 00 22 00 64 00 72 .d.r.o.w. .".d.r
try !analyze -v and see what is the bsod analysis results