X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type; q=dns; s=default; b=T96X
	CUVvru7mqWsFXTcKecvBo4YkQAAkeSI54pptLFRR53IRSYp65niR2h1XxS3qsE8D
	r1Ap2oawMJ024LUuYHjbBrTqUrcePkyAe6ykLgk/uAFG8d9VJjgByik2uHhaQWnw
	03zopaSisTrWMFtu98No9EjYIaTdcOfORLuYUco=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type; s=default; bh=hxtDKES88O
	2OvqSobwPCsW311ZQ=; b=mGI+21EKqT+2k+EdydVoFL1dRi67kuddAWLqak5rXb
	xrmUeGurH0Od9j5nKf4uMC51PWR1hv39IMEv09ehYsCwI8inCY41kQr97nQ4XHKS
	WcMxU1yjZTYQz5dSirQ9KaBRx0eHEGNgWlXsGyZThyWSwKh1/aZFz40k8gu3yOVq
	U=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=lying, 864, 3579, kills
X-HELO: mail-wm0-f48.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20130820;        h=x-gm-message-state:subject:to:references:from:message-id:date         :user-agent:mime-version:in-reply-to;        bh=o5jfv322wQzbnN8ZiUGSizbNd78IPNGQfRAffWp9cpE=;        b=fB5rsquQVGIXjnb1BvapDczRkeLXG5sUo9KxdMH6VeZk8UCF3e63XQF2ptCN9MOu5m         VyucTdNHxsaRrYczAVgvQiP+WJxk3RazJzxIjDLrwUdASnGQE/9rDhDoKuWESrw1Bhyx         lcd3sX6WELwOdhEBolvd0GKqxE++dvNfnCL8ymf7794bWVCT0pwkBwuuh3ifxIQn5YYn         SWGT7UFYVgAgnePf+5oBzfoF6ub0JrdSPjTEG8U3uISsllt6Z4P8ej28WUPdKp/93iNu         NE15SMptSMPVuIsL+lW9J3gj9kpSX+Zr4qop6KQ7K5voiV2jMkfkyLRAPDqeUlD9XEH7         GPKQ==
X-Gm-Message-State: ALyK8tIoCIptfNZ8Xf/BZzQ7Q6MGkhM7kl15YW4U1uOrMbTKMCT+BCX3Pu1dqbQOcVb6pg==
X-Received: by 10.28.26.67 with SMTP id a64mr28093867wma.70.1467322046786;        Thu, 30 Jun 2016 14:27:26 -0700 (PDT)
Subject: Re: Why does ldd not show cyg*.dll in its output?
To: cygwin AT cygwin DOT com
References: <3AD694B4-17D4-4963-88FD-435AD4DD36D5 AT etr-usa DOT com> <4b37d689-285d-7dd4-3e3d-d40b4ee2f81f AT cygwin DOT com> <cb61e083-4229-6662-4815-130c41dfe2a4 AT t-online DOT de> <8AFB6FBD-0E6A-4DE7-BB08-61D12D20ED40 AT etr-usa DOT com> <1b8d57d1-b8f8-6027-ef4a-073a60fbae84 AT gmail DOT com>
From: David Macek <david DOT macek DOT 0 AT gmail DOT com>
Message-ID: <a62bb487-1a0c-77a0-ce29-09520dcbdb7b@gmail.com>
Date: Thu, 30 Jun 2016 23:27:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <1b8d57d1-b8f8-6027-ef4a-073a60fbae84@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010202040100050508010908"
X-IsSubscribed: yes

--------------ms010202040100050508010908
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 29. 6. 2016 23:45, David Macek wrote:
> I can try watching them side by side in debuggers tomorrow, maybe I'll fi=
nd something.

Yep, found something. TL;DR the issue is that Windows spins a thread in the=
 process before our DLLs are loaded. Detailed analysis below.

