1. Michael Kramer
  2. PowerBuilder
  3. Thursday, 10 October 2019 19:11 PM

Hi All,
Who has used which code obfuscation tools with PowerBuilder? Successful?

Business requirement: Make deployed PB app's .EXE/.PBDs/.DLLs/assemblies so complex, time consuming, and hence costly for professional attacker to analyze that it isn't worth the effort. 

Any pointers greatly appreciated. /Michael

Roland Smith Accepted Answer Pending Moderation
  1. Saturday, 12 October 2019 23:48 PM
  2. PowerBuilder
  3. # 1

The PBD files created during a 64bit compile are 100% identical to those created during a 32bit compile.

The PBD file format is identical to a PBL file. A PBD file is created by copying the compiled version of objects from the PBL into the PBD.


Correct. It's only the App Loader in the EXE that determines whether the code in the PBD runs as 32bit or 64bit. ;-)
  1. Chris Pollach @Appeon
  2. Sunday, 13 October 2019 00:13 AM
I wonder how longptr values are stored in the PBD since that type supposedly has different size on 32-bit and 64-bit.
  1. Michael Kramer
  2. Sunday, 13 October 2019 01:10 AM
From the help:

"Since PowerBuilder does not have a datatype corresponding to the C++ pointer type, and there are no pointer operations in PowerBuilder, longptr is not a full-fledged PowerBuilder datatype. You can use it to hold/pass window handles, database handles, and other objects that are essentially memory addresses. Doing complex operations on longptr type might not work. If you want to represent/compute 8-byte long integers, use longlong."

Longptr is only for calling API functions, so storing a fixed 64bit value in the compiled object may not work. I suspect the 64bit VM allocates a larger variable at runtime and uses that instead of the 32bit long that is in the compiled code.

  1. Roland Smith
  2. Sunday, 13 October 2019 13:03 PM
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Saturday, 12 October 2019 21:28 PM
  2. PowerBuilder
  3. # 2

Remember ... M-Code only protects your PowerScript code but not the DWO source as it's just a text string in the EXE, PBD or DLL. The only way to protect DWO source is to encrypt it in external files or as a Blob in a DB table. Then load the DWO source via a file read or SelectBlob, decrypt it and then use the CREATE() command to safely manage the DWO source at run-time. Thus, you would never hard link DWO's into your App in this case.

Agree. Many options to secure sensitive code.

There are pros and cons. Step 1 is awareness.

Funny, the DW extraction actually stems from Linda's question on getting to DataWindow source. I sensed part of her app portfolio is 3rd party so they have PBDs but no source. So like Roland I had a go at how to extract DW objects.
  1. Michael Kramer
  2. Saturday, 12 October 2019 21:53 PM
This could make an interesting presentation at an Elevate Conference. ;-)
  1. Chris Pollach @Appeon
  2. Saturday, 12 October 2019 23:08 PM
The best way to secure sensitive code is for it to be located on a central server instead of a client app.
  1. Roland Smith
  2. Saturday, 12 October 2019 23:35 PM
There are no comments made yet.
Michael Kramer Accepted Answer Pending Moderation
  1. Saturday, 12 October 2019 18:46 PM
  2. PowerBuilder
  3. # 3

Hi Guys,

I can extract DataWindows from machine code compiled PB libraries despite LibraryDirectory/LibraryDirectoryEx can't read .DLL files.

However => I can still extract DataWindow syntax from the .DLL files if I find the DataWindow name some other way (e.g. brute force attempt or someone tells me)

PB Library Type LibraryDirectory/
Extract DW Syntax
.PBD Success Success
.DLL Failure (empty) Success
.EXE Success Success

I linked the DataWindow objects via .PBR file into all three types of .EXE (32/64-bit P-code + 32-bit machine code). In all cases any of my DW extractor builds could read the .EXE as if it were a .PBD.

Conclusion: Linking DataWindow objects into the .EXE file in a machine code build makes the DataWindows more vulnerable than if they were included in the .DLL files!

Another finding: I can mix and match 32-bit P-code, 64-bit P-code, and 32-bit machine code.
My extractor in machine code reads .PBD files. - and - my extractor in P-code reads .DLL files.

EXE Type DW in 32.PBD DW in 32.DLL DW in 64.PBD DW in any .EXE
(via .PBR)
32-bit P-code Success Success Success Success
32-bit Machine code Success Success Success Success
64-bit P-code Success Success Success Success

Amazing what a few lines of code can do when you set out a target and go for it.
And scary since I care about secure systems.


File size differs. But the interesting part is that a DataWindow object is nothing but a text string containing the DW syntax. It is stored in UTF-16 I presume for fast load but it is just a string at some pre-defined offset within a given file - no matter what the environment is.

All executable code in classes have been compiled to specific incompatible code (32-bit P-code, 64-bit P-code, and 32-bit machine code). Only the DataWindow objects have this peculiar behavior.

