Python 3.5 Runtime Redistributable backported to XP

[-SnooPY-]

On 24.02.2019 at 3:54 AM, heinoganda said:

Dependency Walker shows many red functions in the various system files under Windows XP

I'm sorry, but I saw in Dependency Walker only that _openssl.cp37-win32.pyd uses the system psapi.dll instead of the version made by @Dibya . Could you clarify exactly which functions are marked in red (missing?) ? Are these functions related to kernel32.dll or ws2_32.dll? Can I send here a minidump file to analyze the error from my post above?

Edited February 26, 2019 by -SnooPY-

[heinoganda]

@-SnooPY-

Meanwhile, I have under Python 3.4.4 the current "cryptography" module version 2.6.1 also tested unsuccessfully under Windows XP. There are essentially two problems, one with the file "bcrypt.dll" (it looks like there are still some features missing) and the other with the system file "mpr.dll". I would recommend to install "cryptography" module version 2.4.2 manually to be sure that there are no problems with Python 3.7.

Download:
https://pypi.org/project/cryptography/2.4.2/#files

To install manually:

pip install cryptography-2.4.2-cp37-cp37m-win32.whl

[-SnooPY-]

17 hours ago, heinoganda said:

I would recommend to install "cryptography" module version 2.4.2 manually to be sure that there are no problems with Python 3.7.

Yes, you are right. There are no problems with Python 3.7.1, it's all about the "cryptography-2.5" module and newer ones. But I also don't see any problems with psapi.dll or mpr.dll, only with bcrypt.dll. Nevertheless, the problem with the new versions of "cryptography" and Python crashes would be interesting to solve.

C:\Temp\python-3.7.1>pip list
Package      Version
------------ -------
asn1crypto   0.24.0
cffi         1.12.1
colorama     0.4.1
cryptography 2.4.2
idna         2.8
pip          19.0.3
pycparser    2.19
pyOpenSSL    19.0.0
PySocks      1.6.8
setuptools   40.8.0
six          1.12.0
urllib3      1.24.1
wheel        0.33.1

C:\Temp\python-3.7.1>python
Python 3.7.1 (v3.7.1:260ec2c36a, Oct 20 2018, 14:05:16) [MSC v.1915 32 bit (Intel)] on win32
>>> ^Z

    File: _openssl.cp37-win32.pyd
     MD5: 6b3ef6344fc88c5c991017d4892a917a
   SHA-1: 021b329260f5ae2916ef42097cb8ef2109e35f32
 SHA-256: 67de1aaadf0f19b5d6f7b89ede5a5b6e7986e7955c2ca31ffccf5a882f604e4a

C:\Temp\dumpbin>dumpbin /dependents _openssl.cp37-win32.pyd
Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file _openssl.cp37-win32.pyd

File Type: DLL

  Image has the following dependencies:

    ADVAPI32.dll
    CRYPT32.dll
    USER32.dll
    WS2_32.dll
    python37.dll
    KERNEL32.dll
    VCRUNTIME140.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-utility-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll

C:\Temp\ProxHTTPSProxy>python C:\Temp\ProxHTTPSProxy\ProxHTTPSProxy.py
============================================================================
ProxHTTPSProxyMII v1.5 (urllib3/1.24.1)

  FrontServer  : localhost:8079
  RearServer   : localhost:8081
  ParentServer : None
  Proxomitron  : http://localhost:8118
============================================================================
[12:24] 001 [D] "POST https://www.google.com/gen_204?s=webhp&t=aft&atyp=csi&ei=u
_h4XKayLdqVk74Po469mA0&rt=wsrt.14,aft.276,prt.276&bb=1 0" 204 0
[12:24] 002 [D] "GET https://www.google.com/gen_204?atyp=i&ct=backbutton&cad=&tt
=navigation&ei=u_h4XKayLdqVk74Po469mA0&zx=1551432247610" 204 0
[12:24] 003 [D] "POST https://www.google.com/gen_204?atyp=csi&bb=1&ei=u_h4XKayLd
qVk74Po469mA0&s=jsa&jsi=s,t.0,et.focus,n.iDPoPb,cn.1&zx=1551432247778 0" 204 0
[12:24] 004 [D] "POST https://www.google.com/gen_204?atyp=csi&bb=1&ei=u_h4XKayLd
qVk74Po469mA0&s=webhp&t=all&imn=2&adh=&ima=1&ime=1&imeb=0&imeo=0&wh=620&scp=0&st
o=&sys=hc.1&rt=prt.276,aft.276,iml.522,xjsls.390,dcl.418,xjses.922,xjsee.1356,xj
s.1356,ol.2230,wsrt.14,cst.0,dnst.0,rqst.112,rspt.100,rqstt.2,unt.2,cstt.2,dit.3
46&zx=1551432248922 0" 204 0

