|
Focus on Apple
Security and Leopard (Mac OS X 10.5) Oct 25 2006 08:01PM Todd Woodward (todd_woodward symantec com) (1 replies) Re: Security and Leopard (Mac OS X 10.5) Oct 26 2006 04:14PM Philippe Devallois (phdevallois intego com) (2 replies) Re: Security and Leopard (Mac OS X 10.5) Oct 27 2006 12:53PM Simon Slavin (s slavin lancaster ac uk) (1 replies) Re: Security and Leopard (Mac OS X 10.5) Oct 27 2006 06:16PM Mark Senior (senatorfrog gmail com) (2 replies) Re: Security and Leopard (Mac OS X 10.5) Oct 30 2006 12:24PM Simon Slavin (s slavin lancaster ac uk) (2 replies) RE: Security and Leopard (Mac OS X 10.5) Oct 31 2006 02:37AM rlandsberg (rlandsberg optusnet com au) Re: Security and Leopard (Mac OS X 10.5) Oct 30 2006 05:53PM Derek Chesterfield (dez mac com) (2 replies) Re: Security and Leopard (Mac OS X 10.5) Oct 31 2006 10:38AM Simon Slavin (s slavin lancaster ac uk) Re: Security and Leopard (Mac OS X 10.5) Oct 28 2006 04:45PM Jim Foraker (jf6b andrew cmu edu) (2 replies) |
|
Privacy Statement |
http://semthex.freeflux.net/blog/
The fellow who developed this workaround isn't distributing it, but
others surely will. Given that anyone who owns an Intel Mac has a
copy of the TPM key, it's a good bet that someone who isn't afraid to
break the DMCA (or simply lives in a country where it doesn't apply)
will do so shortly.
On 10/28/06, Jim Foraker wrote:
> On 10/27/06, Mark Senior wrote:
> > And, I suspect using encrypted binaries might in fact gain you
> > something - as long as the AES key is only distributed underground,
> > legitimate researchers mostly won't have access to it. So, any
> Legitimate researchers are not that bad at getting their hands on
> underground tools, once they're known to exist. And if the key gets
> out, it probably won't stay a well-guarded secret for long: too many
> folks want to run OSX on non-Apple hardware.
They may be able to get their hands on the key, but their hands would
be tied by laws such as the DMCA. Circumventing a DRM mechanism is
illegal - the reason for circumventing (e.g. to reverse engineer a
virus) is irrelevant, as is the fact that the DRM mechanism already
had to be circumvented in order to create the target of study.
> > AES-encrypted binaries would be much more difficult for the good guys
> > to reverse-engineer, to figure out what the bad guys are up to.
> More difficult, yes. Given that the OS will happily decrypt the
> segment for you though, I suspect that there are tools that can be
> written to work around the problem.
Yes, but as I understood it the the kernel will only decrypt the
segment to map it to executable memory. The kernel will let you run
an encrypted virus, just not study it.
http://osxbook.com/book/bonus/chapter7/binaryprotection/
You could possibly do some clever trick like load it into a debugger,
not start the execution, and then dump the core as plaintext. But
that's a lot of trouble, and it's also somewhat risky - you want to
treat suspicious code with a circumspection...
Tools to simply decrypt the file without letting it anywhere near an
execution pointer could easily be written, but technical ease and good
motivation for writing such tools doesn't make them legal under the
DMCA.
[ reply ]