1800180078000000 NTLM/NTLMv2 Response header (length 24, offset 120)
0c000c0040000000 Domain Name header (length 12, offset 64)
080008004c000000 User Name header (length 8, offset 76)
0c000c0054000000 Workstation Name header (length 12, offset 84)
1000100090000000 Session Key header (length 16, offset 144)
358288e0 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Negotiate NTLM2 Key (0x00080000)
Negotiate Target Info (0x00800000)
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
Negotiate 56 (0x80000000)
54004500530054004e005400 Domain Name ("TESTNT")
7400650073007400 User Name ("test")
4d0045004d00420045005200 Workstation Name ("MEMBER")
404d1b6f6915258000000000000000000000000000000000 LM/LMv2 Response
ea8cc49f24da157f13436637f77693d8b992d619e584c7ee NTLM/NTLMv2 Response
727a5240822ec7af4e9100c43e6fee7f Session Key
--------------------------------------------------------------------------------
AcceptSecurityContext called to complete the server-side context.
Server Context Export:
48a42e7848a42e7800000000000000000000000000000000
70f10b00 server context handle dwUpper
358289e1 flags
0000000000000000382e09003c2e0900b82e0900c82f09000000000000000000
d002000000000000000000000000000000000000000000000200000000000000
ffffffffffffff7f20010000
6c713b60e6571035c9396ece1e456395 outbound signing key
e775c02a63d159ec64185f6d7d993344 inbound verifying key
e9b0f8e2cbf7b453b8389e8d2d7bb4ba outbound encrypting key
cc0fc51f360b7da837cde6cb417fd735 inbound decrypting key
000000000000000000000000
e932727927bbfe589b599a99d212bf23479fa99e7d8953bd6764862e690a6fac
b5f935ba02df8a75e415ddf7d30fc9a89778a2b7d4f0cc0c032b8757b4312663
8c0b39136536b8af1c3a774fc890cf30fbd16b18059c5eec7b3b3782efe06628
216aeda7e83fcb1446344bdeeb1ef5914ad894333d96ea51fdfc8311ad175b52
254ed93ce58bff50d0c78561aeb36ef8952c205acef3cad506085d5c700080ab
c6d77c22b1c22fb9c32a73a0481d100e298e929dc0e1a671ee1f8d4438a5c476
f22d847ec1196ce6094d5f3edc4201b28f6d43aaf4cdf1e362d6fa98a19307b0
55f640e7544c457424bc04c5dadb41160d7f88beb656a41be21a607a688149a3
00000000000000000000000000000000
cc094487604571968040c0ac1fe2da492938751932bc4139040def8c27635807
ad4e68b5ab6c6a65897f8f2df24f02164cc35466d0111d81f026a23d6d7221fd
34c9cb885e52b10ec88e532ec57a8ba5a6eb3f769446b62ab8a3840548220cd8
ff3b9bb2b731e1e64a50ae08917dc28d869215cf5a677920a801a493c143ec97
1efb576bd717b0303ea9be9fdb9a5dd55b1b8a77aaf42f9ccea183ea6eb36428
f7984bf9d39e9524a7eedd00cae5425533d9bded0b51ded2e43769c7c41a7bc6
af595ff1e33612e8614ddfe9f523785673a085fcd1d67ed4356f5ccd9ddc9003
0a4799bb2b70e71418823cfa06e0f62cbffe133a7cb4baf8101cf325620fb974
0000000000000000
54004500530054004e0054005c007400650073007400 "TESTNT\test"
ntlmHash = md4(password) = 0x3b1b47e42e0463276e3ded6cef349f93
NTLMUserSessionKey = md4(ntlmHash) = 0xae33a32dca8c9821844f740d5b3f4d6c
challenge (from Type 2) = 0x677f1c557a5ee96c
nonce (from Type 3) = 0x404d1b6f69152580
NTLM2SessionResponseUserSessionKey =
HMAC(NTLMUserSessionKey, challenge + nonce) =
0x0d4b30a8750b73ab2dab39e889455fcd
Key exchange performed:
type3Key (from Type 3) = 0x727a5240822ec7af4e9100c43e6fee7f
key = RC4(NTLM2SessionResponseUserSessionKey, type3Key) =
0x5764dc0a93b1292fa898c29524c30a54
We are using server context:
serverSigningConstant =
"session key to server-to-client signing key magic constant" =
0x73657373696f6e206b657920746f207365727665722d746f2d636c69656e74
207369676e696e67206b6579206d6167696320636f6e7374616e7400
serverSealingConstant =
"session key to server-to-client sealing key magic constant" =
0x73657373696f6e206b657920746f207365727665722d746f2d636c69656e74
207365616c696e67206b6579206d6167696320636f6e7374616e7400
signingKey = MD5(key + serverSigningConstant) =
0x6c713b60e6571035c9396ece1e456395
User Session Key is not weakened (128-bit negotiated).
sealingKey = MD5(key + serverSealingConstant) =
0xe9b0f8e2cbf7b453b8389e8d2d7bb4ba
Called MakeSignature on the server-side context for message
"0x0102030405060708".
Yields signature:
0100000069de1aff9cbee43100000000
Sequence number is 0.
seqnum + message = 0x000000000102030405060708
HMAC(signingKey, 0x000000000102030405060708) =
0x9d642651faec52f2164297dcaaa1ff6e
sig = RC4(sealingKey, first 8 bytes) = 0x69de1aff9cbee431
version num + sig + seqnum:
0100000069de1aff9cbee43100000000 = signature
--------------------------------------------------------------------------------
Called EncryptMessage twice on the server-side context for message
"0x0102030405060708".
Yields encrypted messages:
5b4cbbd3b2d8e8a401000000272c6dee5b236fe201000000
29535954c1e00fb9010000002922b8fcada4cda202000000
Uses RC4 cipher from previous signing operation (key exchange encrypts
signature with sealing key as well).
RC4(0x0102030405060708) = sealed message = 0x5b4cbbd3b2d8e8a4
trailer buffer gets signature (sequence number is now 1 because of previous
signing, same RC4 cipher used for this signature too):
HMAC(signingKey, 0x010000000102030405060708) =
0x1b7fc502e4cc73b6d85360d7ee052800
sig = RC4(first 8 bytes) = 0x272c6dee5b236fe2
version num + sig + seqnum:
01000000272c6dee5b236fe201000000 = trailer signature
second message is same, using RC4 cipher from previous operations:
RC4(0x0102030405060708) = sealed message = 0x29535954c1e00fb9
trailer buffer signature with sequence 2:
HMAC(signingKey, 0x020000000102030405060708) =
0x3e46a45716671a6e0d056636f77db4bb
sig = RC4(first 8 bytes) = 0x2922b8fcada4cda2
version num + sig + seqnum:
010000002922b8fcada4cda202000000 = trailer signature
NTLM2 Session Response Authentication; NTLM2 Signing and Sealing Using the 40-bit NTLM2 Session Response User Session Key
LMCompatibilityLevel set to 0 (LM/NTLM).
AcquireCredentialsHandle called with domain "TESTNT", user "test", password
"test1234".
--------------------------------------------------------------------------------
InitializeSecurityContext called with ISC_REQ_INTEGRITY and
ISC_REQ_CONFIDENTIALITY. Following flags were masked off of resulting Type 1
message:
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
Negotiate 56 (0x80000000)
4e544c4d5353500001000000b782080000000000000000000000000000000000
4e544c4d53535000 "NTLMSSP"
01000000 Type 1 message
b7820800 Flags
Negotiate Unicode (0x00000001)
Negotiate OEM (0x00000002)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate Lan Manager Key (0x00000080)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Negotiate NTLM2 Key (0x00080000)
0000000000000000 Supplied Domain (empty, supplied credentials)
0000000000000000 Supplied Workstation (empty, supplied credentials)
--------------------------------------------------------------------------------
AcceptSecurityContext called with ASC_REQ_INTEGRITY and ASC_REQ_CONFIDENTIALITY.
Produces Type 2 message:
4e544c4d53535000020000000c000c003000000035828900919013ccde5c4d16
0000000000000000460046003c00000054004500530054004e00540002000c00
54004500530054004e00540001000c004d0045004d0042004500520003001e00
6d0065006d006200650072002e0074006500730074002e0063006f006d000000
0000
4e544c4d53535000 "NTLMSSP"
02000000 Type 2 message
0c000c0030000000 Target Name header (length 12, offset 48)
35828900 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Target Type Domain (0x00010000)
Negotiate NTLM2 Key (0x00080000)
Negotiate Target Info (0x00800000)
919013ccde5c4d16 Challenge
0000000000000000 Context
460046003c000000 Target Information header (length 70, offset 60)
54004500530054004e005400 Target Name ("TESTNT")
Target Information block:
02000c00 NetBIOS Domain Name (length 12)
54004500530054004e005400 "TESTNT"
01000c00 NetBIOS Server Name (length 12)
4d0045004d00420045005200 "MEMBER"
03001e00 DNS Server Name (length 30)
6d0065006d006200650072002e0074006500730074002e0063006f006d00
"member.test.com"
00000000 Target Information Terminator
--------------------------------------------------------------------------------
InitializeSecurityContext called. Produces a Type 3 message:
4e544c4d5353500003000000180018006000000018001800780000000c000c00
40000000080008004c0000000c000c0054000000000000009000000035828800
54004500530054004e00540074006500730074004d0045004d00420045005200
02a668799b43b02600000000000000000000000000000000191c91d68a26a933
82ec89178c1e496d8f2f63a1c7dc0b54
4e544c4d53535000 "NTLMSSP"
03000000 Type 3 message
1800180060000000 LM/LMv2 Response header (length 24, offset 96)
1800180078000000 NTLM/NTLMv2 Response header (length 24, offset 120)
0c000c0040000000 Domain Name header (length 12, offset 64)
080008004c000000 User Name header (length 8, offset 76)
0c000c0054000000 Workstation Name header (length 12, offset 84)
0000000090000000 Session Key header (empty)
35828800 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Negotiate NTLM2 Key (0x00080000)
Negotiate Target Info (0x00800000)
54004500530054004e005400 Domain Name ("TESTNT")
7400650073007400 User Name ("test")
4d0045004d00420045005200 Workstation Name ("MEMBER")
02a668799b43b02600000000000000000000000000000000 LM/LMv2 Response
191c91d68a26a93382ec89178c1e496d8f2f63a1c7dc0b54 NTLM/NTLMv2 Response
--------------------------------------------------------------------------------
AcceptSecurityContext called to complete the server-side context.
Server Context Export:
40a42e7840a42e7800000000000000000000000000000000
08ee0b00 server context handle dwUpper
35828901 flags
0000000000000000f8290900fc290900782a0900882b09000000000000000000
d002000000000000000000000000000000000000000000000200000000000000
ffffffffffffff7f20010000
605b738984f36aea7d2ccc5678670f2c outbound signing key
94d75dd6591eb8569d8480b5c9c25136 inbound verifying key
e4c55ca209611e9e007009731b7103d5 outbound encrypting key
738e75e9b0df0ac9139839abf5cc8354 inbound decrypting key
000000000000000000000000
37aa90adbac5442beb5c77f553b782d01859687c2e421e524e2fbc4ad5ff0555
43657a283af2366b3f3cafa80372a3a781b123dd6f2c22e45e0c57d23bd78399
f64935c94bbf9112156a67a2dc843e1a7069f8ec30f99388fa61c4cf4c3d3824
b046df9c31fc0a0150d6638ca17fb651c79db25d07efbea5dea02580fe406211
ea9b1341b41f76e366857d5afbe92adb6ee2940bfd6c4fe12995b5acc05fbb73
a98bbd33b906ae14a4da00cb0dcc1b75f0edc2792d9e60cef1c192741d8a1039
8d7b479a97b30e20f4217ef39fe6c30948199604c8f79856d1ee4dd9e589648e
26ca86c67802e78f5b34e8a617d3ab5408582745cdd416711c32e06d87b80fd8
00000000000000000000000000000000
eb024b64187446dcf798db69a299356807ba78fec2b642e6cd77a097a80bb9a5
38e7548a935d923dbd22e1b7d80127fc1cc9fad61e404eac033f6bab10e57923
878f729e84500ce97139d5cb8c11c7b21741e2325f56a34aad757a804f34ed19
a747bf05af9b912f94ffea700dd43a8806d73eb4458bd97e1a375c6d9633f3c6
49092dc8635a9a589ce35221c5dda1f926ef1f6a5bc03bb1ce65e089149d2baa
28b3cab59f448655306c25133629bc812c57be592a1b0e1204537bcf00d176b0
3c0faecce8f6c4dfd0674cfbd27d95fdf1da318e8d8582bbec7f16f0c162eea6
0a8324f26660151d2eb851736edea9e4f86f08a45e4dc3d37c48f54390f46120
0000000000000000
54004500530054004e0054005c007400650073007400 "TESTNT\test"
ntlmHash = md4(password) = 0x3b1b47e42e0463276e3ded6cef349f93
NTLMUserSessionKey = md4(ntlmHash) = 0xae33a32dca8c9821844f740d5b3f4d6c
challenge (from Type 2) = 0x919013ccde5c4d16
nonce (from Type 3) = 0x02a668799b43b026
NTLM2SessionResponseUserSessionKey =
HMAC(NTLMUserSessionKey, challenge + nonce) =
0x6b60097a8f9dbbff2d23f5b15377ca28
We are using server context:
serverSigningConstant =
"session key to server-to-client signing key magic constant" =
0x73657373696f6e206b657920746f207365727665722d746f2d636c69656e74
207369676e696e67206b6579206d6167696320636f6e7374616e7400
serverSealingConstant =
"session key to server-to-client sealing key magic constant" =
0x73657373696f6e206b657920746f207365727665722d746f2d636c69656e74
207365616c696e67206b6579206d6167696320636f6e7374616e7400
signingKey = MD5(key + serverSigningConstant) =
0x605b738984f36aea7d2ccc5678670f2c
User Session Key is weakened to 40-bit for sealing by truncating =
0x6b60097a8f
sealingKey = MD5(weakenedKey + serverSealingConstant) =
0xe4c55ca209611e9e007009731b7103d5
Called MakeSignature on the server-side context for message
"0x0102030405060708".
Yields signature:
01000000d1e2d811145d81ec00000000
Sequence number is 0.
seqnum + message = 0x000000000102030405060708
HMAC(signingKey, 0x000000000102030405060708) =
0xd1e2d811145d81ecf5f8723312c75e3c
version num + first 8 bytes + seqnum:
01000000d1e2d811145d81ec00000000 = signature
--------------------------------------------------------------------------------
Called EncryptMessage twice on the server-side context for message
"0x0102030405060708".
Yields encrypted messages:
ab8d38bb0cad7dd601000000eed64de8afb80c8001000000
b011cc07a7f6127b01000000644a8509d73ac48c02000000
RC4(sealingKey, 0x0102030405060708) = sealed message = 0xab8d38bb0cad7dd6
trailer buffer gets signature (sequence number is now 1 because of previous
signing):
HMAC(signingKey, 0x010000000102030405060708) =
0xeed64de8afb80c801ea5ddd1d98cbdc8
version num + first 8 bytes + seqnum:
01000000eed64de8afb80c8001000000 = trailer signature
second message is same, using RC4 cipher from previous sealing operation:
RC4(0x0102030405060708) = sealed message = 0xb011cc07a7f6127b
trailer buffer signature with sequence 2:
HMAC(signingKey, 0x020000000102030405060708) =
0x644a8509d73ac48c8f5a7f7f65bc8381
version num + first 8 bytes + seqnum:
01000000644a8509d73ac48c02000000 = trailer signature
NTLMv2 Authentication; NTLM1 Signing and Sealing Using the 40-bit NTLMv2 User Session Key
LMCompatibilityLevel set to 3 (LMv2/NTLMv2).
AcquireCredentialsHandle called with domain "TESTNT", user "test", password
"test1234".
--------------------------------------------------------------------------------
InitializeSecurityContext called with ISC_REQ_INTEGRITY and
ISC_REQ_CONFIDENTIALITY. Following flags were masked off of resulting Type 1
message:
Negotiate Lan Manager Key (0x00000080)
Negotiate NTLM2 Key (0x00080000)
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
Negotiate 56 (0x80000000)
4e544c4d53535000010000003782000000000000000000000000000000000000
4e544c4d53535000 "NTLMSSP"
01000000 Type 1 message
37820000 Flags
Negotiate Unicode (0x00000001)
Negotiate OEM (0x00000002)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
0000000000000000 Supplied Domain header (empty, supplied credentials)
0000000000000000 Supplied Workstation header (empty, supplied credentials)
--------------------------------------------------------------------------------
AcceptSecurityContext called with ASC_REQ_INTEGRITY and ASC_REQ_CONFIDENTIALITY.
Produces Type 2 message:
4e544c4d53535000020000000c000c0030000000358281000033b02d17275b77
0000000000000000460046003c00000054004500530054004e00540002000c00
54004500530054004e00540001000c004d0045004d0042004500520003001e00
6d0065006d006200650072002e0074006500730074002e0063006f006d000000
0000
4e544c4d53535000 "NTLMSSP"
02000000 Type 2 message
0c000c0030000000 Target Name header (length 12, offset 48)
35828100 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Target Type Domain (0x00010000)
Negotiate Target Info (0x00800000)
0033b02d17275b77 Challenge
0000000000000000 Context
460046003c000000 Target Information header (length 70, offset 60)
54004500530054004e005400 Target Name ("TESTNT")
Target Information block:
02000c00 NetBIOS Domain Name (length 12)
54004500530054004e005400 "TESTNT"
01000c00 NetBIOS Server Name (length 12)
4d0045004d00420045005200 "MEMBER"
03001e00 DNS Server Name (length 30)
6d0065006d006200650072002e0074006500730074002e0063006f006d00
"member.test.com"
00000000 Target Information Terminator
--------------------------------------------------------------------------------
InitializeSecurityContext called. Produces a Type 3 message:
4e544c4d5353500003000000180018006000000076007600780000000c000c00
40000000080008004c0000000c000c005400000000000000ee00000035828000
54004500530054004e00540074006500730074004d0045004d00420045005200
5d55a02b60a40526ac9a1e4d15fa45a0f2e6329726c598e8f77c67dad00b9321
6242b197fe6addfa0101000000000000502db638677bc301f2e6329726c598e8
0000000002000c0054004500530054004e00540001000c004d0045004d004200
4500520003001e006d0065006d006200650072002e0074006500730074002e00
63006f006d000000000000000000
4e544c4d53535000 "NTLMSSP"
03000000 Type 3 message
1800180060000000 LM/LMv2 Response header (length 24, offset 96)
7600760078000000 NTLM/NTLMv2 Response header (length 118, offset 120)
0c000c0040000000 Domain Name header (length 12, offset 64)
080008004c000000 User Name header (length 8, offset 76)
0c000c0054000000 Workstation Name header (length 12, offset 84)
00000000ee000000 Session Key header (empty)
35828000 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Negotiate Target Info (0x00800000)
54004500530054004e005400 Domain Name ("TESTNT")
7400650073007400 User Name ("test")
4d0045004d00420045005200 Workstation Name ("MEMBER")
5d55a02b60a40526ac9a1e4d15fa45a0f2e6329726c598e8 LM/LMv2 Response
NTLM/NTLMv2 Response:
f77c67dad00b93216242b197fe6addfa0101000000000000502db638677bc301
f2e6329726c598e80000000002000c0054004500530054004e00540001000c00
4d0045004d0042004500520003001e006d0065006d006200650072002e007400
6500730074002e0063006f006d000000000000000000
--------------------------------------------------------------------------------
AcceptSecurityContext called to complete the server-side context.
Server Context Export:
40a42e7840a42e7800000000000000000000000000000000
08ee0b00 server context handle dwUpper
35828101 flags, also has an unknown flag set
0000000000000000782e0900782e0900f82e0900f82e09000000000000000000
d002000000000000000000000000000000000000000000000200000000000000
ffffffffffffff7f20010000
1c4c7aaa7403acf01b1fa565bc950810 outbound signing key
1c4c7aaa7403acf01b1fa565bc950810 inbound verifying key
1c4c7aaa7403acf01b1fa565bc950810 outbound encrypting key
1c4c7aaa7403acf01b1fa565bc950810 inbound decrypting key
000000000000000000000000
783ee50c1d1209b1cb2ea115e7899fbe9547b2b03c1ef14c20d102e0a7282a00
d4919756821af4ff388a5333c51835fc482c71a5f6bdea3745e2dc6124dd3241
c9a9849d267ebc3d7608554962235fb568d6874699cd141fb7395b801b796650
ca0edaee65d2304afe707504067aefb38669eda3547f7c5d946ecf3aadbf437d
6f4288e1d9a6935e63ae7ba467afaac1ccc3529a1c36d7b49cf2e407779e2985
3173db8d814e9b405cc00d01d5d016a022b6c62be96b90c2f792ecce4dc4f36c
f58b2d74980a6dde17d3d8f8e63b0b7264342f600fab05580344bae88ffa5ab9
27df19f96a51bba8f083eb3f10ac218cfdc8fb8ea2255711c74b4f5913e3b896
00000000000000000000000000000000
783ee50c1d1209b1cb2ea115e7899fbe9547b2b03c1ef14c20d102e0a7282a00
d4919756821af4ff388a5333c51835fc482c71a5f6bdea3745e2dc6124dd3241
c9a9849d267ebc3d7608554962235fb568d6874699cd141fb7395b801b796650
ca0edaee65d2304afe707504067aefb38669eda3547f7c5d946ecf3aadbf437d
6f4288e1d9a6935e63ae7ba467afaac1ccc3529a1c36d7b49cf2e407779e2985
3173db8d814e9b405cc00d01d5d016a022b6c62be96b90c2f792ecce4dc4f36c
f58b2d74980a6dde17d3d8f8e63b0b7264342f600fab05580344bae88ffa5ab9
27df19f96a51bba8f083eb3f10ac218cfdc8fb8ea2255711c74b4f5913e3b896
0000000000000000
54004500530054004e0054005c007400650073007400 "TESTNT\test"
ntlmHash = md4(password) = 0x3b1b47e42e0463276e3ded6cef349f93
ntlmv2Hash = hmac(ntlmHash, "TESTTESTNT") = 0xc4ea95cb148df11bf9d7c3611ad6d722
challenge (from Type 2) = 0x0033b02d17275b77
blob (from Type 3) = 0x0101000000000000502db638677bc301f2e632972
6c598e80000000002000c0054004500530054004e00540001000c004d0045004
d0042004500520003001e006d0065006d006200650072002e007400650073007
4002e0063006f006d000000000000000000
NTLMv2UserSessionKey = HMAC(ntlmv2Hash(HMAC(ntlmv2Hash, challenge + blob))) =
0x1c4c7aaa7403acf01b1fa565bc950810
Key is *not* weakened (NTLM1 only weakens Lan Manager Session Keys).
Called MakeSignature on the server-side context for message
"0x0102030405060708".
Yields signature:
01000000ffffff0051cefea77f098ee3
CRC32(0x0102030405060708) = 0xc588ca3f
Sequence number is 0.
0x00000000 + crc32 + seqnum = 0x00000000c588ca3f00000000
RC4(key, 0x00000000c588ca3f00000000) = 0x8661cb7d51cefea77f098ee3
version num + first 4 bytes overwritten with counter value (0xffffff00 here):
01000000ffffff0051cefea77f098ee3 = signature
--------------------------------------------------------------------------------
Called EncryptMessage twice on the server-side context for message
"0x0102030405060708".
Yields encrypted messages:
f483b904264d83060100000098010700bd9719c0b34f5362
022cc2127f9e206e01000000800307001855ec8494231273
same RC4 cipher is used from previous signing operation (i.e., not reset):
RC4(0x0102030405060708) = sealed message = 0xf483b904264d8306
trailer buffer gets signature; again uses same RC4 cipher
(sequence number is now 1 because of previous signing):
RC4(0x00000000c588ca3f01000000) = 0x2246e9cbbd9719c0b34f5362
version num + first 4 bytes overwritten w/counter (0x98010700):
0100000098010700bd9719c0b34f5362 = trailer signature
second message is same:
RC4(0x0102030405060708) = sealed message = 0x022cc2127f9e206e
trailer buffer signature with sequence 2:
RC4(0x00000000c588ca3f02000000) = 0x6fde4d031855ec8494231273
version num + first 4 bytes overwritten w/counter (0x80030700)
01000000800307001855ec8494231273 = trailer signature
NTLMv2 Authentication; NTLM2 Signing and Sealing Using the 56-bit NTLMv2 User Session Key
LMCompatibilityLevel set to 3 (LMv2/NTLMv2).
AcquireCredentialsHandle called with domain "TESTNT", user "test", password
"test1234".
--------------------------------------------------------------------------------
InitializeSecurityContext called with ISC_REQ_INTEGRITY and
ISC_REQ_CONFIDENTIALITY. Following flags were masked off of resulting Type 1
message:
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
4e544c4d5353500001000000b782088000000000000000000000000000000000
4e544c4d53535000 "NTLMSSP"
01000000 Type 1 message
b7820880 Flags
Negotiate Unicode (0x00000001)
Negotiate OEM (0x00000002)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate Lan Manager Key (0x00000080)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Negotiate NTLM2 Key (0x00080000)
Negotiate 56 (0x80000000)
0000000000000000 Supplied Domain header (empty, supplied credentials)
0000000000000000 Supplied Workstation header (empty, supplied credentials)
--------------------------------------------------------------------------------
AcceptSecurityContext called with ASC_REQ_INTEGRITY and ASC_REQ_CONFIDENTIALITY.
Produces Type 2 message:
4e544c4d53535000020000000c000c003000000035828980514246973ea892c1
0000000000000000460046003c00000054004500530054004e00540002000c00
54004500530054004e00540001000c004d0045004d0042004500520003001e00
6d0065006d006200650072002e0074006500730074002e0063006f006d000000
0000
4e544c4d53535000 "NTLMSSP"
02000000 Type 2 message
0c000c0030000000 Target Name header (length 12, offset 48)
35828980 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Target Type Domain (0x00010000)
Negotiate NTLM2 Key (0x00080000)
Negotiate Target Info (0x00800000)
Negotiate 56 (0x80000000)
514246973ea892c1 Challenge
0000000000000000 Context
460046003c000000 Target Information header (length 70, offset 60)
54004500530054004e005400 Target Name ("TESTNT")
Target Information block:
02000c00 NetBIOS Domain Name (length 12)
54004500530054004e005400 "TESTNT"
01000c00 NetBIOS Server Name (length 12)
4d0045004d00420045005200 "MEMBER"
03001e00 DNS Server Name (length 30)
6d0065006d006200650072002e0074006500730074002e0063006f006d00
"member.test.com"
00000000 Target Information Terminator
--------------------------------------------------------------------------------
InitializeSecurityContext called. Produces a Type 3 message:
4e544c4d5353500003000000180018006000000076007600780000000c000c00
40000000080008004c0000000c000c005400000000000000ee00000035828880
54004500530054004e00540074006500730074004d0045004d00420045005200
bf2e015119f6bdb3f6fdb768aa12d478f5ce3d2401c8f6e9caa4da8f25d5e840
974ed8976d3ada46010100000000000030fa7e3c677bc301f5ce3d2401c8f6e9
0000000002000c0054004500530054004e00540001000c004d0045004d004200
4500520003001e006d0065006d006200650072002e0074006500730074002e00
63006f006d000000000000000000
4e544c4d53535000 "NTLMSSP"
03000000 Type 3 message
1800180060000000 LM/LMv2 Response header (length 24, offset 96)
7600760078000000 NTLM/NTLMv2 Response header (length 118, offset 120)
0c000c0040000000 Domain Name header (length 12, offset 64)
080008004c000000 User Name header (length 8, offset 76)
0c000c0054000000 Workstation Name header (length 12, offset 84)
00000000ee000000 Session Key header (empty)
35828880 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Negotiate NTLM2 Key (0x00080000)
Negotiate Target Info (0x00800000)
Negotiate 56 (0x80000000)
54004500530054004e005400 Domain Name ("TESTNT")
7400650073007400 User Name ("test")
4d0045004d00420045005200 Workstation Name ("MEMBER")
bf2e015119f6bdb3f6fdb768aa12d478f5ce3d2401c8f6e9 LM/LMv2 Response
NTLM/NTLMv2 Response:
caa4da8f25d5e840974ed8976d3ada46010100000000000030fa7e3c677bc301
f5ce3d2401c8f6e90000000002000c0054004500530054004e00540001000c00
4d0045004d0042004500520003001e006d0065006d006200650072002e007400
6500730074002e0063006f006d000000000000000000
--------------------------------------------------------------------------------
AcceptSecurityContext called to complete the server-side context.
Server Context Export:
40a42e7840a42e7800000000000000000000000000000000
08ee0b00 server context handle dwUpper
35828981 flags
0000000000000000282e09002c2e0900a82e0900b82f09000000000000000000
d002000000000000000000000000000000000000000000000200000000000000
ffffffffffffff7f20010000
f7301e5d23f1d578c51ec0728b67453e outbound signing key
06403212f9e8c05ce1739938c200eca5 inbound verifying key
3d6483dce52cd6c4d7553545e607d92d outbound encrypting key
ccc6efbcea980c0ac685753a4c9bbe0c inbound decrypting key
000000000000000000000000
3a6d27764b2010cdeda24d421b961cb92835eac0ecd6bf50375d308219362975
443ce13be9d2621d1283dc484f3e6ae66c4e8851f12632c3c1d9d5808763770b
9b61ebf7b7152252da1ff484b611732e3dcca15e9567939ce48bac450c7d46df
14ff026557a49db4dbe54cde538c21c6d0a59a24d87a06498dd74340bc4a13ab
6f851aa070a7587f9fa86b560d16d4e3b22d97b33147eefccbc87c6e3479f53f
bab898af09865aa3692f5b330a99f600c2b118cec766fec903a6551ecfe0e225
e77bae642ad3c5fa0fbb0e5caac4bd9e07ef2b602c1754f2908eb501be5991fd
41ad688add8f392308f3f974f881783872b07ee8fb7104055fa99289d1f0ca94
00000000000000000000000000000000
21a58f9635cee06b4f94512adc8125717aa7a877750d646503e17073b1e5c1a6
d874c3a2b0499f905bebef1a3f5f8bee8e8ce69c4b87c900bf2f41ea72167f91
1dfc82a959862708575caf3a0a7bbbd7f337ba5ab6fae7c69734e9a1e367a44e
cfc5292ed9da1f5e0f2d01a0ae0214b58a1eb8619b524c7dbe47d41bc83bb346
0983d533dd40ab76c742ca45c0e4c2cbf5e8f6f7f222b76658a31c795005193e
f17812d0c4247e806e4afddb10cc68d6b90c2807b20e9860549318621130ac06
bc15e2f8232b9aec20fb95decd89d2f43d0b69bdd3136f382644888d533284b4
92feedaa7c9df9393c55316cffd1489ead172cdf43995636636a85f05d6d044d
0000000000000000
54004500530054004e0054005c007400650073007400 "TESTNT\test"
ntlmHash = md4(password) = 0x3b1b47e42e0463276e3ded6cef349f93
ntlmv2Hash = hmac(ntlmHash, "TESTTESTNT") = 0xc4ea95cb148df11bf9d7c3611ad6d722
challenge (from Type 2) = 0x514246973ea892c1
blob (from Type 3) = 0x010100000000000030fa7e3c677bc301f5ce3d240
1c8f6e90000000002000c0054004500530054004e00540001000c004d0045004
d0042004500520003001e006d0065006d006200650072002e007400650073007
4002e0063006f006d000000000000000000
NTLMv2UserSessionKey = HMAC(ntlmv2Hash(HMAC(ntlmv2Hash, challenge + blob))) =
0x62ff13231f566f5dadf7391e183b5f39
We are using server context:
serverSigningConstant =
"session key to server-to-client signing key magic constant" =
0x73657373696f6e206b657920746f207365727665722d746f2d636c69656e74
207369676e696e67206b6579206d6167696320636f6e7374616e7400
serverSealingConstant =
"session key to server-to-client sealing key magic constant" =
0x73657373696f6e206b657920746f207365727665722d746f2d636c69656e74
207365616c696e67206b6579206d6167696320636f6e7374616e7400
signingKey = MD5(key + serverSigningConstant) =
0xf7301e5d23f1d578c51ec0728b67453e
User Session Key is weakened to 56-bit for sealing by truncating =
0x62ff13231f566f
sealingKey = MD5(weakenedKey + serverSealingConstant) =
0x3d6483dce52cd6c4d7553545e607d92d
Called MakeSignature on the server-side context for message
"0x0102030405060708".
Yields signature:
01000000fa317a333d8f510c00000000
Sequence number is 0.
seqnum + message = 0x000000000102030405060708
HMAC(signingKey, 0x000000000102030405060708) =
0xfa317a333d8f510cccab257d9f2193c4
version num + first 8 bytes + seqnum:
01000000fa317a333d8f510c00000000 = signature
--------------------------------------------------------------------------------
Called EncryptMessage twice on the server-side context for message
"0x0102030405060708".
Yields encrypted messages:
a8e6671c79cf265701000000673773407fb60b4201000000
2fe89f6c6ea06d4b01000000244e0bcbce6ec16c02000000
RC4(sealingKey, 0x0102030405060708) = sealed message = 0xa8e6671c79cf2657
trailer buffer gets signature (sequence number is now 1 because of previous
signing):
HMAC(signingKey, 0x010000000102030405060708) =
0x673773407fb60b428f70358ca67720ba
version num + first 8 bytes + seqnum:
01000000673773407fb60b4201000000 = trailer signature
second message is same, using RC4 cipher from previous sealing operation:
RC4(0x0102030405060708) = sealed message = 0x2fe89f6c6ea06d4b
trailer buffer signature with sequence 2:
HMAC(signingKey, 0x020000000102030405060708) =
0x244e0bcbce6ec16ce3493f55854bcc5c
version num + first 8 bytes + seqnum:
01000000244e0bcbce6ec16c02000000 = trailer signature
Anonymous NTLMv1 Authentication; NTLM2 Signing and Sealing Using the 128-bit Null User Session Key With Key Exchange Negotiated
LMCompatibilityLevel set to 0 (LM/NTLM).
AcquireCredentialsHandle called with empty string ("") for domain, user, and
password.
--------------------------------------------------------------------------------
InitializeSecurityContext called with ISC_REQ_INTEGRITY and
ISC_REQ_CONFIDENTIALITY. Produces Type 1 message:
4e544c4d5353500001000000b78208e000000000000000000000000000000000
4e544c4d53535000 "NTLMSSP"
01000000 Type 1 message
b78208e0 Flags
Negotiate Unicode (0x00000001)
Negotiate OEM (0x00000002)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate Lan Manager Key (0x00000080)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Negotiate NTLM2 Key (0x00080000)
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
Negotiate 56 (0x80000000)
0000000000000000 Supplied Domain header (empty, supplied credentials)
0000000000000000 Supplied Workstation header (empty, supplied credentials)
--------------------------------------------------------------------------------
AcceptSecurityContext called with ASC_REQ_INTEGRITY and ASC_REQ_CONFIDENTIALITY.
Produces Type 2 message:
4e544c4d53535000020000000c000c0030000000358289e05bce6f12f47ddbdf
0000000000000000460046003c00000054004500530054004e00540002000c00
54004500530054004e00540001000c004d0045004d0042004500520003001e00
6d0065006d006200650072002e0074006500730074002e0063006f006d000000
0000
4e544c4d53535000 "NTLMSSP"
02000000 Type 2 message
0c000c0030000000 Target Name header (length 12, offset 48)
358289e0 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Target Type Domain (0x00010000)
Negotiate NTLM2 Key (0x00080000)
Negotiate Target Info (0x00800000)
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
Negotiate 56 (0x80000000)
5bce6f12f47ddbdf Challenge
0000000000000000 Context
460046003c000000 Target Information header (length 70, offset 60)
54004500530054004e005400 Target Name ("TESTNT")
Target Information block:
02000c00 NetBIOS Domain Name (length 12)
54004500530054004e005400 "TESTNT"
01000c00 NetBIOS Server Name (length 12)
4d0045004d00420045005200 "MEMBER"
03001e00 DNS Server Name (length 30)
6d0065006d006200650072002e0074006500730074002e0063006f006d00
"member.test.com"
00000000 Target Information Terminator
--------------------------------------------------------------------------------
InitializeSecurityContext called. Produces a Type 3 message:
4e544c4d5353500003000000010001004c000000000000004d00000000000000
4000000000000000400000000c000c0040000000100010004d000000358a88e0
4d0045004d0042004500520000c1442e6cca8c010e77138430aa35738e
4e544c4d53535000 "NTLMSSP"
03000000 Type 3 message
010001004c000000 LM/LMv2 Response header (length 1, offset 76)
000000004d000000 NTLM/NTLMv2 Response header (empty)
0000000040000000 Domain Name header (empty)
0000000040000000 User Name header (empty)
0c000c0040000000 Workstation Name header (length 12, offset 64)
100010004d000000 Session Key header (length 16, offset 77)
358a88e0 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Anonymous (0x00000800)
Negotiate Always Sign (0x00008000)
Negotiate NTLM2 Key (0x00080000)
Negotiate Target Info (0x00800000)
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
Negotiate 56 (0x80000000)
4d0045004d00420045005200 Workstation Name ("MEMBER")
00 LM/LMv2 Response
c1442e6cca8c010e77138430aa35738e Session Key
--------------------------------------------------------------------------------
AcceptSecurityContext called to complete the server-side context.
Server Context Export (on Win2k, appears to vary by OS):
40a42e7840a42e7800000000000000000000000000000000
08ee0b00 server context handle dwUpper
358a89e1 flags
0000000000000000e8290900ec290900682a0900782b09000000000000000000
0000000000000000000000000000000000000000000000000200000000000000
ffffffffffffff7f00000000
9128c3e5df618a48a83b44cfd92d58fe outbound signing key
594757aaa803afd943de25e087e3f9f1 inbound verifying key
fc52e8bf1605ab57e89c6d6b4ffa92f6 outbound encrypting key
96465577ba181d141711572e5e15fe5d inbound decrypting key
000000000000000000000000
53a979fb1564d02ea0c33a32b0a1b2015f261b6ee6207804aa4f88fc57826b61
5a9fe8764931f9903efea3e1d258cddda292d6da10b536287a9859ff212d6781
f51a0eb439afc1f30cf0a75d4b54145c5bf4e7036a95c573dc0a3b479dcbbb09
6c4c698b1fc22acc8eeb8f7183ea99182274d1e4dfe5bf8d13382941f6ca25b7
7084a56216c906ad7da891fa42082b9b170733b65ef23437a4fd667e5686c6de
87240080ec89d3d4bc194e759aaebde302d55550f83f1d0b46303545c71eb3b1
3c2f6f7b9eb8ab6d1c4011f12c51baf77fcec00fd7e07248e2604485be238aef
77b91265ac5227ee944ded8cd868634a973dc4db439c0dc8a696937ccfd9e905
00000000000000000000000000000000
09dd12ae4213ac358896e19a9d26cfc8957750b5f557bae5f3ef98d891a4059f
f25ed0195d141aea3d62e31fd7a9aa1e07fd83cb4d3f7401825b7e66a14b28cd
52d6e8a2049036756dfcb929d220d5463499ca3368a071634c0c9cd10dcc4ef9
11d30f108a45648979477f0641c2b485f6adc0a8922be91dde847c93278040a6
b886c6605ac132fe731c589467a76131c9498db13beb2f9baf2c59e06f6c6af0
bbc4b00e6bce78da2de602e797f103b2b6bf4f1b388c0816dfbde2258bd9a3b7
157b5600c55ffaf79e3ac78e48ee55308737ff43817d515cf83e6e70c317bcec
2aed21442e24d465a56923be0b53f4fb8fb3e454ab18760a7adc2239723c4adb
0000000000000000
Anonymous User Session Key = 0x00000000000000000000000000000000
Key exchange performed:
type3Key (from Type 3) = 0xc1442e6cca8c010e77138430aa35738e
key = RC4(AnonymousUserSessionKey, type3Key) =
0x1f5ca72d69bb5c34fd159a57fd5be1e3
We are using server context:
serverSigningConstant =
"session key to server-to-client signing key magic constant" =
0x73657373696f6e206b657920746f207365727665722d746f2d636c69656e74
207369676e696e67206b6579206d6167696320636f6e7374616e7400
serverSealingConstant =
"session key to server-to-client sealing key magic constant" =
0x73657373696f6e206b657920746f207365727665722d746f2d636c69656e74
207365616c696e67206b6579206d6167696320636f6e7374616e7400
signingKey = MD5(key + serverSigningConstant) =
0x9128c3e5df618a48a83b44cfd92d58fe
sealingKey = MD5(key + serverSealingConstant) =
0xfc52e8bf1605ab57e89c6d6b4ffa92f6
Called MakeSignature on the server-side context for message
"0x0102030405060708".
Yields signature:
01000000ae0cbe0dd0b2110300000000
Sequence number is 0.
seqnum + message = 0x000000000102030405060708
HMAC(signingKey, 0x000000000102030405060708) =
0xc14074817421530195b4532d61a4e625
sig = RC4(sealingKey, first 8 bytes) = 0xae0cbe0dd0b21103
version num + sig + seqnum:
01000000ae0cbe0dd0b2110300000000 = signature
--------------------------------------------------------------------------------
Called EncryptMessage twice on the server-side context for message
"0x0102030405060708".
Yields encrypted messages:
fb2e1d6ff8a3569a01000000cc2c5bf59319e7ca01000000
1e2216588e5a7d9801000000e9a3066b8fab0bf102000000
Uses RC4 cipher from previous signing operation (key exchange encrypts
signature with sealing key as well).
RC4(0x0102030405060708) = sealed message = 0xfb2e1d6ff8a3569a
trailer buffer gets signature (sequence number is now 1 because of previous
signing, same RC4 cipher used for this signature too):
HMAC(signingKey, 0x010000000102030405060708) =
0x25141e76f441b10622cfaf0e61450663
sig = RC4(first 8 bytes) = 0xcc2c5bf59319e7ca
version num + sig + seqnum:
01000000cc2c5bf59319e7ca01000000 = trailer signature
second message is same, using RC4 cipher from previous operations:
RC4(0x0102030405060708) = sealed message = 0x1e2216588e5a7d98
trailer buffer signature with sequence 2:
HMAC(signingKey, 0x020000000102030405060708) =
0x7efa2ba18ed911696a0f4d571b05a244
sig = RC4(first 8 bytes) = 0xe9a3066b8fab0bf1
version num + sig + seqnum:
01000000e9a3066b8fab0bf102000000 = trailer signature
Local NTLMv1 Authentication; NTLM2 Signing and Sealing Using an Unknown Session Key With Key Exchange Negotiated (Analysis Incomplete)
LMCompatibilityLevel set to 0 (LM/NTLM).
AcquireCredentialsHandle called with NULL identity (using default credentials
handle for authenticated local user).
--------------------------------------------------------------------------------
InitializeSecurityContext called with ISC_REQ_INTEGRITY and
ISC_REQ_CONFIDENTIALITY. Produces Type 1 message:
4e544c4d5353500001000000b7b208e006000600260000000600060020000000
4d454d424552544553544e54
4e544c4d53535000 "NTLMSSP"
01000000 Type 1 message
b7b208e0 Flags
Negotiate Unicode (0x00000001)
Negotiate OEM (0x00000002)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate Lan Manager Key (0x00000080)
Negotiate NTLM (0x00000200)
Negotiate Domain Supplied (0x00001000)
Negotiate Workstation Supplied (0x00002000)
Negotiate Always Sign (0x00008000)
Negotiate NTLM2 Key (0x00080000)
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
Negotiate 56 (0x80000000)
0600060026000000 Supplied Domain header (length 6, offset 38)
0600060020000000 Supplied Workstation header (length 6, offset 32)
4d454d424552 Supplied Workstation ("MEMBER")
544553544e54 Supplied Domain ("TESTNT")
--------------------------------------------------------------------------------
AcceptSecurityContext called with ASC_REQ_INTEGRITY and ASC_REQ_CONFIDENTIALITY.
Produces Type 2 message:
4e544c4d53535000020000000c000c003000000035c289e0d7ef496afa055352
08ee0b0000000000460046003c00000054004500530054004e00540002000c00
54004500530054004e00540001000c004d0045004d0042004500520003001e00
6d0065006d006200650072002e0074006500730074002e0063006f006d000000
0000
4e544c4d53535000 "NTLMSSP"
02000000 Type 2 message
0c000c0030000000 Target Name header (length 12, offset 48)
35c289e0 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Local Call (0x00004000)
Negotiate Always Sign (0x00008000)
Target Type Domain (0x00010000)
Negotiate NTLM2 Key (0x00080000)
Negotiate Target Info (0x00800000)
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
Negotiate 56 (0x80000000)
d7ef496afa055352 Challenge
08ee0b0000000000 Context (equal to server context handle's dwUpper field)
460046003c000000 Target Information header (length 70, offset 60)
54004500530054004e005400 Target Name ("TESTNT")
Target Information block:
02000c00 NetBIOS Domain Name (length 12)
54004500530054004e005400 "TESTNT"
01000c00 NetBIOS Server Name (length 12)
4d0045004d00420045005200 "MEMBER"
03001e00 DNS Server Name (length 30)
6d0065006d006200650072002e0074006500730074002e0063006f006d00
"member.test.com"
00000000 Target Information Terminator
--------------------------------------------------------------------------------
InitializeSecurityContext called. Produces a Type 3 message:
4e544c4d53535000030000000000000040000000000000004000000000000000
4000000000000000400000000000000040000000000000004000000035c288e0
4e544c4d53535000 "NTLMSSP"
03000000 Type 3 message
0000000040000000 LM/LMv2 Response header (empty, local authentication)
0000000040000000 NTLM/NTLMv2 Response header (empty, local authentication)
0000000040000000 Domain Name header (empty, local authentication)
0000000040000000 User Name header (empty, local authentication)
0000000040000000 Workstation Name header (empty, local authentication)
0000000040000000 Session Key header (empty)
35c288e0 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate Sign (0x00000010)
Negotiate Seal (0x00000020)
Negotiate NTLM (0x00000200)
Negotiate Local Call (0x00004000)
Negotiate Always Sign (0x00008000)
Negotiate NTLM2 Key (0x00080000)
Negotiate Target Info (0x00800000)
Negotiate 128 (0x20000000)
Negotiate Key Exchange (0x40000000)
Negotiate 56 (0x80000000)
--------------------------------------------------------------------------------
AcceptSecurityContext called to complete the server-side context.
Server Context Export:
40a42e7840a42e7800000000000000000000000000000000
08ee0b00 server context handle dwUpper
35c289e1 flags
0000000000000000182e09001c2e0900982e0900a82f09000000000000000000
d002000000000000000000000000000000000000000000000200000000000000
ffffffffffffff7f00000000
65836771d7bf52df502634e521b3154b outbound signing key
9ed7ce6558f0f26db1fbf5163d7b24f9 inbound verifying key
f56d6b81749b7adaf3467f37bc36224e outbound encrypting key
65adf5ede40e84e7338d681e6cbc38ff inbound decrypting key
000000000000000000000000
7263d05c01f686ab2717e06f35c91b7a10fd0f5289ced6b6c423a213e6256a4d
3d128d30290899cbb502412f2d77ae1d4e55cf3fa6df5a785ded4aa3504c5484
155396d88345ff065beab3b738956e07f2b0ad36b8a80ba9f49305753e14e540
3428b4ccd3641ad18b037e9b67be3c1e70a17d816520565e744bd587bfc5b27f
8558099048ec800af1a5bbef92cdd2afe8c3042e510026f3bac7579ec8db5fbd
eb24bc43a742fc6111def922666dfe9d4791e9c60ef0d431d98cc259e2162b7c
49c0da1c2af5ee8e4f440c9a60ca4668391f3b213288f7a46be1c19f198a9c79
699737aadcfb829476f8d7b17be42c73338f71a0fa986c0dac18b9e3e73add62
00000000000000000000000000000000
651771fae2f5fc6da8973bd149126e92212b2f896101d23c568e40b325a383bd
42ec2752b295e5d09e36c899a94fffb8e053ac1c5c72d4de7c66b14b8d862977
bf5f47cfb76a81201f829098a067df7b78dc51630d8f790e0985316cb459e7d5
7f466b6f5a13948b38434ac54c7ee9ab340a6926d75d2aa523d81d0bc23ae4cc
aa1a419fc303cd88f6a4be04e100bb32e6cbf4feae9ab04808d9a111f937fb76
50104dc1c696b6c0740528f193f87d14cedd3f442e15d324454e64c7733e0f9c
ea0c163de8f3c92d1eebed33ba30f7f2350757d6b98abccafd7568229d1bef7a
5519da065e709be3ad2c8418dbb5f002a2eea68c395891c454af62806087a75b
0000000000000000
54004500530054004e0054005c007400650073007400 "TESTNT\test"
User Session Key = ????
Key exchange performed somehow? Shows up in signatures.
We are using server context:
serverSigningConstant =
"session key to server-to-client signing key magic constant" =
0x73657373696f6e206b657920746f207365727665722d746f2d636c69656e74
207369676e696e67206b6579206d6167696320636f6e7374616e7400
serverSealingConstant =
"session key to server-to-client sealing key magic constant" =
0x73657373696f6e206b657920746f207365727665722d746f2d636c69656e74
207365616c696e67206b6579206d6167696320636f6e7374616e7400
signingKey = MD5(key + serverSigningConstant) =
0x65836771d7bf52df502634e521b3154b (from context export)
sealingKey = MD5(key + serverSealingConstant) =
0xf56d6b81749b7adaf3467f37bc36224e (from context export)
Called MakeSignature on the server-side context for message
"0x0102030405060708".
Yields signature:
01000000adc70c8bd4834ae800000000
Sequence number is 0.
seqnum + message = 0x000000000102030405060708
HMAC(signingKey, 0x000000000102030405060708) =
0xb0bd637382da53f4ad3edf2c5a2c9592
sig = RC4(sealingKey, first 8 bytes) = 0xadc70c8bd4834ae8
version num + sig + seqnum:
01000000adc70c8bd4834ae800000000 = signature
--------------------------------------------------------------------------------
Called EncryptMessage twice on the server-side context for message
"0x0102030405060708".
Yields encrypted messages:
9c89720008251ab601000000d4af70567f5ab1df01000000
a8950e40b10e9af501000000c5447ccf7102d98c02000000
Uses RC4 cipher from previous signing operation (key exchange encrypts
signature with sealing key as well).
RC4(0x0102030405060708) = sealed message = 0x9c89720008251ab6
trailer buffer gets signature (sequence number is now 1 because of previous
signing, same RC4 cipher used for this signature too):
HMAC(signingKey, 0x010000000102030405060708) =
0xcd1d04a1962b7d82e6ffd7c37871bf15
sig = RC4(first 8 bytes) = 0xd4af70567f5ab1df
version num + sig + seqnum:
01000000d4af70567f5ab1df01000000 = trailer signature
second message is same, using RC4 cipher from previous operations:
RC4(0x0102030405060708) = sealed message = 0xa8950e40b10e9af5
trailer buffer signature with sequence 2:
HMAC(signingKey, 0x020000000102030405060708) =
0x3011549106db10de5694f567749cb9eb
sig = RC4(first 8 bytes) = 0xc5447ccf7102d98c
version num + sig + seqnum:
01000000c5447ccf7102d98c02000000 = trailer signature
Appendix D: Java Implementation of the Type 3 Response Calculations
import java.security.Key;
import java.security.MessageDigest;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
/**
* Calculates the various Type 3 responses.
*/
public class Responses {
/**
* Calculates the LM Response for the given challenge, using the specified
* password.
*
* @param password The user's password.
* @param challenge The Type 2 challenge from the server.
*
* @return The LM Response.
*/
public static byte[] getLMResponse(String password, byte[] challenge)
throws Exception {
byte[] lmHash = lmHash(password);
return lmResponse(lmHash, challenge);
}
/**
* Calculates the NTLM Response for the given challenge, using the
* specified password.
*
* @param password The user's password.
* @param challenge The Type 2 challenge from the server.
*
* @return The NTLM Response.
*/
public static byte[] getNTLMResponse(String password, byte[] challenge)
throws Exception {
byte[] ntlmHash = ntlmHash(password);
return lmResponse(ntlmHash, challenge);
}
/**
* Calculates the NTLMv2 Response for the given challenge, using the
* specified authentication target, username, password, target information
* block, and client nonce.
*
* @param target The authentication target (i.e., domain).
* @param user The username.
* @param password The user's password.
* @param targetInformation The target information block from the Type 2
* message.
* @param challenge The Type 2 challenge from the server.
* @param clientNonce The random 8-byte client nonce.
*
* @return The NTLMv2 Response.
*/
public static byte[] getNTLMv2Response(String target, String user,
String password, byte[] targetInformation, byte[] challenge,
byte[] clientNonce) throws Exception {
byte[] ntlmv2Hash = ntlmv2Hash(target, user, password);
byte[] blob = createBlob(targetInformation, clientNonce);
return lmv2Response(ntlmv2Hash, blob, challenge);
}
/**
* Calculates the LMv2 Response for the given challenge, using the
* specified authentication target, username, password, and client
* challenge.
*
* @param target The authentication target (i.e., domain).
* @param user The username.
* @param password The user's password.
* @param challenge The Type 2 challenge from the server.
* @param clientNonce The random 8-byte client nonce.
*
* @return The LMv2 Response.
*/
public static byte[] getLMv2Response(String target, String user,
String password, byte[] challenge, byte[] clientNonce)
throws Exception {
byte[] ntlmv2Hash = ntlmv2Hash(target, user, password);
return lmv2Response(ntlmv2Hash, clientNonce, challenge);
}
/**
* Calculates the NTLM2 Session Response for the given challenge, using the
* specified password and client nonce.
*
* @param password The user's password.
* @param challenge The Type 2 challenge from the server.
* @param clientNonce The random 8-byte client nonce.
*
* @return The NTLM2 Session Response. This is placed in the NTLM
* response field of the Type 3 message; the LM response field contains
* the client nonce, null-padded to 24 bytes.
*/
public static byte[] getNTLM2SessionResponse(String password,
byte[] challenge, byte[] clientNonce) throws Exception {
byte[] ntlmHash = ntlmHash(password);
MessageDigest md5 = MessageDigest.getInstance("MD5");
md5.update(challenge);
md5.update(clientNonce);
byte[] sessionHash = new byte[8];
System.arraycopy(md5.digest(), 0, sessionHash, 0, 8);
return lmResponse(ntlmHash, sessionHash);
}
/**
* Creates the LM Hash of the user's password.
*
* @param password The password.
*
* @return The LM Hash of the given password, used in the calculation
* of the LM Response.
*/
private static byte[] lmHash(String password) throws Exception {
byte[] oemPassword = password.toUpperCase().getBytes("US-ASCII");
int length = Math.min(oemPassword.length, 14);
byte[] keyBytes = new byte[14];
System.arraycopy(oemPassword, 0, keyBytes, 0, length);
Key lowKey = createDESKey(keyBytes, 0);
Key highKey = createDESKey(keyBytes, 7);
byte[] magicConstant = "KGS!@#$%".getBytes("US-ASCII");
Cipher des = Cipher.getInstance("DES/ECB/NoPadding");
des.init(Cipher.ENCRYPT_MODE, lowKey);
byte[] lowHash = des.doFinal(magicConstant);
des.init(Cipher.ENCRYPT_MODE, highKey);
byte[] highHash = des.doFinal(magicConstant);
byte[] lmHash = new byte[16];
System.arraycopy(lowHash, 0, lmHash, 0, 8);
System.arraycopy(highHash, 0, lmHash, 8, 8);
return lmHash;
}
/**
* Creates the NTLM Hash of the user's password.
*
* @param password The password.
*
* @return The NTLM Hash of the given password, used in the calculation
* of the NTLM Response and the NTLMv2 and LMv2 Hashes.
*/
private static byte[] ntlmHash(String password) throws Exception {
byte[] unicodePassword = password.getBytes("UnicodeLittleUnmarked");
MessageDigest md4 = MessageDigest.getInstance("MD4");
return md4.digest(unicodePassword);
}
/**
* Creates the NTLMv2 Hash of the user's password.
*
* @param target The authentication target (i.e., domain).
* @param user The username.
* @param password The password.
*
* @return The NTLMv2 Hash, used in the calculation of the NTLMv2
* and LMv2 Responses.
*/
private static byte[] ntlmv2Hash(String target, String user,
String password) throws Exception {
byte[] ntlmHash = ntlmHash(password);
String identity = user.toUpperCase() + target;
return hmacMD5(identity.getBytes("UnicodeLittleUnmarked"), ntlmHash);
}
/**
* Creates the LM Response from the given hash and Type 2 challenge.
*
* @param hash The LM or NTLM Hash.
* @param challenge The server challenge from the Type 2 message.
*
* @return The response (either LM or NTLM, depending on the provided
* hash).
*/
private static byte[] lmResponse(byte[] hash, byte[] challenge)
throws Exception {
byte[] keyBytes = new byte[21];
System.arraycopy(hash, 0, keyBytes, 0, 16);
Key lowKey = createDESKey(keyBytes, 0);
Key middleKey = createDESKey(keyBytes, 7);
Key highKey = createDESKey(keyBytes, 14);
Cipher des = Cipher.getInstance("DES/ECB/NoPadding");
des.init(Cipher.ENCRYPT_MODE, lowKey);
byte[] lowResponse = des.doFinal(challenge);
des.init(Cipher.ENCRYPT_MODE, middleKey);
byte[] middleResponse = des.doFinal(challenge);
des.init(Cipher.ENCRYPT_MODE, highKey);
byte[] highResponse = des.doFinal(challenge);
byte[] lmResponse = new byte[24];
System.arraycopy(lowResponse, 0, lmResponse, 0, 8);
System.arraycopy(middleResponse, 0, lmResponse, 8, 8);
System.arraycopy(highResponse, 0, lmResponse, 16, 8);
return lmResponse;
}
/**
* Creates the LMv2 Response from the given hash, client data, and
* Type 2 challenge.
*
* @param hash The NTLMv2 Hash.
* @param clientData The client data (blob or client nonce).
* @param challenge The server challenge from the Type 2 message.
*
* @return The response (either NTLMv2 or LMv2, depending on the
* client data).
*/
private static byte[] lmv2Response(byte[] hash, byte[] clientData,
byte[] challenge) throws Exception {
byte[] data = new byte[challenge.length + clientData.length];
System.arraycopy(challenge, 0, data, 0, challenge.length);
System.arraycopy(clientData, 0, data, challenge.length,
clientData.length);
byte[] mac = hmacMD5(data, hash);
byte[] lmv2Response = new byte[mac.length + clientData.length];
System.arraycopy(mac, 0, lmv2Response, 0, mac.length);
System.arraycopy(clientData, 0, lmv2Response, mac.length,
clientData.length);
return lmv2Response;
}
/**
* Creates the NTLMv2 blob from the given target information block and
* client nonce.
*
* @param targetInformation The target information block from the Type 2
* message.
* @param clientNonce The random 8-byte client nonce.
*
* @return The blob, used in the calculation of the NTLMv2 Response.
*/
private static byte[] createBlob(byte[] targetInformation,
byte[] clientNonce) {
byte[] blobSignature = new byte[] {
(byte) 0x01, (byte) 0x01, (byte) 0x00, (byte) 0x00
};
byte[] reserved = new byte[] {
(byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00
};
byte[] unknown1 = new byte[] {
(byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00
};
byte[] unknown2 = new byte[] {
(byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00
};
long time = System.currentTimeMillis();
time +=<PHONE_NUMBER>0000l; // milliseconds from January 1, 1601 -> epoch.
time *= 10000; // tenths of a microsecond.
// convert to little-endian byte array.
byte[] timestamp = new byte[8];
for (int i = 0; i < 8; i++) {
timestamp[i] = (byte) time;
time >>>= 8;
}
byte[] blob = new byte[blobSignature.length + reserved.length +
timestamp.length + clientNonce.length +
unknown1.length + targetInformation.length +
unknown2.length];
int offset = 0;
System.arraycopy(blobSignature, 0, blob, offset, blobSignature.length);
offset += blobSignature.length;
System.arraycopy(reserved, 0, blob, offset, reserved.length);
offset += reserved.length;
System.arraycopy(timestamp, 0, blob, offset, timestamp.length);
offset += timestamp.length;
System.arraycopy(clientNonce, 0, blob, offset,
clientNonce.length);
offset += clientNonce.length;
System.arraycopy(unknown1, 0, blob, offset, unknown1.length);
offset += unknown1.length;
System.arraycopy(targetInformation, 0, blob, offset,
targetInformation.length);
offset += targetInformation.length;
System.arraycopy(unknown2, 0, blob, offset, unknown2.length);
return blob;
}
/**
* Calculates the HMAC-MD5 hash of the given data using the specified
* hashing key.
*
* @param data The data for which the hash will be calculated.
* @param key The hashing key.
*
* @return The HMAC-MD5 hash of the given data.
*/
private static byte[] hmacMD5(byte[] data, byte[] key) throws Exception {
byte[] ipad = new byte[64];
byte[] opad = new byte[64];
for (int i = 0; i < 64; i++) {
ipad[i] = (byte) 0x36;
opad[i] = (byte) 0x5c;
}
for (int i = key.length - 1; i >= 0; i--) {
ipad[i] ^= key[i];
opad[i] ^= key[i];
}
byte[] content = new byte[data.length + 64];
System.arraycopy(ipad, 0, content, 0, 64);
System.arraycopy(data, 0, content, 64, data.length);
MessageDigest md5 = MessageDigest.getInstance("MD5");
data = md5.digest(content);
content = new byte[data.length + 64];
System.arraycopy(opad, 0, content, 0, 64);
System.arraycopy(data, 0, content, 64, data.length);
return md5.digest(content);
}
/**
* Creates a DES encryption key from the given key material.
*
* @param bytes A byte array containing the DES key material.
* @param offset The offset in the given byte array at which
* the 7-byte key material starts.
*
* @return A DES encryption key created from the key material
* starting at the specified offset in the given byte array.
*/
private static Key createDESKey(byte[] bytes, int offset) {
byte[] keyBytes = new byte[7];
System.arraycopy(bytes, offset, keyBytes, 0, 7);
byte[] material = new byte[8];
material[0] = keyBytes[0];
material[1] = (byte) (keyBytes[0] << 7 | (keyBytes[1] & 0xff) >>> 1);
material[2] = (byte) (keyBytes[1] << 6 | (keyBytes[2] & 0xff) >>> 2);
material[3] = (byte) (keyBytes[2] << 5 | (keyBytes[3] & 0xff) >>> 3);
material[4] = (byte) (keyBytes[3] << 4 | (keyBytes[4] & 0xff) >>> 4);
material[5] = (byte) (keyBytes[4] << 3 | (keyBytes[5] & 0xff) >>> 5);
material[6] = (byte) (keyBytes[5] << 2 | (keyBytes[6] & 0xff) >>> 6);
material[7] = (byte) (keyBytes[6] << 1);
oddParity(material);
return new SecretKeySpec(material, "DES");
}
/**
* Applies odd parity to the given byte array.
*
* @param bytes The data whose parity bits are to be adjusted for
* odd parity.
*/
private static void oddParity(byte[] bytes) {
for (int i = 0; i < bytes.length; i++) {
byte b = bytes[i];
boolean needsParity = (((b >>> 7) ^ (b >>> 6) ^ (b >>> 5) ^
(b >>> 4) ^ (b >>> 3) ^ (b >>> 2) ^
(b >>> 1)) & 0x01) == 0;
if (needsParity) {
bytes[i] |= (byte) 0x01;
} else {
bytes[i] &= (byte) 0xfe;
}
}
}
}
All trademarks mentioned in this document are the property of their
respective owners.


password used by customer's web user, during provisioning only.
not saved anywhere, since we're generating "Access key" for the app.
can't be used later (by admin), since login requires Yubikey.
Register customer:
use email with auto-forward to admin's email
- e.g: if administrator has an email<EMAIL_ADDRESS>use<EMAIL_ADDRESS>e-mails will be sent to<EMAIL_ADDRESS>(Enter full name of customer)
paste password from clipboard
Close window.
Open mail, "Bitgo Email Verification". Right-click on "Click to Verify" and open in incognito window again.
Paste password again to login
Configure client Account
Add a Yubikey device to user (label unimportant)
Create Customer's Access-Token:
in customer's window, top-right menu, User-Settings
Select, "Developer Options" and then "+ Add Access Token"
Give it a Label
scroll to the end of the page (very long..)
Enter "IP Address Allowed":
Check View, Spend, Full-Administrative-Access and "agree"
Top-right menu, select "Manage Organization" and Invite Users, as role "Member"
On Customer's incognito window: refresh page and select organization ("Tabookey") from top/right menu.
Create Wallet
In Admin window
In Chrome/Settings/Advanced/Downloads: change default location to the customer's flash drive
(otherwise, you'll need to copy the files manually after download)
Select "Wallets", click "Create Wallet"
Select coin: Ethereum, click "Create"
Quick Setup, click "Next"
Wallet name: (customer name), click "Next"
Click: Secondary Password.
Paste from clipboard wallet password (twice), click "Next"
Select "I already have a backup key". use This key:
Click "Next".
For the Key-ID: put the customer's ID number (Teudat Zehut)
Click "Next" : The Bitgo Keycard PDF is downloaded.
Follow BitGo instructions to enter activation code (from PDF) to activate wallet. Check all checkboxes and click activate.
Save the (encrypted) wallet password on the same secure drive
Add Wallet Users
In Admin window:
Click "Add Additional User" button
Tap "select people from your organization"
Choose customer's email from dropdown.
Select role "Spender", click "Next"
Use
Switch to the customer's incognito window, to accept invitation to join wallet.
Click "Activities" and then "Join"
Use
In Admin window: add guardians:
Click "Add Additional User" button
Tap "select people from your organization"
Choose guardians emails from dropdown.
Select role "Admin", click "Next"
Use
Contact guardians and make sure they accept invitation to join wallet.
You can only proceed after guardians (and customer) accepted the invitations.
Note: Guardian should refresh page, select organisation from top/right menu, on top of the page click "Activity" and approve joining the wallet.
Wallet Policy, upload
Change wallet Policy
Check: Approve All Outgoing Transactions
Dropdown: Require Multiple (2) Admin Approvals
MUST wait for 2nd guardian to approve these changes.
Upload to server:
Put in ADMINISTRATOR's Yubikey OTP #1:
Put in ADMINISTRATOR's Yubikey OTP #2:
Put in Customer's Yubikey OTP-ID:
Script below uses above wallet password
Click
Save above activation key (until user receives Yubikey)
Put initial deposit $4.99 in ETH into wallet.
Send Yubikey to user.
After Yubikey is received by customer:
Make video call, validate customer
Customer must enable fingerprint on device.
Let customer install App (from Google Play)
Cutomer launches application:
App requires user to enter Yubikey
Guardian gives activation key to customer on the phone
Customer enters activation key
Customer click VERIFY (enabled only if activation key is valid for yubikey)
~30 seconds waiting:
Pull encryped data from server, decrypt, configure app.


Enter your age in solar years
Enter at what age you'd prefer to die
Enter
This is your age in mercury years
This is your age in venus years
This is your age in mars years
This is your age in jupiter years
this is how much years you have left to live on each planet


The amount of data downloaded (in bytes)
The duration of the file
The encoded rate
The first piece
The height of the file
Get the file ID (index)
An alias for ID
The name of the file
The number of pieces
The priority of the file
The size of the file (in bytes)
The ETA to stream
The streamability of the file
Indicate if the file is streamable
The width of the file
Set the file data
Update the priority of the torrent
Refresh the torrent
Set the file priority
Generated using TypeDoc
Create the file instance


Thinking styles
Learning to code with an abstract random thinking style
June 28, 2015
The abstract random thinking style
According to the following personal thinking style quiz: Check Your Personal Thinking Style, I have an abstract random thinking style. Thus, I strive in settings that are people-oriented and unstructured and use abstract thought and intuition. Further characteristics of the abstract random thinking style are to establish good relationships with others and to like group activities. Learning is more difficult in competitive or unfriendly environments.
My personal experience at DBC
From past learning experiences, I know that I can solidify my learnings best when I "force" myself into a more structured way of lerning. Although I strive in unstructured settings and achieve the same results, I can control my learnings better when structuring my progress. However, knowing that I have no problem at all when things get messy or out of structure, but that I actually enjoy working in that way, gives a lot of confidence. While coding, I actually enjoy it a lot to jump right into a problem and not have an all structured approach. I like to build different blocks simultaneously and have it all just build up and fit in nicely together. I am excited to see how this will work when we get to more complicated challenges.
When working in pairs, I notice most that I have an abstract random thinking style in contrast to a concrete sequential abstract style. If the pair does not enjoy working in unstructured settings, it is even more important to have a structured approach to a challenge instead of jumping right in to the problem or building up different pieces simultaneously. The biggest difficulty for me is to be navigating as I struggle explaining my thoughts in a concrete and exact way. My approach to be overcoming this problem is to practice as much as I can. In each pairing session, I drive AND navigate. I try to check beforehand which will be the more complicated part of the challenge to be navigating and suggest to take on that part in order to challenge myself.


Back To Homepage
Chapter 1 - What is Diabetes?
Chapter 2 - Glucose Monitoring
Chapter 3 - Insulin
Chapter 4 - Hypoglycemia or Low
Chapter 5 - Hyperglycemia or High
Chapter 6 - Nutrition
Chapter 7 - Exercise and Diabetes
Chapter 8 - Personal Plan
Chapter 9 - Famous with Diabetes
Menu
Diabetes Tutorial For Kids
New-Onset Diabetes Educator


KRIPPENDORF'S TRIBE (PG-13)
Directed by Todd Holland Running Time: NA Scheduled Release: February 27, 1998 (USA-wide)
Reviewed by E. Benjamin Kelsey
* ½ (out of four)
The yet-to-be-released KRIPPENDORF'S TRIBE is being marketed as a family comedy, but buyer beware. This movie can't make up its mind. Is it a family comedy with vulgar references to both the male and female bodies, menstruation, circumcision, and sex that would make any parents squirm at the thought of having their child next to them? Or is it an adult comedy approached with such immaturity that only adolescents will appreciate the effort? Either way, "unbalanced" is the word to stamp on this hit and miss and miss and miss effort.
The premise is catchy - Widowed anthropology professor James Krippendorf (Richard Dreyfuss) has spent the past two years "getting over" the death of his wife, neglecting key research and squandering grant money on personal living expenses. Now it's time to show what he's achieved in those two years, and he has absolutely nothing to show for it. With a fabricated tale of studying a previously undiscovered tribe in New Guinea, Krippendorf petitions for new funds while hiding the fact that the previous $100,000 grant was spent on trips to McDonald's. But when his "discovery" becomes the latest craze among colleagues, the professor finds he must do more than talk about the tribe - he must create it. With the aid of his three children, the headstrong teen Shelly (Natasha Lyonne of EVERYONE SAYS I LOVE YOU), the slightly younger Mickey (Gregory Smith), and the nine-year-old Edmund (Carl Michael Lindner), the "Shelmikedmu" tribe (named from the first half of each child's name) is born, and videos quickly produced in Krippendorf's backyard are passed off as stunning documentary footage of the newly found New Guinea tribe.
Despite the professor's wishes, the buzz surrounding his discovery only grows, due in greatest part to Veronica Micelli (Jenna Elfman), an overly vivacious (and voluptuous) anthropologist who barges her way into the discovery and basically deems herself Krippendorf's main assistant. Hungry for recognition, Micelli sets up interviews, lectures, etc. in an effort to make this the biggest sociological event in history, a sure fire way to go down in the history books. Krippendorf, on the other hand, is seeing himself go down a jail cell corridor, not in history books, and with each new lecture, he must come up with something impressive to unleash about the tribe - mating habits, domestic structure, etc. Thru fumbling improvisation, and often some quick thinking from his oldest son, Krippendorf makes it thru each new lecture, but only creates more and more interest in the highly unique tribe. On the opposing end is Krippendorf's arch rival, Ruth Allen (Lily Tomlin), an arrogant professor whose jealousy drives her on a mission to disprove the existance of the non-existent tribe.
It's a cute idea, and approached with a more subtle (and mature) style, KRIPPENDORF'S TRIBE could've been a real winner. Sadly, the mostly-misfired toilet humor, overly comical musical score (by Bruce Broughton), and sugar coated sentiments (all the key ingredients of a "family comedy") just aren't the right tone for this film.  At the state it's in now, you've got something along the lines of MEDICINE MAN meets MRS. DOUBTFIRE meets DUMB & DUMBER, and that's not a concoction anyone should be overly anxious to try.
The overall product here is a highly forgettable cup of "average", with a few laugh-out-loud moments and a great big gap in between them. Most of the characters are surprisingly two-dimensional, and the only one who seems to exhibit any real acting effort (Lyonne) seems to go greatly unappreciated. Director Todd Holland has gone about making this film in all the wrong ways. It's stuck in limbo between Disney family fare (JUNGLE 2 JUNGLE) and potentially hilarious adult comedy (A FISH CALLED WANDA). It's this unbalanced structure that really knocks it down a grade, and it's a brutal drop.
A strong warning to parents: forget the impression given by advertisements, do you want to take your kids to a film that has a woman asking a man if he finds her attractive merely because she's holding his penis? Yes, it's put that bluntly! Just be warned - this is merely one example of the many shocking subjects to be brought up in the film, and others might not be as tame.
February 21, 1998
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


You can create code constructs using statement completion. Start typing a method declaration or a statement, and press &shortcut:EditorChooseLookupItemCompleteStatement; after the opening parenthesis. The braces are created, with the caret placed inside:


PM Imran praises economic team | Pakistan - Geo.tv
by Web DeskISLAMABAD: Prime Minister Imran Khan on Saturday heaped praise on the government's economic team, claiming that due to the policies of the government, the value of the rupee had increased.
According to details, the prime minister said that in the past four months, the current account deficit had been eliminated and for the first time in more than two years, the current account had recorded a surplus.
This is not the first time that the prime minister has claimed that the economy was out of the woods in Pakistan. A couple of days ago, he said that Pakistan's economy had now stabilised and as a result the government was focused on job creation.
The prime minister had said that the rupee’s value has increased against the dollar in the last three months and the country’s exports were also on the rise. He had also congratulated his team on the stabilisation of the rupee.
The prime minister had further said that the economy had stabilised and the country would now progress. "The most positive outcome is that the IMF, World Bank and ADB themselves said that Pakistan is on the right direction," he had said.


Rich and famous to get major tax refund after victory against HMRC
Wayne Rooney is among hundreds of famous faces in line for a major tax refund after winning a battle against HMRC.
A host of celebrities ploughed money into a £263m scheme, which allowed them to claim tax relief in return for investing into a project to build two data centres.
675 people paid a combined total of £79million towards the Tyneside based development in 2011, and got £131million in relief.
But the taxman argued that those involved – including comedian Jimmy Carr and football manager Arsene Wenger – benefited excessively from tax cuts.
In 2016, HMRC sent so-called ‘accelerated payment notices’ (APN) demanding those involved to hand over more money in tax.
After some appealed to the tax tribunal the case went to the High Court, which ruled against HMRC.
The ruling yesterday means some of the investors who have already paid tax demands will be able to claim money back.
Advertisement Advertisement
It is not clear how much each celebrity had put into the scheme, and there was no suggestion of wrongdoing by any of those involved.
The tax relief was meant to start economic growth in deprived areas – but HMRC said it amounted to ‘tax profit’.
The scheme’s allowances meant investors could claim 50% tax relief on the full £263million cost of the project, even though their total investment was only £79 million.
Many said at the time that were pleased to be investing in schemes they hoped would create jobs in the North East.
Two judges, Mr Justice Zacarol and Judge Jonathan Richards, ruled that the schemes did qualify for relief.
The sites were completed in 2012 and 2013 and are designed to house computer servers belonging to businesses and government organisations.
However, the court heard that since the data centres have been completed, efforts to find a tenant have been ‘unsuccessful’.
The judges said: ‘At no point since the appellants acquired their interests in the Data Centres have those Data Centres been let.’
Other celebrities who had invested into the scheme include Roy Hodgson, the late Status Quo guitarist Rick Parfitt, and Lady Elizabeth-Ann Redgrave, wife of Olympic legend Sir Steve.
The case threatens to drag on further, with judges giving HMRC the right to appeal.
Mr Justice Zacaroli said: ‘We invited further submissions from the parties as to how the apportionment of the price that which does and that which does not qualify for EZAs is to be calculated.’
Advertisement Advertisement
A HMRC spokesperson said: ‘We are disappointed with the decision and are considering an appeal.’
Got a story for Metro.co.uk?
Get in touch with our news team by emailing us at<EMAIL_ADDRESS>For more stories like this, check our news page.


The unit called AcquisitionTime accepts any data type that implements the
Signal
interface as input and outputs a Parameter type that contains the acquisition
time of the input data. This can be input to another unit as a parameter,
such as SetAcqTime. If the input is not of
Signal type, then a text parameter is output with an error message.


--- permalink: /about/ layout: single title: Creating with performance in mind tags: [about, me, allthethings] ---
I'm a developer with solid roots in performance testing and a passion for solving puzzles. My strengths include strong analytical skills, the ability to understand applications built on a variety of architectures, and solid communication skills from years of work as a consultant (remote and onsite). My most recent obsessions are Ruby, Rails, Android, Raspberry Pi, Javascript, and CSS.
Over the years, I've truly begun to enjoy public speaking and am proud to have spoken at three conferences. I'm looking forward to future speaking opportunities as I progress in my development career.
At my previous job, I was tasked with training all new performance testers (who often started with minimal testing background). That experience led me to search for ways to continue mentoring as I moved out of performance testing and into development. Luckily, I found the GT MentorJackets program and have been volunteering as a mentor for the past two years.
When I'm not sitting at my computer doing programmer things, I enjoy cooking and playing board games with my husband Yang and hanging out with our mini bull terrier Allie (gator).


A simple python tkinter application, with a slight focus on biology.
This python project consists of 6 different modules. Each module preforms a specific task, demonstrated within the name.
This module accepts an input of DNA nucleotides, and converts the string into the corresponding amino acid sequence that it represents. The default button, will set the contents of the box to a predefined DNA sequence.
This module accepts a string of either nucleotides or amino acids. The specific input type of DNA, RNA, or protein can be set. The module will then attempt to convert the string into the total mass, from the corresponding input type. This module also provides 3 default inputs, one for DNA, one for RNA, and one for protein.
This module accepts a string of nucleotides, then plots the relative density of GC within the region.
This module accepts a string representing the relative path to the image. The image can then have the color values altered, or the image set to greyscale.
This module accepts two different strings, one in each input box. The user then defines whether the sequences should be compared as DNA, or protein sequences. There are two different comparison options provided, to compare either by similarity or by alignment. Alignment will take into account the distance between regions of similarity.
This module accepts parameters, an amplitude, frequency, and decay value, that is used to generate a graph showing the signal. The user can input multiple parameters, to stack multiple signals together. There is also the option to show a fourier transform of the data; showing the real component, imaginary, or the magnitude.


Apache Drill is a low latency distributed query engine for large-scale datasets, including structured and semi-structured/nested data. Inspired by Google's Dremel, Drill is designed to scale to several thousands of nodes and query petabytes of data at interactive speeds that BI/Analytics environments require.
Drill includes a distributed execution environment, purpose built for large-scale data processing. At the core of Apache Drill is the 'Drillbit' service, which is responsible for accepting requests from the client, processing the queries, and returning results to the client.
A Drillbit service can be installed and run on all of the required nodes in a Hadoop cluster to form a distributed cluster environment. When a Drillbit runs on each data node in the cluster, Drill can maximize data locality during query execution without moving data over the network or between nodes. Drill uses ZooKeeper to maintain cluster membership and health-check information.
Note that though Drill works in a Hadoop cluster environment, Drill is not tied to Hadoop and can run in any distributed cluster environment. The only pre-requisite for Drill is Zookeeper.
The following image represents the flow of a Drill query: The flow of a Drill query typically involves the following steps:
The following image represents Drillbit components:
• RPC end point: Drill exposes a low overhead protobuf-based RPC protocol to communicate with the clients. Additionally, a C++ and Java API layers are also available for the client applications to interact with Drill. Clients can communicate to a specific Drillbit directly or go through a ZooKeeper quorum to discover the available Drillbits before submitting queries. It is recommended that the clients always go through ZooKeeper to shield clients from the intricacies of cluster management, such as the addition or removal of nodes.
• SQL parser: Drill uses Calcite, the open source framework, to parse incoming queries. The output of the parser component is a language agnostic, computer-friendly logical plan that represents the query.
• Optimizer: Drill uses various standard database optimizations such as rule based/cost based, as well as data locality and other optimization rules exposed by the storage engine to re-write and split the query. The output of the optimizer is a distributed physical query plan that represents the most efficient and fastest way to execute the query across different nodes in the cluster.
• Execution engine: Drill provides a MPP execution engine built to perform distributed query processing across the various nodes in the cluster.
• Storage plugin interfaces: Drill serves as a query layer on top of several data sources. Storage plugins in Drill represent the abstractions that Drill uses to interact with the data sources. Storage plugins provide Drill with the following information:
• Metadata available in the source
• Interfaces for Drill to read from and write to data sources
• Location of data and a set of optimization rules to help with efficient and faster execution of Drill queries on a specific data source
In the context of Hadoop, Drill provides storage plugins for files and HBase/M7. Drill also integrates with Hive as a storage plugin since Hive provides a metadata abstraction layer on top of files, HBase/M7, and provides libraries to read data and operate on these sources (SerDes and UDFs).
When users query files and HBase/M7 with Drill, they can do it directly or go through Hive if they have metadata defined there. Drill integration with Hive is only for metadata. Drill does not invoke the Hive execution engine for any requests.
• Distributed cache: Drill uses a distributed cache to manage metadata (not the data) and configuration information across various nodes. Sample metadata information that is stored in the cache includes query plan fragments, intermediate state of the query execution, and statistics. Drill uses Infinispan as its cache technology.
The goal for Drill is to bring the SQL ecosystem and performance of the relational systems to Hadoop scale data WITHOUT compromising on the flexibility of Hadoop/NoSQL systems. There are several core architectural elements in Apache Drill that make it a highly flexible and efficient query engine.
Dynamic schema discovery: Drill does not require schema or type specification for the data in order to start the query execution process. Instead, Drill starts processing the data in units called record-batches and discovers the schema on the fly during processing. Self-describing data formats such as Parquet, JSON, AVRO and NoSQL databases have schema specified as part of the data itself, which will be leveraged by Drill dynamically at the query time. Schema can change over the course of a Drill query, so all of the Drill operators are designed to reconfigure themselves when such schema changing events occur.
Flexible data model: Drill is purpose-built from ground up for complex/multi-structured data commonly seen in Hadoop/NoSQL applications such as social/mobile, clickstream, logs and sensor equipped IOT. From a user point of view, Drill allows access to nested data attributes, just like SQL columns, and provides intuitive extensions to easily operate on them. From an architecture point of view, Drill provides a flexible hierarchical columnar data model that can represent complex, highly dynamic and evolving data models and allows efficient processing of it without need to flatten or materialize it either design time or at execution time. Relational data in Drill is treated as a special or simplified case of complex/multi-structured data.
Decentralized metadata: Unlike other SQL-on-Hadoop technologies or any traditional relational database, Drill does not have a centralized metadata requirement. In order to query data through Drill, users do not need to create and manage tables/views in a metadata repository, or rely on a database administrator group for such a function.
Drill metadata is derived from the storage plugins that correspond to data sources. Drill supports a varied set of storage plugins that provide a spectrum of metadata ranging from full metadata such as for Hive, partial metadata such as for HBase, or no central metadata such as for files.
De-centralized metadata also means that Drill is NOT tied to a single Hive repository either. Users can query from multiple Hive repositories in a single query and then combine data with information from HBase tables or a file in the distributed file system.
Users also have the ability to create metadata (tables/views/databases) within Drill using the SQL DDL syntax. De-centralized metadata is applicable during metadata creation. Drill allows persisting metadata in one of the underlying data sources.
From a client access perspective, Drill metadata is organized just like a traditional DB
(Databases->Tables/Views->Columns). The metadata is accessible through the ANSI standard INFORMATION_SCHEMA database.
Extensibility: Drill provides an extensible architecture at all layers, including storage plugin layer, query layer, query optimization/execution, and client APIs. You can customize any layer for the specific needs of an organization or you can extend the layer to a broader array of use cases.
Drill provides a built in classpath scanning and plugin concept to add additional storage plugins, functions, and operators with minimal configuration.
The following list provides a few examples of Drill's extensible architectural capabilities:
Drill is designed from the ground up for high performance on large datasets. Few core elements of Drill processing that help Drill achieve its performance include:
Distributed engine: Drill provides a powerful distributed execution engine for processing queries. Users can submit requests to any node in the cluster. You can simply add new nodes to the cluster to scale for larger volumes of data, support more users or to improve performance.
Columnar execution: Drill optimizes for both columnar storage and execution by using an in-memory data model that is hierarchical and columnar. When working with data stored in columnar formats such as Parquet, Drill avoids disk access for columns that are not involved in an analytic query. Drill also provides an execution layer that performs SQL processing directly on columnar data without row materialization. The combination of optimizations for columnar storage and direct columnar execution significantly lowers memory footprints and provides faster execution of BI/Analytic type of workloads.
Vectorization: Rather than operating on single values from a single table record at one time, vectorization in Drill allows the CPU to operate on vectors, referred to as a Record Batches. Record Batches are arrays of values from many different records. The technical basis for efficiency of vectorized processing is modern chip technology with deep-pipelined CPU designs. Keeping all pipelines full to achieve efficiency near peak performance is something impossible to achieve in traditional database engines, primarily due to code complexity.
Runtime compilation:
Runtime compilation is faster compared to the interpreted execution. Drill generates highly efficient custom code for every single query for every single operator. Here is a quick overview of the Drill compilation/code generation process at a glance.
Optimistic and pipelined query execution: Drill adopts an optimistic execution model to process queries. Drill assumes that failures are infrequent within the short span of a query and therefore does not spend time creating boundaries or checkpoints to minimize recovery time. Failures at node level are handled gracefully. In the instance of a single query failure, the query is rerun. Drill execution uses a pipeline model where all tasks are scheduled at once. The query execution happens in-memory as much as possible to move data through task pipelines, persisting to disk only if there is memory overflow.


The Cookie Stand!
Locations
1st and Pike
Hours: 6am-8pm
SeaTac Airport
Hours: 6am-8pm
Seattle Center
Hours:6am-8pm
Capital Hill
Hours:6am-8pm
Alki
Hours: 6am-8pm
Sales


Try out our Premium Member services: Virtual Legal Assistant, Query Alert Service and an ad-free experience. Free for one month and pay only if you like it.
S.No.01 HIGH COURT OF JAMMU AND KASHMIR AT JAMMU WP(C) No.4531/2019 CM No. 9597/2019 M/s Choudhary Poulty Farm ...Petitioner(s) Through:- Mr. Amit Gupta, Advocate V/s Union of India and others ...Respondent(s) Through:- Mr. Aijaz Lone, Dy. AG Coram: HON'BLE MR. JUSTICE SANJEEV KUMAR, JUDGE ORDER
1. Impugned in this petition is order No.97-PCB of 2019 dated 28.11.2019, whereby J&K Pollution Control Board in exercise of powers under Section 31 (A) of the Air (Prevention and Control of Pollution) Act, 1981 (hereinafter referred to as "the Act") has directed the District Magistrate, Samba to get the Poultry Farm of the petitioner closed immediately and has further directed the Chief Engineer, Electric & Maintenance (PDD) to snap the electric supply to the aforesaid unit.
2. Learned counsel for the petitioner assails the impugned order primarily on two counts, one that with the promulgation of the J&K Reorganization Act, 2019, the erstwhile State of J&K has become Union Territory and , therefore, by operation of Section 6 of the Act, the State Pollution Control Board has ceased to have jurisdiction over the matter and the action, if any, required to be taken under the Act, can be validly taken by 2 WP(C) No.4531/2019 the Central Board only. He further submits that the poultry unit does not fall within the expression "plant" as used in Section 21 of the Act.
3. Apart from elaborating his submissions on aforesaid two aspects, learned counsel for the petitioner also sought indulgence of this Court to consider taking some measure of protection with regard to the live stock (poultry) on equitable consideration.
4. Mr. Lone, learned counsel appearing for the respondents has vehemently opposed the writ petition and submits that the State Pollution Control Board has all the jurisdiction to issue impugned order. He relied upon Clause 17 of the Jammu and Kashmir Reorganisation (Removal of Difficulties) Order, 2019.
5. Having heard learned counsel of the parties and perused the record, I am of the view that so far as challenge to the impugned order is concerned, same does not have any substance and, therefore, merits rejection. The poultry unit is a plant as defined under Section 21 of the Act, therefore, cannot operate unless, there is consent to establish and operate granted by the State Pollution Control Board.
6. The plea of the learned counsel for the petitioner that with the coming into force of the J&K Reorganization Act, 2019, the State Pollution Control Board has ceased to have jurisdiction is also not tenable in view of issuance of the Jammu and Kashmir Reorganisation (Removal of Difficulties) Order, 2019 by the Government of India. However, I am inclined to accept the request of the learned counsel for the petitioners for providing some measures of protection so far as live stock in the poultry farm is concerned purely on equitable considerations.
7. For the foregoing reasons, this writ petition is disposed of in the following manner:-
3 WP(C) No.4531/2019
i) The Chief Engineer, Electric and Maintenance (PDD), Jammu shall restore electric supply to the petitioner-unit within two days from the date copy of this order is served upon him.
ii) The electricity shall be supplied to the petitioner-unit only for a period of three months from today.
iii) The petitioner shall during the aforesaid period shall not add any new stock to its poultry farm.
iv) The aforesaid directions are subject to petitioner's furnishing an undertaking to this Court that after expiry of the period of three months, he will close the unit on its own, unless he gets no objection from the Pollution Control Board (consent to establish and to operate) and fulfils other requisite legal requirements.
v) In case, the petitioner does not abide by the undertaking given by him to this Court, besides that he will be liable to be proceeded against for contempt of this Court, the respondents shall also be at liberty to forcibly close the petitioner-unit.
(Sanjeev Kumar) Judge Jammu.
31.12.2019 Vinod.
Whether the order is speaking :Yes/No Whether the order is reportable: Yes/No SANJEEV KUMAR UPPAL 2020.01.03 11:17 I attest to the accuracy and integrity of this document


