ScriptingAddition vs Application

Not knowing a fraction of what StefanK knows about cocoa/objc I must say that the word Explorer :smiley: has a good tone in my ears.

By the way, about avoiding Xcode: I am in the business of porting C-Code to OS-X, (old tools). I read a blog over at MacResearch, about how you can use the Organizer. If you just “make projects”, then there is the DDD debugger, which is a graphical interface to GDB, and there is Affinic, which is a free native OS X interface for GDB as well, (but I haven’t used that one extensively.)

I mention this, because there is some overhead of re-organizing existing projects into XCode, but at the same time, source - level debugging can be nice.

By the way, DDD can also debug bash, perl, and a slew of other languages, when set up correctly.

While I am at it, there are two tools for exploring output of shell commands as well: some_command |sed l
and some_command |od -cb
, will show you the output, (control characters, tabs and the like)

I find using vim to be a productive place for editing code as well. me being used to the command-line at all. But, I have full code completion, and I run LLVM from inside vim, and has automagical syntax checking (incremental compilation) while I write. It is not for everybody, just an alternative, that I haven’t really tested with ObjC/Cocoa yet, and I don’t see this as an alternative to XCode, but I think it may help if you are writing more complex classes/much code, it only work on a per file basis. It feels very productive for C and the way C programs are organized. :slight_smile:

Thanks for all the great info everybody! :slight_smile:

gl,

If you already know Cocoa, most of what you need to know can be written in a single page.

You may be right, but let me put it this way: when you come to them from an AS background, Objective-C strikes me as much more comfortable. Maybe it’s something to do with the influence of SmallTalk on both AS and Objective-C’s ancestry.

true, but more In terms of general Cocoa vs Carbon applications. Carbon applications were always a bit more buggy but faster too.

More complicated is to most people more difficult :slight_smile:

A rephrase and a clarification:
The language is simpler, which makes it more complicated to make bigger programs in. ( The original issue was quick and dirty programs.) Well, quick and dirty tools, are made in what we are most familiar with. I don’t resort to C before it proves to be less complicated to realize than in bash, as speed is seldom an issue when it comes to quick and dirty tools. :slight_smile: Having said that, I believe shane’s quick and dirty tools to have a much more compelling interface than mine.

This is quick and dirty in my book: :slight_smile:

[code]/***********************************************************************

Name:    
Created: 05-20-2013
Author:  McUsr

Usage:   
Returns posix path oforiginal item for a file, if it is an alias.
You get a return code, by making osascript crash in an else clause.

DISCLAIMER
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

***********************************************************************/
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#define MAXSTRING 4096
int main( int argc, char *argv[] )
{
char buf[MAXSTRING];
int n= snprintf(buf,MAXSTRING,“osascript -e "tell application \"Finder\" to if kind of (POSIX file \"%s\" as alias) is \"alias\" then return POSIX path of (get original item of item (POSIX file \"%s\" as alias) as alias)" 2>/dev/null”,argv[1],argv[1]);
if ( n < MAXSTRING )
system(buf);
return 0;
}[/code]

I don’t know how you all can learn that stuff. My computer will be obsolete by the time I do that. :o

No, that’s just dirty…

:wink:

:slight_smile: It’s not that difficult. Once you know one compiler language you know them all, when you know some kind of interpreter you know them all and when you know some virtual machine you know similar too. To a pascal programmer it will only take an hour to learn C, after that he’s learning the C libraries. The same works for an C programmer learning pascal. These two languages are basically the same and therefore their principles remains the same, including the developer’s strategy. The same goes for Objective-C, Java and C++ programmers or *PHP, bash and JavaScript. AppleScript is an kind of language on it’s own and is only comparable with it’s predecessors (which I never programmed). What I’m saying is that me or anyone else on this forum didn’t have to learn all these languages like they learned their first language.

*PHP ZendEngine is maybe the most used PHP interpreter at this moment, but more and more it will be replaced with a virtual machine like HHVM.

Too dirty, no C programmer would use code that’s inviting buffer overflows. A shell script would be safer or you have to secure your code. Another proof that C is more difficult than Objective-C.

Yeah DJ Bazzie Wazzie,

