To what extent Dynamic lib can be decoded or decompressed? - ios - ios

Question

I'm developing a dynamic library for an iOS application(not for apple store). Given an IPA, to what extent my dynamic library can be decompressed by hacker/user? can my method definitions in dynamic library read while decompressing? Thanks in advance.

Answer 1

From man dyldinfo:
dyldinfo(1) BSD General Commands Manual dyldinfo(1)
NAME
dyldinfo -- Displays information used by dyld in an executable
SYNOPSIS
dyldinfo [-arch arch-name] [-dylibs] [-rebase] [-bind] [-weak_bind] [-lazy_bind] [-export] [-opcodes]
[-function_starts] file(s)
DESCRIPTION
Executables built for Mac OS X 10.6 and later have a new format for the information in the __LINKEDIT
segment. The dyldinfo tool will display that information.
The options are as follows:
-arch arch
Only display the specified architecture. Other architectures in a universal image are ignored.
-dylibs
Display the table of dylibs on which this image depends.
-rebase
Display the table of rebasing information. Rebasing is what dyld does when an image is not
loaded at its preferred address. Typically, this involves updating pointers in the __DATA seg-
ment which point within the image.
-bind Display the table of binding information. These are the symbolic fix ups that dyld must do
when an image is loaded.
-weak_bind
Display the table of weak binding information. Typically, only C++ progams will have any weak
binding. These are symbols which dyld must unique accross all images.
-lazy_bind
Display the table of lazy binding information. These are symbols which dyld delays binding
until they are first used. Lazy binding is automatically used for all function calls to func-
tions in some external dylib.
-export
Display the table symbols which this image exports.
-opcodes
Display the low level opcodes used to encode all rebase and binding information.
-function_starts
Decodes the list of function start addresses.
This is just one example of the tools that can be used for analysis of dylibs. On my machine, for instance, I ran it on one of OpenSceneGraph's dylibs and here is a snippet I got:
0x143942 __ZN3osg13gluDeleteTessEPNS_13GLUtesselatorE
0x143968 __ZL9GotoStatePN3osg13GLUtesselatorE9TessState
0x143AA9 __ZN3osg15gluTessPropertyEPNS_13GLUtesselatorEjd
0x143B75 __ZN3osg18gluGetTessPropertyEPNS_13GLUtesselatorEjPd
0x143C70 __ZN3osg13gluTessNormalEPNS_13GLUtesselatorEddd
0x143C85 __ZN3osg15gluTessCallbackEPNS_13GLUtesselatorEjPFvvE
0x143E44 __ZN3osg13gluTessVertexEPNS_13GLUtesselatorEPdPv
0x143FE4 __ZL10EmptyCachePN3osg13GLUtesselatorE
0x144063 __ZL9AddVertexPN3osg13GLUtesselatorEPdPv
0x14411A __ZN3osg19gluTessBeginPolygonEPNS_13GLUtesselatorEPv
0x144161 __ZN3osg19gluTessBeginContourEPNS_13GLUtesselatorE
0x1441A1 __ZN3osg17gluTessEndContourEPNS_13GLUtesselatorE
0x1441C9 __ZN3osg17gluTessEndPolygonEPNS_13GLUtesselatorE
And:
__DATA __const 0x001D9D28 pointer 0 __ZTv0_n72_NK3osg6Camera12DrawCallback9classNameEv
__DATA __data 0x001E8208 pointer 0 __ZTv0_n72_NK3osg6Camera12DrawCallback9classNameEv
__DATA __data 0x001E84E8 pointer 0 __ZTv0_n72_NK3osg6Camera12DrawCallback9classNameEv
__DATA __const 0x001DA5F8 pointer 0 __ZTv0_n72_NK3osg8Drawable12CullCallback9classNameEv
__DATA __data 0x001E57E8 pointer 0 __ZTv0_n72_NK3osg8Drawable12CullCallback9classNameEv
And like always, pulling out strings and other const data is ridiculously easy. (The following is from a .so ... I couldn't find an x86 dylib on my system in my 30 seconds of searching ... the method is the same, though) (oh and you can tell that I disasm'd a library shipped with valgrind):
If you have strings consisting of sensitive data then those can easily be pulled from your libs... this is what I got from just dropping one lib into IDA:
__cstring:00003A58 ; Segment type: Pure data
__cstring:00003A58 __cstring segment dword public 'DATA' use32
__cstring:00003A58 assume cs:__cstring
__cstring:00003A58 ;org 3A58h
__cstring:00003A58 aDevRandom db '/dev/random',0 ; DATA XREF: _vgr00000ZU_libSystemZdZaZddylib_arc4random+17o
__cstring:00003A58 ; __data:__crashreporter_info__o
__cstring:00003A64 aValgrind_launc db 'VALGRIND_LAUNCHER',0 ; DATA XREF: vg_cleanup_env+1Co
__cstring:00003A76 aDyld_shared_re db 'DYLD_SHARED_REGION',0
__cstring:00003A89 aDyld_insert_li db 'DYLD_INSERT_LIBRARIES',0
__cstring:00003A9F align 10h
__cstring:00003AA0 aInstrumentedBy db 'Instrumented by Valgrind 3.8.1',0
__cstring:00003AA0 __cstring ends
This is where you'd find all the const strings that are used. Below this section (not shown) is the "pure data" section where other const data is stored.
So, again, it totally depends on exactly what information is sensitive.