[cifs-protocol] [REG:110071868986368] unused bytes after while decoding bkrp requests
Bryan Burgin
bburgin at microsoft.com
Tue Aug 10 16:42:53 MDT 2010
Matthieu,
We completed our review. The raw, unencrypted data you provided is:
Raw data:
----------
64 0c 27 47 c7 2f 9b 49 ac 5b 0e 37 cd ce 89 9a # 00000000
74 01 00 00 02 00 00 00 00 01 00 00 58 00 00 00 # 00000010
bd 8b dc a1 3f 74 3e 47 8d 00 0a 47 42 df 76 bd # 00000020
30 e5 9a 15 1b 59 b8 1e b6 b8 2a d0 9f 30 aa b3 # 00000030
12 9a 98 55 63 d2 11 e4 41 00 db 37 9c d9 86 63 # 00000040
a1 30 1d 8c f4 25 00 16 e2 c1 b0 36 89 10 83 56 # 00000050
ad 8f 0b 11 60 20 c4 07 81 77 c1 d4 95 7d 81 e8 # 00000060
cc a6 bf c5 f5 23 8d 29 2e 9c 8d 21 ff c3 b7 c3 # 00000070
ba 14 35 ec 6f 50 24 14 17 83 5f dc bc 2a d9 f6 # 00000080
ee f9 4f 63 16 0a fc 93 b4 a2 4c 10 cf 28 54 55 # 00000090
7e a7 47 db 24 96 e4 dd 5f 4c 0c 4d c8 17 c9 53 # 000000a0
db 58 98 03 f6 f9 19 ec 56 b0 8d f5 39 9d fb ea # 000000b0
59 dd eb 3d a0 af 1b 7c e1 85 22 d2 19 45 a8 14 # 000000c0
2a 8f 26 3d 3e 4f c8 4d b5 b4 eb 49 6b 16 c2 5f # 000000d0
a7 3b 1e d3 25 e9 84 c0 30 d9 56 f7 15 89 d5 ac # 000000e0
40 96 14 ed 02 cf 66 03 ee f5 79 a3 c6 4e 59 fe # 000000f0
01 07 da 5f d1 b8 d6 e3 15 28 78 83 4b f6 5b d6 # 00000100
b0 10 b7 74 5f aa aa c4 4f 53 e7 1f fd e4 ab a3 # 00000110
bb f3 98 5c 47 ea 2b a5 bf a1 be a2 3b 3b 13 6a # 00000120
aa 5e 85 dd fb df 5c 8e 0f c4 9e df 43 b7 b8 aa # 00000130
01 17 f6 d4 93 cb 35 b9 9f 57 2a ed 8d 6f dc 4d # 00000140
9c ae 9f 2a 45 c9 bb f5 48 8a 3e 98 62 93 b8 20 # 00000150
77 0e 8f 24 75 16 12 2e 7b f0 b9 61 1d ee 8f 2a # 00000160
ed fb ed 39 41 ba 73 91 68 0c 21 4b 9d 2e 13 3b # 00000170
4a 5a 96 83 74 4d 52 34 74 01 00 00 00 00 00 00 # 00000180
8a e3 13 71 02 f4 36 71 02 40 28 00 30 7c de 3d # 00000190
5d 16 d1 11 ab 8f 00 80 5f 14 db 40 01 00 00 00 # 000001a0
04 5d 88 8a eb 1c c9 11 9f e8 08 00 2b 10 48 60 # 000001b0
02 00 00 00 # 000001c0
Which you decoded as follows with an unexplained 52 bytes trailing:
Decoded data:
--------------
BACKUPKEY_RESTORE_GUID {47270C64-2FC7-499B-AC5B-0E37CDCE899A}
64 0c 27 47 c7 2f 9b 49 ac 5b 0e 37 cd ce 89 9a # 00000000
Length 0x174 (372)
74 01 00 00 .. .. .. .. .. .. .. .. .. .. .. .. # 00000010
2.2.2 Client-Side-Wrapped Secret
dwVersion (2) BACKUPKEY_RECOVERY_BLOB_VERSION_VISTA)
cbEncryptedSecret (256)
cbAccessCheck (88)
.. .. .. .. 02 00 00 00 00 01 00 00 58 00 00 00 # 00000010
guidKey: {a1dc8bbd-743f-473e-8d00-0a4742df76bd}
bd 8b dc a1 3f 74 3e 47 8d 00 0a 47 42 df 76 bd # 00000020
EncryptedSecret (for 256 bytes):
30 e5 9a 15 1b 59 b8 1e b6 b8 2a d0 9f 30 aa b3 # 00000030
12 9a 98 55 63 d2 11 e4 41 00 db 37 9c d9 86 63 # 00000040
a1 30 1d 8c f4 25 00 16 e2 c1 b0 36 89 10 83 56 # 00000050
ad 8f 0b 11 60 20 c4 07 81 77 c1 d4 95 7d 81 e8 # 00000060
cc a6 bf c5 f5 23 8d 29 2e 9c 8d 21 ff c3 b7 c3 # 00000070
ba 14 35 ec 6f 50 24 14 17 83 5f dc bc 2a d9 f6 # 00000080
ee f9 4f 63 16 0a fc 93 b4 a2 4c 10 cf 28 54 55 # 00000090
7e a7 47 db 24 96 e4 dd 5f 4c 0c 4d c8 17 c9 53 # 000000a0
db 58 98 03 f6 f9 19 ec 56 b0 8d f5 39 9d fb ea # 000000b0
59 dd eb 3d a0 af 1b 7c e1 85 22 d2 19 45 a8 14 # 000000c0
2a 8f 26 3d 3e 4f c8 4d b5 b4 eb 49 6b 16 c2 5f # 000000d0
a7 3b 1e d3 25 e9 84 c0 30 d9 56 f7 15 89 d5 ac # 000000e0
40 96 14 ed 02 cf 66 03 ee f5 79 a3 c6 4e 59 fe # 000000f0
01 07 da 5f d1 b8 d6 e3 15 28 78 83 4b f6 5b d6 # 00000100
b0 10 b7 74 5f aa aa c4 4f 53 e7 1f fd e4 ab a3 # 00000110
bb f3 98 5c 47 ea 2b a5 bf a1 be a2 3b 3b 13 6a # 00000120
AccessCheck (for 88 bytes):
aa 5e 85 dd fb df 5c 8e 0f c4 9e df 43 b7 b8 aa # 00000130
01 17 f6 d4 93 cb 35 b9 9f 57 2a ed 8d 6f dc 4d # 00000140
9c ae 9f 2a 45 c9 bb f5 48 8a 3e 98 62 93 b8 20 # 00000150
77 0e 8f 24 75 16 12 2e 7b f0 b9 61 1d ee 8f 2a # 00000160
ed fb ed 39 41 ba 73 91 68 0c 21 4b 9d 2e 13 3b # 00000170
4a 5a 96 83 74 4d 52 34 .. .. .. .. .. .. .. .. # 00000180
Size again (0x174) data_in_len and zero param
.. .. .. .. .. .. .. .. 74 01 00 00 00 00 00 00 # 00000180
Trailing unexplained 52 bytes :
8a e3 13 71 02 f4 36 71 02 40 28 00 30 7c de 3d # 00000190
5d 16 d1 11 ab 8f 00 80 5f 14 db 40 01 00 00 00 # 000001a0
04 5d 88 8a eb 1c c9 11 9f e8 08 00 2b 10 48 60 # 000001b0
02 00 00 00 # 000001c0
These 52 bytes is the MS-RPCE Verification Trailer specified in MS-RPCE 2.2.2.13, as follows:
Eight-byte signature octets {0x8a, 0xe3, 0x13, 0x71, 0x02, 0xf4, 0x36, 0x71}:
8a e3 13 71 02 f4 36 71 .. .. .. .. .. .. .. .. # 00000190
Four-byte rcp_sec_vt_pcontext header:
(0x4002 & 3fff) = 0x0002 = rpc_sec_vt_pcontext command
0x0028 = length
.. .. .. .. .. .. .. .. 02 40 28 00 .. .. .. .. # 00000190
rcp_sec_vt_pcontext InterfaceId and TransferSyntax (MS-RPCE 2.2.2.13.4) consume the remaining 40 (0x28) bytes:
.. .. .. .. .. .. .. .. .. .. .. .. 30 7c de 3d # 00000190
5d 16 d1 11 ab 8f 00 80 5f 14 db 40 01 00 00 00 # 000001a0
04 5d 88 8a eb 1c c9 11 9f e8 08 00 2b 10 48 60 # 000001b0
02 00 00 00 # 000001c0
Bryan
From: Bryan Burgin
Sent: Tuesday, August 10, 2010 10:03 AM
To: 'mat at samba.org'
Cc: 'pfif at tridgell.net'; 'cifs-protocol at samba.org'; MSSolve Case Email
Subject: RE: [REG:110071868986368] unused bytes after while decoding bkrp requests
Hi, Matthieu,
Just a quick update. I have a pending TDI with the BKRP team to verify our findings that these bytes are unused and should be ignored if received.
Your other three issues we're distributed to other team members and they are contacting you separately.
Bryan
From: Bryan Burgin
Sent: Monday, July 26, 2010 9:36 AM
To: 'mat at samba.org'
Cc: pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
Subject: RE: [REG:110071868986368] unused bytes after while decoding bkrp requests
Hi, Matthieu,
I made some progress on this last week, but I wanted to close in on a few loose ends before I sent any conclusions. But, let me indicate where I am.
Below is the buffer you provided:
640c2747 c72f9b49 ac5b0e37 cdce899a # 00000000 d.'G./.I.[.7....
74010000 02000000 00010000 58000000 # 00000010 t...........X...
bd8bdca1 3f743e47 8d000a47 42df76bd # 00000020 ....?t>G...GB.v.
30e59a15 1b59b81e b6b82ad0 9f30aab3 # 00000030 0....Y....*..0..
129a9855 63d211e4 4100db37 9cd98663 # 00000040 ...Uc...A..7...c
a1301d8c f4250016 e2c1b036 89108356 # 00000050 .0...%.....6...V
ad8f0b11 6020c407 8177c1d4 957d81e8 # 00000060 ....` ...w...}..
cca6bfc5 f5238d29 2e9c8d21 ffc3b7c3 # 00000070 .....#.)...!....
ba1435ec 6f502414 17835fdc bc2ad9f6 # 00000080 ..5.oP$..._..*..
eef94f63 160afc93 b4a24c10 cf285455 # 00000090 ..Oc......L..(TU
7ea747db 2496e4dd 5f4c0c4d c817c953 # 000000a0 ~.G.$..._L.M...S
db589803 f6f919ec 56b08df5 399dfbea # 000000b0 .X......V...9...
59ddeb3d a0af1b7c e18522d2 1945a814 # 000000c0 Y..=...|.."..E..
2a8f263d 3e4fc84d b5b4eb49 6b16c25f # 000000d0 *.&=>O.M...Ik.._
a73b1ed3 25e984c0 30d956f7 1589d5ac # 000000e0 .;..%...0.V.....
409614ed 02cf6603 eef579a3 c64e59fe # 000000f0 @.....f...y..NY.
0107da5f d1b8d6e3 15287883 4bf65bd6 # 00000100 ..._.....(x.K.[.
b010b774 5faaaac4 4f53e71f fde4aba3 # 00000110 ...t_...OS......
bbf3985c 47ea2ba5 bfa1bea2 3b3b136a # 00000120 ...\G.+.....;;.j
aa5e85dd fbdf5c8e 0fc49edf 43b7b8aa # 00000130 .^....\.....C...
0117f6d4 93cb35b9 9f572aed 8d6fdc4d # 00000140 ......5..W*..o.M
9cae9f2a 45c9bbf5 488a3e98 6293b820 # 00000150 ...*E...H.>.b..
770e8f24 7516122e 7bf0b961 1dee8f2a # 00000160 w..$u...{..a...*
edfbed39 41ba7391 680c214b 9d2e133b # 00000170 ...9A.s.h.!K...;
4a5a9683 744d5234 74010000 00000000 # 00000180 JZ..tMR4t.......
8ae31371 02f43671 02402800 307cde3d # 00000190 ...q..6q.@(.0|<mailto:...q..6q.@(.0|>.=
5d16d111 ab8f0080 5f14db40 01000000 # 000001a0 ]......._..@<mailto:......._..@>....
045d888a eb1cc911 9fe80800 2b104860 # 000001b0 .]..........+.H`
02000000 # 000001c0 ....
I was focused on your specific question regarding the apparent extra 52 bytes. I found the code where I believe this structure is allocated and it appears that we do some rounding-up as we determine how many bytes to allocate. And then, when we encrypt and send the buffer, the total allocation is transmitted.
It begins with BACKUPKEY_RESTORE_GUID
47270C64-2FC7-499B-AC5B-0E37CDCE899A:
640c2747 c72f9b49 ac5b0e37 cdce899a # 00000000 d.'G./.I.[.7....
It then contains what appears to be the length of the remaining buffer (0x174/372). This caught my attention and I'll discuss this in a bit.
74010000 ........ ........ ........ # 00000010 t...............
Followed with 372(0x174) bytes starting with three DWORDS:
-- Version 2: BACKUPKEY_RECOVERY_BLOB_VERSION_VISTA
-- 0x100 (256): length of Encryption Secret
-- 0x58 (88): length of Access Check
........ 02000000 00010000 58000000 # 00000010 t...........X...
-- GUID-Key:
bd8bdca1 3f743e47 8d000a47 42df76bd # 00000020 ....?t>G...GB.v.
-- The encrypted secret (for 256 bytes):
30e59a15 1b59b81e b6b82ad0 9f30aab3 # 00000030 0....Y....*..0..
129a9855 63d211e4 4100db37 9cd98663 # 00000040 ...Uc...A..7...c
a1301d8c f4250016 e2c1b036 89108356 # 00000050 .0...%.....6...V
ad8f0b11 6020c407 8177c1d4 957d81e8 # 00000060 ....` ...w...}..
cca6bfc5 f5238d29 2e9c8d21 ffc3b7c3 # 00000070 .....#.)...!....
ba1435ec 6f502414 17835fdc bc2ad9f6 # 00000080 ..5.oP$..._..*..
eef94f63 160afc93 b4a24c10 cf285455 # 00000090 ..Oc......L..(TU
7ea747db 2496e4dd 5f4c0c4d c817c953 # 000000a0 ~.G.$..._L.M...S
db589803 f6f919ec 56b08df5 399dfbea # 000000b0 .X......V...9...
59ddeb3d a0af1b7c e18522d2 1945a814 # 000000c0 Y..=...|.."..E..
2a8f263d 3e4fc84d b5b4eb49 6b16c25f # 000000d0 *.&=>O.M...Ik.._
a73b1ed3 25e984c0 30d956f7 1589d5ac # 000000e0 .;..%...0.V.....
409614ed 02cf6603 eef579a3 c64e59fe # 000000f0 @.....f...y..NY.
0107da5f d1b8d6e3 15287883 4bf65bd6 # 00000100 ..._.....(x.K.[.
b010b774 5faaaac4 4f53e71f fde4aba3 # 00000110 ...t_...OS......
bbf3985c 47ea2ba5 bfa1bea2 3b3b136a # 00000120 ...\G.+.....;;.j
-- The Access Check (for 88 bytes)
aa5e85dd fbdf5c8e 0fc49edf 43b7b8aa # 00000130 .^....\.....C...
0117f6d4 93cb35b9 9f572aed 8d6fdc4d # 00000140 ......5..W*..o.M
9cae9f2a 45c9bbf5 488a3e98 6293b820 # 00000150 ...*E...H.>.b..
770e8f24 7516122e 7bf0b961 1dee8f2a # 00000160 w..$u...{..a...*
edfbed39 41ba7391 680c214b 9d2e133b # 00000170 ...9A.s.h.!K...;
4a5a9683 744d5234 ........ ........ # 00000180 JZ..tMR4........
Following the 372 (0x174) bytes, I see the length again and zero
........ ........ 74010000 00000000 # 00000180 ........t.......
Which you identified as:
> data_in_len : 0x00000174 (372)
> param : 0x00000000 (0)
> dump OK
In your original mail.
Lastly, I see the unused 52 bytes at the end:
[extra 52 bytes starts here]
8ae31371 02f43671 02402800 307cde3d # 00000190 ...q..6q.@(.0|<mailto:...q..6q.@(.0|>.=
5d16d111 ab8f0080 5f14db40 01000000 # 000001a0 ]......._..@<mailto:......._..@>....
045d888a eb1cc911 9fe80800 2b104860 # 000001b0 .]..........+.H`
02000000 # 000001c0 ....
I'm fairly certain that these 52 trailing bytes are unused and should be ignored. But, I got side tracked looking at what appears to be a length field immediately following the BACKUPKEY_RESTORE_GUID and that it appears to be replicated immediately following the buffer as if they were bookends.
Let me fully read the message you just sent as it has a couple of questions. I wanted to share with you the status of where I was on your original question.
Bryan
-----Original Message-----
From: Matthieu Patou [mailto:mat at samba.org]
Sent: Sunday, July 25, 2010 1:55 PM
To: Bryan Burgin
Cc: pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
Subject: Re: [REG:110071868986368] unused bytes after while decoding bkrp requests
Hi Bryan
Any news on this subject ?
In the mean time I worked on the implementation of the protocol for the samba project and have more questions now.
So page 31 of MS-BKRP.pdf state that the message format for exchange is :
NET_API_STATUS BackuprKey(
[in] handle_t h,
[in] GUID* pguidActionAgent,
[in, size_is(cbDataIn)] byte* pDataIn,
[in] DWORD cbDataIn,
[out, size_is(,*pcbDataOut)] byte** ppDataOut,
[out] DWORD* pcbDataOut,
[in] DWORD dwParam
);
I already asked if there is not some bytes after the dwParam.
After analyzing the out message I have the impression that before the
ppDataOut there is some kind of integer.
Here is the hex dump of an output message:
00000000 00 00 02 00 44 00 00 00 00 00 00 00 8d 65 cd e4
|....D........e..|
00000010 6c 93 62 22 48 e7 04 ff 0c 8f 0e 83 7a e4 dd d4
|l.b"H.......z...|
00000020 4b d1 8e 74 95 67 4f 85 be a5 9c b7 7f fd 39 2c
|K..t.gO.......9,|
00000030 54 bc a7 60 e4 e0 13 26 49 6f ca 35 ee bb 23 24
|T..`...&Io.5..#$|
00000040 51 d4 4e c9 37 1d f0 9e 83 69 bd 10 44 00 00 00
|Q.N.7....i..D...|
00000050 00 00 00 00 |....|
00000054
so from byte 4 (0x44 ) we have clearly (at least to me) the ppDataOut
variable that is NDR encoded (meaning that the size is specified before
on the wire) up to byte 4B then we have the size (pcbDataOut) (0x44 0x00
0x00 0x00) and then the return code.
I attach the out message extracted from the trace I sent last time.
With the following samba idl:
[public,nopush,nopull,noprint] WERROR bkrp_BackupKey (
[in,ref] GUID *guidActionAgent,
[in,ref] [subcontext(4)] uint8 *data_in,
[in] uint32 data_in_len,
[in] uint32 param,
[out] uint32 misc,
[out] DATA_BLOB secret,
[out] uint32 data_out_len
);
We have the following result while using our ndrdump tool:
pull returned NT_STATUS_OK
bkrp_BackupKey: struct bkrp_BackupKey
out: struct bkrp_BackupKey
misc : 0x00020000 (131072)
secret : DATA_BLOB length=68
data_out_len : 0x00000044 (68)
result : WERR_OK
dump OK
As I have also managed to get a correct
BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID exchange I also witnessed that on
the out message there is also "something" (that I named misc in our idl)
(see the get_key_out file which is the extraction of out message on a
BACKUPKEY_RETRIEVE_BACKUP_KEY_GUID request). As the certificate that I
extracted seems to be correct I pretty encline to think I am right as
first we are able to parse the NDR encoded data, and that the result
seems sensible.
Can you see if my analysis is correct and if so can you give us the
explanation of this "misc" parameter. If not, well please tell me the
correct way to parse the message.
Also I've got questions of what is explained in the document.
First in paragraph 3.1.4.1.3, it is stated
"The server MUST ignore the cbDataIn and pDataIn parameters. It MUST
return the RSA public key
from the ClientWrap key pair, in the format specified in section 2.2.1.
If no such key can be found or
created, the server MUST return an error."
The client is supposed to send a 2.2.2 Client-Side-Wrapped Secret struct
in the pDataIn variable, this struct contains also a version field and a
guid field.
Nothing is said about this fields, how should they be populated, can you
explain this ?
Second in paragraph 1.3.1 Call Flows, it is stated
"For the ClientWrap subprotocol, the Microsoft implementation of the
BackupKey Remote Protocol
server stores the following LSA global secret objects (note that the LSA
global secret names are
Unicode strings):
1. G$BCKUPKEY_PREFERRED: This contains the 16-byte GUID ([MS-DTYP]
section 2.3.2.2) of the
RSA key pair currently used for client-side secret wrapping.
2. G$BCKUPKEY_guid: Here, guid is the string GUID that identifies the
wrapping key, formatted as a
GUIDString ([MS-DTYP] section 2.3.2.3). The value of the secret object
is the server's ClientWrap
key pair, formatted as specified in section 2.2.5"
Should I conclude that in a given domain there is only "active" rsa key
on all the server or said in another way no matter which server is asked
at a given moment we will always receive the same GUID for the key ?
Also just to be sure this will be stored in the currentValue attribute
but it will be only accessible through a lsaQuerySecret call right ?
Regards.
Matthieu .
On 19/07/2010 03:06, Bryan Burgin wrote:
> [Mark and dochelp to bcc]
> [Adding case number& CaseMail]
>
> Hi Matthieu,
>
> I began looking at this for you to identify the trailing bytes you specified and to investigate tools to decode/parse the Backup Key request. I'll reply with more information as soon as I have more information to share.
>
> Bryan
>
> -----Original Message-----
> From: Mark Miller (MBD)
> Sent: Sunday, July 18, 2010 11:50 AM
> To: mat at samba.org; Interoperability Documentation Help; pfif at tridgell.net; cifs-protocol at samba.org
> Subject: RE: unused bytes after while decoding bkrp requests
>
> Hi Matthieu,
>
> Thank you for your question. A colleague will contact you to investigate this issue.
>
> Regards,
> Mark Miller
> Escalation Engineer
> US-CSS DSC PROTOCOL TEAM
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat at samba.org]
> Sent: Sunday, July 18, 2010 2:27 PM
> To: Interoperability Documentation Help; pfif at tridgell.net; cifs-protocol at samba.org
> Subject: unused bytes after while decoding bkrp requests
>
> Dear dochelp team,
>
> I started to implement the backup key remote protocol for samba.
>
> Right now I'm a bit suspicious I got the data structure ok as when I parse some bytes with ndrdump I have ~52 bytes unused.
>
> From the attached capture called protected_storage.pcap I managed to extract and decrypt the payload (452 bytes + 12 bytes of padding) at packet 485.
> The payload is also attached to this email as protected_xtr.
>
> Here are the result of ndrdump
> mat at ares:/usr/local/src/samba4/source4$ ./bin/ndrdump protected_storage bkrp_BakuprKey in ~/protected_xtr pull returned NT_STATUS_OK WARNING! 52 unread bytes
> [0000] 8A E3 13 71 02 F4 36 71 02 40 28 00 30 7C DE 3D ...q..6q .@(.0|<mailto:.@(.0|>.=
> [0010] 5D 16 D1 11 AB 8F 00 80 5F 14 DB 40 01 00 00 00 ]....... _..@<mailto:_..@>....
> [0020] 04 5D 88 8A EB 1C C9 11 9F E8 08 00 2B 10 48 60 .]...... ....+.H`
> [0030] 02 00 00 00 ....
> bkrp_BakuprKey: struct bkrp_BakuprKey
> in: struct bkrp_BakuprKey
> guidActionAgent : *
> guidActionAgent :
> 47270c64-2fc7-499b-ac5b-0e37cdce899a
> data_in: struct bkrp_client_side_wrapped
> version : 0x00000002 (2)
> encrypted_secret_len : 0x00000100 (256)
> access_check_len : 0x00000058 (88)
> guid :
> a1dc8bbd-743f-473e-8d00-0a4742df76bd
> encrypted_secret : DATA_BLOB length=256
> access_check : DATA_BLOB length=88
> data_in_len : 0x00000174 (372)
> param : 0x00000000 (0)
> dump OK
>
> To me the result looks sensible I'm just concerned that it seems to have some garbage at the end.
>
> I tried to analyze the frames with netmon 3.4 but it says that it's encrypted (and I didn't find a way to tell him to decrypt ...).
>
> So here is my question: is it normal that I found some trailing bytes ?
> do you have the capacity to parse the protected_xtr file and give us the result of the parsing with your tools ?
>
>
> Cheers, Matthieu.
>
--
Matthieu Patou
Samba Team http://samba.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100810/42a6e583/attachment-0001.html>
More information about the cifs-protocol
mailing list