Ok all i want to know how to do is get data from my network card no matter what it may be, i want it. HOW?
In C there are certain commands that you can use to send data to COM1, LPT1 ect how to i accept data from eth1 and eth2?
Printable View
Ok all i want to know how to do is get data from my network card no matter what it may be, i want it. HOW?
In C there are certain commands that you can use to send data to COM1, LPT1 ect how to i accept data from eth1 and eth2?
You need some form of socket library (e.g. Winsock if you're on Win32). There's no standard way to do this, sadly.
Generally, you'll need to create a socket and bind it to the port you want to listen on.
Is it possible to do through asm? Like, how are the socket libraries implemented in the first place?
You'll have to link to any existing socket libraries; most compilers come with built-in libraries for sockets on the host operating system. If you're on Windows you can just use winsock.h and link to the win32 library, for example.
Frost Drake, I think there should be no need at all to use non-portable super-obfuscated ASM code.
My question here: why do you want to do that?Quote:
Originally Posted by Frost Drake
There isn't going to be a truly platform-independent solution -- the best you can do is some socket library that is implemented on all the major operating systems.
Even if you bypass Winsock, you'd still be tied to Windows because you'd be communicating with the device drivers, and those are platform dependent. In fact the lower down you get the MORE platform dependent your code will become, not less.
I want to extract and see raw packet info, but to do that im sure i have to find out how to
get information from the source or in this case the network card
Or just use this perhaps?
http://www.winpcap.org/default.htm
Here’s why you have to use Winsock or something like it:Quote:
I want to extract and see raw packet info, but to do that im sure i have to find out how to get information from the source or in this case the network card
- Windows prevents user mode programs from directly reading or writing bytes to hardware. In order to do that, you have to write a kernel mode driver.
- Hardware manufacturers do not publish the details of how to communicate directly with their hardware/firmware. They supply a driver that communicates with their particular hardware and with Windows. So, even if you know how to write drivers, you don’t usually have the inside information that you need.
The driver is like a translator/interpreter. It can translate between the standard Windows/Winsock data and the format/data needed by the proprietary hardware.
The advantage to all of this “extra” complication is that your program will work with any network card in any (Windows) computer. In the old DOS days, each application had it’s own driver… You had to get a printer driver for your spreadsheet and another printer driver for your word processor, etc. It was a real mess. If your application didn’t have a driver for your new printer, you were out of luck. (Well, not totally out of luck because most printers had an Epson emulation mode.)