Design Mode
Test Mode
Internal Constraints
External Constraints
Options
Shaft type:
Straight
Stepped
Merge bearing housings:
Internal Contraints
External Constraints
Left Bearing
Right Bearing


{% extends "layout.html" %}
{% block content %}
{% include "includes/phase_banner_alpha.html" %}
{% set breadcrumbs = {
items: [
{
link: '/beta/v5/your-profile',
title: 'Your profile'
},
{
title: 'Capacity'
}
]
}
%}
{% include "includes/breadcrumbs.html" %}
{% endblock %}


You need to enable JavaScript to run this app.
symphoni
the party starts here
Start Party!
Join Party
Privacy Policy
Contact Us
Start Party Here!


Company
Furniture
Electronic
Decrotain
Household
Contact
Living
Objects
6
Tabletop
9
Information
Delivery
Legal Notice
Terms and conditions of use
About us
Secure payment
Outstore
Information
Delivery
Legal Notice
Terms and conditions of use
About us
Secure payment
Outstore
NEW
Buidan 12
Buidan 12
Buidan 12
Buidan 12
Buidan 12
SALE
Buidan 12


EastEnders' Maisie Smith wins Children in Need's Strictly Come Dancing special
Maisie Smith emerged as the winner tonight of EastEnders’ very own Strictly Come Dancing special for Children in Need.
The actress – who portrays Tiffany Butcher in the soap – was competing against fellow castmates Louisa Litton, Rudolph Walker and Ricky Champ.
The 18-year-old was partnered with Strictly pro Kevin Clifton for a special group routine to the classic bop Dancing in the Street, which has been performed by everyone from Van Halen to David Bowie and Mick Jagger.
But in the battle of Walford, it was the youngster who came out on top in the end.
Judges Shirley Ballas, Craig Revel Horwood, Bruno Tonioli and Motsi Mabuse all conferred on the decision – and awarded Maisie with the very special Pudsey edition of the famous Glitterball trophy.
Speaking after her win, Maisie said: ‘I honestly had the most amazing week and I couldn’t have asked for a more wonderful team by my side.
Advertisement Advertisement
‘It’s been amazing.’
The only question remaining now of course…is when is Maisie going to sign up to the main show?!
It was a question many fans found themselves asking too.
‘You were amazing Maisie,’ one fan wrote. ‘You should be on next year’s Strictly!’
Another fan clearly agreed, adding: ‘Maisie Smith just had to do Strictly next year.’
The campaign for Maisie Smith and Strictly Come Dancing 2020 starts here!
In other Children in Need news, host for the night Ade Adepitan had to apologise live-on-air after a London-based segment was hit with technical difficulties.
The annual charity show is aiming to raise money tonight for disadvantaged children up and down the UK.
The charity will be hoping, as ever, to break their own record for the most donations raised in a single broadcast – with last year’s total reaching more than £50 million.
Children In Need airs on BBC One.
Got a showbiz story?
If you've got a story, video or pictures get in touch with the Metro.co.uk Entertainment team by emailing us<EMAIL_ADDRESS>calling 020 3615 2145 or by visiting our Submit Stuff page - we'd love to hear from you.
Advertisement Advertisement


