David Heffernan

Stepping back here, are piecemeal comments from numerous different authors in a forum the best way to design the security for your software? I'd want to be reading a book written with a train of thought. Covering a variety of issues, with explanation of why they matter. And a book that has been well reviewed. It seems to me that standalone tips are the kind of thing that lead to insecure software. Security is an end to end, entire process thing, where the interactions matter. Using a couple parts of best practise doesn't make your software secure. It only needs one part to be missing.

If I were you, I think I'd probably want to know what type of phones these actually were.

Why do you need a phone? Wouldn't it be easier to do it without the phone?

Question is actually about identifying which piece of code is responsible for the lock. Asker already knows which process has it.

Well then they aren't what you say they are.

@avk I am sceptical of your numbers. How can the other algorithms match TimSort for sorted and reverse data?

It's strange then that you don't seem to read what people post. I get a sense sometimes that you ask questions but have already decided what the answer is.

Names mean nothing. You have to understand what people say, and judge it for yourself. Stop following people blindly based on reputation. Try to develop your own critical assessment of what you read.

You weren't following his advice. You misunderstood what he said. I already said this. Did you also misunderstand what I said?

Nick's point is fine. I think you just misunderstood it to mean that you needed to replace all boolean args. Following somebody else's recipe without really grasping the issue won't make your code any better. It will just give you work to do and make it likely that you will introduce bugs to your code? If you don't have comprehensive tests for all of your code then you are in big danger of that.

This makes no sense whatsoever.

There is a well known design flaw with passing arguments to const arguments. procedure Foo(const Bar: IMyInterface); .... Foo(TMyImplementingClass.Create); As we know, Foo won't increment the reference count because Bar is const. Possible issues are the object is leaked, or released early inside Foo (e.g. if something inside takes a reference and then releases it). This should be fixed by having the compiler realise at the call site that something needs to take a reference to the interface while the function is executing, and emitting the necessary code at the call site. I've given up hope that this will ever be fixed. On the other hand, perhaps I should be pleased that Idera consider itself to be one of the hottest companies around.

Use some judgement. You don't need to get rid of all booleans. Code like: SetControlsEnabled(True); SetMenusEnabled(True); SetFeaturesEnabled(True); is perfectly fine. Does it make sense when you read it? Yes, of course it does. What you need to watch out for is code like: EnumerateFrogs(True); Nobody reading that can infer what the argument does.

That's not a problem with the Delphi side of things, that would be a basic design flaw of the library. If the consumer of the library has to call functions that it can't access, in order to use the library, then the library is unusable. You are better off not to speculate and guess like this. If the asker has a question, trust them to ask it.

Not really. You still declare it as a pointer and call the library function to open the file, and a pointer is returned. Only the library needs to know the implementation. It's a pointer to an opaque struct.

Then an untyped pointer will do.

This question is only useful to you if the answer is yes. The answer is no. And you are none the wiser. What you perhaps should have asked about was the underlying reason why you are concerned with a FILE*

And my point is that you are giving yourself a false sense of security. It will take you extra time to develop your own licensing system, and then it gets cracked anyway. You may as well use a standard off the shelf tool and save yourself the time. Plus your paying users are able to use a system that they are familiar with for other software.

If somebody wants to crack your program then your home brew protection won't hold up either.

This won't work either.

All of these security hardware devices are crackable. HASP has a terrible record. And the prices they charge are just ludicrous. You should view these things as a means to help your paying customers use the right amount of licences. They are not going to help you stop hackers cracking your program.

All of this advice is kinda pointless if the attacker is inside your building!

You said "stolen" which seemed odd. I don't know where you get your monetary figures from.

Leave it as an enum, but set the right enum size http://docwiki.embarcadero.com/RADStudio/Sydney/en/Minimum_enumeration_size_(Delphi)

You missed the language member. And probably the enum is actually an int and so 4 bytes.