Re: using git for freebsd development
[EMAIL PROTECTED] wrote: The following can be considered as a followup to the excellent FreeBSD/GIT wiki page: http://wiki.freebsd.org/GitConversion [...] All of the tools either required source CVS repository to be available locally or worked much faster in that case, so the first thing to do was to get src-all from my local cvsup mirror. Easy. Everyone who tries converting freebsd's cvs repository to joe-random-RCS attempts to import the entire source tree as a single project. Honestly, it covers too broad a spectrum. Separate these projects into the cvsup collections: src-sys, src-bin, src-lib, etc.. You won't be able to simply tag a single branch into a full system release without a wrapper script to handle your collections, but that's a small price to pay for the added robustness, separation of privilege, and smaller-scale 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binary file within a shell script
[EMAIL PROTECTED] wrote: I would like to use one exec file from a shellscript but I would like it to be incorporated in the same file, like Nvidia do for its FreeBSD drivers. How can I do this in a convenient way ? I haven't looked at nvidia's driver packaging, but you can embed binaries into shell scripts using uuencode or base64. Example: % cat test.sh #!/bin/ksh echo *** generating ls... file=`mktemp /tmp/ls.XX` [[ $? -eq 0 ]] || exit 1 uudecode -o $lsfile '__EOM__' ^D % uuencode ls /bin/ls test.sh % cat test.sh __EOM__ chmod +x $lsfile echo *** running $lsfile ... $lsfile echo *** cleaning up rm -f $lsfile ^D Note that i used single quotes in the here-document initialization, so there won't be any shell expansion of the uuencoded data. A few commonly-installed programs that may suit your needs: - uuencode / uudecode - base64 - b64 - openssl base64 If relying on one of the above is infeasible: You can't portably use inline binary data in a shell script without preprocessing it (as with one of the above programs), since most shells can't handle binary zeros; shar(1) fails in this case. You could, theoretically, write a small, clever wrapper function to account for the issue. You'd also have to ensure that regexp(^__EOM__$) (in the above example) doesn't exist within the file contents, and note that excessively long lines may not be handled efficiently by the shell. You'll need to account for files that do or don't end in a newline, possibly by always appending an extra newline, then stripping it upon extraction. Lastly, you'll need to consider whether you 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 CR/LF conversion may be an issue for you. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binary file within a shell script
[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/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
[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 encrypted or unloaded, to be decrypted or loaded on demand. The person running the application can trivially replace ktrace(), ptrace() and setrlimit() with non-functional stubs using LD_PRELOAD. And any application that executes its own code before running the system's dynamic loader -- or is statically linked, for that matter -- is free to unset LD_PRELOAD. There are many attack vectors. There are plenty of countermeasures. There are numerous attacks on each countermeasure. It goes on. This is all common knowledge, even among those creating anti-reverse-engineering techniques; in fact, it's usually prominently stated in an included disclaimer. It's unfortunate to note that, in many countries these days, the most effective deterrent against attacks on binary encryption is legal action. Some corporations add just-in-time page decryption to their binaries specifically for this recourse (e.g., against a competitor who creates applications that hook into the original software). ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: encrypted executables
#!/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 in the main process or in a sub-process), they'll be able to follow the system calls it makes. 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 or loaded on demand. An approach that handles all of the above, with the possible exception of setrlimit(RLIMIT_CORE,...), is shiva, though it's available only for linux and distributed as an executable. http://www.securiteam.com/tools/5XP041FA0U.html Even then, the developers explicitly state that this can only slow the determined attacker in his endeavors, but the solutions everyone seems to be proposing here won't help. 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 in the original binary (depending on the implementation), it won't help in such a 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]
Re: encrypted executables
[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 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 simplistic methods are... just that. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem about libnet on FreeBSD 6.0
[EMAIL PROTECTED] wrote: http://lists.freebsd.org/pipermail/freebsd-hackers/2005-December/014986.html The problem is that libnet defines ether_addr without regard for the fact that it's defined in our system headers. This is a bug in libnet, not FreeBSD. No one claimed otherwise -- hence the 'BROKEN_LIBNET' tag in my post. In particular, libnet/libnet-headers.h has this code, which is very Linux-centric and works around the duplicate definition problem on Linux, but doesn't help anyone on other platforms. 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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem about libnet on FreeBSD 6.0
[EMAIL PROTECTED] wrote: On 12/31/05, Gilbert Fernandes [EMAIL PROTECTED] wrote: I find that I can't include net/ethernet.h when I programming with libnet,because $(CC) complains that struct ether_addr redefined. But I need some definitions in net/ethernet.h,struct ether_header etc. Currently,I just copy the definitions I need from net/ethernet.h,but it seems very ugly.Any one has some good ideas? Here is my include lines, #include .. #include net/ethernet.h #include pcap.h #include libnet.h ... and this is the error, $(CC) said /usr/local/include/./libnet/libnet-headers.h:393: error: redefinition of `struct ether_addr' Assuming that either the practical contents of 'struct ether_addr' are the same for both definitions or that it doesn't matter for any inline functions you may be using within the header file (chances are, this assumption is valid): #include net/ethernet.h #include pcap.h #define ether_addr ether_addr_BROKEN_LIBNET # include libnet.h #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]
Re: Problem about libnet on FreeBSD 6.0
[EMAIL PROTECTED] wrote: Did you read my post? Or are you not on the list? I sent my response directly to the list, not including you specifically. [...] I am on the list,and I don't receive your post. I think you can send post specifically 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-hackers/2005-December/014986.html ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using sysarch specific syscalls in assembly?
On 8/9/2005, alexander [EMAIL PROTECTED] wrote: [...] Unfortunately I'm experiencing some problems right now. From time to time I'm getting a 'Bus error: 10 (core dumped)' This however appears randomly. One time I run the app everything works fine,the next time it core dumps. Are there any errors in my code? %define SYSARCH165 ; syscall sysarch(2) %define I386_SET_IOPERM 4 ; i386_set_ioperm(2) number ioperm_argsdd 378h dd 3 dd 1 OpenIO: push byte ioperm_args push dword I386_SET_IOPERM mov eax,SYSARCH Call _syscall [...] You need to push a _pointer_ to a structure as your second argument to sysarch(2). This means something more along the lines of: 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 mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using sysarch specific syscalls in assembly?
On 8/8/2005, alexander [EMAIL PROTECTED] wrote: [...] i386_set_ioperm(2) states that this procedure is a system call. So it should be easily accessable through assembly language and it's specific syscall id. Unfortunately I wasn't able to find the syscall id in any of the syscalls.master files that are part of the source tree. machine/sysarch.h states that this is a sysarch specific syscall for i386 (hence the i386_*). The following definitions are being made: #define I386_GET_IOPERM 3 #define I386_SET_IOPERM 4 These syscall numbers however are already taken by read(2) and write(2). So how can I make use of these i386 specific syscalls? Is it even possible? If you're unsure of how a function is called, you can always check the C library, under 'src/lib/libc/'. I won't repeat john baldwin'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 portable, then unless you have specific reasons for not doing so, perhaps it's something you'd like to consider. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Creating Compressed Loop FS from stdin
[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 (sought? :), and surprisingly it worked, at least on RELENG_5 as of today! You can always seek stdin, if stdin happens to be associated with a seekable descriptor. It isn't given any special treatment simply because it has a vector of 0. That is, if you use something along the lines of: % ./seekme /etc/services then /etc/services is associated with descriptor 0, and you can seek all you like. If you use % cat /etc/services |./seekme ... then the descriptor isn't associated with a file, and you'll run into problems. ari ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd asm
[EMAIL PROTECTED] said this stuff: [...] [demon]~$ cat hello.asm %include 'system.inc' section .data holadb 'Hola', 0Ah hbytes equ $-hola section .text global _start _start: pushdword hbytes pushdword hola pushdword stdout sys.write pushdword 0 sys.exit [demon]~$ nasm -f elf hello.asm hello.asm:1: fatal: unable to open include file `system.inc' ?Where is that file?... the -current port of nasm is incomplete ? system.inc is not a part of nasm. Ok... we take some modifications... %include 'system.inc' pushdword stdout , and we replace it with pushdword 1 nasm also has no knowledge of sys.func style directives, so they are ignored. The directives in question would be located in the system.inc file that you don't have, and your program may as well be: holadb 'Hola', 0Ah hbytes equ $-hola section .text global _start _start: pushdword hbytes pushdword hola pushdword 1 pushdword 0 ... which doesn't exit, therefore your program accesses memory addresses that aren't meant to supply program code, and it crashes. Freebsd system calls are generally accessed using interrupt vector 0x80. The function that deals with this interrupt in the kernel expects the number of the system call in eax, and it expects the program to have called a function along the way. Thus, it's looking for the following stack structure: [][][][] : return address, inserted by 'call' instruction : descriptor vector : string address : number of bytes to write. To get this, you can try something like the following: holadb 'Hola', 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 can find the necessary system call numbers in /usr/include/sys/syscall.h . ari ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
