Tools

You are currently browsing the archive for the Tools category.

Ice the Guardian v2, the OS X anti-lamware

February 14, 2013 in Security, Tools | No comments

Another day, another lame malware attacking and spying on OS X users, and still using the same old lame Daemons and Agents approach to gain persistence at victims machine. Hey, it works, so why change, right?

Ice the guardian v2 is a quick hack using TrustedBSD to monitor the system LaunchDaemons and LaunchAgents folders. There’s a lot of room for improvement so I’m waiting for your commits ;-)

Apple has the technology in place so they could probably implement something like this default oin OS X. Gatekeeper can’t be the only obstacle to this kind of stuff.

You can find the source at github repo.

Have fun,
fG!

 

Otool-ng – a set of small patches to Apple’s otool

November 21, 2012 in Tools | 4 comments

It’s the lazy post season so I present you otool-ng. It’s a fork of Apple’s otool with small modifications for things that I use often or dislike in current otool.

The segment command LC_MAIN was introduced to replace LC_UNIXTHREAD and one information that is lost is the entrypoint address. While ASLR kind of makes it less useful, I still debug a lot of programs and do other stuff, where ASLR is disabled. So I just added that feature back and now the LC_MAIN output also prints the non-ASLRed entrypoint address. The algorithm appears to be LC_SEGMENT.vmaddr plus the file offset described at LC_MAIN. If you use it and find it not working please let me know.

I have also changed all the file offsets information to hexadecimal because I hate to convert when copying & paste to hex editors.

And the last feature for now is the -z flag. It will modify the PIE flag, inverting the current setting (set if removed, remove if set). Again, it’s something I need from time to time and it’s faster to do it from the command line. I was brainwashed in Economics so I like to be efficient (ok ok, lazy!!!).

You can find the code at https://github.com/gdbinit/otool-ng. To compile it, follow my old (and useful since I use it often) post about darwinbuild. You just need to put the tar.gz file inside the Sources folder to avoid downloading from darwinbuild/Apple servers. There’s a small shell “script” to create the package.

Hope you find it useful. As usual send any requests, patches, complaints, etc :-) .

fG!

P.S.: I need to nag pancake to get an updated iOS package. The version available at Cydia is too old!

Kextstat_ASLR util or how to start hiding your kernel rootkit in Mountain Lion

November 18, 2012 in Tools | 5 comments

Welcome back!

This is a small post about a quick util that I created yesterday’s night while working on a side project. Mountain Lion introduced kernel ASLR and the kextstat util output doesn’t support (yet?) this feature. The addresses are not the real ones and this is quite annoying (kgmacros from kernel debugging also seem to fail at this!).

What this util does is to read the kernel extensions information via the /dev/kmem device (hence this util is probably not useful for a large audience) and display it like kextstat does with the correct address for each kext (just the most important information, the linked against info might be added in the future).

Besides useful for anyone wanting to read the kexts information, it’s also useful for rootkits because it implements the trick that Crisis uses to retrieve this information for 64bits kernels (my posts were against the 32bits version). The only piece left is how to find the sLoadedKexts symbol. Here it’s hardcoded for version 10.8.2. I do have a nice trick to find it but it’s not ready for public consumption. First I want to see if it’s possible to implement my new idea :-)

Due to some whacky reason I was convinced that each kernel extension had individual ASLR slide values, which after I got this util working was demonstrated false. The slide is the same as the kernel. I probably had some mistake while searching manually for the kexts. Practice makes perfection and part of this code was needed for my new project so it’s not wasted time!

The code is located at https://github.com/gdbinit/kextstat_aslr.
One feature to be added is to “bruteforce” the whole sLoadedKexts array. The reason is that rootkits usually decrease the count but the information remains there. Since the class has a capacity instance variable, we can move beyond the count and check if there’s anything suspicious there. Just a fun detail :-)

The last detail is that this is susceptible to changes to OSArray and OSKext classes since it’s using offsets into the instance variables. The best way would be to get this ported to C++ but I still have to read a book or two on C++. Need to verify how stable are these classes since Snow Leopard.

Phew, too many written words for such small util!
Have fun,

fG!

Update:
There is a privileged syscall called kas_info() that allows to retrieve kernel ASLR value. I’ve updated the code to use this feature.

ExtractMachO: an IDA plugin to extract Mach-O binaries from disassembly

July 30, 2012 in Tools | 1 comment

This is an IDA plugin to extract Mach-O binaries located in IDA disassembly, either code or data segments. For now it only supports 32 or 64 isolated binaries and not fat binaries. It also expects a normal formatted binary, not something mangled as my crackme for example. I expect to add support for fat binaries soon.

Why did I created this plugin? Everyone is talking about the latest OS X malware, Crisis (or whatever other name everyone is using – AV scene is so lame that no one respects the first name given, blah!).

I started reversing the dropper binary for Crisis and found a Mach-O binary at the code section. So I decided to write a plugin to extract it :-) .

To use it you need to locate the cursor at the Mach-O magic value (0xFEEDFACE or 0xFEEDFACF) and run the plugin. I might change this in a future release and ask for the start address.

The project is located at Github, https://github.com/gdbinit/ExtractMachO.

Any bugs, bla bla bla, leave a msg, email, or a bug report :-)

Hopefully some posts about Crisis soon.

Enjoy,
fG!

Update:
v1.0 now searches and extracts all valid Mach-O files it can find, fat and non-fat!

How to compile GDB for iOS!

April 16, 2012 in Tips, Tools | 7 comments

One obstacle that I faced long time ago and came again into spotlight is how to recompile gdb for iOS. It is not useful to fix the arm disassembler and then not be able to compile. As far as I know there isn’t any documentation available or an easy method to accomplish this – Saurik’s build environment is not public (?) and Apple sources do not compile directly. Darwinbuild project works great for OS X but it’s a question mark for iOS.

Darwinbuild it is! After some failed hacking last Friday (progress was great and it was near completation), I decided to try to fix the loose end today. Success was finally achieved.
This post contains almost all the information that you need to recompile gdb yourself. There is something that you will need to complete by trial & error. Let’s start the fun!

The reference post on darwinbuild usage is this one, written by yours truly. You should follow it and modify accordingly with the information provided here. My OS X version is still Snow Leopard but you should have no problems with Lion.
The image size should be 2GB, and you should use the build # 10K540. When you execute the “darwinxref edit”, use the following information:

environment = {
INSTALLED_PRODUCT_ASIDES = YES;
MACOSX_DEPLOYMENT_TARGET = 10.6;
NEXT_ROOT = "";
RC_ARCHS = "armv7 armv6";
RC_JASPER = YES;
RC_NONARCH_CFLAGS = "-pipe";
RC_OS = macos;
RC_PRIVATE = /private;
RC_RELEASE = SnowLeopard;
RC_TARGET_CONFIG = iphoneos;
RC_XBS = YES;
SEPARATE_STRIP = YES;
UNAME_RELEASE = 10.0;
UNAME_SYSNAME = Darwin;
};

Word of caution: be careful with copy & pasting this because of the “” (if you get an error while saving from darwinxref edit).

The next step is to edit the darwinbuild database. It’s located at “.build/xref.db”, inside the Build10K540 folder you should be located at. You need to change the gdb version to the latest one, 1708 instead of 1344. Execute the following sql statement to verify it:

SELECT * FROM properties WHERE project="gdb" AND property="version";

and then update the field:

UPDATE properties SET VALUE="1708" WHERE project="gdb" AND property="version";

Start compilation with “darwinbuild -nochroot gdb”. Version 1708 will be downloaded. When configuration/compilation starts, abort it with ctrl-c.
You will need to create a link (there is probably a more elegant solution to this!). Go to the usr/lib folder inside the iOS SDK. There you need to make a link from “crt1.10.6.o” to “crt1.o”.  Small example from my system:

lrwxr-xr-x  1 root  wheel     6 Apr 14 04:12 /Developer4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib/crt1.10.6.o -> crt1.o
-rw-r–r–  1 root  wheel  2720 Aug 30  2011 /Developer4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib/crt1.3.1.o
-rw-r–r–  1 root  wheel  4584 Aug 30  2011 /Developer4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib/crt1.o

Next step is to modify the file “BuildRoot/SourceCache/gdb/gdb-1708/src/gdb/macosx/macosx.defs”. Here you need to replace the import for exc.defs. Change:

#import

to:

#import "/Developer4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/include/mach/exc.defs"

(modify your path accordingly)

Last step for now is to modify the Makefile. We need to modify it so the ARM cross-compiling tools are used. It’s located at BuildRoot/SourceCache/gdb/gdb-1708/Makefile. To make it easier, you have my Makefile as a reference (all files at the end). I left the places that you need to modify tagged with FIXME. Your task is to change the paths.