On my Win8.x, the ldd "debugger" receives these events:

 1. CREATE_PROCESS_DEBUG_EVENT
 2. LOAD_DLL_DEBUG_EVENT for ntdll.dll
 3. LOAD_DLL_DEBUG_EVENT for KERNEL32.DLL
 4. LOAD_DLL_DEBUG_EVENT for KERNELBASE.dll
 5. LOAD_DLL_DEBUG_EVENT for msys-intl-8.dll
 6. LOAD_DLL_DEBUG_EVENT for msys-2.0.dll
 7. LOAD_DLL_DEBUG_EVENT for msys-iconv-2.dll
 8. EXCEPTION_DEBUG_EVENT ev.u.Exception =3D {ExceptionRecord =3D {Exceptio=
nCode =3D 2147483651, ExceptionFlags =3D 0, ExceptionRecord =3D 0x0, Except=
ionAddress =3D 0x7ffda38d1b90 <ntdll!LdrInitShimEngineDynamic+816>, NumberP=
arameters =3D 1, ExceptionInformation =3D {0 <repeats 15 times>}}, dwFirstC=
hance =3D 1}
 9. OUTPUT_DEBUG_STRING_EVENT ev.u.DebugString =3D {lpDebugStringData =3D 0=
x23f2a0 <error: Cannot access memory at address 0x23f2a0>, fUnicode =3D 0, =
nDebugStringLength =3D 24}
10. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread =3D {hThread =3D 0x88, lpTh=
readLocalBase =3D 0x7ff5ffffb000, lpStartAddress =3D 0x180044cf0 <cygthread=
::stub(void*)>}=20
11. EXIT_THREAD_DEBUG_EVENT
12. EXIT_PROCESS_DEBUG_EVENT

I would say events #8 and #9 are not important (ldd ignores them as well). =
Event #10 causes ldd to call `TerminateProcess` because we don't want any o=
f the analyzed program's code to run. This in turn causes events #11 and #1=
2, after which ldd exits.

On my Win10, events are like this:

 1. CREATE_PROCESS_DEBUG_EVENT
 2. LOAD_DLL_DEBUG_EVENT for ntdll.dll
 3. LOAD_DLL_DEBUG_EVENT for KERNEL32.DLL
 4. LOAD_DLL_DEBUG_EVENT for KERNELBASE.dll
(5) LOAD_DLL_DEBUG_EVENT for msys-intl-8.dll
 6. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread =3D {hThread =3D 0x168, lpT=
hreadLocalBase =3D 0x22c000, lpStartAddress =3D 0x7fff19e80720 <ntdll!RtlFi=
ndActivationContextSectionString+3456>}
 7. EXIT_THREAD_DEBUG_EVENT
 8. EXIT_PROCESS_DEBUG_EVENT

Event #6 is the culprit here. NT apparently starts a thread in our process =
which confuses ldd into believing that the process has finished loading DLL=
 from its import table and kills it, as explained above. The thread appears=
 non-deterministically, too, sometimes I see event #5 (and the associated D=
LL in ldd's output), sometimes not. The thread's entry point is always the =
same and ProcExp reports the same location (I checked in case of some symbo=
l mash-up, as it often happens when debugging across the Cygwin-Windows bou=
ndary). When I broke ldd at `case CREATE_THREAD_DEBUG_EVENT`, the new threa=
d's stack trace (from ProcExp) looked like this:

ntoskrnl.exe!KeSynchronizeExecution+0x3f26
ntoskrnl.exe!KeWaitForMultipleObjects+0x10b5
ntoskrnl.exe!KeWaitForMultipleObjects+0xb6f
ntoskrnl.exe!KeWaitForSingleObject+0x370
ntoskrnl.exe!CmUnRegisterCallback+0x1b02c
ntoskrnl.exe!CmUnRegisterCallback+0x1c225
ntoskrnl.exe!NtVdmControl+0x45822
ntoskrnl.exe!FsRtlFreeExtraCreateParameter+0x44b
ntoskrnl.exe!KeSynchronizeExecution+0x4716
ntoskrnl.exe!KeSynchronizeExecution+0x4690
!RtlUserThreadStart

I came up with this naive fix:

--- ldd.cc.orig 2016-04-28 21:54:57.556500700 +0200
+++ ldd.cc      2016-06-30 22:18:05.332452300 +0200
@@ -357,6 +357,9 @@
            }
          break;
        case CREATE_THREAD_DEBUG_EVENT:
