Building Static Deps on Windows, etc.

[Bioblaze]

I am working on a node editor interface, and recently was asked to make a discord bot plugin for the system.

I realized after alot of research, you have some serious hardcoded references to your libs, and made it really annoying since I needed a single static build of the dpp found out omfg its 4gb, so set with a dynamic linked library but then the associated deps were also dynamically linked, like i need them static.

So I wrote a patch that is absolute shit.
But it works for my project as it is, so I decided to post it here in issues, since I doubt its good enough to be a PR lol

diff --git a/library/CMakeLists.txt b/library/CMakeLists.txt
index cc94d030..ac05e15d 100644
--- a/library/CMakeLists.txt
+++ b/library/CMakeLists.txt
@@ -69,9 +69,16 @@ endif()
 
 if (CONAN_EXPORTED)
 	message("-- INFO: ${Green}Conan detected${ColourReset}... finding packages...")
-	find_package(OpenSSL REQUIRED COMPONENTS SSL Crypto)
-	find_package(ZLIB REQUIRED)
-	find_package(Opus)
+	if (NOT WIN32)
+		# On non-Windows, use find_package for Conan targets
+		find_package(OpenSSL REQUIRED COMPONENTS SSL Crypto)
+		find_package(ZLIB REQUIRED)
+		find_package(Opus)
+	else()
+		# On Windows with CONAN_EXPORTED, libraries are provided externally
+		# via cache variables (OPENSSL_SSL_LIBRARY, OPENSSL_CRYPTO_LIBRARY, ZLIB_LIBRARY)
+		message("-- Using externally provided OpenSSL/zlib libraries")
+	endif()
 	find_package(Threads REQUIRED)
 	find_package(Git QUIET)
 endif()
@@ -98,6 +105,11 @@ if(WIN32 AND NOT MINGW)
 			set(HAVE_OPUS_OPUS_H "${CMAKE_CURRENT_SOURCE_DIR}/../win32/include/opus/opus.h")
 
 			include_directories("${CMAKE_CURRENT_SOURCE_DIR}/../win32/include")
+		else()
+			# CONAN_EXPORTED: Use externally provided OpenSSL/zlib
+			# Include dirs and libraries are set by parent CMakeLists.txt
+			message("-- Using externally provided OpenSSL and zlib (static linking)")
+			include_directories(${OPENSSL_INCLUDE_DIR} ${ZLIB_INCLUDE_DIR})
 		endif()
 
 		set(OPUS_FOUND 1)
@@ -295,6 +307,10 @@ foreach (fullmodname ${subdirlist})
 				"${CMAKE_CURRENT_SOURCE_DIR}/../win32/32/lib/zlib.lib")
 		endif()
 
+	elseif (WIN32 AND NOT MINGW AND CONAN_EXPORTED)
+		# Windows with externally provided static OpenSSL/zlib (not Conan targets)
+		# Libraries are linked by parent CMakeLists.txt via target_link_libraries(dpp ...)
+		target_link_libraries(${modname} PUBLIC ws2_32 crypt32)
 	else()
 		if (CONAN_EXPORTED)
 			target_link_libraries(${modname} PUBLIC openssl::openssl ZLIB::ZLIB Opus::opus)

[Bioblaze]

I configure the deps in the project on my side using

# ============================================================================
# Configure DPP with vendored dependencies
# ============================================================================

# DPP must be built as shared on Windows (static lib exceeds 4GB limit)
# but we link OpenSSL/zlib statically INTO the DPP DLL
if(WIN32)
    set(BUILD_SHARED_LIBS ON CACHE BOOL "" FORCE)
else()
    set(BUILD_SHARED_LIBS OFF CACHE BOOL "" FORCE)
endif()

set(DPP_BUILD_TEST OFF CACHE BOOL "" FORCE)
set(DPP_INSTALL OFF CACHE BOOL "" FORCE)
set(BUILD_VOICE_SUPPORT OFF CACHE BOOL "" FORCE)
set(DPP_NO_VCPKG ON CACHE BOOL "" FORCE)
set(DPP_USE_EXTERNAL_JSON ON CACHE BOOL "" FORCE)
set(DPP_NO_CORO ON CACHE BOOL "" FORCE)

