03-24-2008
And now for your question:
every program that you execute has two basic portions:
1 - code section
2 - data section
well there are more sections but if i start explaining, i will have to devote the whole day
code section is the section that the processor executes - i mean the instructions
and data section is where all the data is stored like integer values, constants and stuff - this is also called text section
libc addresses get randomized because of various factors like the amount of space that kernel occupys in the RAM or RAM size itself, when libc is loaded, etc
.text will be static - coz its the text section devoted for storing data. Remember every process has a certain portion of memory reserved for it?
You say .text is static because you are actually calculating the offset address from where the code starts in the memory. In real if you calculate .text will be in different parts of memory in each and every computer
Now please explain me: what does egress has to do with it? I mean egress is a packet filtering tool as far as my knowledge goes. How would it scan the computer's memory and find out about this? If you are sending some sort of shell code to spawn a remote shell egress CANNOT detect it. well it can if it start comparing the text segement offset address from the packet's beginning. but a normal filter like egress cannot do that.This is the job of an IDS (snort?)
If you really want deeper knowledge in this field about bypassing firewalls or IDS check out phrack.org. Sorry i cannot provide you with the exact link as i dont access phrack from work (they are kind of picky)
BTW langley cyber attack was a DDOS attack and not targeted on libc though.
~s4g3
8 More Discussions You Might Find Interesting
1. Programming
Hi,
When i start the Debugger i get this warning:
xldb WARNING: /usr/lpp/xlC/lib/libC.a(ansi_32.o) has been stripped.
anyone know what this warning means?
xldb is a Debugger under AIX.
Lazzar (2 Replies)
Discussion started by: Lazzar
2 Replies
2. Programming
how can i determine the path
for libc.a?
i wonder where it is located in my unix machine (1 Reply)
Discussion started by: gfhgfnhhn
1 Replies
3. AIX
Hi,
The symbolic link from /usr/lib/libc.a to /usr/ccs/lib/libc.a was deleted by accident. So we are trying to restore it, but we have some problems.
After booting from CD, and access the rootvg volume group (without mounting the system), we tried to execute the next commands:
mount /dev/hd4... (1 Reply)
Discussion started by: NicoAIX
1 Replies
4. Linux
I am developing a simple client-server (TCP) application using QT. The server side is to run on CentOS. I am developing both the server and client programs using Ubuntu.
I am now attempting to deploy an experimental version of the server application on the CentOS server, but I am not yet... (2 Replies)
Discussion started by: David Brown
2 Replies
5. HP-UX
i am trying to build on hpux-itanium 64 bit platform. my application needs to link to 64 bit version of the library libCsup.so
This library is present in /usr/lib/hpux64/libCsup.so
I am specifying the location of this library as linker flags
LDFLAGS := -Wl,-N -Wl,+s... (0 Replies)
Discussion started by: skyineyes
0 Replies
6. AIX
Hello
I am trying to install ActivePerl Pro Studio and I am seeing the following errors.
Could not load program ./setup:
Symbol resolution failed for setup because:
Symbol ___memcmp (number 1) is not exported from dependent
module /usr/lib/libc.a(shr.o).
... (2 Replies)
Discussion started by: flagman5
2 Replies
7. UNIX for Advanced & Expert Users
What package would I need to get this file? SUNW_1.22.7. Please help. thank you. :) (5 Replies)
Discussion started by: SystemAddict
5 Replies
8. Red Hat
I have an application rpm which when installed is failing to get installed with error
error: Failed dependencies:
libc.so.6 is needed by testSam-4.7.x86_64
libc.so.6(GLIBC_2.0) is needed by testSam-4.7.x86_64
libc.so.6(GLIBC_2.1) is needed by testSam-4.7.x86_64
... (1 Reply)
Discussion started by: rupeshkp728
1 Replies
LEARN ABOUT ULTRIX
scnhdr
scnhdr(5) File Formats Manual scnhdr(5)
Name
scnhdr - section header for a MIPS object file
Syntax
#include < scnhdr.h>
Description
Every MIPS object file has a table of section headers that specify the layout of the data in the file. Each section that is in an object
file has its own header. The C structure appears as follows:
struct scnhdr
{
char s_name[8]; /* section name */
long s_paddr; /* physical address, aliased s_nlib */
long s_vaddr; /* virtual address */
long s_size; /* section size */
long s_scnptr; /* file ptr to raw data for section */
long s_relptr; /* file ptr to relocation */
long s_lnnoptr; /* file ptr to gp table */
unsigned short s_nreloc; /* number of relocation entries */
unsigned short s_nlnno; /* number of gp table entries */
long s_flags; /* flags */
};
File pointers are byte offsets into the file; they can be used as the offset in a call to FSEEK (see If a section is initialized, the file
contains the actual bytes. An uninitialized section is somewhat different. It has a size, symbols defined in it, and symbols that refer
to it. It cannot have relocation entries or data. Consequently, an uninitialized section does not contain data in the object file, and
the values for s_scnptr, s_relptr, and s_nreloc are zero.
The entries that refer to line numbers (s_lnnoptr and s_nlnno) are not used for line numbers on MIPS machines. See the header file for the
entries to get to the line number table. The entries that were for line numbers in the section header are used for gp tables on MIPS
machines.
The number of relocation entries for a section is found in the s_nreloc field of the section header. This field is a C language short and
can overflow with large objects. If this field overflows, the section header s_flags field has the S_NRELOC_OVFL bit set. In this case,
the true number of relocation entries is found in the r_vaddr field of the first relocation entry for that section. That relocation entry
has a type of R_ABS; thus, it is ignored when the relocation takes place.
The gp table gives the section size corresponding to each applicable value of the compiler option num (always including 0), sorted by
smallest size first. It is pointed to by the s_lnnoptr field in the section header and its number of entries (including the header) is in
the s_nlnno field in the section header. This table only needs to exist for the .sdata and .sbss sections. If a small section does not
exist, then the gp table for it is attached to the corresponding large section so the information still gets to the link editor, The C
union for the gp table follows:
union gp_table
{
struct {
long current_g_value; /* actual value */
long unused;
} header;
struct {
long g_value; /* hypothetical value */
long bytes; /* section size corresponding
to hypothetical value */
} entry;
};
Each gp table has one header structure that contains the actual value of the num option used to produce the object file. An entry must
exist for every num -G num option. The applicable values are all the sizes of the data items in that section.
For .lib sections, the number of shared libraries is in the s_nlib field (an alias to s_paddr). The .lib section is made up of s_nlib
descriptions of shared libraries. Each description of a shared library is a libscn structure followed by the path name to the shared
library. The C structure appears here and is defined in scnhdr.h :
struct libscn
{
long size; /* size of this entry (including target name) */
long offset; /* offset from start of entry to target name */
long tsize; /* text size in bytes, padded to DW boundary */
long dsize; /* initialized data size */
long bsize; /* uninitialized data */
long text_start; /* base of text used for this library */
long data_start; /* base of data used for this library */
long bss_start; /* base of bss used for this library */
/* pathname of target shared library */
};
See Also
ld(1), fseek(3s), a.out(5), reloc(5)
RISC scnhdr(5)