+          if (ev.u.CreateThread.lpStartAddress =3D=3D (void*)0x7fff19e8072=
0) {
+            break;
+          }
          TerminateProcess (hProcess, 0);
          break;
        case EXIT_PROCESS_DEBUG_EVENT:

After which the output switched back to normal. One observed sequence of ev=
ents:

 1. CREATE_PROCESS_DEBUG_EVENT
 2. LOAD_DLL_DEBUG_EVENT for ntdll.dll
 3. LOAD_DLL_DEBUG_EVENT for KERNEL32.DLL
 4. LOAD_DLL_DEBUG_EVENT for KERNELBASE.dll
 5. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread =3D {hThread =3D 0x14c, lpT=
hreadLocalBase =3D 0x26a000, lpStartAddress =3D 0x7fff19e80720 <ntdll!RtlFi=
ndActivationContextSectionString+3456>}
 6. LOAD_DLL_DEBUG_EVENT for msys-intl-8.dll
 7. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread =3D {hThread =3D 0x138, lpT=
hreadLocalBase =3D 0x26c000, lpStartAddress =3D 0x7fff19e80720 <ntdll!RtlFi=
ndActivationContextSectionString+3456>}
 8. LOAD_DLL_DEBUG_EVENT for msys-2.0.dll
 9. LOAD_DLL_DEBUG_EVENT for msys-iconv-2.dll
10. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread =3D {hThread =3D 0x18c, lpT=
hreadLocalBase =3D 0x274000, lpStartAddress =3D 0x7fff19e80720 <ntdll!RtlFi=
ndActivationContextSectionString+3456>}
11. EXCEPTION_DEBUG_EVENT ev.u.Exception =3D {ExceptionRecord =3D {Exceptio=
nCode =3D 2147483651, ExceptionFlags =3D 0, ExceptionRecord =3D 0x0, Except=
ionAddress =3D 0x7fff19f2fd00 <ntdll!LdrInitShimEngineDynamic+864>, NumberP=
arameters =3D 1, ExceptionInformation =3D {0 <repeats 15 times>}}, dwFirstC=
hance =3D 1}
12. OUTPUT_DEBUG_STRING_EVENT ev.u.DebugString =3D {lpDebugStringData =3D 0=
x5ff1a0 <error: Cannot access memory at address 0x5ff1a0>, fUnicode =3D 0, =
nDebugStringLength =3D 24}
13. CREATE_THREAD_DEBUG_EVENT ev.u.CreateThread =3D {hThread =3D 0x118, lpT=
hreadLocalBase =3D 0x276000, lpStartAddress =3D 0x180044cf0 <cygthread::stu=
b(void*)>}
14. EXIT_THREAD_DEBUG_EVENT
15. EXIT_THREAD_DEBUG_EVENT
16. EXIT_THREAD_DEBUG_EVENT
17. EXIT_THREAD_DEBUG_EVENT
18. EXIT_PROCESS_DEBUG_EVENT

Here are some more stacktraces from various points in life of the cuckoo th=
reads, in case they are significant:

ntoskrnl.exe!KeSynchronizeExecution+0x3f26
ntoskrnl.exe!KeWaitForMultipleObjects+0x10b5
ntoskrnl.exe!KeWaitForMultipleObjects+0xb6f
ntoskrnl.exe!KeWaitForSingleObject+0x370
ntoskrnl.exe!KeTestAlertThread+0x591
ntoskrnl.exe!KeReleaseSemaphore+0x4d1
ntoskrnl.exe!KiCheckForKernelApcDelivery+0x23
ntoskrnl.exe!NtDeviceIoControlFile+0x163f
ntoskrnl.exe!NtClose+0x1c37
ntoskrnl.exe!NtClose+0xcb
ntoskrnl.exe!setjmpex+0x3a63
!NtClose+0x14
!RtlGetActiveActivationContext+0x51c
!RtlGetFullPathName_UstrEx+0x4ab
!RtlReleaseRelativeName+0x269
!RtlReleaseRelativeName+0x1f3
!RtlFindActivationContextSectionString+0x3039
!RtlFindActivationContextSectionString+0x11f4
!BaseThreadInitThunk+0x14
!RtlUserThreadStart+0x21