# Tell DPP we're using external dependencies (like Conan would)
# This makes DPP use find_package instead of bundled win32 libs
set(CONAN_EXPORTED ON CACHE BOOL "" FORCE)

# Set up variables for find_package(OpenSSL) and find_package(ZLIB)
set(OPENSSL_ROOT_DIR ${OPENSSL_INSTALL_DIR} CACHE PATH "" FORCE)
set(OPENSSL_INCLUDE_DIR ${OPENSSL_INSTALL_DIR}/include CACHE PATH "" FORCE)
set(OPENSSL_SSL_LIBRARY ${OPENSSL_SSL_LIBRARY} CACHE FILEPATH "" FORCE)
set(OPENSSL_CRYPTO_LIBRARY ${OPENSSL_CRYPTO_LIBRARY} CACHE FILEPATH "" FORCE)

set(ZLIB_ROOT ${ZLIB_INSTALL_DIR} CACHE PATH "" FORCE)
set(ZLIB_INCLUDE_DIR ${ZLIB_INSTALL_DIR}/include CACHE PATH "" FORCE)
if(WIN32)
    set(ZLIB_LIBRARY ${ZLIB_INSTALL_DIR}/lib/zs.lib CACHE FILEPATH "" FORCE)
else()
    set(ZLIB_LIBRARY ${ZLIB_INSTALL_DIR}/lib/libz.a CACHE FILEPATH "" FORCE)
endif()

# Add DPP subdirectory
add_subdirectory(vendored/DPP)

# Make DPP depend on our external builds
add_dependencies(dpp zlib_ext openssl_ext)

# Manually link our static OpenSSL/zlib to DPP since CONAN_EXPORTED expects
# the targets to exist from find_package
target_link_libraries(dpp PUBLIC ${OPENSSL_SSL_LIBRARY} ${OPENSSL_CRYPTO_LIBRARY} ${ZLIB_LIBRARY})
target_include_directories(dpp PUBLIC ${OPENSSL_INCLUDE_DIR} ${ZLIB_INCLUDE_DIR})

[Bioblaze]

I know im lame, sorry

workarounds are king after all.

[Ashthetik]

I'm not a part of the Dev team, but, the reason behind dynamic links is for the user's security.

For example, if there was a vulnerability in OpenSSL or Opus, the system can update to a secure version independently of D++ without having to get the user to reinstall the entirety of D++. The same applies to both POSIX and GNU/Linux since those dependencies are handled by the package manager.

This is an independent statement, but is a somewhat common discussion within the support discord and has been the views projected by the maintainers and alike

[ruslan-ilesik]

I'm not a part of the Dev team, but, the reason behind dynamic links is for the user's security.

For example, if there was a vulnerability in OpenSSL or Opus, the system can update to a secure version independently of D++ without having to get the user to reinstall the entirety of D++. The same applies to both POSIX and GNU/Linux since those dependencies are handled by the package manager.

This is an independent statement, but is a somewhat common discussion within the support discord and has been the views projected by the maintainers and alike

Yep, there is quiet a mixed opinions about it, while we do not explicitly forbid using dpp statically we do not encourage it. It is not only about security but also about an application of dpp. Users may use statically linked lib more easily to be distributed in any kind of malware for like stealers or smth, mostly so novice kids who do not have real idea of what they do, and even so making dpp work statically is not very hard for experienced dev, it is hard enough for other novice people to not use dpp in their malware.

[Bioblaze]

I sorta understand, but this applies for every application, dep that is ever implemented.

I sorta get why you are doing it, but at the same time doesn't make a whole-lot of sense.

Trying to protect people from getting malware, or able to upgrade a dep.

How many end-users are going to be-able to even do that? Developers aren't they'll push out a patch, consumers however will just keep using it.

But to each their own.

[Ashthetik]

How many end-users are going to be-able to even do that? Developers aren't they'll push out a patch, consumers however will just keep using it.

Could you explain what you mean by this? The end user of a bot isn't going to impacted since it's routed through discord. It's more for the developer, or to deter (as Ilesik said) script kiddies from throwing D++ into an infostealers like they do with Interpreted languages.

