Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (6)

Resolved Code Obfuscation for PowerBuilder Apps?

  1. Advice
0
Votes
Undo
  1. Michael Kramer
    Michael Kramer
  2. PowerBuilder
  3. Thursday, 10 October 2019 19:11 PM UTC

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

Modify Title for window with tabs
Source Control for PB 2017
Responses (6)
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Saturday, 12 October 2019 23:48 PM UTC
  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.

 

Comment
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Sunday, 13 October 2019 00:13 AM UTC
Correct. It's only the App Loader in the EXE that determines whether the code in the PBD runs as 32bit or 64bit. ;-)
  1. Helpful
Michael Kramer
  1. Michael Kramer
  2. Sunday, 13 October 2019 01:10 AM UTC
I wonder how longptr values are stored in the PBD since that type supposedly has different size on 32-bit and 64-bit.
  1. Helpful
Roland Smith
  1. Roland Smith
  2. Sunday, 13 October 2019 13:03 PM UTC
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. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Saturday, 12 October 2019 21:28 PM UTC
  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.

Comment
Michael Kramer
  1. Michael Kramer
  2. Saturday, 12 October 2019 21:53 PM UTC
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. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Saturday, 12 October 2019 23:08 PM UTC
This could make an interesting presentation at an Elevate Conference. ;-)
  1. Helpful
Roland Smith
  1. Roland Smith
  2. Saturday, 12 October 2019 23:35 PM UTC
The best way to secure sensitive code is for it to be located on a central server instead of a client app.
  1. Helpful
There are no comments made yet.
Michael Kramer
Michael Kramer Accepted Answer Pending Moderation
  1. Saturday, 12 October 2019 18:46 PM UTC
  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/
LibraryDirectoryEx		 Extract DW Syntax
Describe("DataWindow.Syntax")
.PBD Success Success
.DLL Failure (empty) Success
.EXE Success Success

FOLLOW-UP
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.

/Michael

Comment
Load more comments
Michael Kramer
  1. Michael Kramer
  2. Saturday, 12 October 2019 21:14 PM UTC
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. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Saturday, 12 October 2019 21:17 PM UTC
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. Helpful
Michael Kramer
  1. Michael Kramer
  2. Sunday, 13 October 2019 03:50 AM UTC
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. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Friday, 11 October 2019 15:47 PM UTC
  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.   :-)

HTH

Regards ... Chris

Comment
Load more comments
Andreas Mykonios
  1. Andreas Mykonios
  2. Saturday, 12 October 2019 12:11 PM UTC




Hi Chris.



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



Andreas.

  1. Helpful
Michael Kramer
  1. Michael Kramer
  2. Saturday, 12 October 2019 12:34 PM UTC
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. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Saturday, 12 October 2019 13:04 PM UTC
Hi Andres ... Yes, the EXE has the source code in there (as per Michael's explanation).
  1. Helpful
There are no comments made yet.
Armeen Mazda @Appeon
Armeen Mazda @Appeon Accepted Answer Pending Moderation
  1. Thursday, 10 October 2019 20:16 PM UTC
  2. PowerBuilder
  3. # 5

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

ArmDot

Crypto Obfuscator

Demeanor

DeployLX CodeVeil

Dotfuscator 

NET Reactor

Semantic Designs

SmartAssembly

Spices.Net

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

Comment
Load more comments
Armeen Mazda @Appeon
  1. Armeen Mazda @Appeon
  2. Thursday, 10 October 2019 22:26 PM UTC
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. Helpful
Michael Kramer
  1. Michael Kramer
  2. Thursday, 10 October 2019 22:30 PM UTC
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. Helpful
Michael Kramer
  1. Michael Kramer
  2. Thursday, 10 October 2019 22:32 PM UTC
Thank you for the tip. We can certainly try the machine code option.
  1. Helpful
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 10 October 2019 19:46 PM UTC
  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

HIH

Comment
Load more comments
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Friday, 11 October 2019 05:26 AM UTC
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. Helpful
Michael Kramer
  1. Michael Kramer
  2. Friday, 11 October 2019 09:36 AM UTC
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. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Sunday, 13 October 2019 04:21 AM UTC
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. Helpful
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.