|
Post by wexhammer on Jan 16, 2020 10:09:34 GMT -5
I don't know whether this is the right space to discuss this topic, perhaps it could be moved to another thread. I have come up with an idea for a solution to evade the possible outcome of a commercial program being cracked or the same serial code for that program be shared with others to access the commercial program for free.
We know we can download specific bytes of information from a website whether it's your own or someone else's. Now with that in mind, we could implement in our code the steps to bypass the pirates.
Ideas are welcome, as my idea might not be possible or might not work as intended.
Structure of the idea or something along the lines.
1. In your program implement a string$ to read a string$ from a specific byte of data on your website,you can store serial codes in the code of your php, html or css script on your web page were your customer has been directed too, to download your program wants they've paid.
2.Once the user has downloaded the program the last thing they want to be doing is waiting around for you to come offline to send them a serial code to activate. So with that being said we need to, once the user fires up the program and clicks register, use some code to extract some data from the invoice your web page automatically produces to match another string$ in your program with an equal statement.
Basic Concept:
Extract data from website, and put it in webstring$
then have that webstring$ copy itself into the programstring$
Get the activation to read if webstring$ = programstring$ with an if statement
Save the string to Kernal as the serial for users to fire up later. That way the serial is hidden.
Pros: Stop thugs.
Cons: The serial cant be used again.
'///
Would love to get your feedback as this may be flawed.
|
|
|
Post by sarossell on Jan 16, 2020 11:14:53 GMT -5
Very often, serial numbers or license codes are not actually saved, but rather a hash of the code is saved and then compared with entered data. Pirates can create keygen apps to produce a matching hash without knowing the actual registration information.
Regardless, pirates can just as easily circumvent all licensing methods by running the program through a monitor/disassembler, finding the section of code that handles checking the registration information, and simply swapping the successful and unsuccessful branch jumps so whatever you enter is automatically accepted as correct.
A third method used less often is to create a script that replaces relevant files in demo versions to make them think they have just be recently installed and have not yet expired.
And one final even more rare option is to take a memory dump of the app and suspend its operation so that every time it is run, it thinks it's the first time.
As for passing data via the Internet, there are two thing to be aware of; 1) Still, to this day, there are people who don't have reliable access to the Internet. And 2) Many folks get bent out of shape if they think any private personal information is being transmitted.
Some solutions that have worked in the past have included hardware dongles that must be attached to the computer for the software to work. However, this is costly and not very convenient.
In the end, the battle with piracy will always be a back and forth fight. No matter what you do to prevent piracy, pirates will eventually find a way around it.
It may help to take a more philosophical perspective. Adobe once claimed that they were losing millions of dollars to software pirates to which a well-known pirate responded that the people who pirate expensive software are not that product's demographic in the first place, If they couldn't get a a pirated copy, they are certainly not going to spend money for it. They'll just do without. The only reason they use is BECAUSE they can get a pirated copy. Businesses and professionals that use expensive applications are able and willing to pay for it because they need to be able to rely on regular updates and tech support. And here's the punchline, many students acquire pirated copies of expensive programs, learn how to use them, and become valuable in the employment market because of it. They go on to work at jobs that use these programs, thereby promoting its overall market share and usefulness. Put simply, so called software "piracy" is a victimless scenario. It's not like video or music piracy where the users are much more easily considered the product's demographic.
Whoops, there's that dang soap box again.
:@)
|
|
|
Post by Carl Gundel on Jan 16, 2020 18:53:59 GMT -5
It may help to take a more philosophical perspective. Adobe once claimed that they were losing millions of dollars to software pirates to which a well-known pirate responded that the people who pirate expensive software are not that product's demographic in the first place, If they couldn't get a a pirated copy, they are certainly not going to spend money for it. They'll just do without. The only reason they use is BECAUSE they can get a pirated copy. Businesses and professionals that use expensive applications are able and willing to pay for it because they need to be able to rely on regular updates and tech support. And here's the punchline, many students acquire pirated copies of expensive programs, learn how to use them, and become valuable in the employment market because of it. They go on to work at jobs that use these programs, thereby promoting its overall market share and usefulness. Put simply, so called software "piracy" is a victimless scenario. It's not like video or music piracy where the users are much more easily considered the product's demographic. There are so many ways to add licensing enforcement. In my experience, don't spend too much energy on this. It is worth a modest effort, but people are going to find a way to crack your scheme. Heck, you can easily download registration keys for Microsoft's products. I'm not saying don't do anything, but it's more important to make your software good, and then promote it, and figure out how to make it easy for people to pay for it.
|
|
|
Post by Chris Iverson on Jan 16, 2020 19:49:31 GMT -5
This is probably the most important step(once you have a good product, that is).
Piracy rates of various media, including software, have dropped quite a bit in recent years, because getting the products legit has gotten easier and easier.
For movies/TV/music, there's tons of online stores and streaming services to have nearly whatever you want at the click of a button or tap of a finger.
After all, it's a pain to dig through and find piracy sites and torrents and take care of all of that carefully, when you could just go to Netflix/Hulu/Amazon/etc and stream a movie, or rent it from an online video site like Google Play for a couple bucks and a couple clicks.
The same has shown true of software, as well. Heck, the example given of Adobe products is one of the best examples: it's really hard to justify pirating Photoshop, doing all the work to find a working pirated copy, and hoping you don't get a virus-laden crack, when you can pay $10/mo and get the latest version straight from Adobe.
Make it easy for people to pay for your product, and they quite often will.
Make the experience of using your app as seamless as possible, as well, especially for paying customers. This is one thing I absolutely believe the video industry has wrong(and audio industry tried and failed to screw up quite a few times): they add mechanisms to "deter piracy" that only wind up being a burden and an inconvenience to paying customers. They're screwing over the last people on Earth they should be touching!
The unskippable "piracy is a crime" warning on DVDs and Blu-rays is the first thing that gets removed from pirated copies. And some 4k Blu-rays have started including non-skippable advertisements! Some even require you to be connected to the internet to download new ads! So you get to be accused of being a pirate, and have to sit and wait through mindless advertising to watch something you paid for!
If the best, most convenient way to use your product is to use a pirated version(in this case, a pirated movie with the ads and accusations removed), then you have failed in your product design.
People are creatures of convenience. If you make it easier and simpler to buy and use your product than to pirate it, more people will wind up buying it just to avoid the hassle.
|
|
|
Post by tenochtitlanuk on Jan 17, 2020 5:25:02 GMT -5
I agree with all that has been said here. I operate in the world of 'free' software- ie you are free to use code and examine it and do not necessarily pay- but payment will give you support and access to upgrades. Hence I use Linux, not MS or Apple, Libre Office, GIMP, etc. Similarly I pay for a Flickr license, although the basic version is free, because it hosts securely 20,000 or so of my photos. And I contribute to Wikipedia ( so useful!) or 38 Degrees pressure-group site. However I too have been interested in ways to protect my intellectual property, hence a number of pages on my LB site. May give you some ideas... RunExpiringTrialsCopy protectionSteganographyAs someone who likes things like secrets amd recursion, my mischievous side also likes things like LB programs that spawn and run new instances, crashing the machine if you do not know the backdoor 'kill', but I don't circulate the code!! I also like self-modifying code- I wish I could self-modify my btain to reverse the ravages of 70+ years!!.
|
|
|
Post by sarossell on Jan 17, 2020 10:52:54 GMT -5
I also like self-modifying code- Is self-modifying code even possible with LB? I'm intrigued.
|
|
|
Post by Chris Iverson on Jan 17, 2020 12:36:30 GMT -5
I also like self-modifying code- Is self-modifying code even possible with LB? I'm intrigued. Not directly, no. While you can use API calls to edit your program's RAM, you'd be interfering with and breaking the structure of the Smalltalk VM that hosts the executing LB program. I suppose it might be possible to modify that on the fly, but no one's really tried. There is a trick that's been used to execute assembly code stored in a string in LB by piggybacking on a specific API call, and I can probably dig that up for you if you want, but I wouldn't call it the same thing as self-modifying LB code.
|
|
|
Post by Carl Gundel on Jan 17, 2020 12:39:28 GMT -5
Is self-modifying code even possible with LB? I'm intrigued. Not directly, no. While you can use API calls to edit your program's RAM, you'd be interfering with and breaking the structure of the Smalltalk VM that hosts the executing LB program. I suppose it might be possible to modify that on the fly, but no one's really tried. There is a trick that's been used to execute assembly code stored in a string in LB by piggybacking on a specific API call, and I can probably dig that up for you if you want, but I wouldn't call it the same thing as self-modifying LB code. In a limited way you can create self modifying code by using the EVAL functions, sort of.
|
|
|
Post by sarossell on Jan 17, 2020 12:58:57 GMT -5
@chris: Thanks for the offer. Sadly, I'd have a better grasp of medieval Russian before I could comprehend assembler.
@carl: I did beat my head against the wall with EVAL/$ for quite a while, and I like the idea, but I fear I have yet to grasp its full potential. Either that, or it simply can't do what I think it should. Regardless, I'm sure the failure is on my part.
|
|
|
Post by tenochtitlanuk on Jan 19, 2020 5:29:43 GMT -5
What I am suggesting and using is a kind of virtualised self-modification. I certainly don't expect to be able to modify machine code which is executing at the deepest level in the processer. However, I've had a number of occasions where I want a variable to change persistently, so next time the new value is used. I know this can be done with save/load a changed configuration file, but it allows an element of secrecy. The code below self-modifies its own source code. If you run it from the LB editor, the little appreciated feature that updates a changed source file on-screen as soon as it changes shows the code changing every time. As detailed in the references I gave, doing the same thing with a modified tkn file makes for quite effective copy protection... nomainwin
open "selfMod.bas" for input as #b l =lof( #b) content$ =input$( #b, l) close #b
version =asc( mid$( content$, l -50, 1)) -64 if version <4 then nv$ =chr$( version +1 +64) else end
content$ =left$( content$, l -51); nv$; mid$( content$, l -49)
open "selfMod.bas" for output as #b #b, content$; close #b
'run "notepad selfMod.bas", SHOWMAXIMIZED notice "Version" +chr$( 13) +str$( version) ' + ' _________________________AAAAAAAAA___________________________________ end
|
|