It is within a service's responsibility (such as D++ is to bot Devs) to minimise the supply chain exploitability, for the direct end user.

[Bioblaze]

How many end-users are going to be-able to even do that? Developers aren't they'll push out a patch, consumers however will just keep using it.

Could you explain what you mean by this? The end user of a bot isn't going to impacted since it's routed through discord. It's more for the developer, or to deter (as Ilesik said) script kiddies from throwing D++ into an infostealers like they do with Interpreted languages.

It is within a service's responsibility (such as D++ is to bot Devs) to minimise the supply chain exploitability, for the direct end user.

Well, if there is a exploit/etc for a dependency, having them dynamically linked really doesn't do much?
no developer is going to take a previously released version and re-release out a push with the associated new dll.

They'll push out a new version, for release put a warning on old releases.

And this is due to many platforms not allowing you to update previously released deployments.

It makes little to no sense in my personal opinion, since the only real reason would be for a consumer to download a new dll of a link dep, and replace a existing one.

but what is the rate? 90%+ once they download the app, rarely update or rarely check the platform in association to the downloaded app.

also, script kiddies, etc use way easier/better/languages to make rats/infostealers/etc

someone using C++ to make a rate/infostealer/etc is not a script kiddie, and they'll just make the associated patches to make dpp be statically compiled without the 4gb issue.

much how I did patches to make deps static... it wasn't hard, it was just time consuming since i had to identify the weird path to make it viable....

So that makes no sense also.

me personally rather have a single app no extra files to deploy with it... I don't like having 1 file with 90+ deps all in a folder, hard to distribute, etc.

Since I'm making a plugin system, it isn't that much of a hassle to deploy 1 additional file since i require 2 already. But for normal apps, seems off and annoying.

[Ashthetik]

I see a few misconceptions here with regards to supplychains and modularity of dynamic linking, so I'll clear up the ones I've seen

Well, if there is a exploit/etc for a dependency, having them dynamically linked really doesn't do much?

It does a lot more than what you would initially think. Dynamic linking allows the operating system to update the dependencies independently to the main package – in this case, it's D++. The benefit derived from this is that we can still have a version of D++ that hasn't deprecated a certain dependency version (for whatever reason) and use a newer dependency version. For example: D++ 9.Y.Z using OpenSSL's latest version.

So if OpenSSL has an exploitable vulnerability, D++ will not be impacted with dynamic links since the operating system would update and manage the OpenSSL distribution.

On the other side, static linking requires any product utilising D++ to rebuild the product with the latest patched version of OpenSSL – the D++ version being arbitrary in either example. To patch the product from the OpenSSL vulnerability. Tldr, static links keep the supplychain exploit in play until the third-party (such as yourself) can update the static dependencies. I recommend looking into the 2019 ASUS Live Updater supply chain attack as an example of this.

but what is the rate? 90%+ once they download the app, rarely update or rarely check the platform in association to the downloaded app.

This is actually thanks to dynamic linking, a lot of developers will use a dynamic link rather than ship a pre-built package of critical dependencies, such as OpenSSL, Opus, ZLib, etc. as it's easier for them to rely on a package manager or Windows Update system to take care of these dependencies, once installed.

also, script kiddies, etc use way easier/better/languages to make rats/infostealers/etc

someone using C++ to make a rate/infostealer/etc is not a script kiddie, and they'll just make the associated patches to make dpp be statically compiled without the 4gb issue.

This is also factually incorrect, a skid will utilise a framework, which tends to be written in one of three languages: C++, Node.JS, and Python. There's such a group of skids called BetrayYourFoes (tracking name: Betray) who utilised a C++ system to write a very poorly made Ransomware. I group I've personally investigated. A language is just a tool, a skid is a term used for someone using pre-made tools rolling it as their own – language arbitrary. Ref: https://detraced.org/posts/infostealer-turned-ransomware/

me personally rather have a single app no extra files to deploy with it... I don't like having 1 file with 90+ deps all in a folder, hard to distribute, etc.

Since I'm making a plugin system, it isn't that much of a hassle to deploy 1 additional file since i require 2 already. But for normal apps, seems off and annoying.

