Gdb patches

Here you have the patches I did for gdb:

  • To fix problem with gdbinit
  • To display raw bytes in x/i and disassemble commands
  • To warn about possible number of sections anti-debug trick

You can download a single patch for all changes or one for each individual change. A patched gdb binary for Intel only is available, if you trust my binaries (copy to /usr/libexec/gdb). PHP max upload size doesn’t let me add the patched source package (can’t change it due to it’s impact on others).

I have removed symbolic name printing from the x/i command because I couldn’t find an easy workaround to have all the output aligned. Gdb table system has problems and it doesn’t work well with large columns. Nevertheless the symbolic name (when available) is printed everytime breakpoint is hit and if you really need it, you can use the disassemble command to see where you are (not removed there).

The anti-debug patch just warns about the possible trick. Unless dyld bug is fixed there’s no much interest in automatically fixing the headers. If you want to test it, you can use HT Editor ( to easily modify the nsects. Keep in mind that HTE only supports non-fat binaries!

This is how it looks:

Have fun,

SHA1(all_patches.patch)= 74ee59cc213202d2d99c11ca8cde841890a7c7b6
SHA1(number_sects_anti_debug.patch)= 628498adc71b91447ba8860cec3829acf0eb7f46
SHA1(gdbinit_problem.patch)= efd8ab19d2675d601f02aa7f3b7ca21a9bee7704
SHA1(show_raw_bytes.patch)= 6ba57a401c1d3c0f6d7b31743da79ec63603752e
SHA1(gdb-i386-apple-darwin.bz2)= 4ce058eb26639bba0ab9974ace27adeeef446905

If you put the patch inside gdb-768 dir you might want to use -p2 option for patch (the diffs came out of my hg repository).

32 thoughts on “Gdb patches

  1. Hi 😉

    You’ve got a very interesting blog. Especially optimizing the Apple Dev Tools to be more reversing friendly is a kewl project. However I gave this a try and it doesn’t work:

    gdb$ r
    Unable to find Mach task port for process-id 70506: (os/kern) failure (0x5).
    gdb$ quit

    Even if:

    wishi@dawn ~/patched
    % sudo chgrp procmod gdb-i386-apple-darwin

    wishi@dawn ~/patched
    % sudo chmod 2755 gdb-i386-apple-darwin

    You don’t get it working. Maybe I miss something crucial?

    1. Hello,

      Thank you for the compliment 🙂 Are you using the binary I provided or compiled it yourself (knowing your blog I would bet on this hehehe) ? I had that same error when I compiled gdb from Apple package out of the source. To compile correctly you need to refer to this process . You have to use darwinbuild. If you I can upload my image with my building environment.

      Keep up the good work with your blog 🙂


  2. I got the same err on test using your binary:
    “Unable to find Mach task port for process-id 70506: (os/kern) failure (0×5).”
    whatever i will use your patch and compile it later…

    You have a very nice and informative blog!
    i know you from the windows world for over 5 years ago.
    i am a still reader, but i come twice time almost every day here.
    please add the link to wishi’s blog in your “Links” collection. (very nice blog too, wishi!)

    Thank you and keep update! 😀

  3. I had some free time but I can’t reproduce the bug… I tested with a clean vmware snapshot and replaced original gdb binary with this one and it works… Tried to attach to a running program and it was fine. Tried to run a new program and it was fine… Hummm something is missing ! My Xcode version is 3.1.

    Any ideas ? Must find some more free time to try to reproduce this hehehe

  4. I missed something… I didn’t copy the binary to /usr/libexec/gdb/ but just called it directly.
    – Debugging as root was/is possible without problems: task_for_pid() by default is only accessible by root (or procmod) (

    However I wonder why the binary has to be in a specific path… Anyhow.

    Sorry 😉 But I learned something.

    1. Ahhhhhhhhhhhhhhhhh ! That explains… I tried to understand if you had copied it or not. I assumed you did because you tried to change permissions (which now seems like a rather lame assumption since I should have remembered that copy preserves permissions hehehe).

      You have to copy the binary because gdb command in reality is a script at /usr/bin/gdb. It does some magic due to different architectures 🙂

  5. I backed up the original gdb-i386-apple-darwin to gdb-i386-apple-darwin.orig and copied your patched version to /usr/libexec/gdb/. I load a file in GDB using exec-file and upon executing the “run” command, I too receive the error: “Unable to find Mach task port for process-id 70506: (os/kern) failure (0×5).” The only way I’ve found to get rid of the error is to issue “sudo gdb” instead of just “gdb”. Is there a way to I could run GDB without having to issue the sudo command (to circumvent that error)? I’m running as an Admin account and the file permissions on gdb-i386-apple-darwin (patched version) are the same as the original I backed up.

    1. $ ls -la /usr/libexec/gdb/gdb-i386-apple-darwin
      -rwxr-sr-x 1 root procmod 3051328 Aug 26 23:31 /usr/libexec/gdb/gdb-i386-apple-darwin

      Do you have the s bit set and group procmod ?

  6. fG: your patches absolutely rock…

    Just wanted to stop by and say thanks that you share your knowledge and your tools. I absolutely love your Softice derived UI 😉

    And now with IDA being QT based and available with GUI on Mac, I really feel like home.


    1. Thank you 🙂

      All the credits for gdbinit go to Mammon and all the authors that fixed and added a lot of stuff! I just jumped in and added a few more!

  7. Hi fG!

    Thanks for your G-R-E-A-T blog!

    When I download the file gdb-i386-apple-darwin.bz2 and decompress it a text document file appears, instead of your binary.

    What should a I do?



      1. Dear fG!

        Thanks for your quick reply.

        What I mean by “Text Document” is that when I hit command + I on the uncompressed bz2 file downloaded from, it shows me in the “Kind” of file as being “Document”, instead of “Unix Executable File”.

        I did try to uncompress via Terminal, as you taught me, but the result is the same as double clicking the compressed file, giving me the “Document” kind of file and not a “Unix Executable File”.

        If you don’t mind, could you please send me the gdb uncompressed binary to my e-mail address?

        By the way, now I’m really exited to get started reverse-engineering under Mac OS X, because you really are a great teacher for beginners, sharing true knowledge. That’s the hacker spirit from the 80’s!

        I do appreciate your attention!


        1. Ok I replicated your issue and I understand it now 🙂
          After unpacking, you need to issue the following commands:
          “sudo cp /usr/libexec/gdb/gdb-i386-apple-darwin gdb-i386-apple-darwin.orig”
          (this will backup the original binary)
          “sudo cp gdb-i386-apple-darwin /usr/libexec/gdb/”
          (this will copy the unpacked binary over the original, you should the full path to the unpacked binary or position yourself there)
          “sudo chmod +x /usr/libexec/gdb/gdb-i386-apple-darwin”
          (cp should inherit permissions but to be safe, just readd executable permissions to the new binary)

          You need to do this because in reality the gdb command is a script that further calls for the correct binary in that location. Your document problem is because the unpacked binary doesn’t have execution permission (you can verify this by adding the execute permission to that binary “chmod +x binary_name”). This is a security feature of Unix systems 🙂

          Have fun, don’t spread the cracks 😉

          1. Dear gG!

            It WORKED!!!

            WOW! What a UNIX lesson! Thanks a bunch!

            Sure, I won’t share cracks around. I’ll do it just for fun and for challenges’ sake. This is one thing that I always wanted to do, mess around with Assembly. I’m a Mac OS X programmer wanna be and I was kinda bored with my programming tasks routine.

            Many, many thanks once more.

            You rule!


            1. Just another question.

              Now that I have a working copy of your modified gdb binary, how do I apply the “all_patches.patch”?



                  1. Dear fG!

                    Following your beginners-tutorial-II.txt, I’ve been able to write and compile the example.c program, but under gdb I receive this message:

                    gdb$ exec-file ./example

                    unable to read unknown load command 0x80000022

                    And this is my gdb configuration is:

                    -rwxrwsr-x 1 Neo-Mac procmod 3051328 Feb 16 20:03 /usr/libexec/gdb/gdb-i386-apple-darwin

                    Is any else that I must do make gdb work properly?



                    1. Just re-tested the example and it’s ok for me.
                      How did you started gdb? And the next steps?

                      This shouldn’t have an impact but try to execute the following commands:
                      sudo chown root:procmod /usr/libexec/gdb/gdb-i386-apple-darwin
                      sudo chmod g+s /usr/libexec/gdb/gdb-i386-apple-darwin

                      This should fix permissions for gdb binary (but the problem shouldn’t be originated in this).

  8. Dear fG!

    I start gdb using “sudo gdb”, then I issue “exec-file ./example” command and gdb gives me the output “unable to read unknown load command 0×80000022”.

    Maybe we can try another approach. I’ve been able to compile gdb with darwin build following your instructions.

    I can play around with your example file and with other programs as well, but I really want to apply your patches to display raw bytes in x/i and disassemble commands.

    Inside /usr/libexec/gdb I issue:

    sudo patch -p2 gdb-i386-apple-darwin all_patches.patch

    But I receive this output:

    patching file gdb-i386-apple-darwin
    Hunk #1 FAILED at 1905.
    Hunk #2 FAILED at 1955.
    Hunk #3 FAILED at 1993.
    Hunk #4 FAILED at 2017.
    Hunk #5 FAILED at 2068.
    Hunk #6 FAILED at 2096.
    6 out of 6 hunks FAILED — saving rejects to file gdb-i386-apple-darwin.rej
    can’t find file to patch at input line 177
    Perhaps you used the wrong -p or –strip option?
    The text leading up to this was:
    |diff -r b4b157088bc8 gdb-768/src/gdb/disasm.c
    |— a/gdb-768/src/gdb/disasm.c Wed Aug 12 10:58:48 2009 +0100
    |+++ b/gdb-768/src/gdb/disasm.c Wed Aug 26 15:09:04 2009 +0100
    File to patch:

    How can I properly apply your all_patches.patch?

    Thanks again for your patience!


    1. Dear fG!

      After some googling I found out how to patch and compile gdb, using the Snow Leopard 10.6.6 (Build 10J567) darwinbuild.

      I followed your instructions to build gdb from source, then I unpacked the “gdb-1344.tar.gz”, patched with your “all_patches.patch” file, and I packed it again as “gdb-1344.tar.”

      So I issued a “darwinbuild -nochroot gdb” command and it compiled like a charm!

      Now I’m able to take advantage of all your output improvements on gdb 🙂

      By the way, I love how gdb now displays the raw bytes in x/i and disassemble commands!

      Thanks a lot once more for all your attention and help. Now I’m already making some progresses in my reversing efforts.

      I’ll keep you posted how it goes 😉



  9. actual GDB seems to be : GNU gdb 6.3.50-20050815 (Apple version gdb-1822)
    gdbinit is at 8.0

    so…… is this outdated?
    or still needed for gdbinit to work nicely?

    1. There’s no connection between gdbinit version number and gdb. It should work fine with any gdb version.
      You should read the header of gdbinit for some problems with OS X gdb version.

Leave a Reply

Your email address will not be published. Required fields are marked *