Debugging a stripped ARM binary - objective-c

Question

I've disassembled a stripped ARM binary with Hopper and found the address of a method I'm interested in, 0x00065414. However, when connecting to the running app with gdb all addresses start from a base address that I cannot figure out. How can I determine my running applications base address (Entry Point?) in gdb?
Notes
The binary's FairPlay DRM was removed using Clutch
ASLR was removed by clearing the PIE header flag using a python script
Verified changes using otool
GDB setup
$ gdb ./MyApplication
(gdb) attach -waitfor MyApplication
Start App and it pauses immediately at launch.
(gdb) where
#0 0x3bbcdb88 in <redacted> ()
#1 0x3bbbc8fc in <redacted> ()
#2 0x3bbc4130 in <redacted> ()
#3 0x3bbc4014 in ccpbkdf2_hmac ()
#4 0x3bb9f9d0 in CCKeyDerivationPBKDF ()
#5 0x0015b750 in dyld_stub_pthread_key_create ()
#6 0x0015ca46 in dyld_stub_pthread_key_create ()
#7 0x0015c69c in dyld_stub_pthread_key_create ()
#8 0x0015b4d0 in dyld_stub_pthread_key_create ()
#9 0x0015c110 in dyld_stub_pthread_key_create ()
#10 0x0001695a in dyld_stub_pthread_key_create ()
#11 0x000ba256 in dyld_stub_pthread_key_create ()
#12 0x00017bde in dyld_stub_pthread_key_create ()
#13 0x33b9eaac in <redacted> ()
#14 0x33b9e4f2 in <redacted> ()
#15 0x33b98b40 in <redacted> ()
#16 0x33b33a06 in <redacted> ()
#17 0x33b32cfc in <redacted> ()
#18 0x33b98320 in <redacted> ()
#19 0x3601876c in <redacted> ()
#20 0x36018356 in <redacted> ()
#21 0x31374776 in <redacted> ()
#22 0x31374712 in <redacted> ()
#23 0x31372ede in <redacted> ()
#24 0x312dd470 in CFRunLoopRunSpecific ()
#25 0x312dd252 in CFRunLoopRunInMode ()
#26 0x33b975c2 in <redacted> ()
#27 0x33b92844 in UIApplicationMain ()
#28 0x0001aaf2 in dyld_stub_pthread_key_create ()
#29 0x00009028 in dyld_stub_pthread_key_create ()
Checking various locations for expected instructions so I can set a breakpoint:
(gdb) disas 0x65414
No function contains specified address.
I assume that the correct location is some + 0x65414. So I tried 0x33b92844 which is UIApplicationMain as the base.
(gdb) disas 0x33BF7C58
Dump of assembler code for function <redacted>:
0x33bf7934 <<redacted>+0>: f0 b5 push {r4, r5, r6, r7, lr}
This address is definitely in the land of redacted or symbol stripped code, but the address doesn't land you on a procedure boundary. So it isn't the right place.

Answer 1

You can try a :
starti
It let you enter in your dynamic linker (if your binary id dynamically linked) which will call the __libc_start_main function and as argument of this function, it gives a pointer toward the main function. So you have to set a breakpoint on this address (b*<addr_of_main>) and to continue the execution by using the continue command.
Now that your are in the main function, wait that your programm call your method, if you can't enter in this function, you can modify your registers with :
set $<register>=<value>

Answer 2

Your binary might be loaded with ASLR which is a security feature to make addresses to code and data unpredictable.
Try disabling ASLR when you're in GDB - before loading the executable.
(gdb) set disable-randomization off
(gdb) start

Answer 3

Use info file and/or info shared to figure out the executable's load address or the actual entrypoint address.
(gdb) info file
Mac OS X executable:
<...>/test, file type mach-o-le.
Entry point: 0x00002104
0x00001000 - 0x0002b000 is <...>/test
<...>