Debugging libcrypto on iOS

369 views
Skip to first unread message

jochen

unread,
Jan 12, 2012, 3:26:28 AM1/12/12
to SQLCipher Users
Hi all,

I am playing around with SQLCipher on iOS and I am using the openssl-
xcode project provided on GitHub (https://github.com/sjlombardo/
openssl-xcode) to build OpenSSL's libcrypto. However, I don't seem to
able to build the library such that can I debug into the OpenSSL
source code; the debugger keeps telling me there is "no line number
information" available. Can anybody tell me how to resolve that?

Regards,
Jochen

Stephen Lombardo

unread,
Jan 12, 2012, 10:50:47 PM1/12/12
to sqlc...@googlegroups.com
Hi Jochen,

You might be able to generate a debug build by:
  1. opening up openssl-xcode project, and navigating to the Run Script under the crypto target. 
  2. add -d to the ./config lines
If I might ask, is there some specific openssl behavior you are trying to debug?

Cheers,
Stephen

jochen

unread,
Jan 13, 2012, 2:42:20 AM1/13/12
to SQLCipher Users
Hi Stephen,

thanks for the quick response, I'll give that a try.

To answer your question: I stumbled upon issue 15 (https://github.com/
sjlombardo/sqlcipher/issues/15) and was just curious how seeding the
PRNG might work on iOS. The OpenSSL docs state that /dev/(u)random is
used when available, however, due to the sandboxed iOS security
architecture I'm not sure that is the case and simply wanted to step
through it.

Regards,
Jochen

