5

I wish to create shareware software that contains a registration algorithm. I am looking for a programming language, that cannot be easily decompiled into readable code. For example, C# can be decompiled into readable code.

What are my options?

Edit: I'm looking for something that can be only decompiled into assembly. Delphi, for example, cannot be decompiled like C# or Java, but from what I've heard, Delphi is dying.

Pindatjuh
  • 10,550
  • 1
  • 41
  • 68
Hansel
  • 87
  • 1
  • 2
  • 27
    With all due respect, while I understand your desire for protection, I don't think it's going to work. The people who crack software will disassemble it and figure out where to put the hooks that break your registration system. If they're able to do it to the big names who invest millions in anti-piracy measures, unfortunately they will be able to do it to you. Not saying I like this situation, mind you, but it is what it is. :( – John Rudy Nov 25 '09 at 22:57
  • 6
    Honestly, this has to be way down your list if things influencing you choice of language. Basing the language choice around what you want to do is going to help developing a program that works and people want to buy. – vickirk Nov 25 '09 at 23:30
  • 1
    If at all possible make your software web-based. Earn paying customers by providing a great service at a reasonable price. And don't be afraid to offer a free version to attract attention. Computers make it easy copy content which in turn drives the value of individual copies closer & closer to zero. The value of copies is at an all-time low - it would be foolish to get into the business of selling copies. – leepowers Nov 25 '09 at 23:57
  • 20
    The supposed death of Delphi has been seriously overreported. It's still good and still being developed. – Loren Pechtel Nov 25 '09 at 23:59
  • Have you considered investigating third-party shareware distributors? There are already a few different types of registration systems out there. – Ether Nov 26 '09 at 04:02
  • 13
    http://www.isdelphidead.com – Mason Wheeler Nov 26 '09 at 13:10
  • 9
    I would considere Delphi since it will be the best solution that suits your needs. FWIW Delphi is kicking and alive. – Stephane Wierzbicki Nov 26 '09 at 13:41
  • 1
    This is the best answer I've read on a question like this, and it can be applied to all languages: https://stackoverflow.com/a/506301/5705257 – Jared Feb 05 '18 at 14:35

20 Answers20

29

Delphi is not dying, it is alive and well.

As is the community, at delphifeeds.
You can also see more delphi projects, Freeware, shareware and commercial at the Delphi Wikia.

Thus I'd say Delphi is a very good choice for Software Development. Freeware, Shareware or Commercial.

Update: On September 1st 2011 Embarcadero released Rad Studio XE2. This released adds 64 Bit Compilation, Livebindings, Native Mac OSX compiling, IOS (via XCode) and a whole lot more to the already powerful delphi Dev environment.

Schalk Versteeg
  • 1,057
  • 13
  • 23
23

If your CPU is able to see the code and run it, by definition, a sufficiently talented person can do it too.

You can, however, make it harder by running your code through an obfuscator.

Mehrdad Afshari
  • 414,610
  • 91
  • 852
  • 789
  • You encrypt your code, use TPM fore holding keys, and protected memory area for holding program during runtime. – Maciek Sawicki Nov 25 '09 at 23:12
  • 2
    Maciek: You need to control the hardware, like the iPhone, Xbox, .... and TPM is a hardware thing. You have to rely on processor features like ARM TrustZone to do that. – Mehrdad Afshari Nov 25 '09 at 23:16
19

I'd suggest the language of business and economics can protect your program.

If you are targeting consumers, and price it at say $10, almost all people would find it easier to pay you the $10 vs going into your program and reverse engineering it.

If you are targeting corporations, and say pricing it at $10,000, it just has to be easier to get the purchasing department to approve the payment than to reverse engineer your code. For real companies who would purchase your product, it's not worth the audit risk to have unlicensed code running.

Lastly, what are the costs/benefits of protecting your code? If you write your program in assembly instead of C#, you might have far higher production costs, while reducing the chance of reverse engineering. However, does this cost outweigh the potential lost sales? Could this time be better spent adding value for people who will buy the product? Generally, trying to sell your product to people who are never pay for software is not a economic strategy.