ntoskrnl.exe!KeSynchronizeExecution+0x3f26
ntoskrnl.exe!KeSetEvent+0x6a6
ntoskrnl.exe!MmUnlockPagableImageSection+0xdd
ntoskrnl.exe!KeSynchronizeExecution+0x4b52
!RtlLookupFunctionEntry+0x113f
!RtlReleaseRelativeName+0x248
!RtlReleaseRelativeName+0x1f3
!RtlFindActivationContextSectionString+0x3039
!RtlFindActivationContextSectionString+0x11f4
!BaseThreadInitThunk+0x14
!RtlUserThreadStart+0x21

After some experimentation, I came up with a patch that tries to determine =
whether to ignore a thread based on the thread's entry point lying inside o=
r outside of the memory occupied by ntdll.dll:

--- ldd.cc.orig 2016-04-28 21:54:57.556500700 +0200
+++ ldd.cc      2016-06-30 23:24:20.394384800 +0200
@@ -327,6 +327,10 @@
     {
       bool exitnow =3D false;
       DWORD cont =3D DBG_CONTINUE;
+      MODULEINFO mi;
+      HMODULE ntdll =3D LoadLibrary("ntdll.dll");
+      HMODULE ntdllend =3D NULL;
+      void *entryPoint;
       if (!WaitForDebugEvent (&ev, INFINITE))
        break;
       switch (ev.dwDebugEventCode)
@@ -357,6 +361,31 @@
            }
          break;
        case CREATE_THREAD_DEBUG_EVENT:
+          if (ntdll !=3D NULL)
+            {
+              if (ntdllend =3D=3D NULL)
+                {
+                  /* Using our ntdll.dll HMODULE with a foreign process
+                     should be fine because ntdll.dll is mapped to the same
+                     address in every concurrently executing process and
+                     HMODULEs are just pointers to the image in the process
+                     memory. Using GetModuleHandle(NULL) didn't work for t=
he
+                     author of this code (-> ERROR_INVALID_HANDLE). */
+                  if (GetModuleInformation(hProcess, ntdll, &mi, sizeof(mi=
)))
+                    ntdllend =3D ntdll + (ptrdiff_t)mi.SizeOfImage;
+                  else
+                    ntdll =3D NULL;
+                }
+              if (ntdllend !=3D NULL)
+                {
+                  entryPoint =3D (void*)ev.u.CreateThread.lpStartAddress;
+                  /* If the thread's entry point is in ntdll.dll, let's
+                    assume that this isn't the program's main thread and
+                    ignore it. */
+                  if (ntdll <=3D entryPoint && entryPoint < ntdllend)
+                    break;
+                }
+            }
          TerminateProcess (hProcess, 0);
          break;
        case EXIT_PROCESS_DEBUG_EVENT:
---end---

I can send the patch through proper channels if it passes a sanity check fr=
om someone.

HTH. Cheers.

--=20
David Macek