On 13 Jan., 04:50, Stephen Lombardo <sjlomba...@zetetic.net> wrote:
> Hi Jochen,
>
> You might be able to generate a debug build by:
>
>    1. opening up openssl-xcode project, and navigating to the Run Script
>    under the crypto target.
>    2. add -d to the ./config lines
>
> If I might ask, is there some specific openssl behavior you are trying to
> debug?
>
> Cheers,
> Stephen
>
>
>
>
>
>
>
> On Thu, Jan 12, 2012 at 3:26 AM, jochen <j...@starfinanz.de> wrote:
> > Hi all,
>
> > I am playing around with SQLCipher on iOS and I am using the openssl-
> > xcode project provided on GitHub (https://github.com/sjlombardo/
> > openssl-xcode <https://github.com/sjlombardo/openssl-xcode>) to build

Stephen Lombardo

unread,
Jan 13, 2012, 8:03:16 AM1/13/12
to sqlc...@googlegroups.com
Hi Jochen,

I've looked into this in the past and I can confirm that testing showed OpenSSL using /dev/urandom in RAND_poll when running on an iOS device. Please feel free to let us know the results of your testing as well. Thanks!

Cheers,
Stephen

jochen

unread,
Feb 2, 2012, 9:16:00 AM2/2/12
to SQLCipher Users
Hi Stephen,

I built libcrypto with -d added to the ./config lines (or line as the
latest version on github contains only one of those) as you suggested,
but to no avail; I still cannot step into the library. Can you think
of anything else I could try? Or how did you confirm that RAND_poll
actually reads from /dev/urandom on iOS?

Regards,
Jochen

Billy Gray

unread,
Feb 2, 2012, 9:23:03 AM2/2/12
to sqlc...@googlegroups.com
Hi Jochen,

There is a great article on random functions by Mike Ash, and while it mostly pertains to OS X, the first couple of comments address this specifically (/dev/random being "sandboxed out"):

Comments:

On iOS, because the sandbox stops you from interacting with /dev/random, you have to use SecRandomCopyBytes(). It's just an API to access the random device:http://developer.apple.com/library/ios/#DOCUMENTATION/Security/Reference/RandomizationReference/Reference/reference.html

While I find it extremely dumb that /dev/random is sandboxed out, SecRandomCopyBytes() actually looks easier to use.

Regards,
Billy
--
Team Zetetic
http://zetetic.net

jochen

unread,
Feb 2, 2012, 9:50:18 AM2/2/12
to SQLCipher Users
Hi Billy,

thanks for your reply. I know this article (which actually was the
reason for me investigating the matter) and I am also well aware of
the SecRandomCopyBytes API on iOS. However, since the comments you
mentioned seem to contradict what Stephen wrote above I still would
like to check for myself...

Regards,
Jochen

On 2 Feb., 15:23, Billy Gray <wg...@zetetic.net> wrote:
> Hi Jochen,
>
> There is a great article on random
> functions<http://mikeash.com/pyblog/friday-qa-2011-03-18-random-numbers.html>by
> Mike Ash, and while it mostly pertains to OS X, the first couple of
> comments address this specifically (/dev/random being "sandboxed out"):
>
> Comments:
>
>
>
> > ***leeg <http://www.fuzzyaliens.com/>* at 2011-03-18 17:31:00<http://mikeash.com/pyblog/friday-qa-2011-03-18-random-numbers.html#co...>
> > :
> > On iOS, because the sandbox stops you from interacting with /dev/random,
> > you have to use SecRandomCopyBytes(). It's just an API to access the random
> > device:
> >http://developer.apple.com/library/ios/#DOCUMENTATION/Security/Refere...
>
> > ***mikeash <http://mikeash.com/>* at 2011-03-18 18:05:01<http://mikeash.com/pyblog/friday-qa-2011-03-18-random-numbers.html#co...>
> > :

Stephen Lombardo

unread,
Feb 2, 2012, 4:48:47 PM2/2/12
to sqlc...@googlegroups.com
Hi Folks,

I don't believe the comments in that article are accurate. The documentation for SecureRandom says that the function reads from /dev/random to obtain cryptographically-secure bytes. The availability of /dev/random and /dev/urandom, even from within the sandbox, is further supported by research / analysis and documented in a few papers (here is a recent one http://media.blackhat.com/bh-us-11/DaiZovi/BH_US_11_DaiZovi_iOS_Security_WP.pdf).

To answer your initial question, I originally verified the random generator functionality using a modified openssl with tracing code in RAND_poll that wrote activity to a log file. I was also able to verify in the debugger at a later date. 

However, revisiting this thread today, I was unable to get the -d flag to work with openssl-1.0.0 either. Perhaps I don't recall correctly how I did it before, or maybe the build changed. Rather than using -d with config, you can modify the openssl-xcode project Run Script and add -g into the CFLAGS on line 68 to produce a debug build that you can step through.

I've included an abbreviated gdb session here for convenience and posterity. It shows an app running on a device, opening /dev/urandom, getting a file handle, and reading bytes from it. 

Please feel free to review this and also attempt to reproduce these results independently. Let us know what you find. Thanks!

(gdb) break RAND_poll
Breakpoint 1 at 0x114f14: file openssl-1.0.0f/crypto/rand/rand_unix.c, line 240.
(gdb) continue
Breakpoint 1, RAND_poll () at openssl-1.0.0f/crypto/rand/rand_unix.c:240

...

262    for (i = 0; (i < sizeof(randomfiles)/sizeof(randomfiles[0])) &&
265      if ((fd = open(randomfiles[i], O_RDONLY
(gdb) inspect randomfiles[i]
$1 = 0x133247 "/dev/urandom"
278        int usec = 10*1000; /* spend 10ms on each file */
281        struct stat *st=&randomstats[i];
(gdb) inspect fd
$2 = 8

...

345          if (try_read)
347            r = read(fd,(unsigned char *)tmpbuf+n, ENTROPY_NEEDED-n);
348            if (r > 0)
(gdb) inspect r
$3 = 32

...

393      RAND_add(tmpbuf,sizeof tmpbuf,(double)n);
394      OPENSSL_cleanse(tmpbuf,n);

...

416    return 1;

jochen

unread,
Feb 3, 2012, 3:36:50 AM2/3/12
to SQLCipher Users
Hi Stephen,

thanks again for your assistance; by adding -g to the CFLAGS I was
able to build a debug version of the library I can step into. By doing
so I was also able to verify your results; it seems that /dev/urandom
actually is accessible from inside the iOS sandbox.

I'm sorry if I gave the impression of not believing you in the first
place, but I simply wanted to see for myself.

Regards,
Jochen

On 2 Feb., 22:48, Stephen Lombardo <sjlomba...@zetetic.net> wrote:
> Hi Folks,
>
> I don't believe the comments in that article are accurate. The
> documentation for SecureRandom says that the function reads
> from /dev/random to obtain cryptographically-secure bytes.
> The availability of /dev/random and /dev/urandom, even from within the
> sandbox, is further supported by research / analysis and documented in a
> few papers (here is a recent onehttp://media.blackhat.com/bh-us-11/DaiZovi/BH_US_11_DaiZovi_iOS_Secur...
> ).

Stephen Lombardo

unread,
Feb 3, 2012, 11:29:48 AM2/3/12
to sqlc...@googlegroups.com
Hi Jochen,

Thank you for getting back to the list on this, I'm really glad to hear that you were able to check this independently! 

It's great to see that you, and others, are taking an interest in verifying this sort of thing at a low level. Additional review is always welcome and will help improve the security of SQLCipher.

Cheers,
Stephen
Reply all
Reply to author
Forward
0 new messages