It thought I was going to be quiet for two weeks, now three posts in a day. There was a good question on Stack Overflow about getting system information. The actual question is “what does system_profiler actually do?” But it’s a good way to show how to begin to understand how any program works on the Mac. Here are some of the most basic tools of the trade. This is not a deep tutorial on reverse engineering. It’s a whirlwind tour of how you begin to attack programs using pretty standard tools. I’m not getting into any of the anti-obfuscation tools like Onyx the Black Cat or commercial tools like IDA Pro, or even code injection like SIMBL or F-ScriptAnywhere. When you think you’re going to hide how your program works, make sure you research those first. You’ll learn quickly how hard that really is. Maybe you should read my thoughts about Obfuscating Cocoa.
Read more…
We recently had a discussion on cocoa-students (the excellent list for Big Nerd Ranch alumni; yet another reason to go to BNR classes) about protecting Cocoa programs from reverse engineering, mostly around some anti-copying code. I had some thoughts on the subject since I happen to have a background in anti-counterfeiting.
Cocoa is a reverse-engineer’s dream. Spend some time at culater before dreaming you can really protect a Cocoa program. Objective-C is meant to be highly readable both in source and at run time. Obfuscation is not in its nature. This only points out Objective-C’s particular difficulties in this area; it is not to suggest C or C++ will save you. They’re just not quite as trivial as Objective-C.
That said, the world of obfuscation falls into three big camps: you can try to deal with 70% of your problem, 75% of your problem or 90% of your problem.
Read more…
It’s been quiet here for a while. I’ve been spending most of my time working on XMPPFramework, an opensource framework that makes it easier to build XMPP clients for Mac and iPhone. I’ve been working on this nonstop for several weeks now in preparation for a demo based on this, so there hasn’t been a lot of time to post here. My code for that demo is done now, and I’m headed off on vacation for two weeks. So you should see more traffic here in July. I have quite a backlog of topics I just haven’t had time to really capture.
If you’re interested in a less edited form of my Cocoa musings, I still answer questions at Stack Overflow (feed), and I’ve started experimenting with Twitter, though I’m not sure yet how much I like tweeting.
See you all in July!
I can’t take credit for finding this myself. Gilad Gurantz forwarded it to me. From the Quartz Event Services documentation:
CGEventTimestamp
Defines the elapsed time in nanoseconds since startup that a Quartz event occurred.
typedef uint64_t CGEventTimestamp;
Discussion
An event timestamp is a big, unsigned, 64-bit number. That’s big, really big. You just won’t believe how vastly, hugely, mind-bogglingly big it is. You may think your application has been running for a long time, but that’s just peanuts to an event timestamp.
So if my math is right, “a long time” translates into over 2850 years. And it’s counted since the last reboot. I think we’ll avoid the Y2K problem on this one.
In Part 1 of our series, you learned how to use basic xcconfig files to manage build configuration in Xcode rather than using the Build Panel. This is useful, but a bit tedious to set up every time you make a new project. What we need is a way to automatically create new projects that have our setup in place already. Wouldn’t it be nice if you could create new Project Templates just like the ones that come with Xcode? You can, and since the release of the iPhone version of Xcode, it’s easier than ever. Let’s make one.
Read more…
For those of you worried about the trouble with PandoraBoy’s hotkeys and Applescript, I’ve finally carved out some time to work on this stuff. I keep getting hung up on the hotkeys preference pane, which can’t be opened in IB3, due to the use of the Shortcut Recorder IB Palette. The answer, I’ve always known, is just to rewrite the hotkey pref pane. It isn’t that hard, I’ve just avoided it, and it’s finally time to do it and fix a few bugs in the process.
Have I mentioned recently that PandoraBoy is an excellent small project to practice and hone your Cocoa skills?
XCode has a decent build system, but it doesn’t work as well as it could out of the box. With just a little work, you can make your projects easier to setup and maintain just the way you want them, improve your code, and even speed up your build times.
The first thing we want to do is get rid of one of the great obfuscations of Xcode: The Build panel.
The build panel seems convenient at first, but in practice it makes it hard to see what’s going on in your build. It especially gets confusing as your build settings get complicated. When you need to turn off Thumb Code Generation because of an obscure assembler conflict in legacy C++ code (true story), it would be nice to put a comment somewhere indicating why you’ve done this so someone doesn’t come along later switch the setting. The Build Panel doesn’t give you an easy way to include comments right along with the setting (the “Comments” panel is pretty useless in my experience), and it’s easy to lose settings or accidentally apply them to only to one configuration.
XCode provides a better solution called xcconfig files. Everything you can do in the build panel can be done in xcconfig files, and you can actually read them and make comments. So let’s make some.
Read more…
Answering a question on Stack Overflow, asking for an explanation of the Application Delegate, how it is accessed and created.
In Cocoa, a delegate is an object that another object defers to on questions of behavior and informs about changes in its state. For instance, a UITableViewDelegate is responsible for answering questions about how the UITableView should behave when selections are made or rows are reordered. It is the object that the UITableView asks when it wants to know how high a particular row should be. In the Model-View-Controller paradigm, delegates are Controllers, and many delegates’ names end in “Controller.”
Read more…
Summary: Beginning iPhone Development: Exploring the iPhone SDK
does not provide the student a strong foundation in Cocoa, but does teach key iPhone-UI topics well. For readers with a prior background in Cocoa, it is likely a good book for transitioning to iPhone, particularly iPhone UI.
Beginning iPhone Development is a pretty good book. It assumes you already have some background in ObjC, which makes it harder for people without any Cocoa experience (the most common place to get ObjC experience). A short ObjC intro would have been useful. Like other books in this space, it doesn’t provide much background in basic Foundation features like Collections and Notifications, nor key patterns like delegation, memory management and naming. As students move beyond trivial projects, they will likely start to have trouble unless they shore up these skills elsewhere.
Read more…
Say you want to talk to another app through Applescript. With 10.5, you can much more easily get there from Cocoa without complex forays into CoreServices, Carbon and AppleEvents. The docs on how to do it are a little thin at times (as all Applescript docs are), so let’s walk through it. The relevant docs you’ll want to read are these:
Learning Applescript
Scripting Bridge Framework Reference
Scripting Bridge Sample Code
And most importantly (and most hidden):
SBSystemPref’s Magical README
And now for a step-by-step example. We’re going to send some mail with an attachment through Mail.app.
Read more…