First of all, your name is too long. Do you mind if I write DJ. Anyway, I’m not a Pascal guru. :slight_smile: Wish I were.

I was watching the sitcom, “King of Queens” the other night and Doug was saying something like computers were a matter of ones and zeros. So, what can you do with ones and zeros?

No problem at all kel :slight_smile:

nice show :D. When you bundle bits (short for binary digit: one and zero) into groups with an size of 8 you can create number from 0 to 255 which makes your range of numbers a lot bigger. It’s like when you group 4 decimals you change your range from 0 -9 to 0 - 9999. If you put an table on top where every field (255 fields) is binded to a symbol you can write text using 255 different characters :). With an CPU that can do 3 billion cycles per second spread over multiple cores can show a lot of symbols per second on your screen, today even images (videos/animations are images too). The amount of layers in an computer today is huge and I don’t think that 5% of today’s programmers see those lower layers of the OS or even machine level. Doug was right, at the end it still based on the ones and zeros.

What? Where’s Carrie?

:smiley: Now, tell me what havoc a buffer overflow would do in that particular situation, The program consisting of one singlel system call, that performs an osascript, no setuid, or anything. It serves no purpose of doing so intentionally, and since the buffer should be large enough, to hold any filename you can conjure up on OS X, it is hard to so accidentally as well.

( I actually did ponder it, while I went for sprintf, instsead of snprintf. :slight_smile: )

Edit

I firmly believe that no one would create that buffer overflow for any other reason, than wreak havoc, but I still changed it to using snprintf, though I believe someone wanting to do something malignant, would rather replace the whole “command” with something else.

Someone would probably go for something like this, as quick and dirty, and yet safer:

[code]/***********************************************************************
Name: isalis
Created: 05-21-2013
Author: McUsr

Usage:
Returns posix path of original item for file argument to stdout,
and sets exit code to zero, exits with 1 as exit code if it wasn’t an
alias.

Source:
http://jongampark.wordpress.com/2008/12/23/resolving-aliases-using-cocoa/

Command line to compile:
gcc -O3 -I/System/Library/Frameworks/CoreFoundation.framework/Versions/A/Headers/ -o isalis isalis.m -lobjc -framework CoreFoundation -framework Cocoa

DISCLAIMER
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
fileURLWithPath: bruke denne, men encode any blanks first.

Then there is the toll-free bridging,
And I have to return the bookmark data that is a path, as a posix path.

*/

#import <Foundation/Foundation.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <CFNumber.h>
#include <CFURL.h>

static void usage(void) ;
int main (int argc, const char * argv[]) {
UInt8 *buf=NULL ;
char *orig_path;
Boolean notFound=YES;

if (argc < 2) {
	usage() ;
	exit(2) ;
}
size_t slen, max_path = (size_t) pathconf(".",_PC_PATH_MAX) ;
if ((slen=strlen(argv[1])) >= max_path )
	exit(2) ;
orig_path=CFAllocatorAllocate(CFAllocatorGetDefault(), slen+1, 0);
orig_path=strcpy(orig_path,argv[1]) ;

CFStringRef pstr = CFStringCreateWithCStringNoCopy(NULL, orig_path,
									  kCFStringEncodingUTF8,  kCFAllocatorNull);

CFURLRef url = CFURLCreateWithFileSystemPath( kCFAllocatorDefault, 
                                             (CFStringRef)pstr, 
                                             kCFURLPOSIXPathStyle, FALSE);
if (url != NULL) {
	CFBooleanRef isalias=kCFBooleanFalse ;
	CFErrorRef err=noErr ;
	if ( CFURLCopyResourcePropertyForKey ( url,kCFURLIsAliasFileKey , &isalias, &err)) {
		
        if (isalias == kCFBooleanTrue && err == noErr) {
			
			Boolean isStale=NO;
			CFDataRef bkMrk = CFURLCreateBookmarkDataFromFile(kCFAllocatorDefault , url, &err );
			
			CFURLRef resolvedUrl = NULL ; 
			if ( err == noErr ) {
				resolvedUrl =CFURLCreateByResolvingBookmarkData(kCFAllocatorDefault, bkMrk,
									(CFURLBookmarkResolutionOptions)0, NULL, NULL, &isStale, &err) ;	
			}
			CFRelease(bkMrk) ;	
            if (err == noErr && isalias == kCFBooleanTrue && resolvedUrl != NULL ) {
					
				if (isStale == YES )
					goto cleanup ;
				else if (resolvedUrl != NULL) {
					buf = calloc(max_path+1,1) ;	
					Boolean oktrans =CFURLGetFileSystemRepresentation(resolvedUrl, YES, buf,max_path) ;
					
					if (oktrans ) {
						fprintf(stdout,"%s\n",(char *)buf) ;
						notFound=NO;
						free(buf) ;
					} 
                    CFRelease(resolvedUrl);
				}
			}
       		CFRelease(url);
		}
	}
} 

cleanup:
CFRelease(pstr) ;

return notFound;

}

