glebd / cocoafob Goto Github PK

I think there may be a memory leak in CFobLicVerifier when compiled with ARC (I'm running Xcode 7.2.1/ OS X 10.11.3).

@property (retain) __attribute__((NSObject)) SecKeyRef publicKey;

If I take that out, set the publicKey ivar directly and retain it (and release it when I'm done) that seemed to get rid of the leak.

For a reason I do not understand, it is not possible to paste text using cmd + vin these 2 NSTextField

My builds were failing while reporting 'no issues' when compiling in an ARC-enabled project (regardless of the use of the -fno-objc-arc flag for cocoafob-related class files). After a bit of digging, it appears that CFobLicGenerator's generateRegCodeForName:error: method is to blame. It returns an NSString, but attempts to return a boolean under two conditions. It's a fairly quick change to have it return nil instead.

Here's the detailed build log. Hopefully it helps:

/CocoaFob/CFobLicGenerator.m:115:10: error: implicit conversion of 'BOOL' (aka 'signed char') to 'NSString *' is disallowed with ARC
                return NO;
                       ^~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/include/objc/objc.h:51:25: note: expanded from macro 'NO'
#define NO              (BOOL)0
                        ^~~~~~~
/CocoaFob/CFobLicGenerator.m:123:10: error: implicit conversion of 'BOOL' (aka 'signed char') to 'NSString *' is disallowed with ARC
                return NO;
                       ^~

At the moment decoding is still handled by the custom implementation of base32 and base64.

I want to make a CocoaPod from the Swift 3 version. But a license is required for that. I noticed there's nothing but the Copyright notice included in this repo.

What do you think about including the MIT license?

I don't think there are any other macOS APIs that currently support DSA. Time to bring back OpenSSL or is there a smaller third-party library that does DSA?

We develop an app in objective c using Xcode 7.3.

When attempting to export .xliff's using Xcode's built in "Export for Localization" we received this error:

5/5/16 2:11:40.719 PM Xcode[23346]: [MT] DVTAssertions: Warning in /Library/Caches/com.apple.xbs/Sources/IDEFrameworks/IDEFrameworks-10183.3/IDEFoundation/Localization/IDELocalizationWork.m:355 Details: Failed to read strings file "/var/folders/tn/5fw34l7s7f944602lkyhry_w0000gn/T/Xcode3SourceStringsAdaptor-D43C45A7-9F42-439D-BF39-D4CBA29EC0C3/Localizable.strings", underlying error: The data couldn’t be read because it isn’t in the correct format. Object: <Xcode3LocalizedSourceStringsAdaptorTableWorkContext: 0x7f933867e860> Method: -work Thread: <NSThread: 0x7f9382517c60>{number = 1, name = main} Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide.

After further investigation we believe it's related to this macro in CFobError.m:

NSLocalizedStringFromTableInBundle(description, nil, [NSBundle bundleForClass:[CFobLicVerifier class]], nil)

Changing it to this line appears to fix the issue:

[[NSBundle bundleForClass:[CFobLicVerifier class]] localizedStringForKey:description value:@"" table:nil]

Should we be filing a radar or is this something we should adjust in cocoafob?

Weirdly, when I try to use CocoaFob - whether in an App I'm writing myself, or building the cocoafob example in this repository, it always fails with:

ld: framework not found CocoaFob
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I can build the frameworks - no issues there - but when I try to use them it all goes wrong! Xcode 8.2.1

Hi,

I'm testing CocoaFob master branch (can't use no-openssl branch as I need to target 10.6) and have come across a false positive situation in objective-c.

I generated the licence code using the PHP script with the following input:

ProductCode: MyAppAB
Name: mark
email: [email protected]

Which produced the following licence code: GAWQE-F9A2F-TS2DW-ZYSZE-ZSK2N-PL23V-H76X8-G7NVX-A9KB3-8NFYW-L8WFD-3CD72-EYGHM-ZYKLG-BC8ZQ-Q

That, correctly, verifies in PHP and Objective-C. However, changing the final character (from Q to R for example) also verifies in Objective-C, but not PHP. PHP correctly says it's invalid and gives an error about "found non-zero padding in Base32Decode".

The same is true of licence code GAWQE-FBMG4-RB8NU-4642P-T4FZF-5224K-DGSXZ-M7FQC-CUALV-WDN7C-9X8KW-FQG5B-5TQTZ-B8NPR-5D5Y5-Q which was generated from the same input.

Hey there,

Is there a page (wiki, external documentation, etc) that has a somewhat simple step-by-step guide to using CocoaFob? I am having a lot of trouble getting it up and running, and was hoping for something along the lines of what Sparkle provides.

If this documentation exists, where might I find it? If not, I may end up writing something like that, it might be helpful for others too :)

Since Apple is going to deprecate openssl are there any plans on migrating to Common Crypto framework?

