Category: OSX

A good way to share a functionality across teams or companies is to share it via packaging through libraries, where the code is invisible and the team requiring it can integrate it seamlessly with the code they are working on. iOS allows the usage of static libraries via “.a” files which can be statically loaded at compile time. Runtime usage of libraries(dynamically, “.so” files) is not allowed for user apps. Some general information about these archives and their usage is mentioned below:

• iOS Simulator and an iOS device have different architectures i.e i386 and armv7s respectively. This means it is necessary to test the final library (".a") file on a real device.

• It is possible to compile a i386 based lib via command line on the terminal on a Mac OS X system. However, it is not the same for if you are building for armv7s architecture. In case of armv7s (iOS device), XCode needs to be used.

Below mentioned are the steps to create a library that can be statically linked to iOS code on a device:

• Fire up XCode and choose a new project template type under OS X→Frameworks and Libraries→C/C++ Libraries.


• Name the project and choose type as “Static”.
• Import or just drag and drop .c and .h files into the project.
• Click on “Build Settings” for the project. “Base SDK” should be Latest iOS(7.0) and “Architectures” should be Standard(armv6, armv7).


• Check the “Build Phases” in targets. Add or move the header files to “Public”.
• Select the appropriate scheme and build (Make sure you have a connected iOS device which can be selected as a scheme).


• Go to Product→Archive→Distribute→Save to save the end product which will be a folder containing the headers and the .a file.

Below mentioned are the steps to create a library that can be statically linked to iOS code that will run ONLY on the simulator. Although this is redundant but is helpful if you just want a quick lib integration/usage check:

• Fire up the terminal on OS X and fire the two commands one after another.
• gcc -Wall -c -arch i386 -arch x86_64 *.c
• ar -cvq libXXYYYZZZ.a *.o

Mac Musings- Pulling ‘strings’

‘strings’ is a very powerful good little devil, present in every unix like OS. Its primary job is to hunt down and print text strings embedded in binary strings such as executables. Like every other tool, it is very useful for both hackers and crackers. Pentesters specifically can use this tool to identify vulnerabilities(read static passwords/pass phrases and usernames) during black-box testing of apps.

Usage of ‘strings’ on mac is extremely simple and just requires firing up the terminal and typing in: strings filename

The output is a list of strings present in the binary(if any). So, Coders using static passwords, please beware!

Common usage includes piping it to grep and fold or redirecting the output to a file.


So the thing was, I was tying to setup the adb path on my mac and finally done, I decided to write a little tutorial so that anybody and everybody can simply go through the following instructs and just breeze through it:

  • Fire up the terminal on the mac.
  • Browse to the root directory and create a file named .bash_profile, using the command “touch .bash_profile“.
  • Using the command above can be a little tricky as the user might not have the permissions to create the file under the root directory, so as a solution to that we will use the “sudo chown username file/dirname“, to temporarily change the permissions for a given directory/file.
  • Next, type “open -e .bash_profile” to open it in TextEdit.
  • A TextEdit window will open, copy and past this into that window, export PATH=$PATH:/yoursdkfolderfull path/sdk/platform-tools
  • Save the changes and close text edit.
  • Restart terminal, while in the root directory, type: source .bash_profile
  • ADB should be setup now, check by firing the adb command on the terminal.
  • And Thats pretty much it.