Sponsored Content
Full Discussion: libc re-bassing
Top Forums UNIX for Dummies Questions & Answers libc re-bassing Post 302177902 by s4g3 on Monday 24th of March 2008 02:59:57 AM
Old 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

xldb WARNING: libC.a(ansi_32.o) has been stripped

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

path for libc.a

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

Problem restoring libc.a (AIX 5.3)

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

Deploying Qt on CentOS - libc.so.6 update problem

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

hpux-itanium 64 bit problem for libC

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

Dependent modules libc.a and libpthreads.a

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

libc.so.1 (SUNW_1.22.7) => (version not found)

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

RPM Install error: libc.so.6 is needed by

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
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)
All times are GMT -4. The time now is 02:01 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy