Gdb patches

August 26, 2009 in Tools | 30 comments

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 (hte.sourceforge.net) to easily modify the nsects. Keep in mind that HTE only supports non-fat binaries!

This is how it looks:

Have fun,
fG!

Files:
all_patches.patch
SHA1(all_patches.patch)= 74ee59cc213202d2d99c11ca8cde841890a7c7b6
number_sects_anti_debug.patch
SHA1(number_sects_anti_debug.patch)= 628498adc71b91447ba8860cec3829acf0eb7f46
gdbinit_problem.patch
SHA1(gdbinit_problem.patch)= efd8ab19d2675d601f02aa7f3b7ca21a9bee7704
show_raw_bytes.patch
SHA1(show_raw_bytes.patch)= 6ba57a401c1d3c0f6d7b31743da79ec63603752e
gdb-i386-apple-darwin.bz2
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).

30 comments

Comments feed for this article

Trackback link: http://reverse.put.as/2009/08/26/gdb-patches/trackback/

wishi on September 5, 2009 at 11:35 am

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 (0×5).
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?

Reply
1. fG! on September 5, 2009 at 9:57 pm
  
  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 http://reverse.put.as/2009/01/14/how-to-compile-gdb-and-other-apple-open-source-packages-in-mac-os-x/ . You have to use darwinbuild. If you I can upload my image with my building environment.
  
  Keep up the good work with your blog
  
  fG!
  
  Reply
wishi on September 6, 2009 at 10:26 am

I guess I compile that stuff… because for testing reasons I used your binary. Debugging a Debugger: sounds like fun!

Reply
anonym on September 7, 2009 at 12:31 am

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!

Reply
fG! on September 9, 2009 at 11:28 pm

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

Reply
wishi on September 10, 2009 at 9:58 am

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) (http://developer.apple.com/legacy/mac/library/documentation/MacOSX/Conceptual/universal_binary/universal_binary_tips/universal_binary_tips.html).

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

Sorry But I learned something.

Reply
1. fG! on September 10, 2009 at 12:14 pm
  
  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
  
  Reply
x_O on September 16, 2009 at 12:04 am

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.

Reply
1. fG! on September 16, 2009 at 12:09 am
  
  $ 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 ?
  
  Reply
x_O on September 16, 2009 at 12:13 am

Nope. That was it. It’s all working now. Thanks fG!

Reply
Dave on October 23, 2009 at 4:18 pm

Did you file a radar about this? It’s possible that Apple would fix these bugs.

Reply
Dave on October 23, 2009 at 4:19 pm

Also what about patches for Snow Leopard / 64-bit?

Reply
1. fG! on October 23, 2009 at 10:54 pm
  
  The patches work for Snow Leopard without a problem. Someone already left all the required steps to compile it for Snow Leopard
  
  Reply
NeoBetas on January 25, 2010 at 9:44 am

Is there anyways to modified .gdb_init to show the raw bytes instead patching and recompiling?

Reply
1. fG! on January 28, 2010 at 7:13 pm
  
  Nope. You have to patch and recompile.
  
  Reply
Han Solo on October 25, 2010 at 11:52 pm

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.

Kudos…

Reply
1. fG! on October 26, 2010 at 1:10 am
  
  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!
  
  Reply
Neo on February 16, 2011 at 5:17 pm

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?

Thanks!

Neo

Reply
1. fG! on February 16, 2011 at 10:59 pm
  
  Hum.. what do you mean by text file ? It should decompress a binary. Try to decompress via Terminal: bunzip2 gdb-i386-apple-darwin.bz2
  
  Reply
  1. Neo on February 17, 2011 at 12:34 am
    
    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 http://reverse.put.as/wp-content/uploads/2009/08/gdb-i386-apple-darwin.bz2, 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!
    
    Regards,
    Neo
    
    Reply
    1. fG! on February 17, 2011 at 12:47 am
      
      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
      fG!
      
      Reply
      1. Neo on February 17, 2011 at 1:29 am
        
        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!
        
        Neo
        
        Reply
        
        Neo on February 17, 2011 at 1:31 am
        
        Just another question.
        
        Now that I have a working copy of your modified gdb binary, how do I apply the “all_patches.patch”?
        
        Thanks,
        
        Neo
        
        Reply
        
        fG! on February 17, 2011 at 1:49 am
        
        You don’t need to, the binary has all the patches applied.
        If you ever want to compile and hack other patches, read http://reverse.put.as/2009/01/14/how-to-compile-gdb-and-other-apple-open-source-packages-in-mac-os-x/
        
        Reply
        
        Neo on February 17, 2011 at 2:16 am
        
        Thanks fG!
        
        Now all is working.
        
        I’ll let you know how things are going.
        
        Neo
        
        Reply
        
        Neo on February 17, 2011 at 6:17 pm
        
        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 0×80000022
        
        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?
        
        Thanks,
        
        Neo
        
        Reply
        
        fG! on February 19, 2011 at 12:51 am
        
        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).
Neo on February 19, 2011 at 6:18 pm

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!

Neo

Reply
1. Neo on February 20, 2011 at 4:02 am
  
  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
  
  Regards,
  
  Neo
  
  Reply
  1. fG! on February 20, 2011 at 11:58 am
    
    Very well! Part of the reversing effort is searching, reading and thinking. That’s why it’s fun!
    
    Reply

Gdb patches

30 comments

Reply