Concealing an app from DTrace

  • I found this old message:

        http://lists.apple.com/archives/cocoa-dev/2010/Mar/msg01042.html

    in which stated:

        If you think this is going to help you avoid piracy, it's not. OS X
        has a flag (PT_DENY_ATTACH) that the kernel checks for when a debugger
        asks to attach to a process. If that flag is set, the kernel refuses
        to allow the debugger to attach. iTunes famously does this to prevent
        people from inspecting the operations of the DRM system. It's a
        trivial matter to patch the kernel to not respect this flag,

    I was just wondering if this is still true or true in general...that it is not possible to conceal an application from DTrace.

    Thank you.
  • On May 1, 2012, at 6:04 PM, Eric Gorr <mailist...> wrote:

    > I found this old message:
    >
    > http://lists.apple.com/archives/cocoa-dev/2010/Mar/msg01042.html
    >
    > in which stated:
    >
    > If you think this is going to help you avoid piracy, it's not. OS X
    > has a flag (PT_DENY_ATTACH) that the kernel checks for when a debugger
    > asks to attach to a process. If that flag is set, the kernel refuses
    > to allow the debugger to attach. iTunes famously does this to prevent
    > people from inspecting the operations of the DRM system. It's a
    > trivial matter to patch the kernel to not respect this flag,
    >
    > I was just wondering if this is still true or true in general...that it is not possible to conceal an application from DTrace.

    It is true and will be true as long as your are able to compile your own kernel. Think about it.

    --Kyle Sluder
  • Thanks Kyle.

    Is that the only way? Or is there something easier that would bypass the flag?

    In my case, I am not sure i would be concerned if a custom kernel was required.

    On May 1, 2012, at 9:28 PM, Kyle Sluder <kyle...> wrote:

    > On May 1, 2012, at 6:04 PM, Eric Gorr <mailist...> wrote:
    >
    >> I found this old message:
    >>
    >> http://lists.apple.com/archives/cocoa-dev/2010/Mar/msg01042.html
    >>
    >> in which stated:
    >>
    >> If you think this is going to help you avoid piracy, it's not. OS X
    >> has a flag (PT_DENY_ATTACH) that the kernel checks for when a debugger
    >> asks to attach to a process. If that flag is set, the kernel refuses
    >> to allow the debugger to attach. iTunes famously does this to prevent
    >> people from inspecting the operations of the DRM system. It's a
    >> trivial matter to patch the kernel to not respect this flag,
    >>
    >> I was just wondering if this is still true or true in general...that it is not possible to conceal an application from DTrace.
    >
    > It is true and will be true as long as your are able to compile your own kernel. Think about it.
    >
    > --Kyle Sluder
  • > Is that the only way? Or is there something easier that would bypass the flag?

    There are several that I know of.  But my question first, to you, is why?  I can tell you now that you can't reliably defend against all approaches.  What you can do is make things really awkward for yourself for debugging, slightly awkward for profiling, and problematic for your users as they fail to get normal system behaviours like crash reporting.
  • On Tue, May 1, 2012 at 6:28 PM, Kyle Sluder <kyle...> wrote:

    >> I was just wondering if this is still true or true in general...that it is not possible to conceal an application from DTrace.

    > On May 1, 2012, at 6:04 PM, Eric Gorr <mailist...> wrote:
    > It is true and will be true as long as your are able to compile your own kernel. Think about it.

    Even if you couldn't compiler your own kernel there are all kinds of
    ways to defeat this:

    - Hot-Patch the running kernel by editing its memory space with a
    kernel debugger or even just a hex editor.

    - Load a device driver (Kernel Extension in the case of iOS and OS X)
    that does the hot-patching.

    - Patch the executable binary of the program that you want to crack,
    by writing some No-Op instructions over the code that sets that flag.

    - Build from source any of the libraries that are in the call chain
    from the attempt to set the flag to the context switch into the
    kernel.

    - Replace any of those libraries at runtime, when they dynamic
    libraries are linked, in just the same way as Guard Malloc replaces
    the regular memory allocation library.

    - Rather than replace a library, insert a "shim", that is, what
    appears to the app to be a library, but is just a thin veneer that
    calls through to the regular library, but in certain routines it
    either alerts the input parameters, the output results, or it just
    returns immediately when called rather than calling down to lower
    levels.

    When I was at Working Software in the early nineties, most of our
    products were what the company founder describes as "Virus-Like
    Hacks", with the difference that our products' users wanted them on
    theirs Macs, paid good money for them, and they were packaged in
    full-color boxes with attractive, well-written manuals.

    --
    Don Quixote de la Mancha
    Dulcinea Technologies Corporation
    Software of Elegance and Beauty
    http://www.dulcineatech.com
    <quixote...>
  • Thanks Don. This is what I was looking for in response to my inquiry.

    Sent from my iPad

    On May 2, 2012, at 1:04 AM, Don Quixote de la Mancha <quixote...> wrote:

    > On Tue, May 1, 2012 at 6:28 PM, Kyle Sluder <kyle...> wrote:
    >
    >>> I was just wondering if this is still true or true in general...that it is not possible to conceal an application from DTrace.
    >
    >> On May 1, 2012, at 6:04 PM, Eric Gorr <mailist...> wrote:
    >> It is true and will be true as long as your are able to compile your own kernel. Think about it.
    >
    > Even if you couldn't compiler your own kernel there are all kinds of
    > ways to defeat this:
    >
    > - Hot-Patch the running kernel by editing its memory space with a
    > kernel debugger or even just a hex editor.
    >
    > - Load a device driver (Kernel Extension in the case of iOS and OS X)
    > that does the hot-patching.
    >
    > - Patch the executable binary of the program that you want to crack,
    > by writing some No-Op instructions over the code that sets that flag.
    >
    > - Build from source any of the libraries that are in the call chain
    > from the attempt to set the flag to the context switch into the
    > kernel.
    >
    > - Replace any of those libraries at runtime, when they dynamic
    > libraries are linked, in just the same way as Guard Malloc replaces
    > the regular memory allocation library.
    >
    > - Rather than replace a library, insert a "shim", that is, what
    > appears to the app to be a library, but is just a thin veneer that
    > calls through to the regular library, but in certain routines it
    > either alerts the input parameters, the output results, or it just
    > returns immediately when called rather than calling down to lower
    > levels.
    >
    > When I was at Working Software in the early nineties, most of our
    > products were what the company founder describes as "Virus-Like
    > Hacks", with the difference that our products' users wanted them on
    > theirs Macs, paid good money for them, and they were packaged in
    > full-color boxes with attractive, well-written manuals.
    >
    > --
    > Don Quixote de la Mancha
    > Dulcinea Technologies Corporation
    > Software of Elegance and Beauty
    > http://www.dulcineatech.com
    > <quixote...>
  • On May 2, 2012, at 12:04 AM, Don Quixote de la Mancha wrote:

    > On Tue, May 1, 2012 at 6:28 PM, Kyle Sluder <kyle...> wrote:
    >
    >>> I was just wondering if this is still true or true in general...that it is not possible to conceal an application from DTrace.
    >
    >> On May 1, 2012, at 6:04 PM, Eric Gorr <mailist...> wrote:
    >> It is true and will be true as long as your are able to compile your own kernel. Think about it.
    >
    > Even if you couldn't compiler your own kernel there are all kinds of
    > ways to defeat this:
    > [... snip ...]

    My recollection is that it was even easier to defeat.  You just start the target program with the debugger, as opposed to attaching to it already running, break on ptrace() where it attempts to deny attaching, and simply short-circuit the call.

    Regards,
    Ken
previous month may 2012 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Go to today