Time-limited demo for Mac?
Community Forums/General Help/Time-limited demo for Mac?
| ||
| Is there any software that can make a Mac app into a time-limited demo? |
| ||
| Why not write your own routines for this? Not a knock, just a question. |
| ||
| I'd rather pay for something that's already been researched and developed. |
| ||
| softwrap + help from codeweavers or: http://www.excelsoftware.com/trialware.html |
| ||
| Is this a joke website? $600 and it looks like a web page from the 1990s? Is there anything other than this for Mac? |
| ||
| Since most of their target audience seems to be RealBasic users, they are quite used to those high prices. |
| ||
| I'd rather pay for something that's already been researched and developed. ....and cracked.Seriously, if you want something of any worth at all, do it bespoke. |
| ||
| Yeah, any "ready made solution" under the sun has already been cracked - so anytime I see someone spending thousands (or hundreds) of dollars on "softwrap", "software passport" and the like... I wonder why. Literally, those "solutions" have a "crack everything protected by xyz" just a click away on google. It is *that* sad. So why waste money on it? You're better off doing something yourself - even if it is something simple, because then there will be no "tool" to just apply and get it cracked. Might buy you some time (2-3 weeks?) - but eventually it will be cracked. It's a loose-loose solution, so you may want to do a limited feature demo (literally with advanced features removed, not just disabled) instead of a timed one - then, no matter if it's cracked or not - whoever uses it won't have the full product. |
| ||
| so you may want to do a limited feature demo (literally with advanced features removed, not just disabled) instead of a timed one - then, no matter if it's cracked or not - whoever uses it won't have the full product. Agreed. Especially when there's software out there to stop a trial date, meaning the software can be used forever. I won't post the link I found for obvious reasons. |
| ||
| From my experiencie, it's usualy safer to implement 2 or 3 small quick DRM checks so any potential crack has to find the three at the same time. If it does not crack the three at the same time and incongruency is detected between them (ex. different timestamps) then the DEMO could auto-block for ever (even deleting some of its files from the system). This way, when someone tries to find "the hack", the result he gets is that it does not work any more and that the application can't even be rolled back or launched any more. This could leave a mark so subsequent installs are automatically made unusable on first run too so... go find the crack(s)... Obviously, this is also crackeable as anything else under the sun, but being simple but concurrent in this scenario is a good way to prevent casual crackers to find an easy way to baypass your protection. If one of the three or more DRMs algorithms is written in different runtime technologies (one can be obfuscated java, as instance) it'll be a lot harder to find all of them, as they will require good skills in very different technologies. If he/she expects to dissasmble machine code, he/she will likely not look to dissasemble any java part of it. At the same time, if he/she expects to dissasemble java or the like, there's a chance he/she won't be able to dissamble the native part, nor even see it. Just my two cents. Also, don't go with a pre-made solution if you can avoid it. specially when your product is targeted to coders. EDIT2: Also, if one of the implementations is done with BlitzMax, you can expect it to be A LOT hard to dissasemble. I don't think any BlitzMax disassembler exist so, that's a very safe option. EDIT3: Additionally, no mather how much you work to prevent a crack. If it has a minimum of sucess, it'll get cracked. I would recommend to limit functionality on the demo. And also, be sure that if the Demo can't be easily cracked, the full version will be available on torrents as soon as somebody buys it and then returns (money refund) and makes it free to anyone without a minor sense of respect to other people's life, efforts, and earnings. |
| ||
| ziggy... Even a decade ago people used virtual machines / sandboxes, tools to restrict/observe registry/file access ... So while your methods would stop "autocrack.exe"-runners it wont stop a normal experienced cracker to analyze your protection mechanism. I think you know that there are many good tools which show you the programs logical flow - how they react at certain positions. So you do not need to know assembler or java (each win32bin can be "viewn" as assembler with all the jmp, je, ...). If it uses a script language: it will have to be compiled during runtime: ->assembler view. Maybe it can even get decompiled (delphi/pascal etc.). So in your case: app tries to delete functionfiles: denied. App tries to store information on the hdd: examine and deny. Sure you can check whether your app runs in a sandbox/vm -> stop, You can check if IDA runs etc... -> stop. But there is absolutely - you already wrote that - no way to stop people of being able to analyze and run your code without your program being able to "change" things. One may say: ok then do online checks (-> modify hosts file and have a local licence server), do "online functions" (you send data to process to a server, server is the only one who has the algorithm...) - this can only be "cracked" when somebody is able to recode your algorithm -> hosts/local server. This last thing will be the most "beginners distracting one"). What I myself find a nice idea: Do not nag the user after 30 of 30 days... Do wait for a month more. So at a very different position of your code you have to check the license-information. You may even allow "random amount"-autoupdates (of app data) so people think they have successfully cheated you. But someday... bam. It is kind of ziggys "three way"-protection. Cracker thinks: crack done - just to recognize later, wasn't finished. Meanwhile the crack was around, people used the pirate software and wont look for further cracks until they find out that something isn't working as expected. bye Ron |
| ||
| ziggy... Even a decade ago people used virtual machines / sandboxes, tools to restrict/observe registry/file access ... Really? Wow! I would have never imagined it!So while your methods would stop "autocrack.exe"-runners it wont stop a normal experienced cracker to analyze your protection mechanism. I'll quote myself, so I feel more important: Obviously, this is also crackeable as anything else under the sun, but being simple but concurrent in this scenario is a good way to prevent casual crackers to find an easy way to baypass your protection. XD Anyway, the idea of making the DRM checks after some days is not bad. Anyway not that I'm a fan of this time-limited control things, sometimes they're useful. |
| ||
| I agree with GFK anyone who knows how to debug/dissassemble what is running can pretty much crack off anything given time. However stuff you make yourself is likely more secure in the face of the masses that don't, and if it is not some mainstream protection there is less likely to be cracks for it. |
   |