1. Suhas Shravagi
  2. PowerBuilder
  3. Friday, 14 February 2020 12:57 PM UTC

Hi, we have a desktop application developed in PowerBuilder 2017 R2. This application does not use any external functions or DLL calls. But when it is launched, it has been observed that the application is internally searching for some Windows DLLs on entire Windows installation drive i.e. without qualifying the complete path. May be this is an existing behavior of PowerBuilder, but it is making the application as vulnerable to attack as one can easily develop a malicious DLL with any Windows DLL name the application looks for. Basically it is making dynamic search for dependent DLLs. So Is there any way that will force the PowerBuilder application to search for the required DLLs qualified by the complete path? 

Accepted Answer
Suhas Shravagi Accepted Answer Pending Moderation
  1. Thursday, 17 September 2020 14:12 PM UTC
  2. PowerBuilder
  3. # Permalink

The issue is resolved. We implemented DLL Redirection in our application. Also apart from PB runtime DLLs, we copied all other searched DLLs into the application directory.

  1. Roland Smith
  2. Saturday, 19 September 2020 01:54 AM UTC
This reminds me of an old joke. A patient go to the doctor and says: Doctor, my arm hurts when I do this (raises arm as high as it will go). Doctor: Well don't do that.
  1. Helpful
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Monday, 17 February 2020 00:41 AM UTC
  2. PowerBuilder
  3. # 1

Hi Stuart, reflecting on your reply referencing Raymond Chen.


Relative or Explicit Path

You can decide relative or specific path for each file your app references in code. That is your decision, 100%!
PB will do as you ask it when you call functions like FileOpen(...) , Run(...), or SaveAs(...).

PowerBuilder supports both relative and explicit file path in each app's library list. Again, your decision for each app file.


Relative Paths for PB Runtime Files

PB apps rely on PB runtime files (like PBVM190.dll, PBDWE190.dll, and PBODB190.ini).
They are referenced by relative path. Standard Windows file resolution process is you "weapon of choice" to customize and lock down app's file search. Several options come to mind (combine as you like)

  • Locate all runtime files required by your app in your app's "app folder"
  • Specify App Path for your particular app
  • Lock down access to your app folder as much as possible
  • Don't forget the "all files matter" view: Include graphics files, help files, document templates, etc.
  • Follow same security guidelines as with any other Windows app being PB or non-PB.


As Raymond Chen points out in that blog post: You have a whole different issue than some app being vulnerable if an attacker already gained system admin privilege to your system.

There are no comments made yet.
Stuart Macandrew Accepted Answer Pending Moderation
  1. Sunday, 16 February 2020 22:46 PM UTC
  2. PowerBuilder
  3. # 2

Your security vulnerability is a fallacy I believe.

Raymond Chen explains this rather well  ;



There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Friday, 14 February 2020 22:20 PM UTC
  2. PowerBuilder
  3. # 3

If you want to restrict any Windows application's search path you can definer App Paths per app via registry.
See Microsoft docs for details.

PowerBuilder virtual machine doesn't scan all folders for all files. It uses DLL files just like any other large Windows app.  Including standard file resolution via path, app paths, GAC (for .NET assemblies), etc.

Appeon signs PB runtime files and apply additional security features to protect the integrity of each file.

You should apply same security approach to PowerBuilder apps as you do to other Windows apps. On top of my head I can't remember a single app running on Windows that doesn't include DLL files itself and/or call standard Windows APIs which all delivered via DLL files.

If an attacker injects a compromized version of Kernel32.exe in your system path it will impact every single app using the system path for file resolution - including Windows O/S itself.


HTH /Michael

There are no comments made yet.
Roland Smith Accepted Answer Pending Moderation
  1. Friday, 14 February 2020 19:25 PM UTC
  2. PowerBuilder
  3. # 4

Which DLL files does it appear to be looking for?

What tool are you using to track the behavior?


There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 14 February 2020 19:14 PM UTC
  2. PowerBuilder
  3. # 5

Hi Suhas;

  The PB run-time does not perform such exhaustive DLL searching. My guess is that something else is going on that is invoking this exhaustive O/S search. If a PB run-time DLL is not located via the local folder or System Path, the PB Loader stops and returns an instantiation error.

Regards ... Chris

There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Friday, 14 February 2020 13:18 PM UTC
  2. PowerBuilder
  3. # 6


Which DLL's is it looking for?

Could it be you need to install C++ runtime or some other DLL's which are required like "atl100.dll"?

I think that if the files which are being looked for are in the PATH environment variable, windows wouldn't have to search all over the disk? Not 100% sure, as windows has a somewhat weird logic when looking for files (current path, GAC, PATH, etc.)

About protection: normally a good antivirus would intercept any malicious DLL's no matter where they are being found.



There are no comments made yet.
  • Page :
  • 1

There are no replies made for this question yet.
However, you are not allowed to reply to this question.