Now you are ready to compile and start the trial and error process. This time, compile with “darwinbuild -nochroot -nosource gdb”. This will not unpack again the source package and will keep our previous changes.
The compilation process will start and hopefully you will observe lots of output, which is a good sign! Near completation, errors regarding missing includes will start to appear. Your task is to manually copy them from OS X “/usr/include” to the iOS SDK “usr/include” folder (in my case /Developer4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/include/). The only modifications that you will need to do are to edit some files and change the import location to relative paths (or absolute if you prefer). Not elegant, but it works! When you reach the missing architecture includes, you can use the ones from i386. Sorry for not having a complete file list – I was hacking this without great hope that it would work heheheh.

And that’s it! After you fix the missing includes and defs, the compile should successfully finish and you have your shiny recompile gdb. You can also apply my gdb patches (recommended!). Before starting to compile everything, just go to the SourceCache folder, apply the patch and compile.
Follow the steps from the reference post to copy the compiled binary, apply the necessary entitlements (reference), upload to your device and enjoy :-)

If you don’t feel adventurous enough then I include a fat binary (armv6 and armv7) with my patches. You just need to add the entitlements.
Pancake (from Radare) created a package for this version. Add http://cydia.radare.org to your repo list and install it from there. Thanks to pancake for his work :-)

Any question or problem you run into leave a comment so everyone else can benefit from the (potential) solution.

Have fun,
fG!

Makefile.gz

gdb-arm-apple-darwin.gz

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
SHA256(Makefile.gz)= 9aa69bc9b5a77a682c5bc74435440f26e839c0b216861f64a1af4f5a6432dfaf
SHA256(gdb-arm-apple-darwin.gz)= 7c3744c1be024a28c594c0ad90d75f0d187c5e53d9cb09d0183bba19b7415e6d
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
 
iQEcBAEBAgAGBQJPkTVwAAoJEAADGo6F9Uj36RUIAJF5E3Ak7d/q6MR0tNPMIoKy
/v9lEkt9bBr0QBo/GHj0bEkcVKp58Ft3y2yE14qkk7BpxHYGalvzTLNGy9uk3TRL
xprJpwKxttpms14+N+tNKBEKu3g5iItMbyWiip60UWbhYMlmXpKQFOMxJeHQIYLy
88KlbqEfiztil4UY04q/CUjxFfV38lvQCosgjDJ2XHHMrsJNvxfLslEkMTxOrbS5
C64TNQ3lj7SWvVBgAQ9OkjrWqNcPJyULth9ScKEixhWNHzcjZmIxP9+9PmrfviAn
rckSlEVhNDtOf9tsDfBaMM2STmPG5unuhaMR2vda+VVAtNOHZ+KO1MY6k6y+Zfk=
=jUdm
-----END PGP SIGNATURE-----

Update: List of added/modified include files (I forgot about the power of find :X)
./_locale.h
./libproc.h
./mach/arm/machine_types.defs
./mach/exc.defs
./mach/mach_types.defs
./mach/mach_vm.h
./mach/machine/machine_types.defs
./mach/machine/thread_state.h
./mach/std_types.defs
./ncurses_dll.h
./net/route.h
./sgtty.h
./sys/dir.h
./sys/ioctl_compat.h
./sys/kern_control.h
./sys/proc_info.h
./sys/ptrace.h
./sys/ttychars.h
./sys/ttydev.h
./termcap.h

Gdbinit v8.0: simultaneous support for x86/x86_64 and ARM architectures!

April 13, 2012 in Tools | 15 comments

Here it is, a merge between the x86 and ARM versions of gdbinit. The only inconvenience is that you need to manually change the target, using the “32bits” and “64bits” commands for x86/x86_64 architectures, and “arm” for ARM. That’s a small price to pay for :-)

This version features a lot of cosmetic fixes (indentation mostly) but also some fixes to the ARM related code, and a new command – dumpmacho. This command will dump the Mach-O header to a file. You need to supply the start address and the output filename. Only the header information is dumped – sometimes I need to dump the header and load it into otool or machoview to verify some things. Just a command to automate things!

The next step is to try to compile a new iOS gdb version that features my fixes. I think I will do another attempt to add the armv7 instructions to gdb so it’s not a major pain to debug these binaries. Let’s see if I can succeed this time.

There’s no test suite for gdbinit (<xxxxxxxx> testing is for chumps) ! From my tests everything is working, if not leave a msg here or at github.

Enjoy,
fG!

gdbinit8.gz
SHA256(gdbinit)= fb510d812dabbad968e68ad1e4916aa85400d6375e0e404f5893946151420238

« Older entries § Newer entries »