Dynamic links don't always add additional deployable files, this is solely up to the developer's method of distribution, majority of the dynamic linking can actually be pulled from the system's installed dependencies, regardless of the operating system. That aside, static is normally discouraged for people unfamiliar with application security, if you feel you're comfortable with maintaining the dependencies bundled into it, that's completely fair and understandable

[Bioblaze]

I read alot of this, and for some reason I feel like ai responses.. idk why.

I'll reply to each section individually and not all at once in 1 post, too much to respond too.

But I will point out if v1 has a exploit, and has 5 functions in it, and you have to upgrade a dll to v2 because of said exploit, and 3 of the functions in said exploit are deprecated, which your app depends on.

your app is now fried, congrats. Without the app itself being updated.... -_- updating the dlls independently of each other means nothing, and can actually have adverse effects if not properly handled, such as naming, location and more.

so no... having a OS update them automatically is quite dumb, and the OS doesn't update them unless your talken about OS system specific dlls, which we should not be discussing, since openssl, etc are not on all systems by default...

ok i'll go begin replying in a moment after I finishing what im doing.

[Bioblaze]

It does a lot more than what you would initially think. Dynamic linking allows the operating system to update the dependencies independently to the main package – in this case, it's D++. The benefit derived from this is that we can still have a version of D++ that hasn't deprecated a certain dependency version (for whatever reason) and use a newer dependency version. For example: D++ 9.Y.Z using OpenSSL's latest version.

So if OpenSSL has an exploitable vulnerability, D++ will not be impacted with dynamic links since the operating system would update and manage the OpenSSL distribution.

On the other side, static linking requires any product utilising D++ to rebuild the product with the latest patched version of OpenSSL – the D++ version being arbitrary in either example. To patch the product from the OpenSSL vulnerability. Tldr, static links keep the supplychain exploit in play until the third-party (such as yourself) can update the static dependencies. I recommend looking into the 2019 ASUS Live Updater supply chain attack as an example of this.

I say see my previous response about this.
your taking alot of asumptions here, and pointing too X time Y happened.

Do understand its easier to replace a dynamically linked library with a malicious file, it isn't like it is checking the hash values here? Its checking for location.

I would argue your making more surface area for your attack by doing that then anything else.
now you have to make additional security features, etc etc the list goes down its a cat and mouse game that'll never end.

now if everything is statically linked within the executable, no surface area beyond injection, and obviously failures of the developer in question or/and the dependencies.

in my personal opinion.

[Bioblaze]

This is actually thanks to dynamic linking, a lot of developers will use a dynamic link rather than ship a pre-built package of critical dependencies, such as OpenSSL, Opus, ZLib, etc. as it's easier for them to rely on a package manager or Windows Update system to take care of these dependencies, once installed.

this would only apply to os specific packages.

I do not rely on windows package manager or updater or whatever to update my sdl3.dll with the newest edition, that makes no god damn sense wtf ever.

no idea why this was thrown out there...

[Bioblaze]

This is also factually incorrect, a skid will utilise a framework, which tends to be written in one of three languages: C++, Node.JS, and Python. There's such a group of skids called BetrayYourFoes (tracking name: Betray) who utilised a C++ system to write a very poorly made Ransomware. I group I've personally investigated. A language is just a tool, a skid is a term used for someone using pre-made tools rolling it as their own – language arbitrary. Ref: https://detraced.org/posts/infostealer-turned-ransomware/

being bad at coding, doesn't mean much....

also do understand your paid shit todo the work, so of course the code is cobbled together.. ffs..

so who are u in that group of writers?

this has no point to anything beyond epenor measuring.

[Bioblaze]

Dynamic links don't always add additional deployable files, this is solely up to the developer's method of distribution, majority of the dynamic linking can actually be pulled from the system's installed dependencies, regardless of the operating system. That aside, static is normally discouraged for people unfamiliar with application security, if you feel you're comfortable with maintaining the dependencies bundled into it, that's completely fair and understandable

again this would only apply to os deps...

if your using package X, and its dynamically linked, it'll produce X.dll/.so/etc etc etc

maintaining software and decreasing the overall surface area for a attack is more standard application security practices then anything......

Are you a reddit mod?

I get alot of reddit mod energy from this post...

