Implementing a COM interface in Python - python-3.x

Background: I'm coding in Python and trying to use the win32 IFileOperation to perform shell file operations. In particular, moving/copying a file or directory to a non-existant location requires you to get a IShellItem (or IShellItem2) item referring to the target directory, but SHCreateItemFromParsingName fails if the target doesn't exist yet. Following advice from these related questions:
Creating directories during a copy using IFileOperation
IFileSystemBindData implementation not fully working
I've handled creating the WIN32_FIND_DATAW structure, created the IBindCtx object via pywin32's pythoncom.CreateBindCtx(). The step I'm stuck on is implementing a IFileSysBindData class in Python.
Here's what I've got so far:
class FileSysBindData:
_public_methods_ = ['SetFindData', 'GetFindData']
_reg_clsid_ = '{01E18D10-4D8B-11d2-855D-006008059367}'
def SetFindData(self, win32_find_data):
self.win32_find_data = win32_find_data
return 0
def GetFindData(self, p_win32_find_data):
p_win32_find_data.contents = self.win32_find_data
return 0
bind_data = FileSysBindData()
ibindctx = pythoncom.CreateBindCtx()
# TODO: set the bind data
ibindctx.RegisterObjectParam('File System Bind Data', bind_data)
The last line gives:
ValueError: argument is not a COM object (got type=FileSysBindData)
So obviously there's more to do to get pywin32 to create this in a COM-compatible way.
But I'm stuck on how to use pywin32 (or another solution) to actually create it as a COM object, so I can pass it to the IBindCtx instance.
I'm not super familiar with COM in general, so reading the docs in pywin32 haven't helped me much. I don't even know if I'm supposed to register my class as a server, or use it as a client somehow.

The difficulty is you have to use two python packages:
comtypes to declare and implement custom COM objects
pywin32 because it has lots of already baked interop types, interfaces, classes, etc.
Here is the code, and you'll see the trick to pass a comtypes's custom COM object to pywin32:
import pythoncom
import ctypes
from comtypes.hresult import *
from comtypes import IUnknown, GUID, COMMETHOD, COMObject, HRESULT
from ctypes.wintypes import *
from ctypes import *
from win32com.shell import shell
from os import fspath
# ripped from
# <python install path>\Lib\site-packages\comtypes\test\test_win32com_interop.py
# We use the PyCom_PyObjectFromIUnknown function in pythoncomxxx.dll to
# convert a comtypes COM pointer into a pythoncom COM pointer.
# This is the C prototype; we must pass 'True' as third argument:
# PyObject *PyCom_PyObjectFromIUnknown(IUnknown *punk, REFIID riid, BOOL bAddRef)
_PyCom_PyObjectFromIUnknown = PyDLL(
pythoncom.__file__).PyCom_PyObjectFromIUnknown
_PyCom_PyObjectFromIUnknown.restype = py_object
_PyCom_PyObjectFromIUnknown.argtypes = (POINTER(IUnknown), c_void_p, BOOL)
def comtypes2pywin(ptr, interface=None):
"""Convert a comtypes pointer 'ptr' into a pythoncom PyI<interface> object.
'interface' specifies the interface we want; it must be a comtypes
interface class. The interface must be implemented by the object and
the interface must be known to pythoncom.
If 'interface' is not specified, comtypes.IUnknown is used.
"""
if interface is None:
interface = IUnknown
return _PyCom_PyObjectFromIUnknown(ptr, byref(interface._iid_), True)
class IFileSystemBindData(IUnknown):
"""The IFileSystemBindData interface
https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ifilesystembinddata"""
_iid_ = GUID('{01e18d10-4d8b-11d2-855d-006008059367}')
_methods_ = [
COMMETHOD([], HRESULT, 'SetFindData',
(['in'], POINTER(WIN32_FIND_DATAW), 'pfd')),
COMMETHOD([], HRESULT, 'GetFindData',
(['out'], POINTER(WIN32_FIND_DATAW), 'pfd'))
]
class FileSystemBindData(COMObject):
"""Implements the IFileSystemBindData interface:
https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ifilesystembinddata"""
_com_interfaces_ = [IFileSystemBindData]
def IFileSystemBindData_SetFindData(self, this, pfd):
self.pfd = pfd
return S_OK
def IFileSystemBindData_GetFindData(self, this, pfd):
pfd = self.pfd
return S_OK
find_data = WIN32_FIND_DATAW() # from wintypes
bind_data = FileSystemBindData()
# to avoid this long thing, we could declare a shorter helper on
# FileSystemBindData
bind_data.IFileSystemBindData_SetFindData(bind_data, ctypes.byref(find_data))
ctx = pythoncom.CreateBindCtx()
# we need this conversion to avoid
# "ValueError: argument is not a COM object (got type=FileSystemBindData)"
# error from pythoncom
pydata = comtypes2pywin(bind_data)
ctx.RegisterObjectParam('File System Bind Data', pydata)
item = shell.SHCreateItemFromParsingName(
fspath("z:\\blah\\blah"), ctx, shell.IID_IShellItem2)
SIGDN_DESKTOPABSOLUTEPARSING = 0x80028000
print(item.GetDisplayName(SIGDN_DESKTOPABSOLUTEPARSING)) # prints Z:\blah\blah

