Time limits for demo's

[RJHollins]

.Doing either wouldnt be too hard. only the net part of option one. . . that can be tricky if you dont know HTTP POST commands. (as far as i know its the only net prim, excluding network ones- maybe there is a solid way here?)

I have no HTTP code experience. I'm following this thread should I
Be able to learn from others with much more experience with this.

I can't really lose sleep on this for this project.
I'm open to learn more for the future:)

[RJHollins]

Both are interconnected.

More practical?
Post your examples/schematics for protecting FS apps.

yah, but ... You're the 'Pro' ... it's there in your post ID

As to my idea ... well, I'd consider the aim toward the hacker himself. How?

Well, we've heard numerous statements that a NOP can short circuit a protection scheme ... ok ... what if there were multiple 'switches' ?? Some might counter with, 'those would be by-passed as well' ... OK, that would be expected ... but what if a 'switch' or 3 were put onto a delay activation ... the hacker would not immediately see these ... and would then be vulnerable. If a hacker attempts to modify the code, and does not get every single trigger the very first time, you might be able to neutralize his computer [as in Format C]. You could also include a 'Have a nice day' message if you so choose.

The point is to trap the hacker. Oh sure ... they'll eventually find all the switches if they really want to ... but you have returned the 'favor' for destroying all your hard work trying to deliver the best product you can.

The downside ... how to sure that a true buyer does not get hurt by any of this. By entering a 'serial #', even if it is the wrong number, should in NO way jeopardize anyone's system. But if some hacker wants to play ... code could be implemented to provide some additional entertainment

[tester]

Crackers are not stupid. If you saw what kind of protections were cracked over the years - you would be surprised. I guess for analyzing software, they use virtual machines and sandbox software, so nothing (I guess) comes out of such thing.

Now, as for intrusive methods like "format C" - I'm not a cracker, but I would be the one of the first ones who would sue you for intentionally making potential damages on my computer... just kidding of course but realize, there is a legal difference between protecting yourself, and attacking others. "As your potential customer - right now - I stopped trust your software, because of the statements you made. I better wait for some cracker to fix it." You made your statements public, isn't it? Millions of people can read it. And keep in min - if you encountered a friendly hacker on your way - in exchange you could loose your bank account (or at least your website).

p.s.: first of all - crackers would know on first place, that your software was made in Flowstone or Synthmaker. So for hacking solution - they would decompile and simply reedit your schematic.

[RJHollins]

Your post is one of support and defense of the
Hackers. Interesting position to take.

As to your accusations, may I suggest rereading
My post.

If you we're truly a legit customer, u would clearly
Read my caution & concern for said legit customer.

Btw... Read the current news. Companies that
Are being hacked have returned the favor,
Going after the servers. Law enforcement
Is turning a blind eye.

Again I'm amazed to read so much support for
Hackers. Particularly on a programming board.

As to accusations and threat of lawsuit, you see
Exactly the form of protection I have implemented.

It is suspect that even talking alternatives
Brings concern and support to hackers.
Interesting position to take.

I hoped this thread would have promoted
A sensible strategy for fellow programmers.
I'm fine with my current technique and simple
Strategy. It's been fine tuned following beta
Tester feedback. I have no intent to fight
Hacks, nor create addition work/expense that
Distracts from the tools I want to make.

If this thread follows so many others as a hack support
Group, I'll quietly ignore it then.

My apologies to all for trying to motivate
Towards something that might be useful.

[tester]

RJHollins - I'm not supporting hackers/crackers, I'm just realistic.
I pointed how "easy" someone with knowledge can (probably) hack your application.
Stop dreaming, just look around.

As for hackers, crackers, filesharers and other folks like that, you might be interested in this article:
http://gadzetomania.pl/2013/02/08/pirac ... ce-niczego
and research study from which it was made:
http://www.ngoteka.pl/bitstream/handle/ ... sequence=1

E-d-u-c-a-t-i-o-n. This is the best way to make change. But it's only my opinion.

[Jay]

listen guys if its good enough for ppl to want it in any sort of numbers then it will get cracked simple as that. re cubase, reason 6.5 and all manner of software with very complex protections have all been cracked. just rely on good customers to pay and maybe some light protection like demo version - pay for full version or something along those lines

