I am using Scapy to monitor towards man in the middle I would like to know in Scapy what does mean the following terms???
%IP.src%
%TCP.sport%
%IP.dst%
%TCP.dport%
%TCP.flags%
%TCP.payload%
I'm not Scapy user but seems pretty straight forward:
Source IP Address
TCP Source Port
Destination IP Address
TCP Destination Port
TCP Flags
TCP Payload (message body)
These are the useable TCP-Flags.
# TCP-Flags
FIN = 0x01
SYN = 0x02
RST = 0x04
PSH = 0x08
ACK = 0x10
URG = 0x20
ECE = 0x40
CWR = 0x80
You coul'd test for a flag with the & operator
e.g.:
if paket[TCP].flags & SYN:
do_anything()
Related
>>> packet = IP(dst="ntpid")/UDP(dport=123,sport=50000)/("\x1b\x00\x00\x00"+"\x00"*11*4)
>>> packet.show()
###[ IP ]###
version = 4
ihl = None
tos = 0x0
len = None
id = 1
flags =
frag = 0
ttl = 64
proto = udp
chksum = None
src = xxx.xxx.xxx.xxx
dst = xxx.xxx.xxx.xxx
\options \
###[ UDP ]###
sport = 50000
dport = ntp
len = None
chksum = None
###[ Raw ]###
load = '\x1b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
>>> rep,non_rep = sr(packet)
Begin emission:
Finished sending 1 packets.
..........................^C
Received 26 packets, got 0 answers, remaining 1 packets
I would like to get the ntp_monlist response of my NTP server.
Actually the packet is sent but I didn't receive anything.
Can someone tell me the reason?
I try for it like this？ But the received ntp is question mark。
>>> packet = IP(dst=ntpserver)/UDP(dport=123,sport=50000)/ NTP(version=4)
>>>rep,non_rep = sr(packet)
>>> rep.show()
0000 IP / UDP / NTP v??, ?? ==> IP / UDP / NTP v??, ??
I was able to get this to work with the following command:
data = "\x17\x00\x03\x2a" + "\x00" * 4
send(IP(src=src_ip, dst=dst_ip)/UDP(sport=RandShort(),dport=123)/Raw(load=data),count=packets_chunk)
Source: https://vulners.com/packetstorm/PACKETSTORM:127492
I'm trying to setup connection between two BBB using nrf24l01.
I hope i set up everything properly( but I'm not really sure), I used this tutorial https://electron14.com/?p=404 and this code : RF24/librf24-bbb/librf24, and some self investigation.
the result of pingtest is :
./pingtest
RF24/examples/pingpair/
ROLE: Ping out
- gpio.cpp RF24::begin end fun
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xf0f0f0f0e1 0xf0f0f0f0d2
RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xf0f0f0f0e1
RX_PW_P0-6 = 0x20 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x00
EN_RXADDR = 0x03
RF_CH = 0x4c
RF_SETUP = 0x27
CONFIG = 0x0f
DYNPD/FEATURE = 0x00 0x00
Data Rate = 250KBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_HIGH
Now sending 23...ok...Failed, response timed out.
Now sending 1231...ok...Failed, response timed out.
Now sending 2441...ok...Failed, response timed out.
Now sending 3649...ok...Failed, response timed out.
Now sending 4859...ok...Failed, response timed out.
Now sending 6071...ok...Failed, response timed out.
and from other BBB pongtest
./pongtest
RF24/examples/pingpair/
ROLE: Pong back
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xf0f0f0f0d2 0xf0f0f0f0e1
RX_ADDR_P2-5 = 0xc3 0xc4 0xc5 0xc6
TX_ADDR = 0xf0f0f0f0d2
RX_PW_P0-6 = 0x20 0x20 0x00 0x00 0x00 0x00
EN_AA = 0x00
EN_RXADDR = 0x03
RF_CH = 0x4c
RF_SETUP = 0x27
CONFIG = 0x0f
DYNPD/FEATURE = 0x00 0x00
Data Rate = 250KBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_HIGH
Can someone help me ?
Based on your data, both devices have a status register value of 0x0e, which is clearing the lsb; that bit sets the direction of the device, either Tx (0) or Rx (1). Based on the status register of each board being cleared, you have both of them setup as transmitters.
i'm learning the tun/tap device of linux, there is a little problem i cannot figure out
here is what i've done:
1: create a tap device, name is "tap1", get the file descriptor: tapfd
2: prepare an array huge enough, like: buf[2048]
3: write a ethernet frame into buf, inside it is an ip(udp) packet, 74bytes total. done it in a clumsy way, like:
// mac dst
buf[0] = 0xbb;
buf[1] = 0xaa;
buf[2] = 0xbb;
...
// mac src
buf[6] = 0xaa;
buf[7] = 0xbb;
...
// eth type
...
// ip ver & ip hdr_len
...
...
...
// data offset=42 length=32
buf[42] = 0x61;
...
buf[73] = 0x61
4: call write(), send the [74bytes] mentioned above into [tapfd]
write(fd, buf, 74);
5: use "tcpdump -i tap1 -vv" to check, but the result is as below:
18:06:40.466971 aa:bb:08:00:45:00 (oui Unknown) Unknown SSAP 0x18 > bb:aa:aa:bb:aa:bb (oui Unknown) Unknown DSAP 0x78 Information, send seq 0, rcv seq 0, Flags [Response], length 56
0x0000: 7919 0000 4011 ed95 0a00 0001 0a00 0001 y...#...........
0x0010: 5b25 5f7c 0028 1ae4 6161 6161 6161 6161 [%_|.(..aaaaaaaa
0x0020: 6161 6161 6161 6161 6161 6161 6161 6161 aaaaaaaaaaaaaaaa
0x0030: 6161 6161 6161 6161 aaaaaaaa
total = 56bytes + 12bytes mac src&dst + 2bytes eth type = 70 bytes, so, where is the leading 4bytes?
first, i thought the leading 4bytes should be "preamble & Start of frame delimiter", but as the wiki says, preamble was 7 octets and Start of frame delimiter was 1 octet.
6: then i insert 4 bytes into my [buf], now the buf is like:
buf[0] = 0xab;
buf[1] = 0xab;
buf[2] = 0xab;
buf[3] = 0xcc;
buf = buf + 4;
{ buf[0] ~ buf[73] just as before }
then retry to send 78 bytes to fd
write(fd, buf, 78)
then check again, this time, tcp dump told me that is a legal ethernet frame!
18:13:57.676562 IP (tos 0x0, ttl 64, id 31001, offset 0, flags [none], proto UDP (17), length 60, bad cksum ed95 (->ed96)!)
localhost.23333 > localhost.24444: [bad udp cksum 0x1ae4 -> 0x1ae5!] UDP, length 32
it works! but why? why the leading 4bytes was missing?(please ignore the bad udp checksum)
This looks like a misconfiguration of the flags when opening your tap device.
The documentation for the Linux tun/tap kernel driver describes the following frame format.
3.2 Frame format:
If flag IFF_NO_PI is not set each frame format is:
Flags [2 bytes]
Proto [2 bytes]
Raw protocol(IP, IPv6, etc) frame.
You can find more information here: /usr/src/linux/Documentation/networking/tuntap.rst
Just add IFF_NO_PI to your interface flags and the device driver will not strip away the leading 4 bytes.
I'm trying to retrieve my sensor data from my Raspberry Pi using nrf24l01+ network receiver.
I'm sending it from an Arduino nano board. Here is the setting of my Arduino:
STATUS = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1 = 0xcccccc3ccc 0xcccccc3c3c
RX_ADDR_P2-5 = 0x33 0xce 0x3e 0xe3
TX_ADDR = 0xcccccccc3c
RX_PW_P0-6 = 0x20 0x20 0x20 0x20 0x20 0x20
EN_AA = 0x3e
EN_RXADDR = 0x3f
RF_CH = 0x5a
RF_SETUP = 0x07
CONFIG = 0x0f
DYNPD/FEATURE = 0x3f 0x04
Data Rate = 1MBPS
Model = nRF24L01+
CRC Length = 16 bits
PA Power = PA_MAX
My Raspberry Pi is plugged with nrf24l01+ through GPIO. I made sure the connection is OK by using the C++ example given on https://github.com/TMRh20/RF24:
RF24 radio(RPI_BPLUS_GPIO_J8_15,RPI_BPLUS_GPIO_J8_24, BCM2835_SPI_SPEED_8MHZ);
The data is OK. Now i want to use a nodeJS program to get this data. I'm using this library: https://github.com/natevw/node-nrf
The code is very simple, but somehow is not working (console is silent):
var spiDev = "/dev/spidev0.0";
var cePin = 15; //RPI_BPLUS_GPIO_J8_15
var irqPin = null;
var channel = 0x5a; //90
var radio = require('nrf').connect(spiDev, cePin, irqPin);
radio
.channel(channel)
.dataRate('1Mbps')
.crcBytes(1)
// .autoRetransmit({count:15, delay:4000})
;
radio.begin(function () {
var rx = radio.openPipe('rx', 0xcccccccc3c);
rx.pipe(process.stdout);
});
I'm wondering what I'm doing wrong. Hardware is OK and the setting seems pretty good, what do you think?
Thanks
Usually to find out what is wrong with NRF you should start from basics:
Try simpler NRF configs to test if its working, especially with no CRC bytes etc.
Try it w/o dynamic payload and try fixed payload size on both ends.
Auto-acknowledge also can be an issue (note that when auto-ack is enabled, CRC can't be disabled as it is used to ensure transmission acknowledgement in this mode).
Ensure that CRC lengths match on both ends. In your example on Arduino you have CRC Length = 16 bits whether Raspberry configured with radio.crcBytes(1).
Don't rely on default values, always provide same full configuration on both ends.
These steps can considerably reduce time to locate the problem especially when using different libraries and platforms.
I'm tring to experiment with the ICMP protocol and have created a kernel-module for linux that analyses ICMP packet ( Processes the packet only if if the ICMP code field is a magic number ) . Now to test this module , i have to create a an ICMP packet and send it to the host where this analysing module is running . In fact it would be nice if i could implement it the kernel itself (as a module ) . I am looking for something like a packetcrafter in kernel , I googled it found a lot of articles explaining the lifetime of a packet , rather than tutorials of creating it . User space packetcrafters would be my last resort, that too those which are highly flexible like where i'll be able to set ICMP code etc . And I'm not wary of kernel panics :-) !!!!! Any packet crafting ideas are welcome .
Sir, I strongly advice you against using the kernel module to build ICMP packets.
You can use user-space raw-sockets to craft ICMP packets, even build the IP-header itself byte by byte.
So you can get as flexible as it can get using that.
Please, take a look at this
ip = (struct iphdr*) packet;
icmp = (struct icmphdr*) (packet + sizeof(struct iphdr));
/*
* here the ip packet is set up except checksum
*/
ip->ihl = 5;
ip->version = 4;
ip->tos = 0;
ip->tot_len = sizeof(struct iphdr) + sizeof(struct icmphdr);
ip->id = htons(random());
ip->ttl = 255;
ip->protocol = IPPROTO_ICMP;
ip->saddr = inet_addr(src_addr);
ip->daddr = inet_addr(dst_addr);
if ((sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP)) == -1)
{
perror("socket");
exit(EXIT_FAILURE);
}
/*
* IP_HDRINCL must be set on the socket so that
* the kernel does not attempt to automatically add
* a default ip header to the packet
*/
setsockopt(sockfd, IPPROTO_IP, IP_HDRINCL, &optval, sizeof(int));
/*
* here the icmp packet is created
* also the ip checksum is generated
*/
icmp->type = ICMP_ECHO;
icmp->code = 0;
icmp->un.echo.id = 0;
icmp->un.echo.sequence = 0;
icmp->checksum = 0;
icmp-> checksum = in_cksum((unsigned short *)icmp, sizeof(struct icmphdr));
ip->check = in_cksum((unsigned short *)ip, sizeof(struct iphdr));
If this part of code looks flexible enough, then read about raw sockets :D maybe they're the easiest and safest answer to your need.
Please check the following links for further info
http://courses.cs.vt.edu/~cs4254/fall04/slides/raw_6.pdf
http://www.cs.binghamton.edu/~steflik/cs455/rawip.txt
http://cboard.cprogramming.com/networking-device-communication/107801-linux-raw-socket-programming.html a very nice topic, pretty useful imo
You can try libcrafter for packet crafting on user space. Is very easy to use! The library is able to craft or decode packets of most common networks protocols, send them on the wire, capture them and match requests and replies.
For example, the next code craft and send an ICMP packet:
string MyIP = GetMyIP("eth0");
/* Create an IP header */
IP ip_header;
/* Set the Source and Destination IP address */
ip_header.SetSourceIP(MyIP);
ip_header.SetDestinationIP("1.2.3.4");
/* Create an ICMP header */
ICMP icmp_header;
icmp_header.SetType(ICMP::EchoRequest);
icmp_header.SetIdentifier(RNG16());
/* Create a packet... */
Packet packet = ip_header / icmp_header;
packet.Send();
Why you want to craft an ICMP packet on kernel-space? Just for fun? :-p
Linux kernel includes a packet generator tool pktgen for testing the network with pre-configured packets. Source code for this module resides in net/core/pktgen.c