Related

Constant variable names in all modules/functions

This is version 2 of my question, after the comment on v1 by Omer Dagry.
What's the best way to ensure that constants are available throughout my code?
I've created this constants.ini file that I want to be able to use in any module I create to ensure standard variables for certain functions.
; dd_config.ini
[DEBUG_TYPE]
DEBUG_SUBSTR = -1
DEBUG_START = 0
DEBUG_OS = 1
DEBUG_GENERAL = 2
DEBUG_END = 3
I have re-ordered program 1 so that it populates dd_con before importing dd_debug_exception:
from configparser import ConfigParser
# read the .ini file for some of the code
dd_con = ConfigParser()
dd_con.read(
"C:/Users/DD/dd_constants.ini"
)
# standard error reporting if debug needed
from test_debug_2 import dd_debug_exception
_SHORT = dd_con.get("DEBUG_STYLE", "DEBUG_SHORT")
print(_SHORT)
dd_debug_exception(0, "test", _SHORT)
Import dd_debug_exception does this:
def dd_debug_exception(debug_type,
debug_str,
debug_style: int = dd_con.get("DEBUG_TYPE",
"DEBUG_NORMAL")):
# Handle exceptions in a standard way
if debug_style == _SHORT:
print("hello")
When I try to run it I get the following error:
Traceback (most recent call last): File
"c:\Users\DD\test_config.py", line 9, in
from test_debug_2 import dd_debug_exception File "C:\Users\DD\test_debug_2.py", line 3, in
debug_style: int = dd_con.get("DEBUG_TYPE", NameError: name 'dd_con' is not defined
The import is still not recognising dd_con and therefore my standard variables.

Python ctypes EnumThreadWindows failing with error 87 (ERROR_INVALID_PARAMETER)

I can't seem to get EnumThreadWindows to work. It keeps failing with error 87. Code:
error = ctypes.WinDLL('Kernel32').GetLastError
enum_func = ctypes.WINFUNCTYPE(wintypes.BOOL,
wintypes.HWND,
wintypes.LPARAM)
def callback(hwnd, lParam):
length = ctypes.WinDLL('User32').GetWindowTextLengthW(hwnd) + 1
buf = ctypes.create_unicode_buffer(length)
ctypes.WinDLL('User32').GetWindowTextW(hwnd, buf, length)
print(buf.value)
worker = enum_func(callback)
test = ctypes.WinDLL('User32').EnumThreadWindows(6000, worker, None)
print(error(test))
I've tried pid = wintypes.DWORD(6000), test = ctypes.WinDLL('User32').EnumThreadWindows(pid.value, worker, None) to no avail.
What am I doing wrong?
Here's working code. Make sure to pass a valid thread ID.
You might be interested in the fact that an LPARAM can be anything, including a python object, so if you pass a Python object it can be manipulated in the callback:
import ctypes
from ctypes import wintypes
from collections import namedtuple
Window = namedtuple('Window','hwnd title')
WNDENUMPROC = ctypes.WINFUNCTYPE(wintypes.BOOL,
wintypes.HWND,
ctypes.py_object) # to allow any Python object.
u32 = ctypes.WinDLL('user32',use_last_error=True) # to ensure GetLastError was captured
# Declaring arguments and return type helps catch errors and support 64-bit.
# HWND is 64-bit on 64-bit Python, and could get truncated if left to ctypes default
# of c_int (32-bit). This code works on Python 2.7 and 3.9.
u32.GetWindowTextLengthW.argtypes = wintypes.HWND,
u32.GetWindowTextLengthW.restype = ctypes.c_int
u32.GetWindowTextW.argtypes = wintypes.HWND,wintypes.LPWSTR,ctypes.c_int
u32.GetWindowTextW.restype = ctypes.c_int
u32.EnumThreadWindows.argtypes = wintypes.DWORD,WNDENUMPROC,ctypes.py_object # to pass Python object
u32.EnumThreadWindows.restype = wintypes.BOOL
#WNDENUMPROC # decorator makes this a ctypes-compatible function
def callback(hwnd, lParam):
length = u32.GetWindowTextLengthW(hwnd) + 1
buf = ctypes.create_unicode_buffer(length)
u32.GetWindowTextW(hwnd, buf, length)
lParam.append(Window(hwnd,buf.value)) # append data to the callback parameter
return True # return True to continue enumeration
result = [] # A python object
if u32.EnumThreadWindows(6332, callback, result): # 6332 was a thread in my explore.exe
for wnd in result: # list results when enumeration complete
print(wnd)
else:
print('error:',ctypes.get_last_error()) # print error of EnumThreadWindows.
# Python could use a Win32 function that fails in
# between the ctypes call and calling GetLastError
# directly.
Output:
Window(hwnd=65832, title='')
Window(hwnd=65838, title='')
Window(hwnd=131174, title='')
Window(hwnd=65682, title='')
Window(hwnd=65678, title='')
Window(hwnd=65826, title='Program Manager')
Window(hwnd=196928, title='MSCTFIME UI')
Window(hwnd=65680, title='Default IME')

Access COM methods from Python

I have an old Windows DLL, without source code, who implement a table of utility functions. Years ago it was planned to convert it in a COM object so an IUnknown interface was implemented. To work with this DLL, there is a header file (simplified):
interface IFunctions : public IUnknown
{
virtual int function1(int p1, int p2) = 0;
virtual void function2(int p1) = 0;
// and the likes ...
}
But no CLSID was defined for IFunctions interface. And eventually the interface definition in header file is non-compliant with COM standard.
From C++ the DLL can be loaded with
CoCreateInstance(clsid, 0, CLSCTX_INPROC_SERVER, clsid, ptr);
and with some pointer arithmetic from 'ptr' I find the addresses of funcion1(), etc. Since it worked, no complete COM implementation were done so I cannot QueryInterface for IFunctions interface because the interface is not a COM interface. In Windows Registry I find only the CLSID of the object and a reference to the DLL as it InprocServer32.
I do not have much experience in Python, but I need to use this DLL from Python, perhaps using ctypes and comtypes. I can load the DLL with (CLSID from registry)
unk = CreateObject('{11111111-2222-3333-4444-555555555555}', clsctx=comtypes.CLSCTX_INPROC_SERVER)
I know that in the VTable of the COM object function1() address is just after QueryInterface(), AddRef(), Release() but I cannot find a solution to implement a class like:
class DllFunction:
# not necessary, but for completeness ...
def QueryInterface(self, interface, iid=None):
return unk.QueryInterface(comtypes.IUnknown)
def AddRef(slef):
return unk.AddRef()
def Release(self):
return unk.Release()
# Functions I actually need to call from Python
def Function1(self, p1, p2):
# what to do ??
def Function2(self, p1):
# etc.
I would like to implement this solution in Python trying to avoid the development of an extension module in C++.
Thanks for any help.
Thanks to who provided some hints. Actually I cannot fix the DLL because I do not have the source code. Wrapping it in C++ was an option, but developing a wrapping Python module in C sounds better.
My plan was to use Python only, possibly without additional modules, so I managed to solve the issue using only ctypes. The following code show the solution. It works, but it needs some improvements (error checking, etc).
'''
Simple example of how to use the DLL from Python on Win32.
We need only ctypes.
'''
import ctypes
from ctypes import *
'''
We need a class to mirror GUID structure
'''
class GUID(Structure):
_fields_ = [("Data1", c_ulong),
("Data2", c_ushort),
("Data3", c_ushort),
("Data4", c_ubyte * 8)]
if __name__ == "__main__":
'''
COM APIs to activate/deactivate COM environment and load the COM object
'''
ole32=WinDLL('Ole32.dll')
CoInitialize = ole32.CoInitialize
CoUninitialize = ole32.CoUninitialize
CoCreateInstance = ole32.CoCreateInstance
'''
COM environment initialization
'''
rc = CoInitialize(None)
'''
To use CoCreate Instance in C (not C++):
void * driver = NULL;
rc = CoCreateInstance(&IID_Driver, // CLSID of the COM object
0, // no aggregation
CLSCTX_INPROC_SERVER, // CLSCTX_INPROC_SERVER = 1
&IID_Driver, // CLSID of the required interface
(void**)&driver); // result
In Python it is:
'''
clsid = GUID(0x11111111, 0x2222, 0x3333,
(0x44, 0x44, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55))
drv = c_void_p(None)
rc = CoCreateInstance(byref(clsid), 0, 1, byref(clsid), byref(drv))
'''
Pointers manipulation. Short form:
function = cast( c_void_p( cast(drv, POINTER(c_void_p))[0] ), POINTER(c_void_p))
'''
VTable = cast(drv, POINTER(c_void_p))
wk = c_void_p(VTable[0])
function = cast(wk, POINTER(c_void_p))
#print('VTbale address: ', hex(VTable[0]))
#print('QueryInterface address: ', hex(function[0]))
#print('AddRef address: ', hex(function[1]))
#print('Release address: ', hex(function[2]))
'''
To define functions from their addresses we first need to define their WINFUNCTYPE.
In C we call QueryInterface:
HRESULT rc = driver->lpVtbl->QueryInterface(driver, &IID_IUnknown, (void**)&iUnk);
So we need a long (HRESULT) return value and three pointers. It would be better to be
more accurate in pointer types, but ... it works!
We can use whatever names we want for function types and functions
'''
QueryInterfaceType = WINFUNCTYPE(c_long, c_void_p, c_void_p, c_void_p)
QueryInterface = QueryInterfaceType(function[0])
AddRefType = WINFUNCTYPE(c_ulong, c_void_p)
AddRef = AddRefType(function[1])
ReleaseType = WINFUNCTYPE(c_ulong, c_void_p)
Release = ReleaseType(function[2])
'''
The same for other functions, but library functions do not want 'this':
long rc = driver->lpVtbl->init(0);
'''
doThisType = WINFUNCTYPE(c_long, c_void_p)
doThis=doThisType(function[3])
getNameType = WINFUNCTYPE(c_int, c_char_p)
getName = getNameType(function[4])
getName.restype = None # to have None since function is void
getVersionType = WINFUNCTYPE(c_long)
getVersion = getVersionType(function[5])
getMessageType = WINFUNCTYPE(c_int, c_char_p)
getMessage = getMessageType(function[6])
getMessage.restype = None # to have None since function is void
'''
Now we can use functions in plain Python
'''
rc = doThis(0)
print(rc)
name = create_string_buffer(128)
rc = getName(name)
print(rc)
print(name.value)
ver = getVersion()
print(ver)
msg = create_string_buffer(256)
rc = getMessage(msg)
print(rc)
print(msg.value)
'''
Unload DLL and reset COM environment
'''
rc = Release(drv)
rc = CoUninitialize()
print("Done!")
I hope this example will be useful to somebody. It can be used to wrap a COM object without comtypes and, to me, clarify how ctypes works.

How to get the default application mapped to a file extention in windows using Python

I would like to query Windows using a file extension as a parameter (e.g. ".jpg") and be returned the path of whatever app windows has configured as the default application for this file type.
Ideally the solution would look something like this:
from stackoverflow import get_default_windows_app
default_app = get_default_windows_app(".jpg")
print(default_app)
"c:\path\to\default\application\application.exe"
I have been investigating the winreg builtin library which holds the registry infomation for windows but I'm having trouble understanding its structure and the documentation is quite complex.
I'm running Windows 10 and Python 3.6.
Does anyone have any ideas to help?
The registry isn't a simple well-structured database. The Windows
shell executor has some pretty complex logic to it. But for the simple cases, this should do the trick:
import shlex
import winreg
def get_default_windows_app(suffix):
class_root = winreg.QueryValue(winreg.HKEY_CLASSES_ROOT, suffix)
with winreg.OpenKey(winreg.HKEY_CLASSES_ROOT, r'{}\shell\open\command'.format(class_root)) as key:
command = winreg.QueryValueEx(key, '')[0]
return shlex.split(command)[0]
>>> get_default_windows_app('.pptx')
'C:\\Program Files\\Microsoft Office 15\\Root\\Office15\\POWERPNT.EXE'
Though some error handling should definitely be added too.
Added some improvements to the nice code by Hetzroni, in order to handle more cases:
import os
import shlex
import winreg
def get_default_windows_app(ext):
try: # UserChoice\ProgId lookup initial
with winreg.OpenKey(winreg.HKEY_CURRENT_USER, r'SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\{}\UserChoice'.format(ext)) as key:
progid = winreg.QueryValueEx(key, 'ProgId')[0]
with winreg.OpenKey(winreg.HKEY_CURRENT_USER, r'SOFTWARE\Classes\{}\shell\open\command'.format(progid)) as key:
path = winreg.QueryValueEx(key, '')[0]
except: # UserChoice\ProgId not found
try:
class_root = winreg.QueryValue(winreg.HKEY_CLASSES_ROOT, ext)
if not class_root: # No reference from ext
class_root = ext # Try direct lookup from ext
with winreg.OpenKey(winreg.HKEY_CLASSES_ROOT, r'{}\shell\open\command'.format(class_root)) as key:
path = winreg.QueryValueEx(key, '')[0]
except: # Ext not found
path = None
# Path clean up, if any
if path: # Path found
path = os.path.expandvars(path) # Expand env vars, e.g. %SystemRoot% for ext .txt
path = shlex.split(path, posix=False)[0] # posix False for Windows operation
path = path.strip('"') # Strip quotes
# Return
return path

Retrieving address of native base class with ctypes

I want to be able to pass a certificate to Python's ssl library without requiring a temporary file. It seems that the Python ssl module cannot do that.
To work around this problem I want to retrieve the underlying SSL_CTX struct stored in the ssl._ssl._SSLContext class from the native _ssl module. Using ctypes I could then manually call the respective SSL_CTX_* functions from libssl with that context. How to do that in C is shown here and I would do the same thing via ctypes.
Unfortunately, I'm stuck at the point where I managed to hook into the load_verify_locations function from ssl._ssl._SSLContext but seem to be unable to get the right memory address of the instance of the ssl._ssl._SSLContext struct. All the load_verify_locations function is seeing is the parent ssl.SSLContext object.
My question is, how do I get from an instance of a ssl.SSLContext object to the memory of the native base class ssl._ssl._SSLContext? If I would have that, I could easily access its ctx member.
Here is my code so far. Credits for how to monkeypatch a native Python module go to the forbidden fruit project by Lincoln Clarete
Py_ssize_t = hasattr(ctypes.pythonapi, 'Py_InitModule4_64') and ctypes.c_int64 or ctypes.c_int
class PyObject(ctypes.Structure):
pass
PyObject._fields_ = [
('ob_refcnt', Py_ssize_t),
('ob_type', ctypes.POINTER(PyObject)),
]
class SlotsProxy(PyObject):
_fields_ = [('dict', ctypes.POINTER(PyObject))]
class PySSLContext(ctypes.Structure):
pass
PySSLContext._fields_ = [
('ob_refcnt', Py_ssize_t),
('ob_type', ctypes.POINTER(PySSLContext)),
('ctx', ctypes.c_void_p),
]
name = ssl._ssl._SSLContext.__name__
target = ssl._ssl._SSLContext.__dict__
proxy_dict = SlotsProxy.from_address(id(target))
namespace = {}
ctypes.pythonapi.PyDict_SetItem(
ctypes.py_object(namespace),
ctypes.py_object(name),
proxy_dict.dict,
)
patchable = namespace[name]
old_value = patchable["load_verify_locations"]
libssl = ctypes.cdll.LoadLibrary("libssl.so.1.0.0")
libssl.SSL_CTX_set_verify.argtypes = (ctypes.c_void_p, ctypes.c_int, ctypes.c_void_p)
libssl.SSL_CTX_get_verify_mode.argtypes = (ctypes.c_void_p,)
def load_verify_locations(self, cafile, capath, cadata):
print(self)
print(self.verify_mode)
addr = PySSLContext.from_address(id(self)).ctx
libssl.SSL_CTX_set_verify(addr, 1337, None)
print(libssl.SSL_CTX_get_verify_mode(addr))
print(self.verify_mode)
return old_value(self, cafile, capath, cadata)
patchable["load_verify_locations"] = load_verify_locations
context = ssl.create_default_context(ssl.Purpose.SERVER_AUTH)
The output is:
<ssl.SSLContext object at 0x7f4b81304ba8>
2
1337
2
This suggests, that whatever I'm changing is not the ssl context that Python knows about but some other random memory location.
To try out the code from above, you have to run a https server. Generate a self-signed SSL certificate using:
$ openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -subj '/CN=localhost' -nodes
And start a server using the following code:
import http.server, http.server
import ssl
httpd = http.server.HTTPServer(('localhost', 4443), http.server.SimpleHTTPRequestHandler)
httpd.socket = ssl.wrap_socket (httpd.socket, certfile='cert.pem', keyfile='key.pem', server_side=True)
httpd.serve_forever()
And then add the following line to the end of my example code above:
urllib.request.urlopen("https://localhost:4443", context=context)
Actual SSLContext answer forthcoming, the assumption is no longer correct.
See https://docs.python.org/3/library/ssl.html#ssl.SSLContext.load_verify_locations
There's a 3rd argument, cadata
The cadata object, if present, is either an ASCII string of one or
more PEM-encoded certificates or a bytes-like object of DER-encoded
certificates.
Apparently that's the case since Python 3.4
Getting the underlying PyObject context
This one's easy, ssl.SSLContext inherits from _ssl._SSLContext which in Python data model means that there's just one object at one memory address.
Therefore, ssl.SSLContext().load_verify_locations(...) will actually call:
ctx = \
ssl.SSLContext.__new__(<type ssl.SSLContext>, ...) # which calls
self = _ssl._SSLContext.__new__(<type ssl.SSLContext>, ...) # which calls
<type ssl.SSLContext>->tp_alloc() # which understands inheritance
self->ctx = SSL_CTX_new(...) # _ssl fields
self.set_ciphers(...) # ssl fields
return self
_ssl._SSLContext.load_verify_locations(ctx, ...)`.
The C implementation will get an object of seemingly wrong type, but that's OK because all the expected fields are there, as it was allocated by generic type->tp_alloc and fields were filled in first by _ssl._SSLContext and then by ssl.SSLContext.
Here's a demonstration (tedious details omitted):
# _parent.c
typedef struct {
PyObject_HEAD
} PyParent;
static PyObject* parent_new(PyTypeObject* type, PyObject* args,
PyObject* kwargs) {
PyParent* self = (PyParent*)type->tp_alloc(type, 0);
printf("Created parent %ld\n", (long)self);
return (PyObject*)self;
}
# child.py
class Child(_parent.Parent):
def foo(self):
print(id(self))
c1 = Child()
print("Created child:", id(c1))
# prints:
Created parent 139990593076080
Created child: 139990593076080
Getting the underlying OpenSSL context
typedef struct {
PyObject_HEAD
SSL_CTX *ctx;
<details skipped>
} PySSLContext;
Thus, ctx is at a known offset, which is:
PyObject_HEAD
This is a macro which expands to the declarations of the fields of the PyObject type; it is used when declaring new types which represent objects without a varying length. The specific fields it expands to depend on the definition of Py_TRACE_REFS. By default, that macro is not defined, and PyObject_HEAD expands to:
Py_ssize_t ob_refcnt;
PyTypeObject *ob_type;
When Py_TRACE_REFS is defined, it expands to:
PyObject *_ob_next, *_ob_prev;
Py_ssize_t ob_refcnt;
PyTypeObject *ob_type;
Thus, in a production (non-debug) build, and taking natural alignment into consideration, PySSLContext becomes:
struct {
void*;
void*;
SSL_CTX *ctx;
...
}
Therefore:
_ctx = _ssl._SSLContext(2)
c_ctx = ctypes.cast(id(_ctx), ctypes.POINTER(ctypes.c_void_p))
c_ctx[:3]
[1, 140486908969728, 94916219331584]
# refcnt, type, C ctx
Putting it all together
import ssl
import socket
import ctypes
import pytest
def contact_github(cafile=""):
ctx = ssl.SSLContext()
ctx.verify_mode = ssl.VerifyMode.CERT_REQUIRED
# ctx.load_verify_locations(cafile, "empty", None) done via ctypes
ssl_ctx = ctypes.cast(id(ctx), ctypes.POINTER(ctypes.c_void_p))[2]
cssl = ctypes.CDLL("/usr/lib/x86_64-linux-gnu/libssl.so.1.1")
cssl.SSL_CTX_load_verify_locations.argtypes = [ctypes.c_void_p, ctypes.c_char_p, ctypes.c_char_p]
assert cssl.SSL_CTX_load_verify_locations(ssl_ctx, cafile.encode("utf-8"), b"empty")
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("github.com", 443))
ss = ctx.wrap_socket(s)
ss.send(b"GET / HTTP/1.0\n\n")
print(ss.recv(1024))
def test_wrong_cert():
with pytest.raises(ssl.SSLError):
contact_github(cafile="bad-cert.pem")
def test_correct_cert():
contact_github(cafile="good-cert.pem")

Resources