COme to think of it - same is potentially true for Data Pipeline objects. I leave that to others.
  1. Michael Kramer
  2. Saturday, 12 October 2019 21:14 PM
Surprising !

So ... how do you hook-up an EXE into the app that you use to read the dwsyntax? Do you rename it and then hook it up in the library list or something or is renaming not even necessary?
  1. Miguel Leeuwe
  2. Saturday, 12 October 2019 21:17 PM
Everything is 100% dynamic. Adjusting library list in-flight.

For UI selection of DW objects I use LibraryDirectoryEx to display DW names in DDLB.

Actual extract process is 4 steps.

1) Include EXE at front of LibraryList (SetLibraryList)

2) Assign DW name into datastore

3) ds.Describe to read DW syntax

4) Restore library list ASAP (don't trust any foreign code!)

I keep returning to my original library list (SetLibraryList crashes at 500 files in library list)
  1. Michael Kramer
  2. Sunday, 13 October 2019 03:50 AM
There are no comments made yet.
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 11 October 2019 15:47 PM
  2. PowerBuilder
  3. # 4

Hi Everyone;

   Just an FYI ...

1) If you compile to P-Code, there are de-compilers out there that can reverse engineer your source code.

    So if you have sensitive or TM'ed code to protecty, you might want to think about "Obfuscation" 

    (like the ones that Armeen mentioned).

2) If you compile to M-Code, there are no de-compilers out there for that format.   :-)


Regards ... Chris


Hi Chris.

If you compile using Pcode but without pbd's (in a single executable), then what happens? The code can still reverse engineered?


  1. Andreas Mykonios
  2. Saturday, 12 October 2019 12:11 PM
P-code .EXE is conceptually a .PBD file + tiny bootstrapper:

1) Library List

2) App object's name

3) Actual executable code to load right version of PB VM passing the library list and app object name.

Read: Mostly just first .PBD in library list.
  1. Michael Kramer
  2. Saturday, 12 October 2019 12:34 PM
Hi Andres ... Yes, the EXE has the source code in there (as per Michael's explanation).
  1. Chris Pollach @Appeon
  2. Saturday, 12 October 2019 13:04 PM
There are no comments made yet.
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Thursday, 10 October 2019 20:16 PM
  2. PowerBuilder
  3. # 5

For C# portion of your PB project tons of options, just Google it.  Here are several examples: 


Crypto Obfuscator


DeployLX CodeVeil


NET Reactor

Semantic Designs



For PowerScript portion of your PB project the only legitimate one I am aware of is PB Protect.

For PowerScript PB Protect is the only one I'm aware of. In general, obfuscation is mixed bag. There are number of articles in Google about pros and cons.

Have you considered to compile as DLLs instead of PBDs? To best of my knowledge, the tools that decompile PowerScript work on PBDs not DLLs.

Also, you should sign your DLLs so Windows doesn't pop up security warnings and scare the users. We went through process for PB 2019 R2 doing that for all the runtime DLLs of PowerBuilder.
  1. Armeen Mazda @Appeon
  2. Thursday, 10 October 2019 22:26 PM
Only restriction on source obfuscation is embedded SQL and DW SQL.

DB identifiers can't change though indentation and line breaks can make code hard to comprehend before reformatting.
  1. Michael Kramer
  2. Thursday, 10 October 2019 22:30 PM
Thank you for the tip. We can certainly try the machine code option.
  1. Michael Kramer
  2. Thursday, 10 October 2019 22:32 PM
There are no comments made yet.
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 10 October 2019 19:46 PM
  2. PowerBuilder
  3. # 6

There was this guy name "Ken Shu" or something similar. He wrote ShudePB a very well working Decompiler.

I think he also wrote PBObfuscator. You might find useful links here http://www.mis2erp.com/index_en.html


Totally agree on that, though "bringing to court" might be difficult with the French company too. Obfuscation is not something that will give you any guarantees, therefore I'm pretty sure they'll have the necessary disclaimers to stay out of any court. Obfuscation is just an extra step in making it less easy/attractive to decompile you software. Another form of protection I can think of: is to have as much as possible run on a webserver (nvo with snapobjects?).
  1. Miguel Leeuwe
  2. Friday, 11 October 2019 05:26 AM
Thanks Miguel, I agree fully. We are doing a lot to protect the apps already. Next step is to look at code stored on client machine which we can't lock down 100% since machine has to be usable outside secure rooms on/off premises.

  1. Michael Kramer
  2. Friday, 11 October 2019 09:36 AM
Speaking of "Chinese based vendors" .. Appeon seems pretty "Asian" (and personally I think that's a good thing, before anyone feels offended).

"Appeon is a privately-held company that is majority-owned by Shell Electric, a Hong Kong-based conglomerate employing approximately 5,600 employees worldwide."
  1. Miguel Leeuwe
  2. Sunday, 13 October 2019 04:21 AM
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.