Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Libnet
[Top] [All Lists]

RE: NG & Sparc

Subject: RE: NG & Sparc
Date: Wed, 29 Sep 2004 14:51:49 -0400
Hi Frédéric,

Have you considered porting/testing on Solaris x86 as well?  You can download 
Solaris 8, 9, 10 for free.

The Solaris Express (beta Solaris, currently Solaris 10) site for SPARC/x86 is:
        http://wwws.sun.com/software/solaris/solaris-express/get.html

The Solaris 9 Companion CD for x86 contains gcc, etc, and runs under 10.

-- Shawn


-----Original Message-----
From: Frédéric Raynal [mailto:frederic.raynal@security-labs.org] 
Sent: Wednesday, September 29, 2004 11:39 AM
To: mike schiffman; David Barroso
Cc: Frederic Raynal; Kirby Kuehl; libnet@securityfocus.com
Subject: NG & Sparc


Hi guys,

I am porting libnetng to Sparc Solaris. Currently, I am focusing on
the RAW and PCAP APIs. The link layer is already done, but the writing
is returning an error for an unknown error but I guess (or hope) it is
related to the following problem.

I knew that on Sparc arch, it was impossible to write on not aligned
addresses. Unfortunately, there are many places in the code were I do
something like:

  libnet_<proto>_hdr *hdr;
  hdr = (libnet_<proto>_hdr*)packet; /* packet is u_int8_t* */

Then, when I try to access some field inside the hdr, it makes a bus
error if the address of "packet" is not aligned (packet%4 != 0).

There are 2 places where such problem occurs:
- in the libnet_<proto>_pack_hdr() macros : fix is easy, I create a
  variable of the type of the header, set all fields, and then
  memcpy() this header to the packet.
- when computing checksums, and that is here I need your help ;-)

All functions computing checksums are using the type of casting
described above. There are 2 "kinds" of such functions:
- libnet_do_checksum()
- libnet_build_csum_<proto>()

The problem is that we cant ensure that all pbuf are aligned. for
instance, if someone does:
libnet_build_udp()
libnet_build_ip(..., "AAA", 3, ...); /* AAA being the payload */

The packet will the looks like
 20 bytes  3 bytes  8 bytes
<- IPv4 -><- AAA -><- udp ->

Thus, either IPv4 header or UDP header wont be aligned. If we assume
that packet are ending on an aligned address, UDP will be aligned,
but IP wont. Conversely, if we decide to align the packet from its
beginning, that is UDP that wont be aligned (BTW, that is a bug in the
current API I think as packets are aligned from the beginning in
libnet_pblock_coalesce()).

The only solution I see to avoid that kind of problem is to avoid
doing this casting. It means I need to rewrite partially all checksums
related functions. Hence, before starting that, I'd like to know if
some of you have a better idea ?


        Fred Raynal



<Prev in Thread] Current Thread [Next in Thread>