User Controls
Q̇uick Ċ Q̇uestion
-
2017-01-07 at 9:35 PM UTCLooking into it more, the arpspoof.c examples it uses, use pcap...
-
2017-01-08 at 6:29 AM UTCCan you maybe not front page flush in T&T that'd be great.
-
2017-01-08 at 7:03 AM UTCSomebody is working on a banning.
Anyways, this one works...
https://github.com/m0nad/ARP-Poison
but, what I'm getting isn't that great. I ran the attack against my PC, with my LG Tribute, using my HTC phone as a hotspot for internet connection. After clicking through a bunch of pages here(on my PC), all I found that was somewhat readable was this...
----------------------------------------------------------------
TCP Packet
Ethernet Header
|-Destination Address : 00-10-41-C1-11-31
|-Source Address : 00-20-C2-52-32-32
|-Protocol : 8
IP Header
|-IP Version : 0
|-IP Header Length : 0 DWORDS or 0 Bytes
|-Type Of Service : 144
|-IP Total Length : 19653 Bytes(Size of Packet)
|-Identification : 4664
|-TTL : 202
|-Protocol : 82
|-Checksum : 14134
|-Source IP : 8.0.69.0
|-Destination IP : 1.203.50.246
TCP Header
|-Source Port : 144
|-Destination Port : 19653
|-Sequence Number : 305660096
|-Acknowledge Number : 3394385718
|-Header Length : 0 DWORDS or 0 BYTES
|-Urgent Flag : 0
|-Acknowledgment Flag : 0
|-Push Flag : 0
|-Reset Flag : 0
|-Synchronize Flag : 0
|-Finish Flag : 0
|-Window : 17664
|-Checksum : 459
|-Urgent Pointer : 63026
-----------------Data Pay Load-------------------
..L..8...R76..E...2.@.@.w......e4....PGi.....F...............Z.
..GET /hyI8Qctb.png HTTP/1.1..Host: i.imgur.com..Connection: kee
p-alive..User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit
/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36..
Accept: image/webp,image/*,*/*;q=0.8..Referer: http://niggasin.s
pace/thread/5217..Accept-Encoding: gzip, deflate, sdch..Accept-L
anguage: en-US,en;q=0.8..Cookie: __cfduid=c0212345f665fa1234508a
.ff..b....f..............
----------------------------------------------------------------
and this...
----------------------------------------------------------------
TCP Packet
Ethernet Header
|-Destination Address : 00-10-41-C1-11-31
|-Source Address : 00-20-C2-52-32-32
|-Protocol : 8
IP Header
|-IP Version : 0
|-IP Header Length : 0 DWORDS or 0 Bytes
|-Type Of Service : 144
|-IP Total Length : 19653 Bytes(Size of Packet)
|-Identification : 4664
|-TTL : 202
|-Protocol : 82
|-Checksum : 14134
|-Source IP : 8.0.69.0
|-Destination IP : 2.56.40.56
TCP Header
|-Source Port : 144
|-Destination Port : 19653
|-Sequence Number : 305660096
|-Acknowledge Number : 3394385718
|-Header Length : 0 DWORDS or 0 BYTES
|-Urgent Flag : 0
|-Acknowledgment Flag : 0
|-Push Flag : 0
|-Reset Flag : 0
|-Synchronize Flag : 0
|-Finish Flag : 0
|-Window : 17664
|-Checksum : 568
|-Urgent Pointer : 14376
-----------------Data Pay Load-------------------
..L..8...R76..E..8(8@.@.6......Xp1.8.P.v..'/.V..E&...........Z.
..GET /thread/5201 HTTP/1.1..Host: niggasin.space..Connection: k
eep-alive..Upgrade-Insecure-Requests: 1..User-Agent: Mozilla/5.0
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chro
me/53.0.2785.116 Safari/537.36..Accept: text/html,application/xh
tml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8..Referer: htt
p://niggasin.space/forum/24..Accept-Encoding: gzip, deflate, sdc
h..Accept-Language: en-US,en;q=0.8..Cookie: sessionid=111111118v
fybwac111111111sp073tf; csrftoken=11lEZwp4a111111111111111111111
tb....
----------------------------------------------------------------
Both of these I seemed to capture the exact packets multiple times. I'm not 100% sure, but these don't like right. The IP addresses in the IP header don't look legit to me. I am using my own packet capturing program, though. I think I'm also going to change the two seconds sleep in the arp-poison program to one second or maybe try 100 millisecond.
Is an arp-spoofing/arp-poisoning attack suppose to only catch packets seldom?
Post last edited by SBTlauien at 2017-01-08T07:11:05.299707+00:00 -
2017-01-09 at 1:16 AM UTC
Originally posted by SBTlauien I had tried this and some other things. None worked. The problem, like Lanny said, is that "AF_INET", "SOCK_STREAM", and all of the others, are just integers. I think the compiler just uses them as a reference. So getting my char* to one of those integers is going to be easiest just leaving my long if-elseif statement. I thought about a switch-case but it was more of a curiosity.
regardless of their actual data type, commandline arguments are stored as strings. argv[1] is a pointer to a string (a character array). in this case your socket() function is likely expecting an integer but is getting a character array so is having trouble. you'll want to pull the integer value out of the string, easiest ways are to either cast the variable to a different type or use math to convert the character array to an int.
let's assume the following works to load the commandline arguments as strings:
int main(int argc, char ** argv)
{
char firstParam[256];
char secondParam[256];
strncpy(firstParam,argv[1]);
strncpy(secondParam,argv[2]);
to cast, or convert variables, you could do this (could be done more cleanly but I figure this is easier to read):
int main(int argc, char ** argv)
{
char firstParam[256];
char secondParam[256];
strncpy(firstParam,argv[1]);
strncpy(secondParam,argv[2]);
int intFirstParam=atoi(firstParam);
int intSecondParam=atoi(secondParam);
Honestly not sure how well atoi works but eh.
If you want to use raw math, try the following:
int main(int argc, char ** argv)
{
char firstParam[256];
char secondParam[256];
int intFirstParam;
int x=0;
strncpy(firstParam,argv[1]);
int baseVal=0;
for(x=0;x<256;x++)
{
if(firstParam[x]>47 && firstParam[x]<58)
{
firstParam+=(10^baseVal)*firstParam[x];
baseVal++;
}
elseif(firstParam[x]==0)
{
break;
}
}
reason that approach works is because C stores strings as arrays - each character is an ASCII value and the end of the string is marked with a 0 (null terminator). example:
char youAreAFaggot[16] = "faggot";
youAreAFaggot (chars) = {'f', 'a', 'g', 'g', 'o', 't', "\0"}
youAreAFaggot (ints) = {102, 97, 103, 103, 111, 116, 0}Next question…
will look at that in a few
***just realised I'm calculatiing decimals backwards. fuck. will fiix later
Post last edited by aldra at 2017-01-10T05:49:20.092764+00:00 -
2017-01-09 at 4:42 AM UTCwhy are you using wireshark? if you're trying an arp poisoning attack you should be monitoring the arp tables on the device you're trying to attack. if the tables aren't being updated, you then want to use wireshark/tcpdump/etc to see if your attacker is actually sending the arp traffic (easy to enhancement - should just be able to use the arp keyword in wireshark).
it looks to me like you're testing to see if the end result is working - completely disregarding the steps and potential points of failure along the way. -
2017-01-13 at 12:38 AM UTCsetting up gcc now. time to get back into C
-
2017-01-13 at 12:56 AM UTC
Originally posted by aldra let's assume the following works to load the command line arguments as strings
This isn't necessary. Strings are type *char so you can pass `argv[n]` directly. It does work because passing an array ("firstParam" for example) implicitly casts to a pointer of the array's type. Consider this program:
#include <string.h>
int stdout = 1;
void print_a_string(char *s) {
write(stdout, s, strlen(s));
write(stdout, "\n", 1);
}
int main(int argc, char **argv) {
char mystr[256];
if (argc < 2) {
return 1;
}
strncpy(mystr, argv[1], 256);
print_a_string(mystr);
print_a_string(argv[1]);
}
It passes the type checker will print argv[1] twice.The following users say it would be alright if the author of this post didn't die in a fire! -
2017-01-13 at 1:19 AM UTCoh yeah, you're right. I originally did the copy from pointer to fixed char array because I thought that's what socket() was expecting, it's not necessary if you're not passing data directly to a function that requires it.
