Help with sending library functions to another program

[balazsszekely]

@Gustavo 'Gus' Carreno

Awwww, GetMem, you are such a softy!!! ;-P

You sound like my wife. 

[Gustavo 'Gus' Carreno]

Hey GetMem,

You sound like my wife. 

ROTFL!!!!
Well, you are and you've captured my heart. I might even forget I'm strait and ask you out on a date ;-D

And don't forget to tell your wife that she's a really lucky lass !!

Cheers,
Gus

[Gustavo 'Gus' Carreno]

Hey Mike,

Oooops, I forgot to reply to this one...

[snip] (created in another, more secure language) [snip],

There is no such thing as levels of secure between compiled languages.
They all have to abide by the same rules and produce a binary that is compatible with the operating system they'll run on.
What makes any programming secure or insecure is the element between the chair and the keyboard.

To be honest, if we're talking about "security", Pascal is one of the most "secure" languages on the market.
Why, you ask?
Well, let's see:

• It's a strong typed language, the opposite of many interpreted ones
• It has a managed string implementation, the opposite of C/C++ that produce most of the buffer overflows
• Since one if it's premises was to be close to a natural language(English) as possible, it's rather readable by nature

Rust is probably the most "secure" one at the moment. It's a new language that's trying hard to not make the mistakes of the past. And it has good memory and string handling embedded.

But, the element between the chair and the keyboard can still make programs in these languages that are completely insecure.
Strong typing and good string handling is not a silver bullet!!

[snip] some kind of protected library. [snip]

I would like to know what you call a protected library.
Like I said about the binaries, also the dynamic libraries have to follow an established format so that any program can load them.
The only protection you get is the fact that a compiled anything does not decompile into the original code.
It does, nonetheless, disassemble into assembly, and with that you can recreate the original source with a bit of patience and know how.
So again, what is a protected library?

Since you can decompile a .dll fairly easily, we will be obsfucating and encrypting the compiled code and then
distributing it. So, yes, it is intended to be a locked library that clients can use without getting to the actual source code.

I would really like to know how you will be obfuscating and encrypting a dynamic library. If you do that, I'm afraid that you'll invalidate the established format that they have to be written on.
But let's say that you do obfuscate and/or encrypt said dynamic library, you then still have to provide, in each program that uses the dynamic library, the means(a key and the code to de-obfuscate/de-encrypt) to reverse that in order to be usable.
That means that you locked the door, but left the key on the lock. That pretty much invalidates the exercise, no?

The way you're looking at this security issue is rather naive. Just think, if all that techno-bable you said could be possible, don't you think that someone had done it before?
Ask around and find for yourself. There is no 100% guaranteed way of securing your code. Just less easy to do it.

Cheers,
Gus

[karmacomposer]

@karmacomposer

See attached project.
1. Build the dll(serverinfo subfolder)
2. Run the project

Thank you very much for this.  I will investigate what makes this work.  Lazarus (Free Pascal) works so differently when it comes to external files and I just could not find very much information explaining it clearly.  I work best by examples.

My big problem will be creating very large functions which currently work in their pascal units but I need to offload them to a .dll and still be able to call them and get a result.  That was what this test was for.

I need to study TFarProc, TFunc and TLibHandle to see how they work in this context.  Everything else seems straight forward.

Again, thank you.

Mike

[karmacomposer]

Hey Mike,

Oooops, I forgot to reply to this one...

[snip] (created in another, more secure language) [snip],

There is no such thing as levels of secure between compiled languages.
They all have to abide by the same rules and produce a binary that is compatible with the operating system they'll run on.
What makes any programming secure or insecure is the element between the chair and the keyboard.

To be honest, if we're talking about "security", Pascal is one of the most "secure" languages on the market.
Why, you ask?
Well, let's see:

• It's a strong typed language, the opposite of many interpreted ones
• It has a managed string implementation, the opposite of C/C++ that produce most of the buffer overflows
• Since one if it's premises was to be close to a natural language(English) as possible, it's rather readable by nature

Rust is probably the most "secure" one at the moment. It's a new language that's trying hard to not make the mistakes of the past. And it has good memory and string handling embedded.

But, the element between the chair and the keyboard can still make programs in these languages that are completely insecure.
Strong typing and good string handling is not a silver bullet!!

[snip] some kind of protected library. [snip]

