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.