Thanks

Once #53 is fixed by adding OpenSSL back, we could look into shipping a Swift Package. It's easy with the current code, but I'd rather wait for #53 -- then we don't have to worry about fixing the SwiftPM build process and wrapping libopenssl.a during the fix.

I presume it's supposed to, with the AppleScript files in the bundle and all.

I think this isn't really a code bug, just a lack of documentation on all the steps required to get it to work. My app certainly does notice a clicked URL that it's registered for when it's already open, it just doesn't get launched when it's closed.

Do you know if there is an alternate way to implement the CFobLicVerifier that is compatible with Snow Leopard? My application is crashing on startup there. It was initially a problem with base32 encoding, with this error shown in the log:
dyld: Symbol not found: _kSecBase32Encoding
I found a workaround to that problem by finding code that decided base32 using different APIs. Now I'm having the same kind of error with _kSecDigestSHA1. I haven't yet found alternate APIs for this step that are Snow Leopard compatible. Do you know of any?

The following link in the documentation is dead http://www.potionfactory.com/potionstore

I'm building for 10.7 SDK on 10.8 if that helps.

SecurityFramework should be used for encoding/decoding and signature verification as OpenSSL functions are deprecated.

While playing around, I noticed that adding extra characters to the end of the registration key still produces a valid return in the swift5 implementation. This is down to how the Security framework by apple handles additional characters during a Base32 decode: They simply get ignored and no error is thrown!

Example: The swift implementation will accept both of these registration keys:

• GAWQE-F9AQP-XJCCL-PAFAX-NU5XX-EUG6W-KLT3H-VTEB9-A9KHJ-8DZ5R-DL74G-TU4BN-7ATPY-3N4XB-V4V27-Q
• GAWQE-F9AQP-XJCCL-PAFAX-NU5XX-EUG6W-KLT3H-VTEB9-A9KHJ-8DZ5R-DL74G-TU4BN-7ATPY-3N4XB-V4V27-Qasdf
• asdfGAWQE-F9AQP-XJCCL-PAFAX-NU5XX-EUG6W-KLT3H-VTEB9-A9KHJ-8DZ5R-DL74G-TU4BN-7ATPY-3N4XB-V4V27-Q

You can reproduce this by adding the following test to the swift5 project in Xcode:

    func testVerifyAdditionalCharactersFail() {
      let verifier = LicenseVerifier(publicKeyPEM: publicKeyPEM)
      XCTAssertNotNil(verifier?.pubKey)
      let name = "Joe Bloggs"
      let regKey = "GAWQE-F9AQP-XJCCL-PAFAX-NU5XX-EUG6W-KLT3H-VTEB9-A9KHJ-8DZ5R-DL74G-TU4BN-7ATPY-3N4XB-V4V27-Qasdf"
      let result = verifier?.verify(regKey, forName: name) ?? false
      XCTAssertFalse(result)
    }

The expected result would be that this is an invalid key, thus asserting the result with a false value. However, this test will fail, because the verification function will return a true!

I also tried this in the Python implementation and that "successfully" failed during the Base32 decode -> All okay.

As I don't know the security framework to well, I added the following code to the LicenceVerifier.swift:

      ...
      let decoder = try getDecoder(keyData)
      let signature = try cfTry(.error) { SecTransformExecute(decoder, $0) }
      
      // reverse the signature to check for truncated data / additional data entered by the user
      let encoder = try getEncoder(signature as! Data)
      let reverseSignature = try cfTry(.error) { SecTransformExecute(encoder, $0) }
      let reverseSignatureString = String(decoding: reverseSignature as! Data, as: UTF8.self).replacingOccurrences(of: "=", with: "")
      if(reverseSignatureString != keyString) { return false }
      
      let verifier = try getVerifier(self.pubKey, signature: signature as! Data, nameData: nameData)
      let result = try cfTry(.error) { SecTransformExecute(verifier, $0) }
      ...

and a bit further down add this function:

  // MARK: - Helper functions
  fileprivate func getEncoder(_ signature: Data) throws -> SecTransform {
    let encoder = try cfTry(.error) { return SecEncodeTransformCreate(kSecBase32Encoding, $0) }
    let _ = try cfTry(.error) { return SecTransformSetAttribute(encoder, kSecTransformInputAttributeName, signature as CFTypeRef, $0) }
    return encoder
  }

I don't think this is the nicest solution, but it works. Does anyone else know this might be fixed with a cleaner method? Seems like a workaround for something that I have missed!

Hello,

I am using your code for licensing my app. Unfortunately it has been cracked teh day of the release. Do you have any tip to make it a little more secure?

Thanks and regards,

Some code changes required to suppress warnings in Swift 3.1

If anyone has an example I would appreciate it.

Is there any chance to use CommonCrypto instead of OpenSSL? I'd really like to get rid of all those deprecation warnings.