static void usage(void) {
fprintf(stderr,“Usage: isalis [posix/path/to/file]\n”);
fprintf(stderr,“Prints the path of the file to stdout, and exits with zero if the path given was an alias.\n”);
}[/code]
It does take some more time, than figure out the osascript, but it is more satisfiable, and faster too. :slight_smile: (Code originally snagged from a NSFileManager category I found here.)

Last changed 2013-5-24: It should not contain any code deprecated in Mountain Lion.

There you go :)… the problem was putting an argv directly in an formatted string function. Who knows if the given argument is an file path, maybe even by accident. Still, it can mess up any data from machine code to buffered files that needs to written to the disk later. When programming C it is not that you will look at the odds of something like this will happen, you have to make it impossible. Every input into the program needs to be checked in C, Objective-C will all do this for you. You could also have used strlen() function to check the length of argv[1], to be sure it didn’t exceed PATH_MAX (Defined in sys/syslimits.h).

But this is getting off topic again so I leave it that.

This is a quick and dirty tool, nothing more, nothing less.

Even if you managed to make a buffer overflow with the latter, I see hardly any damage that would do.
As for the first one, why bother with a buffer overflow, when hex-edit exists? :

And we are actually dealing with protected memory here, so there isn’t even a shared memory segment to destroy.
At least, if this works as I expect; such a utility would be dropped (killed) the very same (nano) second, it tried to write to a memory page it didn’t own. Please enlighten me, if that isn’t so.

I actually updated it, to check runtime with pathconf.

Now you just need to get rid of that deprecated FSResolveAliasFile…

If in assembly the actual call is made to sprintf that ends with _chk it will be protected against simple buffer overflows because the standard sprintf call is never been made and is substituted at compile time for an more secure one (it doesn’t do that on my machine in Xcode 4). There is also an stack protection like you’re saying but doesn’t kick in when you exceed one or more bytes, you have to exceed more than 16 bytes in i386 architecture and more on 64-bit architecture (also turned off in Xcode 4 by default). It isn’t an watertight solution, it’s only to prevent accidental overflows and reduce the damage to a minimum.

Hello.

It is inconvenient to have a program crash, because of a stray pointer or something, if you overwrite into a heap segment, but the first buffer (buf) was allocated in the bss segment. If memory serves me right, that segment is allocated before the bottom of the stack, (bss first, stack grows upwards towards bss). Dynamically memory are allocated on the heap, on pages, that the program owns. So say you managed a buffer overflow with sprintf, then most probably your program would crash, and that is of course inconvenient. This was a private tool for me, and I hardly see this as something that could be used in a buffer overflow exploit anyway, since its ttl is so short. But I think you are right on a general basis, when it comes to security, to fill the gaps there is. :slight_smile: Things can be exploited in unforeseen ways too.

I also fixed it, because, if you use something to feed it lines from a file, and the file have line endings that is carriage returns instead of newlines, then it is pretty quick, to make the buffer overflows. :slight_smile:

Edit

Constants are placed in the bss segment. Uninitialized variables in the Data segment, so if the datasegment where set to just keep this buf- char array, then It could probably have overwritten the top of the heap?

(I have to sit down and have a look atthe memory-model). :slight_smile:

Anyway, calling pure (Core)Foundation executables is not a proper alternative to “ScriptingAddition vs Application” for extending scriptability