brianegge
  • 29,240
  • 13
  • 74
  • 99
  • 3
    It's enough that one person removes the protection, the decision doesn't have to be made by each single (potential) customer. – unwind Nov 26 '09 at 16:38
13

You could write it in Perl.

(I kid, I kid! Put down the pitchforks!)

Ken
  • 437
  • 7
  • 10
12
  1. As the others said, Delphi is NOT dying.
  2. As the others said, there is no bulletproof method.
  3. As the others said, there are tools to make the life of a cracker much harder.

But what the others didn't say is:

  1. Java, .NET (etc.) obfuscation is rather a toy compared with obfuscation toys for eg. Delphi and other native solutions. (of course YMMV)
  2. A very good technology to relatively protect your executable can be found here.
NotMe
  • 87,343
  • 27
  • 171
  • 245
John Thomas
  • 4,075
  • 3
  • 29
  • 41
8

Repeat after me: "Obscurity is not security."

You would be better off using a hard encryption algorithm (where "hard" doesn't mean "difficult", but "not bi-directional; not easily reversible".

Ether
  • 53,118
  • 13
  • 86
  • 159
  • 1
    Since all encryption algorithms would eventually have to produce code which can be executed in memory, all they do for "protection" is give the crackers more face when they crack it. **WHEN** they crack it, note, not **if**. – JUST MY correct OPINION Jul 04 '10 at 15:58
7

Isn't this logically impossible?

If you can run the code, you can get the instructions being executed by your CPU. At that point, your algorithm is readable, for some definitions of readable.

Dominic Rodger
  • 97,747
  • 36
  • 197
  • 212
  • It is possible, but only if you can secure the platform to prevent smart people from accessing the code and / or the keys used to decrypt it. TPM tries to do this, but it requires hardware support, OS support, chains of trust, etc. It is simply not an economic proposition for a shareware app. – Stephen C Nov 25 '09 at 23:57
  • 1
    You can't prevent smart people from deciphering the instructions, at some level "smart people" will be able to see the instruction set, if they can see the instruction set they can change it. If they can change it, they can change how it works, such as bypassing the security. – Jason D Nov 26 '09 at 05:04
4

No language is capable of that AFAIK.. since it's impossible as it can always be reverse engineered.. though a good number of developers would cry if you coded it in brainfvck though.

meder omuraliev
  • 183,342
  • 71
  • 393
  • 434
  • 2
    Actually, they wouldn't bother decompiling it, since raw hex machine code is much more readable than a few languages I could name. Actually, if you coded that in a language like Intercal, it would be automatically obfuscated. – David Thornley Nov 25 '09 at 23:00
3

"I'm looking for something that can be only decompiled into assembly."

Try writing your program in assembly. That is the best possible solution.

Noctis Skytower
  • 21,433
  • 16
  • 79
  • 117
  • if you write it in assembler, my experience is that your intentions are easier to understand. compiled code is harder to understand. – X-Ray Nov 28 '09 at 00:36
2

if you really concern about people disassemble your software, make your software as a service (SaaS) http://en.wikipedia.org/wiki/Software_as_a_service

technomage
  • 525
  • 4
  • 14
1

Try finding an obfuscator. As the name suggests it obfuscates the code enough that reverse-engineering it will not be trivial.

Or use C/C++. Those can be disassembled, but that's it.

Of course, this is just enough to keep the not-sufficiently-competents from understanding and reverse-engineering the code.

terminus
  • 13,745
  • 8
  • 34
  • 37
1

As Dominic said, if you can run it, it can be decompiled.

That said, I believe there are tools that obfuscate the compiled code and make it more difficult for someone to disassemble and reverse or take apart a registration process.

For example, I believe that major companies like Adobe and Microsoft use products like this, in order to make it much more difficult for folks to disassemble and crack their programs.

It's like security or cryptography or even the locks on your car/house - someone with enough time and resources can probably break through anything.

You just need to tilt the curve enough to make it sufficiently unattractive for anyone to really try, so that they'd be more likely to move onto easier targets.

Chirael
  • 3,025
  • 4
  • 28
  • 28
  • The difference with my locks is that, if somebody wants to break in, they have to pick my locks (probably not too difficult), and they have to be there. With something like this, it takes one person to figure out what you've done and publish it on the net. Imagine how locks would work if one person, working remotely, could jam every lock in the country so they wouldn't lock. – David Thornley Nov 25 '09 at 22:58
  • True, but that starts getting very philosophical - you could ask why anyone buys MP3s from iTunes when they can just get them for free (the lock has already been broken), etc. As the old saying goes, locks don't really keep thieves out, they keep honest people honest :) – Chirael Nov 25 '09 at 23:01
  • I suspect the only reason people by MP3s from iTunes is that they've been brainwashed into thinking the media distribution war hadn't been won by the open community. "Derrr I guess the music industry owns the Internet.." – PP. Nov 25 '09 at 23:12
1

I am going to make the assumption that because you're writing shareware and you mention a registration algorithm you are wanting to protect your software from a keygen or patch that bypasses the restrictions on your trial versions.

Really the most you can do is deter. Like others have mentioned there are obfuscation techniques available, but they are not preventative. There are commercial software packers available which compress the file and make it initially unreadable. But the program has to be decompressed at some point so the machine can run it, so it's still reversible.

And that is pretty much the crutch against any of the anti-reversing techniques you'll see. It has to be interpreted by the machine at some point. More modern packers use anti-debugging techniques to deter the more novice reversers. But these techniques end up being documented rather quickly on popular reversing sites. Many of the techniques are bypassed with nothing more than a simple debugger plugin.

The only way I can think of to protect your executable from being arbitrarily reversed is to run the whole thing on a server you control and just pipe the output to users. But that's not always feasible.

As far as your language options go, take a loot at this. I can't really speak to how complete it is but I'm sure some others can add languages they think of.

marco0009
  • 163
  • 2
  • 8
1

If you're lookig "for something that can be only decompiled into assembly", that essentially means that you want to use a language that gets compiled (or assembled) directly into a native code executable.

The usual prime suspects then are C, C++, Delphi, VB6. Of course, also assembly meets your criteria, although I doubt you'd want to write any project of decent size in it.

PhiS
  • 4,540
  • 25
  • 35
1

Very simple:

No Programminglanguage,No Programm can Protect your Software. The Software Cracker will reversengine your App till it is just asembler and will crackt it.

streetparade
  • 32,000
  • 37
  • 101
  • 123
0

All code can be read back in assembly. Someone can reverse engineer your application and see what the machine is doing.

Crowe T. Robot
  • 2,045
  • 17
  • 18
0

This is not so much a matter of choosing the right language as it is finding a tool that will do code obfuscation for you. Nothing is bulletproof, but there are efforts to accomplish this sort of thing.

Eg. see this research project about Java code obfuscation.

Parappa
  • 7,566
  • 3
  • 34
  • 38
0

You can't be 100% sure nobody will able to read your code, but you can make it very hard. You can encrypt your code and modify it during run time.

For example I have not heard of any successful attempts to reverse engineering Skype.

Maciek Sawicki
  • 6,717
  • 9
  • 34
  • 48
0

You could always write it in APL. You could deliver the source and still no one would be able to understand it.

Bruce
  • 2,230
  • 18
  • 34
0

Any code running on client-side can be reverse engineered with enough trial and error. In my opinion, make the client-side code contain only the GUI code, while running the actual security requiring authentications etc. on serverside.

On the other hand, if your app's a service which runs on the client-side, such as a game, CAD, POS or anything that needs to have high quality code on the client-side, I'd recommend storing process outputs on your server-side with an encrypted upload tool, then authenticate the client's key/account data every-time before sending their data back? It is an overkill for most projects though.