Edited March 1, 2019 by -SnooPY-
Added a screenshot

[heinoganda]

2 hours ago, -SnooPY- said:

Nevertheless, the problem with the new versions of "cryptography" and Python crashes would be interesting to solve.

I agree with that. As mentioned earlier, HTTPSProxy works on Windows 7 (bcrypt.dll should be functional on this level). Have already tested various "bcrypt.dll" file variants, where at least one, HTTPSProxy not crashed and if the certificates in Cert folder existed conditionally worked.

At least you can currently exclude Python 3.7, but what will after March 2019, especially since the last under Windows XP officially functioning Python 3.4.4 is no longer supported. It is likely that future modules will make problems. 

Whether an error message helps the creator of the cryptography module because of the lack of support for the module (version 2.5, 2.6 and 2.61) with Python 3.4.4 on Windows XP, I dare to doubt.

Edited March 1, 2019 by heinoganda

[-SnooPY-]

On 3/1/2019 at 3:15 PM, heinoganda said:

Have already tested various "bcrypt.dll" file variants, where at least one, HTTPSProxy not crashed and if the certificates in Cert folder existed conditionally worked.

In my case, ProxHTTPSProxy (python.exe) crashes absolutely the same, both at the stage of "Creating CA ..." and if I just do nothing in a few minutes after launch.

On 3/1/2019 at 3:15 PM, heinoganda said:

Whether an error message helps the creator of the cryptography module because of the lack of support for the module (version 2.5, 2.6 and 2.61) with Python 3.4.4 on Windows XP, I dare to doubt.

It bothers me that it is impossible to compile new "cryptography" module ( >=2.5 ) from sources, disabling the forced use of bcrypt.dll.

Edited March 3, 2019 by -SnooPY-

[Dibya]

Next time I will compile from source.

Please find out as many issues as much possible.

Cheers

[-SnooPY-]

3 hours ago, Dibya said:

Next time I will compile from source.

Do you mean Python > 3.7.1 or "cryptography" module > 2.4.2 ?

3 hours ago, Dibya said:

Please find out as many issues as much possible.

I recently discovered an interesting tool called WinAPIOverride - it may be useful to solve some problems with the lack of necessary API functions.

[Dibya]

1 hour ago, -SnooPY- said:

Do you mean Python > 3.7.1 or "cryptography" module > 2.4.2 ? 

I recently discovered an interesting tool called WinAPIOverride - it may be useful to solve some problems with the lack of necessary API functions.

I mean python greater than 3.7.1

[heinoganda]

3 hours ago, Dibya said:

I mean python greater than 3.7.1

In all honor, but what good is Python greater than 3.7.1, if the current modules do not work. We need the latest cryptography module, which works well in Windows XP.

[Dibya]

9 hours ago, heinoganda said:

In all honor, but what good is Python greater than 3.7.1, if the current modules do not work. We need the latest cryptography module, which works well in Windows XP.

Well your kind command accepted to port cryptography module

[-SnooPY-]

23 hours ago, heinoganda said:

We need the latest cryptography module, which works well in Windows XP.

With Python itself, not everything is so rosy either. I hardly found bcrypt.dll which does not cause Python 3.7.1 to crash, but other errors appeared. It seems that something is still wrong with sockets. Errors when creating a new certificate occur after the connection is already broken.

C:\Temp\ProxHTTPSProxy>python C:\Temp\ProxHTTPSProxy\ProxHTTPSProxy.py
============================================================================
ProxHTTPSProxyMII v1.5 (urllib3/1.24.1)

  FrontServer  : localhost:8079
  RearServer   : localhost:8081
  ParentServer : None
  Proxomitron  : http://localhost:8118
