DLL vs PBD

Miguel Leeuwe Accepted Answer Pending Moderation

Wednesday, 11 March 2020 11:31 AM UTC
PowerBuilder
# 1

Hi,

This is a question for Chris (or anyone who knows the answer):

Chris commented here:

Hi Michael;

The C++ M-Code is accomplished via a C++ Code "emitter". The Emitter tokenizes the generated code - so de-compilation is virtually impossible. ;-)

My question is: So if DLL's are being "tokenized", does the same "tokenization" apply for code that goes into the EXE file?

The situation here is that management probably "ignores that benefit of DLL's" so the idea I have, is to keep using PBD's and include some pbl that holds sensitive data (like "hardcoded passwords") into the EXE instead of in some PBD.

We do have "some" encryption on those passwords, but still the encryption key is hard coded and put together from a few pieces of that encryption key in different places in the code.

regards

Comment

Load more comments

Chris Pollach @Appeon
Wednesday, 11 March 2020 13:26 PM UTC

Correct

Helpful 0

Roland Smith
Wednesday, 11 March 2020 17:57 PM UTC

If you need to embed a password in code, encrypt the string outside the app and put the encrypted string in the code. Then when you need to use it, decrypt the password. That way the plain text of the password is only in memory.

This would be a good use case for indirect variables. Code that uses the password would think it is just assigning one variable to another but behind the scenes the indirect function would decrypt the hard coded value.

https://www.topwizprogramming.com/freecode_indirect.html

Helpful 0

Miguel Leeuwe
Wednesday, 11 March 2020 19:10 PM UTC

Hi Roland, yes that's a very good tip, I'll certainly have a look at it. (when time's available).

Personally I was thinking to use the windows AD vault. That way if things aren't secure enough it won't be the programmers fault (but MS's). Regretfully I wasn't assigned to this task.

Helpful 0

There are no comments made yet.

Michael Kramer Accepted Answer Pending Moderation

Sunday, 8 March 2020 05:58 AM UTC
PowerBuilder
# 2

I'm very much in line with Ricardo. "Your mileage may vary!"

Performance is SO environment dependent. You have to measure P-code vs. M-code in YOUR app in YOUR environment. PB manual on compile to machine code discusses what code elements runs faster. Only certain elements are impacted at all - but your performance may be dominated be all other things like apps competing for local memory; network delays; file distribution on disks, and database performance.

In my 27+ years with PB I never had to compile to M-code due to performance bottle-necks.
Issues were always somewhere else.

Security is so much more than protect from decompile. BTW: Any PB app can export DataWindows from M-code files. Easiest way to safeguard file content is to keep app files stored on "secure" servers and only allow terminal access like RDP or Citrix.

I would argue only reason M-code version of PBD is considered "more safe" is that the format isn't publicly documented. But anyone with enough resources could analyze exactly how P-code turns to M-code -- and hence establish foundation for decompile. Start with PBL having 1 class with 1 function returning "Hello, world." Then gradually expand. It is time consuming but isn't rocket science.

Improving security should in my view start with risk assessment including gap-analysis = "What do we need to improve?" With that baseline analyze options, then decide - and finally execute.

HTH /Michael

Comment

Chris Pollach @Appeon
Sunday, 8 March 2020 16:29 PM UTC

Hi Michael;

The C++ M-Code is accomplished via a C++ Code "emitter". The Emitter tokenizes the generated code - so de-compilation is virtually impossible. ;-)

Having DWO code exposed is really not a threat. Exposing "Protected B" (or higher) sensitive data in your app is a much higher exposure. For example, PB Apps that encrypt / decrypt data via SQL. That means that exposed sensitive data like bank account numbers, SSN (SIN), Credit Card, etc data can be easly sniffed via network packet sniffers. Sensitive data like aforementioned, can also be gleaned off instance variables if the data does *not* remain encrypted. Basically, no sensitive data should be stored in DWO buffers, global or instance variables in its decrypted form.

Food for thought.

Regards ... Chris

Helpful 0

There are no comments made yet.

Ricardo Jasso Accepted Answer Pending Moderation

Sunday, 8 March 2020 00:50 AM UTC
PowerBuilder
# 3

Marc,

Compiling one of our applications to m-code took half an hour. Compiling the same application to p-code took less than a minute. Execution speed was practically the same.

I don't think that for in-house, traditional business applications compiling to m-code is worth the longer compilation time since execution time is practically the same. Maybe for specific scientific or image processing applications it is worth. Or for commercial applications that are going to be distributed to the public, to protect the code.

Regards,

Ricardo

Comment

There are no comments made yet.

Armeen Mazda @Appeon Accepted Answer Pending Moderation

Saturday, 7 March 2020 21:07 PM UTC
PowerBuilder
# 4

Besides the benefits of what Marco mentioned in the post he provided, you also have benefit that DLLs cannot be decompiled to source code whereas PBDs can.

Comment

Chris Pollach @Appeon
Saturday, 7 March 2020 21:29 PM UTC

Hi Armeen ... Yes, M-Code compiles have a superior code privacy! An excellent benefit when your PB App's have sensitive code or corporate algorithms that you do not want to ever expose. Another PRO for DLL's (M-Code compiles) for me is that the C++ compiler is much more stringent on your PowerScript code. I always do both (M-code & P-Code) compilations on my frameworks. Just to make sure that the new PowerScript compiles 100% clean & there are *no* Linkage-Editor errors/warnings. Once is see that, I am now super confident in my subsequent P-Code compiles. So in essence, I use the M-Code compiles as a 1st super Q/A code check. Food for thought.

One other PRO for M-Code compiles is that you can trap the generated C++ code in the background & then run that through commercial security analysis software. Makes your IT security people get the "warm & fuzzies". ;-)