WhatTheFunct?

Hey folks! This time I’m gonna share with you a small IDAPython tool made by Federico Muttis (aka @acid_. Maybe you remember him from the -pretty awesome- pidgin vulnerability or the WebEx one). This is one of those scripts that you have to use and reuse several times when working with obscure firmwares, memory dumps or even unknown pieces of code.  A lot of us made something like this in the past. It’s a must. But I felt that we really needed something with a little more generical approach. Like Acid did.

Let’s see what he has to say about it

When reversing unknown binaries, such as firmware or any non-standard executable (ELF, PE, etc), it’s pretty common that IDA doesn’t recognize most of the functions.

This is when I usually start hitting “C” whenever something looks like code, and then define everything that looks like functions using “P”.

Of course IDA helps a bit, i.e. when you find a function that jumps to another section on the file, it disassemblies that part, and defines some functions.

But sometimes the binary file is just too long, and even if IDA helps by defining such sections of the file as code/functions, there is a lot of undefined code as well.

This little IDA Python script finds all your defined functions, takes the first instruction’s opcode and searches for it in the rest of the file, if the opcode is found in an undefined portion of the file, it does MakeCode, which is the same as hitting “C”, and then MakeFunction (IDC equivalent for “P”).

It’s worth mentioning that the script also filters which opcodes are functions prologues based on a set of common instructions (i.e. “STMFD” (for ARM), “PUSH” and “MOV”).

You should modify it to suit your needs.

import idc
import struct
import idautils

def find_all( opcode_str ):
    ret = []
    ea = idc.FindBinary(0, 1, opcode_str)
    while ea != idc.BADADDR:
        ret.append(ea)
        ea = idc.FindBinary(ea + 4, 1, opcode_str)
    return ret
    
def define_functions():
    # The function first searches for all user defined functions, reads
    # the opcodes and searches for that opcodes in the rest of the file.
    #
    # You can extend this by adding more disassembled instructions that
    # make you believe are function prologues.
    #
    # Obviously not any PUSH is a function start, this is only a filter
    # against erroneously defined functions. So if you define a function
    # that starts with other instruction (and you think there could be
    # other functions that start with that instruction), just add it here.
    prologues = ["STMFD", "push", "PUSH", "mov", "MOV"]
    
    print "Finding all signatures"
    ea = 0
    opcodes = set()
    for funcea in idautils.Functions(idc.SegStart(ea), idc.SegEnd(ea)):
        # Get the opcode
        start_opcode = idc.Dword(funcea)
        
        # Get the disassembled text
        dis_text = idc.GetDisasm(funcea)
        we_like_it = False
        
        # Filter possible errors on manually defined functions
        for prologue in prologues:
            if prologue in dis_text:
                we_like_it = True
        
        # If it passes the filter, add the opcode to the search list.
        if we_like_it:
            opcodes.add(start_opcode)
        
    print "# different opcodes: %x" % (len(opcodes))
    while len(opcodes) > 0:
        # Search for this opcode in the rest of the file
        opcode_bin = opcodes.pop()
        opcode_str = " ".join(x.encode("hex") for x in struct.pack("<L", opcode_bin))
        print "Searching for " + opcode_str
        matches = find_all( opcode_str )
        for matchea in matches:
            # If the opcode is found in a non-function
            if not idc.GetFunctionName(matchea):
                # Try to make code and function
                print "Defining function at " + hex(matchea)
                idc.MakeCode(matchea)
                idc.MakeFunction(matchea)

    print "We're done!"
    
define_functions()

This in an example of a firmware file with only user (and IDA) defined functions:

And this is after the script ran:

Obviously, blue means code within a function.

Nice seatbelt.

Hey guys!
Today I wanna mention a little bug we found together with Matias Eissler. It’s not the big thing,  that’s clear. But it’s potentially dangerous and it shows the complexity of a sandbox implementation.

This is the story: After a few hours fooling around with the sandbox, we found this method that allowed us to bypass the network access restriction. The funny thing here is that we did a quick search on google about the topic to see if some of this was reported before and guess what?  Charlie Miller publicly disclosed the same thing (that apple events were allowed in a sandbox profile) in the quicklookd profile like 3 years ago.

