<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: cipe-l,AT,inka,DOT,de
Subject: CIPE-Win32, WIN2K, VC7 (sources, BSOD,encryption)
From: Dmitry Basko <dbasko,AT,rainbow,DOT,by>
Date: Thu, 5 Jun 2003 11:15:51 +0300
In-reply-to: <200306041702.26703.dwilson@ibl.bm>
Organization: Rainbow Technologies
References: <20030604152719.53878.qmail@web13902.mail.yahoo.com><5.2.0.9.0.20030604154333.00b9a7a0@mail.internet2.edu><200306041702.26703.dwilson@ibl.bm>
Reply-to: Dmitry Basko <dbasko,AT,rainbow,DOT,by>

Hello,
1) I'd like to add two words about it also. I started to work with the
project only several days ago (WIN2K, VC7) and noticed that there is
a problem with includes. In my case, I just put winsock2.h
before windows.h, because winsock2.h has following definition inside:
/*
 * Pull in WINDOWS.H if necessary
 */
#ifndef _INC_WINDOWS
#include <windows.h>
#endif /* _INC_WINDOWS */
Alternative way could be not include windows.h after winsock2.h at
all.
Way with _WINSOCKAPI_ will also work, because it excludes winsock.h from
the list of includes, existed in windows.h
MSDN samples includes different scenarios of including winsock2.h

2) I strongly believe that problem with automatic service start
depends on the time and place of the service (driver) in the "start tree" of
other services (drivers) and could be mend with putting correct info
into the registry . If this is not done yet, I will check it later.

3) file CIPESocketIO.cpp, function CipeSocketIO::HandlePeerEvent (...)
looks a little bit strange (at least for me). I mean
switch ()
{
case NK_DATA:
...
case NK_ACK:
CT_DUMMY:
...
CT_KILL:
}
It looks like word "case" was missing, because  NK_ACK and  CT_DUMMY
are members of the same enum.

4) Blowfish encryption. Two WIN2K can not agree about the dynamic key. I 
should
investigate it deeper, but what I see now is:

1 [PC] (receiver):
----------- Before decryption   <CipeSocketIO::CompleteAsyncReceive()>
00000   16 7a 06 ea 72 f4 88 99 64 25 03 d5 50 b7 8e 1e    .z..r...d%..P...
00010   3d 0f 05 f6 b0 6d a1 75 89 c0 01 e8 37 7f 1f 5c    =....m.u....7..\
00020   41 fb 41 2f 07 74 7c dd 00 00 00 00 00 00 00 00    A.A/.t|.........

Decryption CRC. CRC=[14ea0ab9] :: [14ea0ab9]<CipeBlowfishEncryptor::Decrypt>

----------- after decryption    <CipeSocketIO::CompleteAsyncReceive()>
00000   03 54 da c9 c3 af a1 e2 a7 cc a1 74    .....T.........t
00010   96 ef d3 9f 53 e2 89 f3 42 3c ca 52 b9 0a ea 14    ....S...B<.R....
00020   fc 6f d2 56 00 00 00 00 00 00 00 00 00 00 00 00    .o.V............

received and decrypted key and CRC (last DWORD)
<CipeSocketIO::HandlePeerEvent> :: case NK_IND:
00000   03 54 da c9 c3 af a1 e2 a7 cc a1 74 96 ef d3 9f    .T.........t....
00010   53 e2 89 f3 00 00 00 00 00 00 00 00 00 00 00 00    S...............

[PC1] NK_IND: BAD CRC of key for decryption. NK_ACK will not be send.
 attached CRC=f389e253, calculated CRC=3d57e253

[PC2] (sender):
Original key and CRC (last DWORD)
------------------ Before encryption <CipeSocketIO::Send>
00000   03 54 da c9 c3 af a1 e2 a7 cc a1 74 96 ef d3 9f    .T.........t....
00010   53 e2 57 3d 00 00 00 00 00 00 00 00 00 00 00 00    S.W=............

 ----------------- After encryption  <CipeSocketIO::Send>
00000   16 7a 06 ea 72 f4 88 99 64 25 03 d5 50 b7 8e 1e    .z..r...d%..P...
00010   3d 0f 05 f6 b0 6d a1 75 89 c0 01 e8 37 7f 1f 5c    =....m.u....7..\
00020   41 fb 41 2f 07 74 7c dd 00 00 00 00 00 00 00 00    A.A/.t|.........

Conclusion: packet was received correctly (at least it was not
modified during transmission),in this case I am
interested in .nk.ind.keydata + CRC (size of (DWORD)) part,
but last two bytes of CRC were changed,( attached CRC=f389e253,
calculated CRC=3d57e253) therefore this key was rejected by PC1
(receiver). I suspect that there is something wrong with "encrypt
- decrypt" procedure.

5). BSOD during changing state of WIN2K. My modest experience in
development of kernel drivers tells me that there is a big probability
that the driver has track System power state and behaves itself
accordingly (change its internal state and report about it properly to the 
Power Manager)
or reports that it is not  power management-aware driver.(for
example return NDIS_STATUS_UNSUPPORTED to query of
OID_PNP_CAPABILITIES). Quick look at the AdapterQuery function (I
recompiled driver with VC7 but did not worked with it yet, just added
several diagnostic messages) shows that in case of receiving
OID_PNP_CAPABILITIES driver returns NDIS_STATUS_INVALID_OID..
Additional info can be found in DDK (Power Management for Legacy Miniport 
Drivers)
If I have more time (and if it is really necessary) I can try to
correct this problem later.

I work with CIPE-Win32-2.0-pre15, everything, written above may not be
applicable for other versions of CIPE.

Thanks for your patience.
-- 
Best regards,
Dmitry Basko             dbasko,AT,rainbow,DOT,by     http://www.dbasko.com


<< | Thread Index | >> ]    [ << | Date Index | >> ]