[ruslan-ilesik]

I read alot of this, and for some reason I feel like ai responses.. idk why.

I'll reply to each section individually and not all at once in 1 post, too much to respond too.

But I will point out if v1 has a exploit, and has 5 functions in it, and you have to upgrade a dll to v2 because of said exploit, and 3 of the functions in said exploit are deprecated, which your app depends on.

your app is now fried, congrats. Without the app itself being updated.... -_- updating the dlls independently of each other means nothing, and can actually have adverse effects if not properly handled, such as naming, location and more.

so no... having a OS update them automatically is quite dumb, and the OS doesn't update them unless your talken about OS system specific dlls, which we should not be discussing, since openssl, etc are not on all systems by default...

ok i'll go begin replying in a moment after I finishing what im doing.

Your statement is not wrong, but in practice it is not really like that. In most of cases bug fixes do mot change ABI of dll/so file, so linker is capable of working with it, for instance, I would not expect openssl for example to break anything until it is major release and even so they provide pathes and support for older version for long time.

(As i have no knowledge of your experience i should mention that adding new methods to dll/so does not break the abi)

[Ashthetik]

I read alot of this, and for some reason I feel like ai responses.. idk why.

That's just my general writing style when discussing something from a professional perspective. I tend to write more formally and use correct grammar.

But I will point out if v1 has a exploit, and has 5 functions in it, and you have to upgrade a dll to v2 because of said exploit, and 3 of the functions in said exploit are deprecated, which your app depends on.

your app is now fried, congrats. Without the app itself being updated.... -_- updating the dlls independently of each other means nothing, and can actually have adverse effects if not properly handled, such as naming, location and more.

This is what is called breaking features, and happens regardless of whether it's dynamically linked or static. In these cases, a developer will write a patch parallel to the new version. You're assuming all updates happen the moment a version is released. Updates like these tend to rolled out cummatively as they are with Windows or when updating MacOS and Linux/UNIX.

It also ignores that deprecated functions get a backported patch to mitigate and will throw a warning about when the functions will be removed.

so no... having a OS update them automatically is quite dumb, and the OS doesn't update them unless your talken about OS system specific dlls, which we should not be discussing, since openssl, etc are not on all systems by default...

It's not dumb at all, as for the points made above, and to be made below. This is a completely narrow view on the development and security of applications and systems.

Do understand its easier to replace a dynamically linked library with a malicious file, it isn't like it is checking the hash values here? Its checking for location.

I would argue your making more surface area for your attack by doing that then anything else.
now you have to make additional security features, etc etc the list goes down its a cat and mouse game that'll never end.

This is typically covered by the antivirus in most cases, especially for windows and is a risk any applications hold

I do not rely on windows package manager or updater or whatever to update my sdl3.dll with the newest edition, that makes no god damn sense wtf ever.

Yes, not all packages are updated through the PM or Windows, but packages like OpenSSL which is critical to D++ and many other applications, are maintained through your PM and Windows Updater. Hence why I'm containing the bounds of my examples to packages that directly impact the D++ project

being bad at coding, doesn't mean much....

also do understand your paid shit todo the work, so of course the code is cobbled together.. ffs..

Not what I was referring to at all, you don't need to be good or bad, malware development is speciality and your skills in programming are an arbitrary factor to how impactful the malware may be. I was using Betray as an example of where a skid may utilise a framework built in a certain language to prove that the language used in malware is a redundant feature.

so who are u in that group of writers?

My researcher tag for DeTraced is Tr4ceAng3l, I personally wrote the dissection of the malware up until the encrypted payload, which we never released the details for since I didn't have time to R&D a vaccine for the ransomware

if your using package X, and its dynamically linked, it'll produce X.dll/.so/etc etc etc

It can, yes, but as I mentioned above, within the scope of D++ the critical dependencies are managed by the OS and it's package manager, where applicable.

maintaining software and decreasing the overall surface area for a attack is more standard application security practices then anything.....

Yes, that's just reaffirming what I said regarding these practices being application security oriented. Attack Surface Reduction itself isn't exclusive to just AppSec and is a standard with Security In Depth as a philosophy, since it applies to all aspects of security.