Hello !
I am Tarushi Pathak. I am , currently , a 3rd year student at SRM Institute of Science and Technology where
I am pursuing my Bachelor's in CSE.
I am a highly driven individual with a core interest in the field of Data Science and Deep Learning.
I strive to stay ahead of the curve by ceaselessly updating my
knowledge and skillset.
Me and Machine Learning : A Love Story
I have interned at multiple companies , mostly as a Machine Learning Intern and have done multiple courses in the same field.
Implementing Machine Learning or training a model
(while implementing deep learning), always leaves me spellbound and wanting for more.
I have tried my hands at other technologies such as web development, internet of things and app
development, but it is only when I work with a
deep learning model that I become entirely engrossed in the process. Thanks to the courses, I am able to understand things like, the model
not learning
anything in training by looking at the loss graphs or when the model annoys me with some errors , I can't rest until I resolve the bugs. I don't know much
about passion but
this field definitely seems closer to that.
This is why I wish to pursue a career in this field.


We bring together everything that's required to craft your profile and share your story effectively with a global audience of high school students.
Zapply can revolutionize your company . Join today
Students
Fairs
Universities
Hard Workers
Our analytics will provide insights to help you grow. Use a dashboard to manage your fairs, track the number of stdents you're reaching, and ways to reach a broader audience.
Whether you need specific advice or general support, we're here to help. Contact our 24/7 support service