So, when we checked the current version of the profile and saw that it was modified to also restrict apple events we though: “Ok, if Apple modified the profile after Charlie’s talk,  they recognize the issue as a vulnerability, or at least as a problem”.
Well, they actually recognized the issue, and they are considering to ‘modify the documentation’ to explicily point this out. Better than nothing, but that means that by the time, the no-network sandbox profile doesn’t actually restrict network access. Funny huh?

Some articles mentioning the issue:

http://apple.slashdot.org/story/11/11/13/2152232/mac-os-x-sandbox-security-hole-uncovered
http://www.theinquirer.net/inquirer/news/2124732/apple-fails-fix-longstanding-sandbox-vulnerability
http://threatpost.com/en_us/blogs/mac-os-x-sandbox-security-hole-uncovered-111211

Edit:

Some words about the comments I’ve seen regarding the issue: It doesn’t affect the applications sandboxed directly from the source code. This issue only exist (as Apple suggests) when a user runs a -maybe untrusted- binary application in a sandboxed environment through the sandbox-exec command. Althought that is a problem itself, because the user would get a false sense of security, I think the main problem is that those profiles are provided as some sort of example. If a developer,  for instance, defines a sandbox environment for a critical application based on that rules, the new application will be as insecure as the default profiles.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

    Core Security - Corelabs Advisory
    http://corelabs.coresecurity.com/

 Apple OS X Sandbox Predefined Profiles Bypass

1. *Advisory Information*

Title: Apple OS X Sandbox Predefined Profiles Bypass
Advisory ID: CORE-2011-0919
Advisory URL: http://www.coresecurity.com/content/apple-osx-sandbox-bypass
Date published: 2011-11-10
Date of last update: 2011-11-10
Vendors contacted: Apple
Release mode: User release

2. *Vulnerability Information*

Class: Access control failure [CWE-264]
Impact: Code execution
Remotely Exploitable: Yes
Locally Exploitable: No
CVE Name: CVE-2011-1516

3. *Vulnerability Description*

Several of the default pre-defined sandbox profiles don't properly
limit all the available mechanisms and therefore allow exercising part
of the restricted functionality. Namely, sending Apple events is
possible within the no-network sandbox (kSBXProfileNoNetwork). A
compromised application hypothetically restricted by the use of the
no-network profile may have access to network resources through the
use of Apple events to invoke the execution of other applications not
directly restricted by the sandbox.

It is worth mentioning that a similar issue was reported by Charlie
Miller in his talk at Black Hat Japan 2008 [2]. He mentioned a few
processes sandboxed by default as well as a method to circumvent the
protection. Sometime after the talk, Apple modified the mentioned
profiles by restricting the use of Apple events but did not modify the
generic profiles.

4. *Vulnerable packages*

   . Apple Mac OS X 10.7.x
   . Apple Mac OS X 10.6.x
   . Apple Mac OS X 10.5.x

5. *Non-vulnerable packages*

   . Apple Mac OS X 10.4

6. *Vendor Information, Solutions and Workarounds*

Contact the vendor for more information.

7. *Credits*

This vulnerability was discovered and researched by Anibal Sacco and
Matias Eissler from Core Security Technologies. The publication of
this advisory was coordinated by Carlos Sarraute.

8. *Technical Description / Proof of Concept Code*

The use of Apple events is possible within the several default
profiles as no-network, no-internet (kSBXProfileNoNetwork,
kSBXProfileNoInternet) and others. A compromised application
hypothetically restricted by the use of the no-network profile may
have access to network resources through the use of Apple events to
invoke the execution of other applications not directly restricted by
the sandbox.

As Apple's "App Sandbox Design Guide" document points out,
applications that require sending Apple events to other arbitrary
applications are not suitable for sandboxing, because some developer
tools restrict Apple events by default while defining the sandbox. The
reason for this is that, as we show here, by dispatching Apple events
a process can escape the sandbox [1].

The method used by Charlie Miller involves dropping a script to the
disk and getting it executed by launchd via launchctl. Our approach is
technically the same without the need to drop a file. In our PoC we
used "osascript" to send the required Apple events to launchd in order
to execute the new process. As the new process is not a 'child' of the
sandboxed process, it is created without the sandbox restrictions.

An additional risk with these profiles is that they are supposed to
provide an example of how a process should be restricted in different
scenarios. If the no-network profile allows Apple-script events, this
may result in new applications using the same restriction rules,
therefore offering a false sense of security.

The following PoC illustrates this vulnerability:

/-----
import os
import sys
import socket

if len(sys.argv) != 2:
    print "[-] Usage: sandbox-exec -n no-network python %s hostname" %
sys.argv[0]

try:
    targetIP = sys.argv[1]
    s = socket.socket()
    s.connect((targetIP, 80))
    s.send('GET /\r\n\r\n')
    print(s.recv(1024))
    print "\n\n\n[+] Sandbox escaped"

except Exception, e:
    if "Operation not permitted" in str(e): #print repr(e)
        print "[-] Blocked by seatbelt"
        print "[ ] Escaping..."
        os.system("""/usr/bin/osascript -e 'tell application
"Terminal" to do script "python %s %s"'""" % (sys.argv[0], targetIP))

- -----/

9. *Report Timeline*

. 2011-09-20:
Core Security Technologies notifies Apple Product Security of the
vulnerability, including technical details. Preliminary publication
date is set to November 7, 2011.

. 2010-09-20:
Vendor acknowledges the receipt of the information.

. 2010-10-05:
Vendor informs that it does not see any actual security implications.
The kSBXProfileNoNetwork sandbox profile does not promise that Apple
Events will be blocked in the documentation. (Specifically, all it
guarantees is "all sockets-based networking is prohibited".)

. 2011-10-13:
Core responds that the kSBXProfileNoNetwork sandbox profile should
guarantee that "all sockets-based networking is prohibited". The PoC
sent to Apple shows that through the use of Apple events (osascript is
used in the PoC just to keep it simple) an attacker could circumvent
the restriction. So, at the end, sockets-based networking is used.

. 2010-10-18:
Vendor responds that it is currently considering modifying its
documentation to explicitly point out what Core described; namely,
that the restrictions that these particular sandbox profiles provide
are limited to the process in which the sandbox is applied.

. 2011-11-10:
The advisory CORE-2011-0919 is published as user release.

10. *References*

[1] App Sandbox Design Guide -- Designing for App Sandbox
http://developer.apple.com/library/mac/#documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html

[2] Charlie Miller, "Hacking OS X", Black Hat Japan 2008
https://www.blackhat.com/presentations/bh-jp-08/bh-jp-08-Miller/BlackHat-Japan-08-Miller-Hacking-OSX.pdf

11. *About CoreLabs*

CoreLabs, the research center of Core Security Technologies, is
charged with anticipating the future needs and requirements for
information security technologies. We conduct our research in several
important areas of computer security including system vulnerabilities,
cyber attack planning and simulation, source code auditing, and
cryptography. Our results include problem formalization,
identification of vulnerabilities, novel solutions and prototypes for
new technologies. CoreLabs regularly publishes security advisories,
technical papers, project information and shared software tools for
public use at: http://corelabs.coresecurity.com.

12. *About Core Security Technologies*

Core Security Technologies enables organizations to get ahead of
threats with security test and measurement solutions that continuously
identify and demonstrate real-world exposures to their most critical
assets. Our customers can gain real visibility into their security
standing, real validation of their security controls, and real metrics
to more effectively secure their organizations.

Core Security's software solutions build on over a decade of trusted
research and leading-edge threat expertise from the company's Security
Consulting Services, CoreLabs and Engineering groups. Core Security
Technologies can be reached at +1 (617) 399-6980 or on the Web at:
http://www.coresecurity.com.

13. *Disclaimer*

The contents of this advisory are copyright (c) 2011 Core Security
Technologies and (c) 2011 CoreLabs, and are licensed under a Creative
Commons Attribution Non-Commercial Share-Alike 3.0 (United States)
License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/

14. *PGP/GPG Keys*

This advisory has been signed with the GPG key of Core Security
Technologies advisories team, which is available for download at
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iEYEARECAAYFAk68OxMACgkQyNibggitWa0YWgCfYbGm9R0+YJw6CxP6TNwdhEWr
9ZMAn16nqBqNbO582D5QpejeuTEV5RAj
=HruN
-----END PGP SIGNATURE-----

Ph-Neutral

And the day finally came. The last (public, at least) edition of Ph-Neutral is very close and i gotta say: I’m very excited about being there.  Luckily, I’ll be arriving two days before the conference so I’m gonna have enough time to recover myself after the flight. I wanna be in good shape to deal with the -pretty insane- Ph-Neutral rhythm that usually consist in the mix of highly technical talks with amazing parties at night.

I’m also looking forward to seeing a lot of friends I only get to see a couple of times a year (at best) and, of course, im always happy to meet new people so if you wanna share a few beers with me drop me a mail (als.alsx), tweet me (@hannibals) or just look for the bald-guy-with-a-goat-beard near any of these talks:

Building your own TETRA radio sniffer  / Harald Welte (laforge)

Chip & PIN is definitely broken  / Andrea Barisani & Daniele Bianco

FreeBSD Kernel Exploitation  / argp

Advances in Win32 ASLR evasion  / JF

Exploiting the Hard-Working DWARF:

Trojans with no Native Executable Code  / James Oakley & Sergey Bratus

1 fact + 2 rules – 3 outcomes = 0 good news for you! (or how I walked in and destroyed your company)  / Jayson E. Street

Exploit Next Generation ++  / Nelson Brito

98% Zero-Day Virus Detection (by natural language training)  / Shirtie

You can read more and see some of the abstracts here

Jailbreakme

Hey guys! It’s been a long time since my last post… I’ve been very busy with some personal projects but i though this advisory deserveded at least a small post about it.

I’ll make it short; Matias Eissler, a teammate at Core triggered the Jailbreakme bug in OSX, so we decided to spend some time researching it.

But, what we found is a completely different bug, when handling exactly the same type of component. And, btw, it has *very* dangerous attack vectors.

For all these things (and because we wanna support this amazing project) we are gonna give a small talk about this bug, its attack vectors and its exploitation (Core Impact already counts with a working multiversion exploit) today, on the upcoming Open Security Jam 2010 as an event of the La Fabrica de Inventos, the first BsAs. Hackerspace.

Hope to see some of you there.

Oh, another little thing! This advisory was released as “User Release”. That means that Apple still didn’t patched it. Although it was reported to apple almost 3 months ago.
I suggest you to read the timeline. I think this was the right thing to do. Apple likes to establish dates that is not going to honor and.. to be honest, it looks like some kind of power demonstration technique to me.
And… they might not have *that* power.

Apple OS X ATSServer CFF CharStrings INDEX Sign Mismatch
1. Advisory Information

Title: Apple OS X ATSServer CFF CharStrings INDEX Sign Mismatch
Advisory Id: CORE-2010-0825
Advisory URL: http://www.coresecurity.com/content/Apple-OSX-ATSServer-CharStrings-Sign-Mismatch
Date published: 2010-11-08
Date of last update: 2010-11-08
Vendors contacted: Apple
Release mode: User release
2. Vulnerability Information

Class: Input validation error [CWE-20]
Impact: Code execution
Remotely Exploitable: Yes (client-side)
Locally Exploitable: No
CVE Name: CVE-2010-1797
Bugtraq ID: N/A
3. Vulnerability Description

The Apple Type Services is prone to memory corruption due a sign mismatch vulnerability when handling the last offset value of the CharStrings INDEX structure.

This vulnerability could be used by a remote attacker to execute arbitrary code, by enticing the user of Mac OS X v10.5.x to view or download a PDF document containing a embedded malicious CFF font (Compact Font Format [1]).

This vulnerability is a variation of the vulnerability labeled as CVE-2010-1797 (FreeType JailbreakMe iPhone exploit variation).
4. Vulnerable packages

* Apple Mac OS X v10.5.x

5. Solutions and Workarounds

According to information provided to us by Apple, a patch for this fix has already been developed. Apple provided us a release date for this patch in two opportunities but then failed to meet their our deadlines without giving us any notice or explanation.

Apple Mac OSX 10.6 is not affected by this vulnerability, upgrading to this version is highly recommed when possible.
6. Credits

This vulnerability was discovered and researched by Anibal Sacco and Matias Eissler, from Core Security Technologies. Publication was coordinated by Fernando Russ and Pedro Varangot.
7. Technical Description

When loading a PDF with an embedded CFF font a sign mismatch error exists in ATSServer when handling the last offset value of the CharStrings INDEX structure.
This could be triggered in different ways:

* When trying to make a thumbnail of the file
* When trying to open the file with the Preview app
* Serving the file in a web server and tricking the user to click on it.
* Embedded in an email (if handled by Mail.app)

This allows to corrupt the process memory by controlling the size parameter of a memcpy function call allowing an attacker to get code execution.

At [00042AFA] we can see how the value obtained from the file is sign extended prior to be passed to the function loc_370F0. Inside this function this value will be used as the size parameter of memcpy:

00042AF2 movsx eax, word ptr [edx+5Eh] 
00042AF6 mov [esp+0Ch], eax 
00042AFA movsx eax, word ptr [esi+4] 
00042AFE mov [esp], edi 
00042B01 mov [esp+8], eax 
00042B05 mov eax, [ebp-2Ch] 
00042B08 mov [esp+4], eax 
00042B0C call loc_370F0 

An attacker could take advantage of this condition by setting a negative offset value (0xfffa) in the file that will be converted to a DWORD without enough validation leading to a memcpy of size 0xfffffffa.

This vulnerability results in arbitrary code execution.
8. Report Timeline

* 2010-08-26: Vendor contacted, a draft of this advisory is sent and September 28th is proposed as a coordinated publication date. Core remarks that since this is a variation of a publicly disclossed vulnerability it may have already been discovered by other security researchers like vulnerability research brokers or independent security researchers.
* 2010-08-28: The Apple Product Security team acknowledges the report, saying that they were able to reproduce the issue in Mac OS X 10.5 but not in Mac OS X 10.6, they also said that the deadline for September 28th will be imposible to meet.
* 2010-08-30: Core informs Apple that there is no problem changing the publication date for the report, whenever the new publication date remains reasonable. Also, Core asks for a tentive timeframe for the fix, and confirm that Mac OS X 10.6 does not seem to be affected.
* 2010-08-31: Apple acknowledges the comunication informing the publication timing, and state that they are still trying to determine the most appropiate timeframe.
* 2010-09-28: Core asks the vendor for an update regarding this issue. Also, Core asks for a specific timeframe for the fix, and sets October 18th as tentative publication date.
* 2010-09-28: Apple acknowledges the comunication informing that this issue will be fixed in the next security update of Mac OS X 10.5, which is tentatively scheduled for the end of October without a firm date of publication.
* 2010-08-31: Apple asks Core about credit information for the advisory.
* 2010-09-28: Core acknowledges the comunication sending the credit information for this report.
* 2010-10-20: Core asks Apple for a firm date for the release of this securiry issue since the initial propossed timeframe of October 18th is due.
* 2010-10-22: Apple acknowledges the comunication informing that the publication date is scheduled to the week of October 25th. Also, Apple notifies that the assigned identifier for this vulnerability is CVE-2010-1797.
* 2010-11-01: Core asks Apple for a new schedule for the publication, since there was no notice of any Apple security update during the week of October 25th.
* 2010-11-01: Apple acknowledges the communication informing that the publication date was rescheduled to the middle of the week of November 1st.
* 2010-11-03: Core informs Apple that the publication of this advisory was scheduled to Monday 8th, taking into account the last communication this is a final publication date. Core also informs that the information about how this vulnerability was found and how it can be exploited will be discussed in a small infosec related local event in Buenos Aires city.
* 2010-11-08: Core publishes advisory CORE-2010-0825.

9. References

[1] http://en.wikipedia.org/wiki/PostScript_fonts#Compact_Font_Format
10. About CoreLabs

CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com.
11. About Core Security Technologies

Core Security Technologies develops strategic solutions that help security-conscious organizations worldwide develop and maintain a proactive process for securing their networks. The company’s flagship product, CORE IMPACT, is the most comprehensive product for performing enterprise security assurance testing. CORE IMPACT evaluates network, endpoint and end-user vulnerabilities and identifies what resources are exposed. It enables organizations to determine if current security investments are detecting and preventing attacks. Core Security Technologies augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web at http://www.coresecurity.com.
12. Disclaimer

The contents of this advisory are copyright (c) 2010 Core Security Technologies and (c) 2010 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/
13. PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc.

Breakpoint

Conditional breakpoints. Ohh beloved conditional breakpoints!

Everybody loves conditional breakpoints. They allows us to wait at a certain moment to stop, sparing us a lot of tedious manual tracing. There isn’t anything easier and more gratifying that hooking our process’ code by just setting a breakpoint, typing some lines, and looking our process stopped right there, when the fun starts.

Nowadays, almost every decent debugger counts with hardware breakpoints. Some of them with very flexibles interfaces and some others with very limited ones. In fact, this is a crucial point when deciding the limit between a complex hardware breakpoint and the use of a debugging library/tool that allows us to have full control of the context to programatically manipulate the process execution as we need.

When talking about IDA, we can say that it has a very flexible interface because it allows us to define the breakpoint conditions using the IDC scripting language. It’s mostly used to express very simple conditions like EAX == 0×1 or to do little memory modifications. But, as an IDAPython fan, I’ve always wanted to be able to use IDAPython when handling my quick conditional breakpoints.

Thinking on this and with the help of some friends i managed to get a way to reuse the tip I’ve previously shared with you here.
The idea behind this post is to take advantage of the posibilities of using IDC in conditional breakpoints to define an IDC function that will execute and evaluate an IDAPython function.

To demonstrate this I’ve made a very simple script called conditional_plugin.py that can be used as a template for more elaborated scripts.
Let’s see the code. It’s divided in two main parts: The one in charge of setting a breakpoint in a desired address, and one in charge of the handling of it.

def set_bp(address, cnd):

 global cond_file

 print "[+] Setting conditional IDAPython breakpoint on %08x" % address

 add_bpt(address, 0, BPT_SOFT)
 enable_bpt(address, True)
 SetBptCnd(address, cnd)

idaapi.CompileLine('static cond() {return (RunPythonStatement("condition()") | Byte(0x10000));}')
set_bp(ScreenEA(), 'cond()')

We can clearly see that set_bp only sets a breakpoint (in this example, a software breakpoint), enables it, and defines a condition for it.
The next two lines are very similar to this. There is a small caveat with this technique but we’ll talk about the particularities of this case later. By now, we’ll just take care of:

1 – Define the IDC function “func()” that will be in charge through RunPythonStatement of calling our Python function “condition()“.
2 – Set cond() as breakpoint condition
Then we have the IDAPython condition itself:

def condition():
...

 # Condition
 eax = GetRegValue("EAX")
 if eax != 0x0:
 print "[+] Condition met"
 BREAK()
 else:
 CONTINUE()

It’s in this function where we’ll be doing the IDAPython magic to handle our breakpoint.
In this example we’ll just get the EAX value to compare it with an specific value. If the condition is met, we’ll call BREAK() to stop the process execution. Otherwise, we’ll call CONTINUE() to continue with the normal execution. Let’s see this two functions

CONTINUE = lambda: PatchByte(0x10000,0)
BREAK = lambda: PatchByte(0x10000,1)

These are just some DEFINE-like lines to get rid of the problem i’ve mentioned before. RunPythonStatement always returns 0. As there is no way to obtain a value sent from python I chose to use a byte from the process memory space as a global variable through IDC and IDAPython.
Probably there are better solutions to this issue out there. I must admit didn’t search enough. Anyway, if somebody has a better idea, I’ll be glad to hear about it

Here, we’ll simply use PatchByte() to put 0 or 1 at address 0×10000, the memory address used by every process to hold the environment variables.

This explains the line that defines the cond() function:

idaapi.CompileLine('static cond() {return (RunPythonStatement("condition()") | Byte(0x10000));}')

It’s just a dirty way to keep it a oneliner: RunPythonStatement always returns 0, so Byte(0×10000) is what really matters. that way cond() will return 0 or 1 depending on which function (CONTINUE or BREAK) we called.

So, there you have it! A quick ‘n dirty way to programaticaly handle breakpoints with IDAPython.

Of course, this is obviously just a basic example. Based in this template we can implement a lot of different techniques like memory tracking, function monitoring, process patching, bypasses of anti debugging methods, code injection, and much more fun!

If my laziness doesn’t stop me -as it usually does- I will try to put together a few scripts I’ve made to offer you a few different starting-points.

See ya!

IDAPython

Today, i want to share with you a very useful tip that ive been using for a while, and i particulary like. Gera posted a variation of it in the IDA official forum some time ago but i think that would be useful to share it also here.

Usually, in IDA, we find ourselves needing a way to define a shortcut for that useful IDAPython script to bypass the tedious “alt+9 + [select the wanted IDAPython script] + enter” procedure.

When i finished the FindInFunc script (you can read my previous post about it here), i faced that situation for the Nth time and i finally managed to get an easy hack to get it working.

