Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
BE AWARE! Creating spyware, computer viruses and similar nasties can be illegal where you live and is considered extremely unethical by almost everyone. Still, I need to ask this to raise awareness about how easy it is to create one. I am asking this after the W32/Induc-A was introduced to this world by someone who came up with a nasty way to spread one. So I want to know how a virus can be created so I will be able to recognise them in the future!
Recently a new virus was discovered which spreads itself by replacing the developers' copies of library code. Actually, through the source code of Delphi 4 through 7. What happened is that there's a virus in the wild which searches the computer for a file called SYSCONST.PAS, to which it will add itself as source code. This file happens to be a source file for the runtime libraries of Delphi. (This runtime source code is available for Delphi developers.) As a result, after being infected a programmer would create lots of new versions of this virus without even knowing it. Since virus scanners sometimes generate false positives many developers might thus decide to ignore the warnings of the scanner and maybe they'll even disable their scanner while building their project. To make it worse, their project might even trigger the scanners of their customers so it's likely that those programmers won't check their source code but will just try to fool the scanner somehow. That is, if a virus scanner is even able to recognise the virus, which isn't very likely. Thus, we software developers might be creating viruses without realizing what we're doing!
So, how to create a virus? Simple: get your source code infected by a virus and you're done!
Okay, so the source code of Delphi 4 through 7 might be infected. All Delphi developers, please check your source files! The case is just a proof-of-concept and apparently it can be very successful. Besides, most virus scanners won't check source code but just focus on executables. This virus could stay undetected for quite a while.
This virus also was successful because it misused source code. Delphi is a commercial project and the source code is available. But who is sure that these hackers won't be attacking open-source projects in similar ways? There are lots of open-source projects out there and who is going to check them all making sure they're all behaving in a decent way? And if someone is checking the code, will he be able to recognise if something is malicious code?
So, to make sure we can recognize malicious source code, I have to ask: How do I create a virus? How do I recognise the code that will create a virus? What is it that most malware will want to do?
There is a bit of discussion about the Delphi runtime source code, about this code being open-source or not. Borland uses a dual-license for their source code from the moment when they started to support Linux with Kylix. As a result, the source code has a "GPL" symbol declared which indicates if the libraries are compiled as GPL code or not. As GPL, the source code would be open-source. This also happens to be the source version that was attacked by the virus. Anyway, to avoid discussions here, I've asked this question here so we can focus more on the virus problem and less on Delphi. Basically, we're talking about a virus that attacks source code. Technically, all source code could be at risk but open source code is a likely candidate since hackers know it's structure and can target those files that are rarely modified, thus rarely checked. (And if they can hack their way into a CVS system, they could even erase the traces of their modifications, thus no one might notice the modiifications!)
While this does not really answer your question, I think a really interesting paper to read is Reflections on Trusting Trust by Ken Thompson. It raises a fascinating point that even if your source code is free of defects (viruses, trojans, etc.), you might still be producing defective executables if your compiler is defective. And even if you rebuild the compiler from clean source code, you can still have the same problem.
Unless you're building your computer from the ground up with your own microchips, hand-assembling your own BIOS, writing your own operating system, compiler, and software, you have to draw the line somewhere and trust that the hardware and software upon which you're building your systems are correct.
You could check for the Evil Bit on incoming packets... http://en.wikipedia.org/wiki/Evil_bit
If you want to recognize malware, you must know how it works. This means researching malware and aquirering the skill to produce malware.
search for 29A - they wrote papers on virus
read about rootkits (there are even books on it)
read about reverse engineering
read source code of malware - there's plenty of it in the web.
learn assembler
learn about your OS
reverse the os-kernel
get clam-av, check the source
I won't provide links here. They are easily found though.
If you really want to learn, and are willing to put in the time, your time is probably better spent on google to find then participate in a greyhat community. this topic is highly complex.
if your question is as simple as "what's an easy way to recognize a virus from its source code", well, it probably won't be easy, because there's infinite ways to go about it.
You ask "What is it that most malware will want to do?".
An excellent source for this sort of information is The Hacker Quarterly, which is so mainstream, you may find it at your local bookstore, or you can subscribe online to get it mailed to you.
It was started to help hackers and phreakers share information. It is still very popular with hackers today and is considered by many to be controversial in nature.
Contents of the Current Issue include:
Not The Enemy
Regaining Privacy in a Digital World
The Security-Conscious Uncle
Why the "No-Fly List" is a Fraud
TELECOM INFORMER
Finding Information in the Library of Congress
Hacking the DI-524 Interface
Simple How-to on Wireless and Windows Cracking
If You Can't Stand the Heat, Hack the Computers!
Security: Truth Versus Fiction
Hacking the Beamz
HACKER PERSPECTIVE: Jason Scott
iTunes Stored Credit Card Vulnerability
Zipcar's Information Infrastructure
The How and Why of Hacking the U.N.
Listen to Radio Hackers!
HACKER SPACES - EUROPE
Abusing Metadata
Verizon FIOS Wireless Insecurities
TRANSMISSIONS
Using Network Recon to Solve a Problem
Suing Telemarketers for Fun and Profit
HACKER HAPPENINGS
Plus LETTERS and MARKETPLACE
There is also an excellent series of articles on Hacking at Wikipedia and on Computer Viruses.
... And yes, it is important for programmers to understand how hacking and code breaking works, so they can do the best they can to circumvent it in their programs.
There is no difference between malicious code and an unintentional security bug.
You might as well be asking "How can I write a useful program that has no bugs and is impossible to exploit".
As we all learn in CS its impossible to even write debuggers to catch infinite loops let alone intelligent malevolence.
My advice for security conscious applications is an ex(p|t)ensive code review and use of commercially available static analysis software.
Related
We are distributing a software module for iOS online. Since, Apple is advocating bitcode and even making it mandatory for apps on some devices (watchOS/tvOS) - forcing us to deliver this software module (static library) with bitcode.
The concern is how secure bitcode is from anyone to reverse engineer and decompile (like java bytecode) and how to protect against it? It is easy for anyone to download libraries from the website and extract bitcode (IR) from it and decompile. Some valuable information on it here
https://lowlevelbits.org/bitcode-demystified/
Bitcode maynot be concern for apps as apple will strip it but definitely appears to be a concern for static libraries.
Any insights?
As the link notes "malefactor can obtain your app or library, retrieve the [code] from it and steal your ‘secret algorithm.’" Yep. Totally true.
Also, if you ship non-bitcode libraries, a "malefactor can obtain your app or library, retrieve the [code] from it and steal your ‘secret algorithm.’"
Also, if you ship non-bitcode apps, a "malefactor can obtain your app or library, retrieve the [code] from it and steal your ‘secret algorithm.’"
There is no situation where this is not true. Tools as cheap as Hopper (my tool of choice, but there are also some cheaper solutions) and elaborate as IDA can decompile your functions into passable C code.
If you're working with Cocoa (ObjC or Swift), you have made it even easier to reverse engineer because it's so easy to dynamically introspect Cocoa.
This is not a solvable problem. Both apps and libraries can try to employ obfuscation techniques, but they are complex, fragile, and typically require significant expense or expertise (and often both). In any case, you will need to continually improve your obfuscation as people break it. This is fairly pointless for a library, since there's very little you could re-protect once it leaks, but you can try.
It will leak. That's not solvable. Bitcode doesn't change a whole lot about that. It might be somewhat simpler to read IR than ARM assembly, but not that much, and certainly not if the thing you're protecting is small (like a small algorithm or a key).
There are some obfuscation vendors out there. Product recommendations are off-topic for Stack Overflow (because they attract spam), but search for "ios obfuscation" and you'll find them. In this space, since it's just "tricky hiding" (not security or encryption) you generally get what you pay for. Open source solutions make little sense, since the whole point is to be tricky and hide how you're doing it. I've worked with some open source obfuscation libraries that make it easier to extract secrets from your code (because they're trivial to reverse, and their use marks the parts of the code where you're hiding things).
If this is important to your business plan, then budget for that, and expect it to introduce some challenging bugs, and expect it to be broken anyway (but maybe take longer).
#Rob Napier, you are wrong in comparing orange to apple. Reading assembly code or disassembling with IDA is world apart compared to reading code generated by decompiling intermediate code. Bitcode is totally a nuisance
What should I know about code obfuscation in Delphi?
Should I or shouldn't I do it?
How it is done and is there any good tools (commercial/free) to automate it?
Why would you need to?
As a whole Delphi does not decompile back, unlike .net, so, while decompilation is always a bit of a risk, Ive never found a decompiler that actually did it to a useful way, lots of areas got left as assembler and so on.
If people want to rework your work, they can, no matter what, obfuscation or not, heck, some coders write almost naturally obfuscated code (having worked with a few)
My vote therefore, is shouldnt bother. Unless someone can show me a decompiler for delphi that really works, and produces full sets of compilable, and all delphi where it was originally, I wouldnt worry one drop.
Pythia is a program that can obfuscate binaries (not the source) created with Delphi or C++ Builder. Source code for Pythia is here.
Before:
After:
There's no point obfuscating since the compiler already does that for you.
There is no way to re-create the source code from the binary.
And components can be distributed in a useful way without having to distribute the source code.
So there usually is no (technical) reason for distributing the source code.
You could do other things to reduce an attacker's ability to disable your software activation system, for example, but in a native-compiled system like Delphi, you can't recreate source code from the binaries. Another answer (the accepted one at the moment) says exactly this, and someone else pointed out a helpful tool to obfuscate the RTTI information that people might use to gain some insight into the internals of your software.
You could investigate the following hardening techniques to block modification of your system, if that's what you really want:
Self-modifying code, with gating logic that divides critical functions of your code such as software activation, into various levels of inter-operable checksums, and code damage and repair.
Debug detection. You can detect debuggers being used on your software and attempt to block the software from working in this case.
Encrypt the PE binary data on disk, and decrypt it either at load time, or just in time before it runs, so that critical assembler code can not be so easily reverse engineered back to assembly language.
As others have stated, hackers working on your software do not need to restore the original sources to modify it. They will attempt, if they try it at all, to modify your binaries directly, and will use a detailed and expansive knowledge of assembler language to circumvent things you may wish them not to.
You can use free JCF (Jedi Code Formatter) to obfuscate your source code. However, pascal syntax does not allow strong obfuscation and JCF even doesn't do it's best (well, it's a code formatting tool, not obfuscator!)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I am looking a tool for protect and licensing my commercial software, Ideally must provide an SDK compatible with Delphi 7-2010, support AES encryption, Keys generator and capacity to create trial editions of my application.
I am currently evaluating ICE License. Someone has experience with this software?
Here's my list of software protection solutions. I'm looking at switching from ASProtect to another protection so I'm also in the process of analyzing most of these programs:
Themida (Oreans)
http://www.oreans.com/products.php
There are unpacking tutorials for all the versions of Themida. There is however the possibility of requesting "custom" builds which might help avoid this.
Code Virtualizer (Oreans)
http://www.oreans.com/products.php
Allows to protect specific parts of the application with a Virtual Machine. A cracker on a forum said he "made a CodeUnvirtualizer to fully convert Virtual Opcodes to Assembler Language".
EXECryptor
Very difficult to unpack. GUI does not work under Vista. Appears to no longer be developed.
ASProtect
Small protection overhead. Appears to no longer be developed.
TTProtect - $179 / $259
13 MB download. Chinese developer. Adds about xxx overhead to the exe.
http://www.ttprotect.com/en/index.htm
VMProtect - $159 / $319 (now $199/$399)
http://www.vmprotect.ru/
10 MB download. Russian developer. Seems to be updated frequently. Supports 32 and 64-bit. Uncrackable according with one exetools post, but there seems to be an unpacking tutorial already.
Enigma Protect - $149
http://enigmaprotector.com/en/home.html
7 MB download. Russian developer. Regarded as very difficult to crack. Adds about xxx overhead to the exe.
NoobyProtect - $289
http://www.safengine.com/
10.5 MB download. Chinese developer. Regarded as very difficult to crack. Adds about 1.5 MB overhead to the exe.
ZProtect - $179
http://www.peguard.com
RLPack
http://www.reversinglabs.com/products/RLPack.php
KeyGen already available.
One thing to note is that the more protection options you enable on the software protector, the bigger the possibility of the protected file being flagged by an anti-virus as a false-positive. For example, on Themida, checking the option to encrypt the file, will most likely create a few false-positives by a few anti-virus programs.
I'll update this answer once I get more replies from a hackers forum where I asked some questions about these tools.
And finally, don't use the build-in serial number/license management of these tools. Although they might be more secure than using your own, you will be tied up to that specific tool. If you decide to change software protection in the future, you will also have to manage all the customer keys transfer to a new system.
Don't bother. It's not worth the hassle. Only a perfect licensing system would actually do you any good, and there's no such thing. And in the age of the Internet, if your system isn't perfect, all it takes is for one person anywhere in the world to produce a crack and upload it somewhere, and anyone who wants a free copy of your program can get it. (And using a pre-existing library just gives them a head start on cracking it.)
If you want people to pay for your software instead of just downloading it, the one and only way to do so is to make your software good enough that people are willing to pay money for it. Anyone who tells you otherwise is lying.
I have used OnGuard (using the Delphi 2009/2010 source from SongBeamer) along with Lockbox to handle encryption with success. Both are commercial quality libraries and are free to use with full source.
I did once also use IceLicense, but switched to OnGuard/Lockbox which allowed me greater control over the key generation process which we embedded directly into our CRM system.
Of course there is no %100 bullet-proof protection suite, but having some type of protection is better than having nothing.
I worked with WinLicense in Delphi 2009 and Delphi 2010 on Windows XP and Vista. It is a good product with lots of protection options, and customizations. It provides a SDK for developers, and has nice documentation and samples. It also provides a license manager for you. They provide trial download too.
As far as I remember, they offer some customer specific versions too; that means they are willing to provide a custom-built product which is customized according to your needs, but of course that will cost more.
Since WinLicense is a well-known and popular protection suit, many crackers are after it. As you know, the more famous a tool is, the more appealing it is to crackers. But the good thing about Oreans is that they actively monitor underground forums, and provide frequent updates to their products.
So IMHO, if you are supposed to buy a prebuilt protection suite, then you'd better go for WinLicense.
A little late to the post, but check out Marx Software Security (http://www.cryptotech.com) they have a USB device with RSA & AES on chip, with network based license management.
I bought a license for ICE License in 2007. Unfortunatly (as far as I know) the component haven't been updated since June 2007. Back then a Vista compatible version was in the work but never came out of beta. I don't think they updated the component for Delphi 2009 and 2010 yet.
Ionworx is an one man company which might explain the lack of updates and lack of answer to support questions (emailed them 2-3 times since 2007 and never got back to me). They also removed their support forum from their site.
ICE License is better than nothing but I would stay away from this product because the lack of updates & support.
I investigated this a few years ago, and came to the following conclusions:
All copy protection can be broken
Nag screens on load irritate people to the point where they may stop using the product
Random nag screens can interrupt the users work flow to the point where they perceive it to be a reduction in the speed of the application
Set up compiler options, so that you have a version as a demo (perhaps with save functions removed), reduce multi user versions so that only one client can connect at a time (not using, for ex:
if connection=1 then reject
but reducing the viability for multiple connections in code)
Themida has good protection, and I think it built with Delphi too ;-)
if you have a better budget, you can look at winLicense and other tools from same company.
Have a look at this question which is pretty similar, and includes many of the tools.
Take a look at InstallShield. We've been using it for a while ourselves, and it has a lot of capabilities for trial support, licensing, and others. I don't know about key generation off the top of my head as our use doesn't require keys, but there's a lot available to you from them.
AppProtect wraps an EXE or APP file with computer unique password or Serial Number based online activation. QuickLicense is a more comprehensive tool that support all license types (trial, product, subscription, floating, etc.) and support both a wrapping approach or API to apply the license to any kind of software. Both are available from Excel Software at www.excelsoftware.com.
For example, are they using Java/Struts? Or ASP.NET? Or PHP? Or some combination of technologies?
Not sure how public they are about their infrastructure, but it would be very interesting to know what they use.
Not sure if this is what you are looking for, but see here: http://en.wikipedia.org/wiki/Second_Life#Technology
As is often the case with such questions, High Scalability has an overview of the Second Life architecture, plus links to presentations by SL staff and other resources.
I will take a wild guess, a combination of scripts running on a server written in C++.
While this is an antique question, I'm surprised that no one mentioned OpenSimulator or some other Sim application. OpenSimulator will allow you to run your own Second Life clone on your own hardware and with one of the many SL viewers that are out there, you could just connect to your own virtual world. And this World would be very similar to SecondLife, including it's scripting language!
OpenSimulator is written in C# back in 2007 using the Second Life Protocol to be very identical, although they don't strive for complete compatibility.
The Firestorm Viewer is also open source as Linden Labs once published the source code of their viewer using an LGPL license. But the Firestorm team doesn't make access to the source code easy to find. (It is here!) You will need to know C++ to understand the code.
So, Second Life is made from three parts: Server, client and a special protocol that goes in-between. As Second Life is old, it also uses some older techniques and protocols as developers generally don't fix things that aren't broken. Then again, this question is also old and I'm not even sure if anyone is still interested in Second Life.
Still, if someone is still interested then this gives some nice additional information.
This question already has answers here:
How do you protect your software from illegal distribution? [closed]
(22 answers)
Closed 5 years ago.
I'm developping an application and I'm looking for some cool informations about protecting it against copy ! Do you guys know some book/articles/any informations about it ?
Thanks in advance for your advices !
If your software is good, someone will find a way to copy it no matter what you do.
If your software is no good, nobody will bother to copy it.
Most of my software falls in the second category, so I've never bothered with copy protection. Many believe that this is an endeavor not worth the effort.
Have incentives to not copying it.
For instance, Xbox 360 games, that are easily copied, and executed on modded boxes, now tend to bundle codes in the box that unlocks downloadable content in-game. These codes are of course only available to people actually buying the game.
So your best option is to make it a better deal for the guy that buys your software, than it is for the people copying it.
Having said that, that option might not be possible or easily done, in which case you should avoid giving your paying customers too hard a time. For instance, if you add serial numbers with online activation and limited number of activations before they need to call you or sit waiting for you to answer an email, I can guarantee that this way will hurt more than just ignoring the people that copy your software in the first place.
The worst option you can go for is the one that will make some of your paying customers wish they hadn't.
In addition to Carl's comment I want to add that a rigid copy protection system can make users really annoyed and so a good software becomes a bad software.
Other than that it really depends on the software what to do - can you expect internet connectivity or might the application be running in a data center behind many firewalls? If the net is available an auto-update service is a nice way to track usage - while you should take privacy into consideration then. Otherwise some random serial number process is often good enough: Those who take the effort to bypass it most likely won't buy the software anyways and for others copy and pasting a serial number might be acceptable. But then again: It depends on the software and the users and ...
Punishing the paying users and making it harder to use the software legally than illegally certainly won't work out.