[EMAIL PROTECTED] wrote:
> ari edelkind <[EMAIL PROTECTED]> writes:
> > Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is
> > already being traced. As for core files, a process can use
> > setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory
> > pages may be encr
Dag-Erling Smørgrav wrote:
> ari edelkind <[EMAIL PROTECTED]> writes:
> > Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is
> > already being traced. As for core files, a process can use
> > setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory
> > pages may
ari edelkind <[EMAIL PROTECTED]> writes:
> Keep in mind that ptrace(PT_ATTACH,...) will fail if a process is
> already being traced. As for core files, a process can use
> setrlimit(RLIMIT_CORE,...) to disable core dumps, and individual memory
> pages may be encrypted or unloaded, to be decrypted
"Thiago Damas" <[EMAIL PROTECTED]> writes:
> And if you make a wrapper, and execute like a shell script:
>
> #!/usr/local/bin/mysecyritywrapper
> <...encryted code goes where...>
>
> In this way. it'll be hard to use truss, ktrace, strace etc...
Uh, no, not at all. Not even a little. Hint: 'kt
[EMAIL PROTECTED] wrote:
> What prevents me from patching the kernel (!) to just ignore the
> resource limit? Nothing.
Exactly! I mean, it won't help that much if you have pages that haven't
been loaded or decrypted. But if you're patching the kernel anyway, you
can always have it log the decryp
On Feb 20, 2008, at 20:18 , Joerg Sonnenberger wrote:
On Wed, Feb 20, 2008 at 09:39:03PM -0500, ari edelkind wrote:
Mind you, it's true that disabling core dumps with a resource limit
doesn't keep one from creating a core image using gcore, but since
gcore
generally must either attach to a
On Wed, Feb 20, 2008 at 09:39:03PM -0500, ari edelkind wrote:
> Mind you, it's true that disabling core dumps with a resource limit
> doesn't keep one from creating a core image using gcore, but since gcore
> generally must either attach to a process using ptrace() or access
> mapped code segments
> >#!/usr/local/bin/mysecyritywrapper
> ><...encryted code goes where...>
> >
> > In this way. it'll be hard to use truss, ktrace, strace etc...
>
> No, not really. All of those tools can trace through
> to sub-processes, so whenever the code gets decrypted and
> starts executing (whether it's i
Thiago Damas wrote:
And if you make a wrapper, and execute like a shell script:
#!/usr/local/bin/mysecyritywrapper
<...encryted code goes where...>
In this way. it'll be hard to use truss, ktrace, strace etc...
No, not really. All of those tools can trace through
to sub-processes, so whe
On Wed, 20 Feb 2008 09:51:23 -0300 "Thiago Damas" <[EMAIL PROTECTED]> wrote:
> And if you make a wrapper, and execute like a shell script:
>
> #!/usr/local/bin/mysecyritywrapper
> <...encryted code goes where...>
>
>
> In this way. it'll be hard to use truss, ktrace, strace etc...
Depends
And if you make a wrapper, and execute like a shell script:
#!/usr/local/bin/mysecyritywrapper
<...encryted code goes where...>
In this way. it'll be hard to use truss, ktrace, strace etc...
[]s
On Feb 19, 2008 1:09 AM, Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> On 2008-02-18 19:54,
Hi Warner,
On Mon, Feb 18, 2008 at 09:44:59PM -0700, M. Warner Losh wrote:
> kill -ABRT
>
> will generate a core file.
>
> Often times, the core file can be quite useful in recovering the
> original executable.
>
> emacs has used this technique for years to 'preload' stuff, take a
> core dump,
In message: <[EMAIL PROTECTED]>
Giorgos Keramidas <[EMAIL PROTECTED]> writes:
: On 2008-02-18 19:54, Jerry Toung <[EMAIL PROTECTED]> wrote:
: >On Feb 18, 2008 5:39 PM, Dimitry Andric <[EMAIL PROTECTED]> wrote:
: >>On 2008-02-19 02:18, Jerry Toung wrote:
: >>> anybody knows of a tool to
On Feb 18, 2008 8:13 PM, Mike Meyer <
[EMAIL PROTECTED]> wrote:
>
> Basically the DRM problem (only executing your property under
> conditions you specify, not under those the end user might want). A
> *lot* of money has been spent trying to do this, but nobody has done
> it yet. Some very smart p
On Mon, 18 Feb 2008 19:54:14 -0800 "Jerry Toung" <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2008 5:39 PM, Dimitry Andric <[EMAIL PROTECTED]> wrote:
> > On 2008-02-19 02:18, Jerry Toung wrote:
> > > anybody knows of a tool to encrypt executables under FreeBSD? may be
> > from
> > > the ports?
> > > I a
On 2008-02-18 19:54, Jerry Toung <[EMAIL PROTECTED]> wrote:
>On Feb 18, 2008 5:39 PM, Dimitry Andric <[EMAIL PROTECTED]> wrote:
>>On 2008-02-19 02:18, Jerry Toung wrote:
>>> anybody knows of a tool to encrypt executables under FreeBSD? may be
>>> from the ports? I am not talking about simple file
On Feb 18, 2008 5:39 PM, Dimitry Andric <[EMAIL PROTECTED]> wrote:
> On 2008-02-19 02:18, Jerry Toung wrote:
> > anybody knows of a tool to encrypt executables under FreeBSD? may be
> from
> > the ports?
> > I am not talking about simple file encryption.
>
> Can you elaborate on what you *are* tal
you elaborate on what you *are* talking about then? Some
> security-by-obscurity scheme, perhaps? :)
Encrypted executables, using some sort of stream or block cipher may not
be something which looks *very* useful, but there are a few interesting
things which can be done with executable encryption
On 2008-02-19 02:18, Jerry Toung wrote:
> anybody knows of a tool to encrypt executables under FreeBSD? may be from
> the ports?
> I am not talking about simple file encryption.
Can you elaborate on what you *are* talking about then? Some
security-by-obscurity scheme, perhaps? :)
Good afternoon list,
anybody knows of a tool to encrypt executables under FreeBSD? may be from
the ports?
I am not talking about simple file encryption.
I found something called 'burneye' but it's for Linux.
Thank you all,
Jerry
___
freebsd-hackers@freebs
20 matches
Mail list logo
