full-disclosure - Re: A modest proposal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 19 Jul 2012 18:43:52 -0700
From: Gage Bystrom <themadichib0d@...il.com>
To: Glenn and Mary Everhart <everhart@....com>, 
	"full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: A modest proposal

1.) waste of a reference by no follow through :( shame shame
2.) The only real problem with that idea is that you'd be doing it wrong.
As in what you are doing does not accomplish what you want it to do. Those
polymorphic techniques are there to prevent identification, not necessarily
to prevent hooking, code injection, and reverse engineering. You use
completely different techniques for those.
3.) It wouldn't be hard to get around it. Just replace a dll or two with
the functions you want to intercept and analyze the output. They couldn't
care less how polymorphic your code is if it still needs to pass the juicy
data to a library function. And in a lot of cases they are already doing
this, so its highly possible that you could suddenly take an application a
piece of malware was designed to harvest information from, make it all
polymorphic, and the same old malware version could still mess with it. And
yes, it would still he able to identify the application cause the end user
needs to be able to identify it and the malware would just use whatever
method the end user would to spot it for injection or what not.
3.) I will say, at least you're thinking, even if its flawed.
On Jul 19, 2012 6:24 PM, "Glenn and Mary Everhart" <everhart@....com> wrote:

> Hello, FD...
> A thought occurred to me:
> Why not use the same kind of polymorphism and software metamorphism that
> is used by malware writers as a protective measure?
>
> If you have a piece of code that you don't want malware to be able to
> inspect, that might perhaps
> have some "secrets" in it or that you want not to be trivial to have
> some other code patch,
> why not arrange for that code to be different in form (but the same in
> function) with every copy?
>
> (For places that insist on code that must be signed, you might need to
> have only perhaps scores or
> hundreds of variants, and then make it clear that the "signed code"
> requirements were making
> the systems that have them LESS secure than those without. <bwahahaha>.
> <grin>.)
>
> There are many ways to achieve this kind of result. Many would result in
> somewhat larger
> executables or the like, or possibly larger data, but some of the
> methods don't even need access
> to source code. (I would suspect many systems like this will be clearest
> to those of us who have
> worked in assembly languages and the like over the years, but that is a
> bit beside the point.)
>
> If every copy of a program is laid out differently, and data gets moved
> around also from copy
> to copy, the job of the attacker would seem to get much harder.
>
> Glenn Everhart
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/