We know that it is possible to set a shortcut to an IDC script by defining it in the idamain.cfg so after googling for a while i went to the IDAPython source and i’ve found this:

/* Simple Python statement runner function for IDC */
static const char idc_runpythonstatement_args[] = { VT_STR, 0 };
static error_t idaapi idc_runpythonstatement(value_t *argv, value_t *res)
{
res->num = PyRun_SimpleString(argv[0].str);
return eOk;
}

http://code.google.com/p/idapython/source/diff?spec=svn32&r=32&format=side&path=/trunk/python.cpp

This functions alows us to execute a python sentence in the context of an IDC script… Dude! It’s pretty much convenient for our purposes because if we do:

RunPythonStatement("execfile 'c:\pathoffile\script.py'")

Voila! We have our script executed.

So, all we need now is to add something like this to the main() function in ida.idc:

AddHotkey("Alt-F8", "py_findinfunc");

And then, add this handler at the end, in the same file.

static py_findinfunc()
{
RunPythonStatement("execfile('c:\\FindInFunc.py')");
}

Sometimes, we want to jump to some piece of code where we’ve never been before. We can not use the “Text Search” command for this task because it will search for the pattern through the whole binary. Well, we can in fact, but its not going to be so optimal.

For that problem i’ve coded a little IDAPython script who searchs for an string within the limits
of a defined function. I wanted to share it with you as another example of the IDA + Python customization
posibilities.

from idautils import *
from idaapi import *

function_start = ScreenEA()
function_end   = FindFuncEnd(function_start)
matches = ""

pattern = AskStr("","Search for:")
for head in Heads(function_start, function_end):
 if isCode(GetFlags(head)):
 code = "%s %s %s" %(GetMnem(head),GetOpnd(head,0),GetOpnd(head,1) )
 if pattern in code:
 matches += "0x%x - %s\n" % (head ,code)
print "Results:"
print matches

Hope this is useful for you.

Peludo

Oh yeah!. Have you heard about Peludo from the Netifera guys?

You should. From the netifera’s page:

“Peludo is a system to create and run platform independent, self-contained and injectable applications written in the C programming language. It provides a cross compiling environment with the tools to generate applications in Peludo’s new binary format (PLD). The system also provides the runtime necessary to launch these programs as independent executable files or as position independent code that can be injected into a runnning process. Peludo makes the netifera probe’s Java virtual machine injectable and easier to port to new platforms.”

This is just a beta release. By now it only supports Linux/x86 and FreeBSD/amd64 as host and Linux/i386 as target platform but you can bet the Netifera guys are gonna extend this in nothing.

Inside Peludo’s tgz you will find a very complete documentation about what Peludo is and how it works together with a fully commented source code and very clear use instructions.

You can download it here.

Ekoparty Security Conference

Well… everybody knows Ekoparty. One of the most important Security Conferences at south america.  And a very important event in the local scene.

Of course, Alfred and I will be talking there. This’ll be a great opportunity for us to show all the PoC that we left out (coz of the Turbo Talk) in the past Black Hat – Las Vegas.

So, i hope you be there.

If you wanna share a beer (or two) and chat a bit.  Please drop me a msg.

BlackHat 2009 - Vegas

Has been a long time since my last post here… Alfred and I were working very hard for our last research/talk (the continuation of ‘Persistant BIOS Infection’) “Deactivate the rootkit” where we found that Computrace  (an Anti-Theft Technology system) comes by default on most of the laptops BIOSes and it can be controlled by an attacker compromising the whole system’s security mechanisms.

Im not going to explain all the research here… a lot has been said about this. We just did a turbo-talk at black hat ( a very long one, im really happy about that) and we didnt have the time to show all the proofs we gathered but we did it through Core. Here is all the stuff. Draw Your Own Conclusions

Slides: Black Hat – Las Vegas 2009

White Paper : Black Hat – Las Vegas 2009

Then, after some words of the computrace guys denying almost all our findings (here), we made public this page with all the proof, meaning: a tool to detect if your laptop has computrace in it, a network dump showing the first stage of the communication in plain text :S, several videos demonstrating what we said, and a tool to control and redirect computrace.

You can find the Core Security response here:

and the Core’s project page here.

A few pages who covered the talk:

Slashdot

ZDNet

SecurityFocus

Reddit