--------------ms010202040100050508010908
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG
9w0BBwEAAKCCCuwwggUCMIID6qADAgECAhAwzJDbT70jeYw1Cb83uS/9MA0G
CSqGSIb3DQEBCwUAMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv
cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwHhcN
MTUxMjIzMDgyOTQ0WhcNMTYxMjIzMDgyOTQ0WjBKMSAwHgYDVQQDDBdkYXZp
ZC5tYWNlay4wQGdtYWlsLmNvbTEmMCQGCSqGSIb3DQEJARYXZGF2aWQubWFj
ZWsuMEBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQCnUGZaXVaGbHTA2s29ZRn4EWF+mN7cEUhAXNs704Brun7YwopS2xsAVuRq
+WGQLWZqVyLRHOnCsx5uqnF5e1ZjEl21l5hrcM2aFEyyTAEVeXvZSk7Oghqj
IPp7u5dWwadD6ck/EkJeqHv4gfyI+/NLutTUaft3pcj9eI4IlGkxK4UO7VMh
TBVi9KyRfLiZJpy1OdQ0JDidQcoLnCqQX7SWcQNko+ujMaw/K3UkT6xFTW0H
Huhq/rBEJPdFG5XHyjsTh72NymPw1JSngKOoETJomaIrSx30CYwmIEXgleKG
RzYmSlSJP8UActCxwz7Qo3BajrH0iu3lHDqbBnviPXoZAgMBAAGjggG3MIIB
szALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME
MAkGA1UdEwQCMAAwHQYDVR0OBBYEFLU/0F3NtsxZQdtsyjsQV+CRUcP1MB8G
A1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUFBwEBBGMw
YTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG
AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xp
ZW50MS5jcnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNz
bC5jb20vc2NhLWNsaWVudDEuY3JsMCIGA1UdEQQbMBmBF2RhdmlkLm1hY2Vr
LjBAZ21haWwuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wu
Y29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIEMCwwKgYIKwYBBQUHAgEW
Hmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsF
AAOCAQEAkXAWZ3p8s2aNO4q+MAsuph4diGLSiq3adMsWo3/IqAA7nJVkhobz
XXqTd84T0gFgDdbUCEGxL9YQpsM9fJzRZtP46XBdWR/sSA4UMUZsYAVBkRX+
aDSoLn2lAhtoiJlT0HlKiYk3mscEmk4E8/SQkl2Eo7wY0kuV+0nFWt9QI4ip
xSWkYHt9U1puCPL0PLe8voOM0vsBXhjoO3VTTRVIa5n/ssN+8XNxIevtPl5A
w0UQ5ewZrdV7iItgTzdyw8ZYd3dtbSKrg2cBN0n3muDy9sQhF0zqh2YF1Yci
C8vKcMRPceXBV77D6sS16seSoJqQzYKfN0K9pe6zMDnp0seOPjCCBeIwggPK
oAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkG
A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0
YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAw
NVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD
QTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC
/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk
9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqf
hM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgK
yVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwv
IjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2h
YQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQE
AwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/
BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0
c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzAB
hhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFs
OWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRo
Q9BBrvIwPwYDVR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAgEA
i+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY0JdOruKbrWDsXUsiI0j/
7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM
3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606
tEc9uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafg
u6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSi
F3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo02wrlxY6iMFq
vlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj
95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0f
QoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9
MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgR
dAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2de
oprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIBATCBiTB1MQswCQYDVQQGEwJJ
TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g
Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs
YXNzIDEgQ2xpZW50IENBAhAwzJDbT70jeYw1Cb83uS/9MA0GCWCGSAFlAwQC
AQUAoIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xNjA2MzAyMTI3MjNaMC8GCSqGSIb3DQEJBDEiBCCaZNHKO5ZtI3XD
W+Pd22Vw1wZqzl/ZUDTuW6yiqy9XajBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCG
SAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGa
BgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBD
QQIQMMyQ20+9I3mMNQm/N7kv/TCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTEL
MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsT
IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpT
dGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQMMyQ20+9I3mMNQm/N7kv/TAN
BgkqhkiG9w0BAQEFAASCAQAjZrFlcDmKXJIDgYs9abIRm7h2wpYrt5VTFQVt
wgZ56G7dxvXqo4MdeQErCWzMBr9Wd5Po+op4TwrQ0LX4xUT1SpNXMmkLWT88
8ty5kTOAIMxwwwQosBKN3udD4MQ3F6M09QA+b9/pgjy4WPyUeuaH9a4mU4Xx
r9ROwXPjPHJbCiBDAv6F8fs5HkUtanTX8cdBcRkFjTOYxK2hhoKZfDYBbxoh
bwlBRdaZtkCNLy+OHwvYYot6KRIameRYdNF9BbfsoSgInXTF6OTFwfRJUe7q
/3s9hATOAUvYnCdIGNp5FKZ6uOPYSoZ9iC60RselCGqOdU54ujp6148fA4bJ
9o1pAAAAAAAA

--------------ms010202040100050508010908--