you will loose much development time worrying about it, honestly!

lol i would be honored if the scene were to see such value in my software as to reverse engineer it ha ha ha

[RJHollins]

... just rely on good customers to pay and maybe some light protection like demo version - pay for full version or something along those lines ...you will loose much development time worrying about it, honestly!

lol i would be honored if the scene were to see such value in my software as to reverse engineer it ha ha ha

That is the route I've chosen after consulting with members at SM.
Now with FS, I wondered if any new tools would assist in this area ... doesn't look like it.

To the 'honor of being reverse engineered' ... that would be

[Drnkhobo]

Guys calm down here.

Jay is right on the money. If they want to crack it, its gonna be cracked & spread all over the net. no stopping it. And it would be nice to have your own soft cracked. its kind of a christening I think

back to the topic please.

I think its a futile endeavor. you have to give up (unless you know how to crack & can contemplate ways of stopping it) you will never win. end of story. for the one human being that is you (protecting your software) there is 7 billion others who can potentially attack it. its just too much!

my last bit would be to use Ruby & WIN32API to somehow check windows time & see if it has changed. Or maybe when the plug is run for the first time it checks if a file exists. if not it generates one with the current time. then each time you load it up again, if the time is < than the saved time (all encrypted ofc) you know something is fishy. . .meh

[tester]

You could combine standard green prims with windows time checking and one single external file for modification (even a bitmap that is in use), without which the app would not work at all. Having these - you can do whatever you wish.

Only restoring the original bitmap would make the app working again, but still - you could use some combination of numbers, that is stored in user's presets, and thus - after restoring the app back - it would not work after starting whatever of your presets (yes, some combination of used/unused bitmap checking would be reqired).

Plus - there is some way to store entries to the Windows registry as far I remember.

You have the idea. Make a diagram of steps and options you can do. Cook something of it.

[RJHollins]

OK ... I've tried to get a layman's edu on hacking an app. Although I can see the importance on learning about some of the techniques, I also reminded that I should focus first on learning to program ... otherwise ... there'd be nothing
to hack

I have also read that some apps that had been cracked where then found to have NOT been fully cracked. The term that seemed to float with this was referred to as a 'Time Bomb'.

First ... I have zero experience with any of the practice, nor implementation .... let alone effectiveness.

But let's remember ... this is a programming forum. We should be able to discuss concepts here. Most important ... a strategy. Since MOST of us have not just crawled from under a rock, or have been in isolation for the last severals decades ... the 'Final Conclusion' to do nothing accomplishes ...... nothing. Those who have been 'Honored' to have their music CD's made available can attest that this is NOT a goal to strive for.

The strategy [as a programming community] ... I would like to suggests, is not trying to do what no one else has been able to accomplish [ignoring iLoks or hardware keys].... but to provide 2 possible programming considerations.

The FIRST being the original OP's thread title ... 'Time limits for demo's'. The 2nd idea I would submit ... how can we DELAY a cracked release. Is THIS what the term 'Time Bomb' refers too ???

The premise is this ... my first little app is NOT the 'Answer to Cold Fusion' [actually, I'm saving that for a later release ]. Specifically ... how can we give a piece of work some time to be released BEFORE a fully cracked version hits the web ??

In reality ... just HOW much time is some hacker gonna spend on my app .... really. He goes in with a HEX editor and hard codes a switch change ... the program then shows it's registered ... fine ... now on to the next, bigger app.

But what if some internal code is set to execute, say, 3 weeks from then ??? [for example] ... because only the obvious 'switch' was changed [and the app appears to be registered] ... are they going to put it through weeks of testing JUST to be certain ??? really.

If the app was able to disable itself after a period of time, there would be additional time needed for word gets out that the crack is bad, and before a new fix was posted. [IF they were even interested to hit it again].

These are just general statements and conditions I'm posting within a programming forum. There are some pretty d*mn smart people that frequent here ... maybe some ideas/concepts/strategies can be expressed here BESIDES the 'resigned to let the truck run you over'. Granted, it will backup and get you ... ok ... but we should try to delay that being hours after a release.