Lazarus
Programming => General => Topic started by: GPcH on May 29, 2017, 02:09:48 pm
-
Hello!
I'm from DotFix Software and we are pleased to release obfuscation for FreePascal / Lazarus compiled files. Starting v6.1, our software protection platform DotFix NiceProtect supports obfuscation for applications developed in FreePascal and already 10 years we supports Delphi obfuscation. More information how it works you can read here:
https://www.niceprotect.com/help/obfuscation.htm
Delphi and FPC compilers is very similar, but have too different internals at binary files. It need additional reasearch, development and testing. We have ask only one question: do it needs to the FPC community? If yes, we can make additional tool, just for obfuscation (with selecting form in binary EXE/OCX/DLL file and other features). I'm so sorry, but we can't make it free or for small price, because development needs a lot of time, but FPC community is not so large.
Thanks for any reply!
-
I find it useless. Just compiling with optimizations (-O2 and up) and stripping all debug and profile information, and apply smartlinking, will make it almost un-decompilable. Not only FPC, but also Delphi. I remember using Delphi decompilers for Delphi 6 and they were unable to decompile any actual code except resources (and you don't need a decompiler to do that).
-
Obfuscators are indeed completely useless for compiled languages. Only useful for marketing and a false sense of protection.
Furthermore I see some that greatly impact performance.
Although I know of at least one esteemed FPC programmer/guru that sometimes uses it, fully aware of the above.
If you want I can re-publish some code from my old obfuscating experiment times..... (way back machine...)
Obfuscation stems from a thorough misunderstanding of how compiled software works. Or that software can not be debugged in-memory and tailored VM's. At some point obfuscators *must* unhide code and that reveals program flow, otherwise the software won't execute. It keeps the script-kiddies at bay to some extend, but not much else.
I don't see the market and if I need it, I will use my own code. O:-) Which relies on simple encryption and compression rather than anything else, apart from linker sections.
Good enough.
-
If you bothered to click the URL that GPCH posted, you'll see that it obfuscates type names in that reappear in streamed component RTTI, which can be used as starting point in reverse engineering attempts.
But it is indeed a lot less needed than with e.g. bytecode languages. Most users won't either need it, and some others will go to different techniques (like we do with whole EXE encryption + hw dongle)
-
I find it useless. Just compiling with optimizations (-O2 and up) and stripping all debug and profile information, and apply smartlinking, will make it almost un-decompilable. Not only FPC, but also Delphi. I remember using Delphi decompilers for Delphi 6 and they were unable to decompile any actual code except resources (and you don't need a decompiler to do that).
Can you upload any FPC exe file, what use forms, classes and GUI part (not pure API or KOL/MCK) and protected against decompilation using compiler options? I will provide screenshots how it can be decompiled using our DE Decompiler. Also you can see this private video: https://www.youtube.com/watch?v=uWGTKOirvJo&t=204s
This is just our internal tool, not a commercial product and can't be downloaded.
-
IMHO it's a misnomer to call it a decompiler, not one statement of Pascal is decompiled.
It walks resources, and recreates form declarations from it, finds the location of the related published methods in RTTI, and then disassembles the published methods.
-
And this kind of "decompiler" (resources decompiled, method headers and class names decompiled and assembler code for e.g. the method bodies and other code) for years, in multiple flavors -including one or two by me - and completely freeware.
It's less than an intermediate programmer task for a programmer that knows Object Pascal, just a bit of assembler and a bit about how resources are stored. And it it Windows only I presume?
If you are trying to market such a think you would look like an absolute beginner. Even windows OS resources are not prevented from view in any way. There a reason for that.
I shall give some tips to do it properly:
- make sure you know the internals of the linker and not the compiler. That's easier to hide code with, changing/merging and splitting linker sections.
- make sure lots of important code is in the resources, and load these resources on the fly from the executable. (google for dll in a resource, load from memory)
- Oh well, create forms on the fly and in code would also help, as does rewriting the system units.
- And self-modifying code is not supposed to work anymore on a modern OS.
All the basic stuff is still here: http://www.delphibasics.info/
That includes both "how to hide" code basics and "how to reveal" code basics.
-
- Oh well, create forms on the fly and in code would also help, as does rewriting the system units.
In the past I've worked with a dummy application that saved the streamed forms to disk. These were then encrypted and added to the main binary. Sometimes a bit finicky, but quite workable.
In the end we chose encrypting dongle, but the main reason to use an obfuscator is that when a customer gives it to a wannabe hacker, that one immediately gives up (because it is off the beaten path). Of course it won't stop the real cracks, but there is something to it.
-
@Marco
I already mentioned that, regarding ..... tongue in cheek. Indeed if software is of such high value that it risks being copied (any software is) then feel free to use a professional solution like a dongle. We even contemplated that in my PerfectView days. We chose a document signature solution for our projects since that also can provide legal proof of infringement. (hidden in and over the code, not like a MS or Apple codesigning solution. We hid the serial in essential parts of the code. all 128 bytes of them in a multi GB total product. Hardly findable without the algorithm)
I don't know if we ever used it, but we used something similar made a collegue before.
Also note I changed my mind about referring to such websites as I link to above. This is actually on-topic: openness is superior in every case.
-
And this kind of "decompiler" (resources decompiled, method headers and class names decompiled and assembler code for e.g. the method bodies and other code) for years, in multiple flavors -including one or two by me - and completely freeware.
We published DE Decompiler at 2007 year and Lite version (without code decompilation) is free. You can download it on some web archives (just google for latest DE Decompiler Lite 2.0 (http://www.google.ru/search?ie=UTF-8&q=DE%20Decompiler%20Lite%202.0)). On our video from my previous post I just shown the decompiler for Delphi x64. Do you know any freeware or commercial decompiler with support of Delphi x64 files? I'm about decompiler with solution explorer (to analyze each class, form, uses of each form, methods and events).
Also you're wrong about the resources. We get only dfm content from the resources. All other parts (units, classes, methods, properties, etc) decompiled from internal structures, not from the resources. Decompiler supports "Uses", "Try ... Except" statements, recovery calls of standard functions of VCL (using assembler signatures for each Delphi version), etc.
PS: My post not about decompilation, but about RTTI obfuscation. Our software protection platform also supports code virtualization (https://www.niceprotect.com/protection_technologies.htm). Virtualization provided on most software protectors. but obfuscation for FreePascal classes at no one.
-
I still don't see your point. That's a basic dictionary lookup. What's difficult about it? (core algorithm)
The only thing you show is that it is -probably - designed with - some - knowledge of - basic- computer science.
Sorry, but I can't get my grumpy mode even in place....
If you would -could - compare Donald Trump in a competition of and with sheer stupidity, Trump wins. We know that. You come very very close to defeating Trump.. :D ;)
[edit]
I will add that obfuscation is easy... So why bother.... It is about revealing obfuscation and that is even easier with your code examples.... Get the point?
1) nice idea (at first sight)
2) been there (way before 2000)
3) done it
4) useless (proof that it does not hold value)
BTW We also have DeDe which is freeware and still works if you upgrade it yourself.... 8-) 8-) 8-) O:-) >:D but that is not the best of breed, although quite cute.
-
@GPcH
In contrast to others, I think you(your team) did a good job. Nevertheless @Ñuño_Martínez, @marcov, @Thaddy has a valid point when they say obfuscation is pretty much useless nowadays. Take a look how easy is to read between the lines, if you know where to look(attached image). Left Ollydbg, right a "dummy" pascal code. With programs like CDA(function hooking), you can find in 5 minutes where the exact equivalent of a button click is in asm(OllyDbg), even if the code is obfuscated. The "dummy" code can be easily patched to show valid password even when you enter an invalid one.
-
@getmem
So that makes two of esteemed FPC programmers :D
At least I trust you and Marco with your code revealing capabilities... 8-)
You just proved my point, btw.. :-X
-
It might be beneficial for TS to have a look at ramblings from people like Fravia.
The tools mentioned so far are just a tip of the ice-berg, there are far better ones. There is also innovation and progress in that field.
As shown by GetMem, using olly is usually enough to get you going.
With regards to dongles, i can only laugh at those. Much annoyance for the user (especially when having multiple software requiring as such) and they don't help a bit. In the end it all boils down to software.
-
RTTI obfuscation is just an addition to the code virtualization, morphing, exe packing, resource protecting, etc. It's just additional layer of protection. For example, DotFix Niceprotect (https://www.niceprotect.com) supports a lot of virtualization and obfuscation features and RTTI obfuscation is just one of theese.
The reason to create this topic is in asking the question: Do anyone needs RTTI obfuscation as additional tool (include command line) to use it with another protection system (not with our DotFix NiceProtect)? Most people already use another protection, but no one protection supports obfuscation for internals (not code) of FreePascal.
Thank you to all for the replies!
-
I still don't see your point. That's a basic dictionary lookup. What's difficult about it? (core algorithm)
Just the understanding of the asm instruction, and then getting some simple loop structures back is quite a bit of work. Just try it yourself.
Personally I like the decompiled code snapshot posted by GPcH a lot, I'll keep it in mind.
-
I still don't see your point. That's a basic dictionary lookup. What's difficult about it? (core algorithm)
Just the understanding of the asm instruction, and then getting some simple loop structures back is quite a bit of work. Just try it yourself.
Personally I like the decompiled code snapshot posted by GPcH a lot, I'll keep it in mind.
I know that. Time. But it is not complicated at all. Look up my old code....
But the presentation looks good... :'( :-[ ;D >:( >:( >:( >:( >:( >:D >:D
BTW half a screenshot is enough for me that it says that you have to run the program. That's not what I explained and naive...
Since when has software a build in hardware timer.... Silly... So you run the piece of sh*t over a software cpu... Basics...
Anyway, I am out.. >:( :D O:-)
-
In general I don't understand this kind of questions. Or for OP: proposals. It is sheer nonsense. It bothers me all day again.
Advice: use your time for something different and brilliant. You can't make a career out of obfuscation, try buying an ostrich suit and stick your head into the ground. Makes more money.
And now I will try to keep myself REALLY out, ok? <halfway grumpy.. >:D>
-
Don't get distracted or disappointed: You are a good programmer. Don't waste your time...Go for something brilliant... works half the time, but not always...trust me... been there done it, have a house and a garden (and some female dogs, cat, daughters and wife...) :'( :-* O:-)
[edit]
This was obviously a reply to something that was removed.
I also do that. sometimes. Mea Culpa...
-
I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code. We have been looking at dotfix's software and I have a question:
Can we use your software to actually encrypt the source code? If the source code is encrypted, then it makes it almost impossible to decompile or disassemble, right?
How can we protect our code with your software above and beyond obsfucation, which I have read is pretty much useless for true protection.
Thank you.
Mike
-
I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code. We have been looking at dotfix's software and I have a question:
Can we use your software to actually encrypt the source code? If the source code is encrypted, then it makes it almost impossible to decompile or disassemble, right?
How can we protect our code with your software above and beyond obsfucation, which I have read is pretty much useless for true protection.
Thank you.
Mike
Source code is not decompiled nor disassembled. Disassembly applies to compile code, not source code.
You can obfuscate source code. That's usually done by replacing descriptive variable names with very cryptic and nonsensical ones as well as totally messing up the formatting of the code. Just so you know, that's simply laughable. It really isn't worth the effort on your part.
As far as making code hard to disassemble, there are what's called "software protectors" that do all kinds of things to make the executable difficult to disassemble properly and difficult to run under a debugger. That will definitely frustrate the amateurs out there but, it will be no great obstacle to an experienced reverse engineer.
Keep in mind too that every time one of these "software protectors" comes up with something new, there is someone out there impatiently waiting for that new thing to appear, for him/her to publish how to defeat it. Prestige is currency there.
Best defense is, make the software really easy to disassemble but, add all kinds of "red herrings" for the cracker to follow. Easy stuff too so the guy gets really bored, you don't want to provide a challenge because it will be accepted and defeated, instead provide boredom, more boredom and boredom ad nauseam. IOW, don't challenge the smarts (you'll lose), challenge the patience! (you do that well, you have a chance - young kids know that!.)
-
I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code.
You could have spent those 5 years to educate yourself instead of asking really stupid questions. (which is fine, I do the same)
to protect the compiled code
Not possible.. Period.
Take the legal track, that usually can achieve some result.
-
I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code.
You could have spent those 5 years to educate yourself instead of asking really stupid questions. (which is fine, I do the same)
Like here, since Karmacomposer never said he spent 5 years on the problem.
to protect the compiled code
Not possible.. Period.
Take the legal track, that usually can achieve some result.
Basic anti piracy controls can strengthen a court case because it needs active circumvention of copyright controls, making an "accidental" defence less likely.
-
If the source code is encrypted, then it makes it almost impossible to decompile or disassemble, right?
How can we protect our code with your software above and beyond obsfucation, which I have read is pretty much useless for true protection.
At first, no. Sourcecode encryption is not helping....
But:
Due to RTTI some of your identifiers actually end up in the exe (e.g. TForm). A decompiler that knows the fpc RTTI format, will be able to use that. So replacing all identifiers with nonsense names => may help.
Also a decompiler might (not sure what is on the market) recognize code from the RTL or LCL (even in its compiled form).
Splitting functions, inserting other code,.... All that may help.
Actually an obfuscater that rewrites the code, spilts subroutines, inserts none-sense code, inlines some code, yet calls other,.... That may make it a little harder to decompile.
-
Machine code can be translated into Assembly code (disassembler), from there you can create high level pseudo code (decompilers). Probably the most famous one is Hex-Rays in IDA Pro. Other notables are Snowman (think its also in Ghidra and an option for IDA Pro), Reko, and RetDec. The quality of the pseudo code (in pseudo C) is the subject of lots of debate, but it can give an idea of how the original source code works. We have to also keep in mind that such tools are slowly improving. How useful this "kind of useful" information is, most likely depends on how much an expert the person is.
In regards to Object Pascal, the decompilers that I've seen on the web were mainly targeting Delphi. Revendepro, DeDe, etc... They all look old. Haven't seen anything specifically for FPC, though clearly if a concerted effort was made, it could be done. Probably the most obvious thing that shows up with FPC, with something simple like Resource Hacker or similar are .lfm (TForm) data. Then the next common thing is "string hunting". You could use the well known decompilers on FPC executables, but then how useful psuedo C code is going to be in comparison to the actual source is doubtful. Then add various optimizations into the mix, yet more doubtful.
Usually obfuscation is necessary for the scripting and interpreted languages, like JavaScript or C#. Compiled languages are a higher step in difficulty. There are people that are really good at reading Assembly (disassembler output). It's just that its troublesome for most, so the numbers of programmers interested in and good at reading it are few. Regular people, users, and customers are not about that life, which is the realm of those into cracking, criminals, professionals, or security. Those that are hardcore into cracking, will usually not be customers and nearly nothing will deter them because they are getting off on the challenge. If any deterrent can work on those types, it's likely the legal route, like notifying ISPs, suing over copyright and trademark violations, etc...
-
Actually an obfuscater that rewrites the code, spilts subroutines, inserts none-sense code, inlines some code, yet calls other,.... That may make it a little harder to decompile.
There are YouTube videos of high-level programmers ripping into Metasploit defensive measures like obfuscation and anti-debugger (code for the specific purpose of having its payload undisturbed). "Tricky code" could slow people down, but clearly those about that life are going to figure it out with enough time. Average folk don't even know about such things, so it's definitely going to be a select percentage even trying.
-
Actually an obfuscater that rewrites the code, spilts subroutines, inserts none-sense code, inlines some code, yet calls other,.... That may make it a little harder to decompile.
There are YouTube videos of high-level programmers ripping into Metasploit defensive measures like obfuscation and anti-debugger (code for the specific purpose of having its payload undisturbed). "Tricky code" could slow people down, but clearly those about that life are going to figure it out with enough time. Average folk don't even know about such things, so it's definitely going to be a select percentage even trying.
Hence, I said: "make it a little harder". And I did not say "might stop" or anything alike.
-
Obfuscation is usually needed for scripts only. And not only to protect it from "decompiling", but also to reduce code size and make interpretation faster. For compilers it's better to use some binary manipulation.
-
You can obfuscate source code. That's usually done by replacing descriptive variable names with very cryptic and nonsensical ones as well as totally messing up the formatting of the code. Just so you know, that's simply laughable. It really isn't worth the effort on your part.
I'm winding back and commenting here since plenty of others will point out that "security by obscurity" is never a good idea, and that if you want to keep your code fully-protected the only thing you can do is keep it on systems under your full physical control... and then pray incessantly that you won't be hit by a zero-day. However, on the topic of obfuscators:
Tools that produce "shrouded C" etc. typically do much more than remove formatting and replace symbolic names: they also replace control structures by jumps and gotos and so on. They can be moderately effective against casual perusal by an application-level programmer, but confer no protection at all against a determined (and expensive) professional.
But obfuscating the source should still result in the same- or at least a very similar- executable being emitted, so is of no practical use if a product is being shipped as binaries: avoiding RTTI and making sure that debugging info is stripped is far more important.
The only real area in which an obfuscator might be relevant is if somebody is using GPL-licensed libraries, and is of a mind to protect his own code which, as everybody now knows, similarly becomes GPLed on release of the binary. I have to caution that the legality of doing that has not, to the best of my knowledge, been tested in court, and the attempt would risk getting an extreme amount of media and possibly legal attention.
MarkMLl
-
I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code.
If you are referring to software protection, then you might want to check out some of these links:
https://forum.lazarus.freepascal.org/index.php/topic,38960.0.html
http://forum.lazarus.freepascal.org/index.php/topic,13000.msg67843.html#msg67843
https://wiki.freepascal.org/OnGuard
For simple windows executable obfuscation tool, search the net:
https://duckduckgo.com/?q=windows+executable+obfuscation+tool&ia=web
There is no perfect tool for either. Whatever you use, it will just lower the percentage of people who are able to decode your code and data, but that percentage will never be zero. When there is a will, there is a way...
-
Can we use your software to actually encrypt the source code? If the source code is encrypted, then it makes it almost impossible to decompile or disassemble, right?
In addition to what the others wrote: your code needs to be decrypted to be able to run. And that's when the attacker got you (or more precisely your code). Even if you use asymmetric encryption there will be the decryption key stored in your binary and the attacker can change that to use their own. Or they can patch your decryption code so that it works with unencrypted code as well and you're back to square one.
I'd go a route similar to 440bx: add things that bores the attackers. They have better things to do, other software to crack.
-
...plenty of others will point out that "security by obscurity" is never a good idea,
I'm sure you can tell, I definitely agree with that.
Tools that produce "shrouded C" etc. typically do much more than remove formatting and replace symbolic names: they also replace control structures by jumps and gotos and so on. They can be moderately effective against casual perusal by an application-level programmer, but confer no protection at all against a determined (and expensive) professional.
The reality is, it is quite unusual to run into a piece of code that has algorithms so novel and sophisticated that they merit the trouble. Usually, code that is really that sophisticated is protected mostly, if not completely, by legal means.
When I see posts about protecting software, it reminds me that I've personally used pirated copies of software I legally purchased and, the reason is, the pirated copy had been "cleansed" of annoyances that paying customers had to put up with. I'm naturally reluctant to update/upgrade software because, aside from a whole new set of bugs, comes the uncertainty of what new annoyances are in the new version (I hate upgrading Windows... takes days to clean up the mess MS hands you and... they expect you to pay them to clean the mess they handed you ... gotta love it!)
The other thing that I always remember is that large companies like Adobe and Autodesk among many others have spent significant amounts of money attempting to protect their software and, all they've managed to accomplish is to provide entertainment for those who enjoy unraveling binary puzzles.
I can understand putting some simple, easy to defeat, protections to prevent "joe user" from passing copies around. Joe user doesn't even know what a debugger is, for that guy, something trivial will be as effective as whatever the latest "protection" technology offers (and quite often a whole lot less hassle for the paying customer which means no loss of good will.)
-
I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code. We have been looking at dotfix's software and I have a question:
Can we use your software to actually encrypt the source code? If the source code is encrypted, then it makes it almost impossible to decompile or disassemble, right?
DotFix NiceProtect works with compiled EXE/DLL/OCX files, not with source code. At this time, latest version supports RTTI obfuscation for Lazarus/Freepascal 32 and 64 bits. More information about RTTI obfuscation you can read at my article here: https://www.dotfixsoft.com/niceprotect_62.htm
-
I read about Obfuscator here: https://www.niceprotect.com/help/obfuscation.htm (https://www.niceprotect.com/help/obfuscation.htm)
I think it's important for applications need high security like big companies projects, but maybe small businesses projects don't need it much.
-
I read about Obfuscator here: https://www.niceprotect.com/help/obfuscation.htm (https://www.niceprotect.com/help/obfuscation.htm)
I think it's important for applications need high security like big companies projects, but maybe small businesses projects don't need it much.
That is what I referred to as "RTTI" in one of my earlier posts.
It may for some of the hackers add some time they need to spent. But it wont deter or fail them in getting what they want.
Other hackers may not even try to use the info, because you could have intentionally misnamed it, to lead the astray. For those it does not matter at all.
Of course you do not want your "Enter personal license token" name "EditLicenseToken", with an "OnEditLicenseTokenExit" method attached to it. That would be a give a way.
-
I read about Obfuscator here: https://www.niceprotect.com/help/obfuscation.htm (https://www.niceprotect.com/help/obfuscation.htm)
I think it's important for applications need high security like big companies projects, but maybe small businesses projects don't need it much.
That is what I referred to as "RTTI" in one of my earlier posts.
It may for some of the hackers add some time they need to spent. But it wont deter or fail them in getting what they want.
Other hackers may not even try to use the info, because you could have intentionally misnamed it, to lead the astray. For those it does not matter at all.
Of course you do not want your "Enter personal license token" name "EditLicenseToken", with an "OnEditLicenseTokenExit" method attached to it. That would be a give a way.
Interesting to know that some hackers don't need the use of the info.
-
Microsoft, Adobe, Symantec, Autodesk are big software companies. They have both the money and manpower to implement high secure copy protection but they all fail. It is very easy to get the cracked version of their software, if you know how.
Programmers can make their software harder to be hacked but so far none is hack-proof.
Autodesk AutoCAD is so expensive, lots of user use the cracked version for free. LibreCAD is free, many users donate some money to support it including me.
-
There was a text editor called pe.exe that I encountered years ago and if I remember correctly, it works in the Dos environment.
It would warn the user and close itself when the program was infected or the program was intervened in the binary editor.
In a way, it protected itself. It was a very interesting practice back then.
I didn't understand much at the time, but now, I guess, he was checking the md5 values of his executable code segments
-
Maybe making another versions of an expensive software product with low prices or free and less than the original software in its abilities can solve a part of the problem. Users those don't need all the huge abilities of a software but they need some basics of it, they can buy the lower price version of the advanced version, so they don't need the cracked ones.
-
I think it's important for applications need high security like big companies projects, but maybe small businesses projects don't need it much.
Small companies need it more because one lost sale is usually a bigger chunk out of the annual turnover.
Projects are often done break-even or even at a loss (e.g. due to tender costs and underbidding), and the sale of copies is what brings in the first sound profit, sometimes years after the initial work.
-
I see no solution @marcov. Companies make attractive special software products with high prices, they attract users of world to use their products. If the company is small, it will be hurt for small loss, if the company is big, it can't accept its money to be stolen by hacking its products, look, maybe as I told before, the solution is making lower traditional versions of the softawre with advanced futures with low prices.
-
Всем привет!
Может это кому-то и будет полезно... но я не уверен. Но люди разные.
Занимаясь программированием уже достаточно давно, я считаю, мне (иногда) проще прочитать ассемблерный код, чем даже ковыряться в открытых исходниках какой-то программы (допустим на C++).
Лично я не вижу ни чего, что стоило бы внимания, для взлома. (меня интересует разработка) Большая часть информации уже в открытом доступе. Я не совсем понимаю, что вы сможете скрыть, чтоб я не смог этого повторить. Мне достаточно увидеть как работает программа. И, если это того будет стоить, можно сделать и аналог и лучше.
А запутать код... ну да, уже писалось, проще сделать так, чтоб утомить человека поиском. Но если б я занимался взломом, то у меня бы были все наработки, для уменьшения времени взлома.
Создавайте лучше что-нибудь полезное для пользователя!
google translate: Hello everyone!
Maybe it will be useful for someone ... but I'm not sure. But people are different.
Having been programming for a long time, I think it's (sometimes) easier for me to read assembly code than even poking around in the open source code of some program (let's say in C ++).
Personally, I don't see anything worth looking into to hack. (I'm interested in development) Most of the information is already in the public domain. I don't quite understand what you can hide so that I cannot repeat it. It's enough for me to see how the program works. And, if it's worth it, you can make an analog and better.
And to confuse the code ... well, yes, it has already been written, it is easier to do so as to tire a person with a search. But if I was engaged in hacking, then I would have all the best practices to reduce the time of hacking.
Better create something useful for the user! :)
-
I see no solution @marcov.
The solution is to do at least some minimal work against reverse engineering, and licensing. (keys etc).
The balance (and the risks to the bottom line)(will be different for each company and business.
At some point we had a product that upgraded an older machine, which was a reengineered solution that allowed more modern (and thus cheaper replacement costs) equipment. Iow it was always a netto financial gain for the purchaser long term, so it was not price elastic at all.
The abuse was simply copying the new solution on an older machine if it broke down and needed new parts. And then it was "forgotten" to obtain a license, because going through the purchasing department and IT for it was considered a hassle. In some companies (and countries) there is simply no culture (checks and balances, a bosses, foremen that regularly audit such things) against such behaviour.
Then it is your job to protect your employer's business to at least not to make it too easy.
Companies make attractive special software products with high prices, they attract users of world to use their products. If the company is small, it will be hurt for small loss, if the company is big, it can't accept its money to be stolen by hacking its products, look, maybe as I told before, the solution is making lower traditional versions of the softawre with advanced futures with low prices.
I think this rarely applies, I seriously doubt it is just about price, that is a gross oversimplification.
Even if it is just about price, where is the magic border, and what actually makes people more honest when it is cheaper. Because whatever your price is, pirated full featured software is still cheaper.
-
Having been programming for a long time, I think it's (sometimes) easier for me to read assembly code than even poking around in the open source code of some program (let's say in C ++).
At DOS era, C++, Pascal and assembly were popular programming languages. I see that you prefer assembly more than C++, I don't know if C++, assembly and BASIC maybe the popular languages in Russia?
You seem expert in programming, but not all people are programmer and they can't do the same.
-
@marcov, you have good analyzing.
-
At DOS era, C++, Pascal and assembly were popular programming languages. I see that you prefer assembly more than C++, I don't know if C++, assembly and BASIC maybe the popular languages in Russia?
You seem expert in programming, but not all people are programmer and they can't do the same.
Нет, я не считаю себя экспертом. Мне ещё учиться и учиться. :-[
Многие языки программирования (как и везде) уходят с пика популярности. Но C/C++ достаточно популярен, чтобы его можно было использовать. Упоминания о Basic мне давно не попадались. Ассемблер - это основа, и кто хочет понять, тот должен (на мой взгляд) это знать.
Паскаль стоит особняком. Его просто не забывают, и многие не забывают поливать его грязью.
google translate: No, I don't consider myself an expert. I still have to study and study. :-[
Many programming languages (as elsewhere) are leaving their peak of popularity. But C/C++ is popular enough to be used. I haven't come across any mention of Basic for a long time. Assembler is the foundation, and whoever wants to understand should (in my opinion) know it.
Pascal stands alone. He is simply not forgotten, and many do not forget to throw mud at him.
-
Pascal stands alone. He is simply not forgotten, and many do not forget to throw mud at him.
Thanks!
Lazarus freePascal is good version of this language.
-
Personally, I don't see anything worth looking into to hack. (I'm interested in development) Most of the information is already in the public domain. I don't quite understand what you can hide so that I cannot repeat it. It's enough for me to see how the program works. And, if it's worth it, you can make an analog and better.
This is a very valid point. A high level programmer can just need to see or interact with the software, in order to get ideas of how to create something similar. It's a matter of if such people aren't already busy or interested in something else.
Another point, which seems to have gotten obscured, is that those into cracking are not necessarily interested in the source. As far as source, that is more about scripting and interpreted languages, as opposed to being a significant threat to compiled languages. If they can get the source (because of what the program was written in), of course it would be a party for them, but that's not necessarily the main or easy objective. They are more often interested in circumventing the security of the program to allow for illegal usage. Which is often patching or altering the program. Assembly language and tools to exploit vulnerabilities are where they are at. When it comes to a vulnerability, that's quite unpredictable, no matter the defense or protection. As mentioned, nothing is hacker-proof. More of a matter of slowing people down, and relying on that the vast majority are not so obsessed (to include groups dedicated to such a purpose) to spend massive amounts of time trying to crack it. Legal ramifications are probably the greater deterrent than the technical. Of course, at least having your door locked, is better than it being wide open. But it doesn't mean a burglary can't happen, despite the lock.
-
At DOS era, C++, Pascal and assembly were popular programming languages. I see that you prefer assembly more than C++, I don't know if C++, assembly and BASIC maybe the popular languages in Russia?
You seem expert in programming, but not all people are programmer and they can't do the same.
Нет, я не считаю себя экспертом. Мне ещё учиться и учиться. :-[
Многие языки программирования (как и везде) уходят с пика популярности. Но C/C++ достаточно популярен, чтобы его можно было использовать. Упоминания о Basic мне давно не попадались. Ассемблер - это основа, и кто хочет понять, тот должен (на мой взгляд) это знать.
Паскаль стоит особняком. Его просто не забывают, и многие не забывают поливать его грязью.
Many programming languages (as elsewhere) are leaving their peak of popularity. But C/C++ is popular enough to be used. I haven't come across any mention of Basic for a long time. Assembler is the foundation, and whoever wants to understand should (in my opinion) know it.
I think "Java" can be used instead of BASIC in the trinity I imagined in Russia of the most popular basic languages, so I imagine it like this "C++, assembly and Java". I didn't see an alternative for assembly to be used popularly in Russia :)