Script files always visible in bundle resources?

A quick question:

Is there a way to hide the script files in the resources bundle? I know how to make them run-only but can they be “internalized” so they can not be seen (and read in a text editor.) The OBC-C class files are not available so perhaps that can be true for the script files as well?

Thanks, Rob

I’m pretty sure the answer is no.

rob -

There is a way, but it is kind of clunky (i.e. you have to hide it AFTER you build the app). You will need one piece of free ware (though you could also do this from the command line). Here is the freeware:

http://gotoes.org/sales/ChangeFolderVisibilityMacOSX/index.php

Now, go to your app, and choose to show bundle contents. Make an alias to the “Contents” folder, and put the alias somewhere convenient (like your desktop).

Now, launch the freeware application mentioned above. When prompted if you want to change the visibility of a file or folder, select “file.”

Now, navigate to the bundle contents using the shortcut that you put somewhere convenient. Select it, and navigate to the script you want to hide. Once you find it, run the app. The app will run the command line thing, and relaunch Finder. The file in the bundle will be hidden!

They aren’t needed, because they’ve been compiled into executable code.

Yes, I didn’t think there was much chance to have the script files “embedded” but thought I would ask any way. Good point though about setting the hidden bits on the files - though anyone can access a hidden file easily.

If you open one of these non-run scripts in a text editor, the code is visible but mostly not readable. Is it encrypted or just in some raw form - I am totally ignorant about file encoding. How easy is it to convert it to something readable. I Notice that the properties are readable but most looks like it is encrypted.

Thanks all, Rob

If you have proprietary code that you don’t want accessible, I suggest you a write a few small portions of it in Cocoa that ASOC can grab via subclassing or superclassing. Indeed, read-only .scpt files are mostly gibberish in BBEdit, but if you hide a few key lines in a class or method won’t that be enough security? (Who do you suppose will be so diligent as to reverse engineer your ASOC code? It’s a major PITA.) Afterall, if you can code in ASOC you’re so close to writing in Cocoa anyway.

I have down just that, putting my registration codes and some other stuff in a utility OBJ-C class and get them from there. Everything else script-wise can entertain some would-be hacker. thanks, Rob

Rob -

What if you used something like PERL’s crypt in a shell script. For example:

set passwordEnteredByUser to do shell script "perl -e 'crypt(" & ASpasswordEnteredByUser & ",salt)''

Of course, you would encrypt all of your passwords / reg codes / whatever ahead of time using the same method. According to the documentation (http://perldoc.perl.org/functions/crypt.html), it can’t be decoded. Mix this up with changing the visibility flags, and it’s going to be a real pain to get at your codes.

You might also want to look at this blog on using OpenSSL.

Related post: compile ASOC scpt files as Execute only:
http://macscripter.net/viewtopic.php?pid=122574#p122574


Question:
If a script file is encrypted using another method like OpenSSL, how is it de-crypted at runtime?

That’s what I am using for encryption in the app but I didn’t think of it for the reg codes. Thanks Craig et al!

Rob

Excellent Craig. Just the answer I was looking for.

I was not meaning to encode the entire file, just the password.
I have not had a situation where I would use this with AppleScript but the same
technique could be useful when sending email you don’t want anyone to read but
the person with the password.

Disclaimer
I know very little about cryptography so use this example for fun. If you really need
to encrypt sensitive information, do the proper research. :wink:

But, since you asked. Here is a simple example.

AppleScript to encode
save this to a file on your desktop and name it “safari_new_doc.txt”

tell application "Safari"
	make new document at beginning
end tell

AppleScript after encryption

Shell commands to run from the Terminal
The password is included in the code for demonstration purposes only. For a little more security
I would encode the password as well and pass it in at run time.

Hi,

based on jobu’s blowfish encryption routine in Code Exchange I wrote a Cocoa wrapper named SKCrpyt which I use myself in some projects.
You can use a predefined key by just using the init method or a custom key with the

- (id)initWithKey:(NSString *)string

method. The corresponding convenience class methods are

[code]+ (SKCrypt *)standardCrypt

  • (SKCrypt *)cryptWithKey:(NSString *)string[/code]
    The methods

[code]- (NSString *)encrypt:(NSString *)string

  • (NSString *)decrypt:(NSString *)string[/code]
    perform the en-/decryption

You can download the class files here

Very nice! Thanks for sharing. :cool:

Thanks Stefan,

I’ve been using jobu’s version via the applescript but it’s nice to have it in your form.

basically a one liner in applescript…

--inS = string to encode, decode
--inK = key string which can be static or made on the fly
--inM = "e" or "d" for encrypt or decrypt

to pDE(inS, inK, inM)

return do shell script ("echo " & (quoted form of inS) & " | openssl enc -bf -" & inM & " -pass pass:" & (quoted form of inK) & " -salt -a")
	
end pDE

Rob

Didn’t you check Craig’s post? I tried it earlier and it works fine for me. Check the OSACompile checkbox at the bottom of Build Options in the Project Settings. It’s called “Save as Execute-Only”.

Thats’ not what I meant. That makes the scripts non-readable. I was wondering if they could be hidden altogether. As Run-Only they can still be read in any text editor, though not in a form which most folks can decipher. However , all your properties are plainly visible. No big deal - I am putting the “private” stuff in the class files instead.

Rob

Not in a form that any folks can decipher, apart from any strings.

Really? So the run only version is non-reversibly encrypted (or just messed up?) Interesting.