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
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.
DB identifiers can't change though indentation and line breaks can make code hard to comprehend before reformatting.