I would like to know what you call a protected library.
Like I said about the binaries, also the dynamic libraries have to follow an established format so that any program can load them.
The only protection you get is the fact that a compiled anything does not decompile into the original code.
It does, nonetheless, disassemble into assembly, and with that you can recreate the original source with a bit of patience and know how.
So again, what is a protected library?

Since you can decompile a .dll fairly easily, we will be obsfucating and encrypting the compiled code and then
distributing it. So, yes, it is intended to be a locked library that clients can use without getting to the actual source code.

I would really like to know how you will be obfuscating and encrypting a dynamic library. If you do that, I'm afraid that you'll invalidate the established format that they have to be written on.
But let's say that you do obfuscate and/or encrypt said dynamic library, you then still have to provide, in each program that uses the dynamic library, the means(a key and the code to de-obfuscate/de-encrypt) to reverse that in order to be usable.
That means that you locked the door, but left the key on the lock. That pretty much invalidates the exercise, no?

The way you're looking at this security issue is rather naive. Just think, if all that techno-bable you said could be possible, don't you think that someone had done it before?
Ask around and find for yourself. There is no 100% guaranteed way of securing your code. Just less easy to do it.

Cheers,
Gus

The main language I use that I consider very secure is because the source code can be encrypted before the compile stage and the resulting executable cannot be disassembled or decompiled - the resulting code is encrypted and therefore useless to outside attempts.

No other language offers this that I know of.  Pascal is the next best and I needed to convert our security software to allow for web languages - which every client asked for.  With the other language, we would have to create the entire project, GUI and all.  This way, the client can use any front end language and we can interface with it using XML (post/get) and SSL for transit. Once it hits our middleware/core, we can then encrypt and store the data as per our normal system.

To say it's not been easy is an understatement.  I used to code in Pascal back in Borland days, but I am very, very rusty.  My last software I created with Pascal was called Rocket and was a advanced web browser (for its time) way back in the days of 56k dialup.

The language I have been using for over 20 years since then is called Livecode and is what allows me to encrypt the source before compilation, making it extremely resilient to cracking and hacking.

Mike

[Gustavo 'Gus' Carreno]

Hey Mike,

The language I have been using for over 20 years since then is called Livecode and is what allows me to encrypt the source before compilation, making it extremely resilient to cracking and hacking.

I had a look at the LiveCode web site and from a quick look, granted not a deep dive into the subject, it looks to me that it's an interpreted language or a compile to byte code language(a la .NET).

I was comparing compiled to compiled. You're comparing compiled to whatever LiveCode is. It's not apples to apples is it?

You can obfuscate and encrypt all you want, but the binary that runs the obfuscated/encrypted code still has, in plain old assembler, the procedure and the key to undo all that and then JIT compile or whatever it does to run your code.
Again, with a bit of patience and a good Hex Editor, you can get ALL your source back. At least with a compiled binary, you have to manually recreate the source by hand. This LiveCode scenario just gives you all the code back.

To be honest, no one in it's right mind will attempt any hacking and cracking of, either a compiled binary or your LiveCode thingamajig if it doesn't pay off immensely.
So in reality, compiled or LiveCode, have the same level of security.
Unless you're doing top secret military contract, what you're saying is nothing more than Marketing bable to get clients to pay more cash.

Just my 2c.

Cheers,
Gus

[Gustavo 'Gus' Carreno]

Hey Mike,

No other language offers this that I know of.  Pascal is the next best and I needed to convert our security software to allow for web languages - which every client asked for.  With the other language, we would have to create the entire project, GUI and all.  This way, the client can use any front end language and we can interface with it using XML (post/get) and SSL for transit. Once it hits our middleware/core, we can then encrypt and store the data as per our normal system.

What you're describing here is your typical OAuth2 secured, REST Service behind some kind of LAMP stack, but with XML(old and on it's way out) instead of JSON.
This should be tackled from a web centric tools approach, and yes, Object Pascal is not the best tool for the project here.
And I'm guessing, neither is LiveCode.

I'm guessing that your superiors decided on your current path due to the legacy code that has piled up, right? Or just because you don't have Web competency in your programmer's pool.

From what you're telling me, you're about to re-invent the wheel, but 5 years too late and having to catch up. Not a good place to be... Microsoft tried that with smartphones and had to give up...

But hey, it's their money, they can waste it as they see fit

Cheers,
Gus