ale
potential for conflict.
In fact, even src-bin may be too broad, and it may make sense to have
separate projects within the collection hierarchy. This would, at
least, make reparenting projects (say, from src-bin to src-usrbin)
easier.
ari
___
freebsd-h
[EMAIL PROTECTED] wrote:
> echo "*** generating ls..."
> file=`mktemp /tmp/ls.XX`
> [[ $? -eq 0 ]] || exit 1
Er, s/^file/lsfile/, obviously.
ari
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailm
must account
for CR/LF conversion in file transfers or while editing your script.
You probably won't want to deal with all of this, and would be better
off leaving it for out-of-band extraction, such as with dan's gzexe
suggestion. You'll still need to determine whether
[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 individ
lways have it log the decrypted pages as they're loaded.
There wasn't anything in my original e-mail that should make you think i
was claiming you couldn't defeat binary encryption and protection
measures (especially not the link that i included about defeating
shiva). But naive simpl
case, either.
That said, here's a set of slides from a talk on attacking
shiva-encrypted binaries:
http://www.blackhat.com/presentations/bh-federal-03/bh-federal-03-eagle/bh-fed-03-eagle.pdf
ari
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
work with 7.0 betas
before, but with this patch things run as well as they did
on 6.x.
Ari S.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
391 #if (!__GLIBC__)
This is typical for libnet, and it has run into compatibility problems
of this sort in the past on systems other than freebsd. Search for
"edelkind libnet" or "redefinition libnet" on google for some of these.
ari
ly to me and cc
> to the list :-).
> Thanks.
In the future, please respond to personal mails personally. Neither my
direct e-mail address nor this mail were intended for public viewing.
The post to which i was referring is:
http://lists.freebsd.org/pipermail/freebsd-hac
n't matter for any inline
functions you may be using within the header file (chances are, this
assumption is valid):
#include
#include
#define ether_addr ether_addr_BROKEN_LIBNET
# include
#undef ether_addr
ari
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
:
ioperm_args dd 378h
dd 3
dd 1
argp dd ioperm_args
[...]
push dword argp
push dword I386_SET_IOPERM
[...]
Get this wrong, and you'll have unpredictable results.
ari
___
freebsd-hackers@freebsd.org ma
;s
answer, but it's exactly what you'd find there.
That said, C library calls are no more difficult to perform from assembly
language than system calls, so long as you're willing to link in the
standard C library. If you're trying to be more portabl
[EMAIL PROTECTED] wrote:
> > It will not help, since AFAIK you can't seek stdin anyway, or even if I
> > am wrong and you can seek it to the end you will be unable to seek it
> > backward.
>
> I tested the patch before posting it, fully expecting to find that stdin
> really cannot be seeked (so
, 0Ah
hbytes equ $-hola
section .text
global _start
_start:
pushdword hbytes
pushdword hola
pushdword 1
mov eax,4 ; SYS_write
calldoint
pushdword 0
mov eax,1 ; SYS_exit
calldoint
doint:
int 0x80
ret
You ca
and architectures that i briefly checked.
This information is in the files with pattern:
//machdep.c
The function in question is "exec_setregs" on freebsd 5.x, or "setregs"
on freebsd 4.x.
ari
___
[EMAIL PROTECTED] mailing
utable code, as(1) offers non-operation instructions (which should
be unnecessary in any situation where a programmer doesn't know what
he's getting himself into). Newer versions of gnu as(1) seem to pad
this with zeros, which you can duplicate with:
.align 4, 0
ari
pushl $0
movl$1, %eax
int $0x80
ari
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
, as the filter would expect from the state table. If you have
implemented filtering, you should check into this.
ari
[EMAIL PROTECTED] said this stuff:
>
> On Tue, 24 Feb 2004, Ganbold wrote:
>
> > Maybe this is off topic question. I'm looking for good tftp server in
>
lse.
The *_MAX macros, of course, should still be used whenever possible.
ari
[EMAIL PROTECTED] said this stuff:
> Write a simple C program to ++ an int or long variable and see when it overflows.
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[
a
> marker file. However, I believe I've determined that the mtime of
> enclosing directories also changes to reflect the last file that was
> updated within its hierarchy. So, it makes sense that I simply check
> the directory that contains the marker file.
A
hip using
only reverse dns. The initial part of the description is a bit
misleading, but the fact that setting this option to 'no' does not
disable reverse lookups is not a bug.
ari
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
s isn't intended to solve all
the world's coding problems. It will probably never be used by as many
programmers as systrace will by administrators. It's just furthering
the unix mentality of shedding privileges, without granting additional
ones. You seem to think that the
y
system calls; not every function call will even be included in a class.
For example, the ability to block memory-related routines would probably
not be a good idea, and doing so may break your program, depending
merely on which standard c library you use. If you expect memory leaks
i'm considering. What i _am_ considering, however, is tying
this into mandatory access controls, for which hooks are already in the
kernel. But MAC doesn't seem to be fully implemented yet, as of
5.1-RELEASE.
I am threatening neither cerb nor systrace by implementing flowpriv[1].
I believ
[EMAIL PROTECTED] said this stuff:
> In the last episode (Aug 17), ari said:
> > Currently, root is the only user that can actually drop significant
> > privileges, as root is the only user that has access to such
> > functions. This is flawed --- any user should be able
[EMAIL PROTECTED] said this stuff:
> ari wrote:
> > Currently, root is the only user that can actually drop significant
> > privileges, as root is the only user that has access to such functions.
> > This is flawed --- any user should be able to relinquish his privileges,
v/
I welcome any discussion and criticism.
ari
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
usr/src/sys/compile/GENERIC -> Makefile . NORMAL_C type of
compilation is enough for them.
Please Respond to: [EMAIL PROTECTED] AND/OR [EMAIL PROTECTED]
Best Regards,
Ismail Ari
HP Labs
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
28 matches
Mail list logo
