> On 12 Jan 2015, at 03:59, Charles Srstka wrote:
>
> After all, you’re going to want some sort of automatic system for generating
> license codes for your users,
Actually, no. As I said, the licence codes are being generated via FastSpring
(and that's OpenSSL). All I need is a method to val
On 12 Jan 2015, at 10:52, 2551 <2551p...@gmail.com> wrote:
> Given that my licences are being generated with OpenSSL in the FastSpring
> website,
Didn't FastSpring have an SDK that you just drop into your app to validate
their licenses?
> does that mean I HAVE TO use OpenSSL to validate them? I
> On 12 Jan 2015, at 17:52, 2551 <2551p...@gmail.com> wrote:
>
>
>> On 12 Jan 2015, at 03:59, Charles Srstka wrote:
>>
>> After all, you’re going to want some sort of automatic system for generating
>> license codes for your users,
>
> Actually, no. As I said, the licence codes are being ge
> On 12 Jan 2015, at 18:44, Roland King wrote:
>
> Part of the problem, at least for me, is I haven’t figured out yet what you
> actually have that you’re trying to verify. Is it a string, a file
>
Thanks, Roland.
It's a string that looks like this:
DAWFE-F1AU6-6ZBFX-4FWHE-JQN8V-SSSUQ-JY3D
> On 12 Jan 2015, at 18:39, Uli Kusterer wrote:
>
> Didn't FastSpring have an SDK that you just drop into your app to validate
> their licenses?
That's actually what I expected when I signed up, but it doesn't appear to be
the case, unless I've overlooked something somewhere.
My understandi
> On Jan 12, 2015, at 7:51 AM, 2551 <2551p...@gmail.com> wrote:
>
> if anyone here is using FastSpring or similar (eSellerate, Kagi)
I've used eSellerate for many years. They provide a very well-documented API
for generating and validating registration keys in a variety of formats for
purcha
> On 12 Jan 2015, at 20:37, 2551 <2551p...@gmail.com> wrote:
>
>> On 12 Jan 2015, at 18:44, Roland King wrote:
>>
>> Part of the problem, at least for me, is I haven’t figured out yet what you
>> actually have that you’re trying to verify. Is it a string, a file
>>
>
>
> Thanks, Roland.
>
> So my guess would be that you have somewhere on the Fastspring site asked
> them to generate a CocoaFob key.
Correct.
>
> What that string of stuff most likely is is .. some information you have
> supplied, like a user name or serial number or whatever fields you told
> FastSpring you want
> On Jan 12, 2015, at 6:39 AM, Uli Kusterer
> wrote:
>
> On 12 Jan 2015, at 10:52, 2551 <2551p...@gmail.com> wrote:
>> Given that my licences are being generated with OpenSSL in the FastSpring
>> website,
>
> Didn't FastSpring have an SDK that you just drop into your app to validate
> their l
> On 12 Jan 2015, at 20:38, Bill Cheeseman wrote:
>
> I've used eSellerate for many years. They provide a very well-documented API
> for generating and validating registration keys in a variety of formats for
> purchase i
Thanks for that, Bill.
I'm not in any way contractually obliged to st
On Jan 8, 2015, at 7:00 PM, Andrew Keller wrote:
> On Jan 8, 2015, at 6:11 PM, Greg Parker wrote:
>
>> On Jan 8, 2015, at 2:54 PM, Andrew Keller wrote:
>>
>>> On Jan 8, 2015, at 5:20 PM, Ken Thomases wrote:
>>>
On Jan 8, 2015, at 4:03 PM, Andrew Keller wrote:
> I would like
>
> If you use AquaticPrime, unfortunately, it does not generate standard
> signatures. It manually hashes and then encrypts using the private key. This
> sounds like a normal signature, but it is missing some information stored in
> standard PKCS #1 v2.0 signatures. This means that Security.fr
>
> Of course, I could have missed something, and if anyone here is using
> FastSpring or similar (eSellerate, Kagi) and can confirm otherwise, I'd be
> both relieved and grateful to get your advice. I must admit when I started
> this thread, I did so in the hope that someone else on the list
Somebody (Dave Fernandes, apparently) wrote:
>>
>> If you use AquaticPrime, unfortunately, it does not generate standard
>> signatures. It manually hashes and then encrypts using the private key. This
>> sounds like a normal signature, but it is missing some information stored in
>> standard P
> On Jan 12, 2015, at 12:05 PM, Jens Alfke wrote:
>
>
> Somebody (Dave Fernandes, apparently) wrote:
>>>
>>> If you use AquaticPrime, unfortunately, it does not generate standard
>>> signatures. It manually hashes and then encrypts using the private key.
>>> This sounds like a normal signatu
> On Jan 12, 2015, at 11:53 AM, Tamas Nagy wrote:
>
>>
>> If you use AquaticPrime, unfortunately, it does not generate standard
>> signatures. It manually hashes and then encrypts using the private key. This
>> sounds like a normal signature, but it is missing some information stored in
>> s
>> Or you go find documentation on CocoaFob’s file format,
>
> Tried that…
There is no file involved, it’s just a string containing user name and whatever
else you need to verify the license. It is described in CocoaFob README and
there is a small sample available as well.
>
>> which I’m sure
We just implemented a bunch of license code in our upcoming app and we went
with CocoaFob. I updated it a bit as I don’t think its been updated in a bit,
but honestly its not hard. The foundation of the code is good, so it works.
Just my two cents.
> On Jan 12, 2015, at 7:09 AM, Roland King wr
On Jan 12, 2015, at 10:30 AM, Andrew Keller wrote:
> On Jan 8, 2015, at 7:00 PM, Andrew Keller wrote:
>
>> On Jan 8, 2015, at 6:11 PM, Greg Parker wrote:
>>
>>> On Jan 8, 2015, at 2:54 PM, Andrew Keller wrote:
>>>
On Jan 8, 2015, at 5:20 PM, Ken Thomases wrote:
> On Jan 8, 2
Hi
I rolled out my own license scheme so that I don’t have to pay anyone. ;) I
find that coding license checking methods with Cocoa and Objective-C is
terribly unsafe. Objective-C has the nasty habit of exposing classes and their
methods, which you can easily access/find out if you know what yo
I'm still having an issue with this - I think.
I've exhaustively hunted down every leak and memory allocation in my app -
luckily it's a fairly small one, though one that can create many threads - and
have eliminated everything I have control over*
My heap space is still growing over time. I'm
On Monday, January 12, 2015, João Varela wrote:
> Hi
>
> I rolled out my own license scheme so that I don’t have to pay anyone. ;)
> I find that coding license checking methods with Cocoa and Objective-C is
> terribly unsafe. Objective-C has the nasty habit of exposing classes and
> their methods
Did you read the devforums thread I pointed you at a couple of weeks ago? I
noted it was iOS not OSX however my general belief is as time goes by, more and
more code is common to the platforms so if there’s a bug in iOS at 8.x (and
there is) it may also exist on OSX at some recent version. On th
>
> On Jan 12, 2015, at 6:42 PM, João Varela wrote:
>
> Hi
>
> I rolled out my own license scheme so that I don’t have to pay anyone. ;) I
> find that coding license checking methods with Cocoa and Objective-C is
> terribly unsafe. Objective-C has the nasty habit of exposing classes and
> th
> On 13 Jan 2015, at 1:18 pm, Charles Srstka wrote:
>
> Now I just put it in plain C/Obj-C functions, because:
>
> 1. The assembly is always there.
I agree about just using plain code, as the obfuscation is in the source
mostly, not the resulting object code.
But if it's built from macros,
> On 13 Jan 2015, at 12:21 pm, Roland King wrote:
>
> Did you read the devforums thread I pointed you at a couple of weeks ago?
Umm, not sure Roland. I read the blog post by bbum about using Allocations,
which is the one you linked in this thread. Did you mean something else?
Forgive me, I c
https://devforums.apple.com/message/1056669#1056669
No that one from the same mail.
> On 13 Jan 2015, at 10:51, Graham Cox wrote:
>
>
>> On 13 Jan 2015, at 12:21 pm, Roland King wrote:
>>
>> Did you read the devforums thread I pointed you at a couple of weeks ago?
>
>
> Umm, not sure Ro
Thanks - sorry I missed it in the first mail for some reason.
An interesting thread. This remark from Quinn stood out for me:
"If you stop issuing new requests, NSURL{Session,Connection} quickly recovers
this memory to the point where, at the end of a cycle like this, the memory use
(as shown b
This is a fight you cannot win, so don't waste your time. A dedicated
cracker will bypass any protection. I use minimal obfuscation and
asymmetric key generation, and that's it.
Gleb
On 13 January 2015 at 02:32, Graham Cox wrote:
>
> > On 13 Jan 2015, at 1:18 pm, Charles Srstka
> wrote:
> >
>
On Jan 12, 2015, at 8:32 PM, Graham Cox wrote:
>
>
>> On 13 Jan 2015, at 1:18 pm, Charles Srstka wrote:
>>
>> Now I just put it in plain C/Obj-C functions, because:
>>
>> 1. The assembly is always there.
>
>
> I agree about just using plain code, as the obfuscation is in the source
> mostl
> On 13 Jan 2015, at 00:34, Gleb Dolgich wrote:
>
> You can throw it at me as well, what with me being the author of CocoaFob
Gleb, I appreciate your input. I found the no_openssl branch and downloaded it,
but I'm still unsure what to do with it.
On the CocoaFob page it says "There is no fr
> On 13 Jan 2015, at 11:05, 2551 <2551p...@gmail.com> wrote:
> Presumably, I only need the stuff in the objc folder, do I import all of
> those files? And if so, what headers do I import into the class that contains
> my registration view? What method/methods do I connect the "Enter" button and
> On 13 Jan 2015, at 11:23, 2551 <2551p...@gmail.com> wrote:
>
> Is that all I need to do?
I see I need CFobError, too. Is just this stuff going to be enough to get this
to work?
>
> CFobError.h √
> CFobError.m √
>
> CFobLicV
You don't need cocoafob.m as it's test code. CFobLicVerifier.{h|m} and
CFobError.{h|m} should be it as all the necessary decoding in the
no_openssl branch is handled using SecurityFramework. The function
codecheck() in cocoafob.m just shows you how to verify a licence.
Regards,
Gleb
On 13 January
> On 13 Jan 2015, at 11:52, Gleb Dolgich wrote:
>
> You don't need cocoafob.m as it's test code. CFobLicVerifier.{h|m} and
> CFobError.{h|m} should be it as all the necessary decoding in the no_openssl
> branch is handled using SecurityFramework. The function codecheck() in
> cocoafob.m just s
On 1/12/2015 7:30 PM, Gleb Dolgich wrote:
This is a fight you cannot win, so don't waste your time. A dedicated
cracker will bypass any protection. I use minimal obfuscation and
asymmetric key generation, and that's it.
Gleb
I haven't been following this thread closely, but I do wish to respon
> On Jan 12, 2015, at 8:05 PM, 2551 <2551p...@gmail.com> wrote:
>
> On the CocoaFob page it says "There is no framework or a library to link
> against. You include the files you need in your application project directly".
That's pretty inadequate, IMHO (speaking as a library developer.) The pro
> On Jan 12, 2015, at 9:07 PM, pscott wrote:
>
> Experience has taught me that copy protection and license keys almost never
> prevent software piracy, except where the cost of ownership is so low that
> defeating the protection isn't worth the effort. I don't mean to discourage
> anyone, but
> On 13 Jan 2015, at 11:20, Graham Cox wrote:
>
> Thanks - sorry I missed it in the first mail for some reason.
>
> An interesting thread. This remark from Quinn stood out for me:
>
> "If you stop issuing new requests, NSURL{Session,Connection} quickly recovers
> this memory to the point wher
39 matches
Mail list logo