============================================================================
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 2309)
Traceback (most recent call last):
  File "socketserver.py", line 647, in process_request_thread
  File "socketserver.py", line 357, in finish_request
  File "socketserver.py", line 717, in __init__
  File "http\server.py", line 426, in handle
  File "C:\Temp\ProxHTTPSProxy\ProxyTool.py", line 115, in handle_one_request
    BaseHTTPRequestHandler.handle_one_request(self)
  File "http\server.py", line 414, in handle_one_request
  File "C:\Temp\ProxHTTPSProxy\ProxHTTPSProxy.py", line 167, in do_CONNECT
    dummycert = get_cert(commonname)
----------------------------------------

PS. Another version of bcrypt.dll from GOG Galaxy WinXP Patch by Drako Pensulo.

Edited March 4, 2019 by -SnooPY-

[Thomas S.]

I am very interested in this discussion.

But I wonder that you are constantly try to workaround a security-related application just because you want to make a particular version work?

It's just too many security risks. I would never use files from foreign sources here. Prefer to get along with cryptography 2.4.2 for a while.

Even cryptography, which is maintained by a large number of developers, is described here by the programmers themselves as not harmless, see:

https://cryptography.io/en/latest/hazmat/bindings/openssl

 

Edited March 5, 2019 by Thomas S.

[-SnooPY-]

5 hours ago, Thomas S. said:

But I wonder that you are constantly try to workaround a security-related application just because you want to make a particular version work?

In my opinion, we don't do anything criminal. Most versions of bcrypt.dl mentioned here contain sources so everyone can be convinced that there are no "surprises". For example, another one I wrote yesterday (thanks @jumper for the hint).  bcrypt.zip

Personally, I am interested in two things:
- why "cryptography" module cannot be compiled from sources
- what has changed so much in "cryptography" greater than 2.4.2, that now Python crashes even in cases not directly related to this module

[dencorso]

On 3/5/2019 at 4:07 AM, Thomas S. said:

But I wonder that you are constantly try to workaround a security-related application just because you want to make a particular version work?

Some of our members (with all due respect) indulge in the latest version fetish (LVF), which can be mostly harmless when not taken to extremes. I, myself, do indulge in it sometimes, I reckon, but the farthest I usually go is to change the minimum "Subsystem Version" to allow executables to run, nowadays. If I really have something that only runs on Win 7+, I either do it on 7SP1 or eschew it, usually the latter. As of today, all that I need to do in my day-to-day can be done in XP SP3. I consider the Extended Kernel approach mostly useless, although I dedicate lots of respect to @Xeno86, @jumper, and @blackwingcat.    I consider the WDMSYS/WDMEX (Extended Driver Interface) very useful, but nobody has been ever able to port to the NT-family OSes what Walter Oney and @rloew ( ) did for 9x/ME... and that's why we still haven't working Intel USB 3.0 drivers at this point in time. Of course, these are just my 2¢ and everybody may disagree. Moreover, YMMV, obviously. But, considering @Thomas S. did ask the queestion above, I felt it shouldn't remain unanswered. That's all.

On 3/5/2019 at 4:07 AM, Thomas S. said:

It's just too many security risks. [...] Prefer to get along with cryptography 2.4.2 for a while.

Sage words and attitude, IMO. +1

On 3/5/2019 at 4:07 AM, Thomas S. said:

I would never use files from foreign sources here.

It depends, IMO: people I know (even if just through the internet) and trust I don't consider foreign sources.
Otherwise I do agree to that, too.

[Thomas S.]

On 3/5/2019 at 9:59 AM, -SnooPY- said:

[...] we don't do anything criminal [...]

Of course not

On 3/5/2019 at 9:59 AM, -SnooPY- said:

Personally, I am interested in two things:
- why "cryptography" module cannot be compiled from sources
- what has changed so much in "cryptography" greater than 2.4.2, that now Python crashes even in cases not directly related to this module

Ok, I understand your plan.

21 hours ago, dencorso said:

[...] I, myself, do indulge in it sometimes, I reckon, but the farthest I usually go is to change the minimum "Subsystem Version" to allow executables to run, nowadays. If I really have something that only runs on Win 7+, I either do it on 7SP1 or eschew it, usually the latter. As of today, all that I need to do in my day-to-day can be done in XP SP3. [...]

That's how I do it, too.

OK, I fully understand all of You. Go ahead!