BLACK MASK: 02/07/17

Tuesday, February 7, 2017

I wonder if i helped a friend with this research...they track you, (of course in TOR) because they add a mdf. file written in visual studio (of course) on your tables database (I'm not sure if its really temporary) ...so...wherever they are search them in here:

**Compare MySQL databases & automatically create schema & data change scripts/migrations rapidly (up & down SQL supported) for database version control. Supports most migration tools.https://github.com/DBDiff/DBDiff**

Download Symantec Root Certificates

Root 01 - SHA1 - RSA 1024 bits

Name: VeriSign Class 3 Public Primary CA - G2
Serial Number: 7d d9 fe 07 cf a8 1e b7 10 79 67 fb a7 89 34 c6
Valid From: Sunday, May 17, 1998 4:00:00 PM
Valid to: Tuesday, August 01, 2028 3:59:59 PM
Certificate SHA1 Fingerprint: 85 37 1c a6 e5 50 14 3d ce 28 03 47 1b de 3a 09 e8 f8 77 0f

Download

Root 02 - SHA1 - RSA 1024 bits

Name: VeriSign Class 3 Public Primary CA
Serial Number: 3c 91 31 cb 1f f6 d0 1b 0e 9a b8 d0 44 bf 12 be
Valid From: Sunday, January 28, 1996 4:00:00 PM
Valid to: Wednesday, August 02, 2028 3:59:59 PM
Certificate SHA1 Thumbprint: a1 db 63 93 91 6f 17 e4 18 55 09 40 04 15 c7 02 40 b0 ae 6b

Download

Root 03 - SHA1 - RSA 2048 bits

Name: VeriSign Class 3 Primary CA - G5
Serial Number: 18 da d1 9e 26 7d e8 bb 4a 21 58 cd cc 6b 3b 4a
Operational Period: Tue, November 07, 2006 to Wed, July 16, 2036
Certificate SHA1 Fingerprint: 4e b6 d5 78 49 9b 1c cf 5f 58 1e ad 56 be 3d 9b 67 44 a5 e5

Download

Root 04 - SHA1 - RSA 2048 bits

Name: VeriSign Class 3 Public Primary CA - G3
Serial Number: 00 9b 7e 06 49 a3 3e 62 b9 d5 ee 90 48 71 29 ef 57
Valid From: Thursday, September 30, 1999 4:00:00 PM
Valid to: Wednesday, July 16, 2036 3:59:59 PM
Certificate SHA1 Fingerprint: 13 2d 0d 45 53 4b 69 97 cd b2 d5 c3 39 e2 55 76 60 9b 5c c6

Download

Root 05 - SHA384 - ECC 384 bits

Name: VeriSign Class 3 Public Primary CA - G4
Serial Number: 2f 80 fe 23 8c 0e 22 0f 48 67 12 28 91 87 ac b3
Valid From: Sunday, November 04, 2007 4:00:00 PM
Valid to: Monday, January 18, 2038 3:59:59 PM
Certificate SHA1 Fingerprint: 22 d5 d8 df 8f 02 31 d1 8d f7 9d b7 cf 8a 2d 64 c9 3f 6c 3a

Download

Root 06 - SHA1 - RSA 2048 bits

Name: VeriSign Class 2 Public Primary CA - G3
Serial Number: 61 70 cb 49 8c 5f 98 45 29 e7 b0 a6 d9 50 5b 7a
Valid From: Thursday, September 30, 1999 4:00:00 PM
Valid to: Wednesday, July 16, 2036 3:59:59 PM
Certificate SHA1 Fingerprint: 61 ef 43 d7 7f ca d4 61 51 bc 98 e0 c3 59 12 af 9f eb 63 11

Download

Root 07 - SHA1 - RSA 2048 bits

Name: VeriSign Class 2 Public Primary CA - G2
Serial Number: 00 b9 2f 60 cc 88 9f a1 7a 46 09 b8 5b 70 6c 8a af
Valid From: Sunday, May 17, 1998 5:00:00 PM
Valid to: Tuesday, August 01, 2028 4:59:59 PM
Certificate SHA1 Fingerprint: b3 ea c4 47 76 c9 c8 1c ea f2 9d 95 b6 cc a0 08 1b 67 ec 9d

Download

Root 10 - SHA256 - RSA 2048 bits

Name: VeriSign Universal Root CA
Serial Number: 40 1a c4 64 21 b3 13 21 03 0e bb e4 12 1a c5 1d
Valid From: Tuesday, April 01, 2008 4:00:00 PM
Valid to: Tuesday, December 01, 2037 3:59:59 PM
Certificate SHA1 Fingerprint: 36 79 ca 35 66 87 72 30 4d 30 a5 fb 87 3b 0f a7 7b b7 0d 54

Download

Root 11 - SHA1 - RSA 1024 bits

Name: VeriSign Class 4 Public Primary CA - G3
Serial Number: 00 ec a0 a7 8b 6e 75 6a 01 cf c4 7c cc 2f 94 5e d7
Valid From: Thursday, September 30, 1999 4:00:00 PM
Valid to: Wednesday, July 16, 2036 3:59:59 PM
Certificate SHA1 Fingerprint: c8 ec 8c 87 92 69 cb 4b ab 39 e9 8d 7e 57 67 f3 14 95 73 9d

Download

Root 12 - SHA256 - RSA 2048 bits

Name: Symantec Class 1 Public Primary Certification Authority - G6
Serial Number: 24 32 75 f2 1d 2f d2 09 33 f7 b4 6a ca d0 f3 98
Valid From: Monday, October 17, 2011 5:00:00 PM
Valid to: Tuesday, December 01, 2037 4:59:59 PM
Certificate SHA1 Thumbprint: 51 7f 61 1e 29 91 6b 53 82 fb 72 e7 44 d9 8d c3 cc 53 6d 64

Download

Root 13 - SHA256 - RSA 2048 bits

Name: Symantec Class 2 Public Primary Certification Authority - G6
Serial Number: 64 82 9e fc 37 1e 74 5d fc 97 ff 97 c8 b1 ff 41
Valid From: Monday, October 17, 2011 5:00:00 PM
Valid to: Tuesday, December 01, 2037 4:59:59 PM
Certificate SHA1 Thumbprint: 40 b3 31 a0 e9 bf e8 55 bc 39 93 ca 70 4f 4e c2 51 d4 1d 8f

Download

https://www.ssl247.com/support/download-roots/symantec

doc/TorBOX/Dev

https://ea5faa5po25cf7fb.onion.cab/projects/tor/wiki/doc/TorBOX/Dev?action=diff&version=1240

v1239	v1240
109	109	}}}
110	110	* (proper) Open question: How to sign a certificate if you have no access to the private key and CSR (certificate signing request)? Therefore created [https://lists.torproject.org/pipermail/tor-talk/2012-July/024701.html tor-talk How to pin the SSL certificate for torproject.org?]. Some suggestions, no suitable solution for TorBOX.
111		* (proper) [http://www.mail-archive.com/openssl-users@openssl.org/msg67962.html OpenSSL users Sign public key without having CSR or private key?]
	111	* (proper) [http://www.mail-archive.com/openssl-users@openssl.org/msg67962.html OpenSSL users Sign public key without having CSR or private key?]; [http://www.mail-archive.com/openssl-users@openssl.org/msg67968.html might work] - didn't test, not sure if it could work.
112	112
113	113	== [0.2] [SHELLSCRIPTS] Scroll wheel in VM [OPEN] ==

1. As gnupg is failing to download the public key it can be done manually by this command: curl "https://pgp.mit.edu/pks/lookup?op=get&search=0x4E2C6E8793298290" -o - | gpg --import 2. Gpg key verification can be skipped by replacing a pkgbuild line which is not recommended as tor is a very crucial piece of software. The line is: validpgpkeys=('EF6E286DDA85EA2A4BA7DE684E2C6E8793298290' 'SKIP') Process 1 is safe, 2 is risky and totally your choice. Peace!

https://aur.archlinux.org/packages/tor-browser-en/

AND THEN MODIFY THE REQUEST AND RESPONSE

mitmproxy has a powerful scripting API that allows you to modify flows on-the-fly or rewrite previously saved flows locally.

The mitmproxy scripting API is event driven - a script is simply a Python module that exposes a set of event methods. Here's a complete mitmproxy script that adds a new header to every HTTP response before it is returned to the client:

def response(context, flow):
    flow.response.headers["newheader"] = ["foo"]

(examples/add_header.py)

The first argument to each event method is an instance of ScriptContext that lets the script interact with the global mitmproxy state. The response event also gets an instance of Flow, which we can use to manipulate the response itself.

We can now run this script using mitmdump or mitmproxy as follows:

> mitmdump -s add_header.py

The new header will be added to all responses passing through the proxy.

Example Scripts

mitmproxy comes with a variety of example inline scripts, which demonstrate many basic tasks. We encourage you to either browse them locally or in our GitHub repo.

Events

start(ScriptContext, argv)

Called once on startup, before any other events.

clientconnect(ScriptContext, ConnectionHandler)

Called when a client initiates a connection to the proxy. Note that a connection can correspond to multiple HTTP requests.

serverconnect(ScriptContext, ConnectionHandler)

Called when the proxy initiates a connection to the target server. Note that a connection can correspond to multiple HTTP requests.

request(ScriptContext, HTTPFlow)

Called when a client request has been received. The HTTPFlow object is guaranteed to have a non-None request attribute.

responseheaders(ScriptContext, HTTPFlow)

Called when the headers of a server response have been received. This will always be called before the response hook. The HTTPFlow object is guaranteed to have non-None request and response attributes. response.content will be None, as the response body has not been read yet.

response(ScriptContext, HTTPFlow)

Called when a server response has been received. The HTTPFlow object is guaranteed to have non-None request and response attributes. Note that if response streaming is enabled for this response, response.content will not contain the response body.

error(ScriptContext, HTTPFlow)

Called when a flow error has occurred, e.g. invalid server responses, or interrupted connections. This is distinct from a valid server HTTP error response, which is simply a response with an HTTP error code. The HTTPFlow object is guaranteed to have non-None request and error attributes.

clientdisconnect(ScriptContext, ConnectionHandler)

Called when a client disconnects from the proxy.

done(ScriptContext)

Called once on script shutdown, after any other events.

API

The main classes you will deal with in writing mitmproxy scripts are:

libmproxy.proxy.server.ConnectionHandler	Describes a proxy client connection session. Always has a client_conn attribute, might have a server_conn attribute.
libmproxy.proxy.connection.ClientConnection	Describes a client connection.
libmproxy.proxy.connection.ServerConnection	Describes a server connection.
libmproxy.protocol.http.HTTPFlow	A collection of objects representing a single HTTP transaction.
libmproxy.protocol.http.HTTPResponse	An HTTP response.
libmproxy.protocol.http.HTTPRequest	An HTTP request.
libmproxy.protocol.primitives.Error	A communications error.
libmproxy.script.ScriptContext	A handle for interacting with mitmproxy's from within scripts.
netlib.odict.ODict	A dictionary-like object for managing sets of key/value data. There is also a variant called ODictCaseless that ignores key case for some calls (used mainly for headers).
netlib.certutils.SSLCert	Exposes information SSL certificates.

The canonical API documentation is the code, which you can browse locally or in our GitHub repo. You can view the API documentation using pydoc (which is installed with Python by default), like this:

> pydoc libmproxy.protocol.http.HTTPRequest

Running scripts in parallel

We have a single flow primitive, so when a script is handling something, other requests block. While that's a very desirable behaviour under some circumstances, scripts can be run threaded by using the libmproxy.script.concurrent decorator.

import time
from libmproxy.script import concurrent


@concurrent  # Remove this and see what happens
def request(context, flow):
    print "handle request: %s%s" % (flow.request.host, flow.request.path)
    time.sleep(5)
    print "start  request: %s%s" % (flow.request.host, flow.request.path)

(examples/nonblocking.py)

Make scripts configurable with arguments

Sometimes, you want to pass runtime arguments to the inline script. This can be simply done by surrounding the script call with quotes, e.g. mitmdump -s "script.py --foo 42". The arguments are then exposed in the start event:

# Usage: mitmdump -s "modify_response_body.py mitmproxy bananas"
# (this script works best with --anticache)
from libmproxy.protocol.http import decoded


def start(context, argv):
    if len(argv) != 3:
        raise ValueError('Usage: -s "modify-response-body.py old new"')
    # You may want to use Python's argparse for more sophisticated argument parsing.
    context.old, context.new = argv[1], argv[2]


def response(context, flow):
    with decoded(flow.response):  # automatically decode gzipped responses.
        flow.response.content = flow.response.content.replace(context.old, context.new)

(examples/modify_response_body.py)

Running scripts on saved flows

Sometimes, we want to run a script on Flow objects that are already complete. This happens when you start a script, and then load a saved set of flows from a file (see the "scripted data transformation" example on the mitmdump page). It also happens when you run a one-shot script on a single flow through the | (pipe) shortcut in mitmproxy.

In this case, there are no client connections, and the events are run in the following order: start, request, responseheaders, response, error, done. If the flow doesn't have a response or error associated with it, the matching events will be skipped.

Spaces in the script path

By default, spaces are interpreted as separator between the inline script and its arguments (e.g. -s "foo.py 42"). Consequently, the script path needs to be wrapped in a separate pair of quotes if it contains spaces: -s "'./foo bar/baz.py' 42".

https://mitmproxy.org/doc/scripting/inlinescripts.html

Setting up a man-in-the-middle device with Raspberry Pi, Part 1

I recently purchased that most marvelous of devices the Raspberry Pi and naturally my thoughts turned to the nefarious given its cheap price and small package. I decided to attempt to create a man-in-the-middle device that could be discreetly attached to a remote network and could redirect and sniff traffic. I’m only a very novice Linux user so it took a bit of learning to wrangle man pages as well as some intrepid Google-fu, but I’m going to document how I was able to turn this tiny device into an evil packet-sniffing machine.

For those who don’t know, a man-in-the-middle attack involves secretly becoming an intermediary between the communication between two parties; each thinks they are talking to the other when in fact they are both talking to the attacker. The attacker can choose to pass the information along unmodified (simply observing the communication) or may choose to modify parts of the communication for the own evil ends. The Wikipedia article gives examples and also proposes counter-measures. The most widely used counter-measure currently in place is the use of SSL/TLS to verify the other party in a communication. TLS however relies on a public key infrastructure, and there have already been examples of hackers breaking into certificate authorities and issuing fraudulent certificates so as to perform man-in-the-middle attacks on HTTPS sessions. Hacking a CA is beyond the scope of this article and we will restrict ourselves to performing a MITM attack on HTTP traffic :).

The Raspberry Pi comes in two flavors, Model A and Model B. For the purposes of this article I’ll be using a Model B since it has an Ethernet port; the Model A, while $15 cheaper, doesn’t have any built-in networking. Since our plan is to surreptitiously plug our Pi into our victim network, we’ll need a physical Ethernet port. We’ll also need an SD card of at least 4 GB (these are pretty cheap).

The regular install on a Raspberry Pi is NOOBS (new out-of-box software) and contains several pre-packaged operating systems. However for the purpose of our MITM device we’ll be using a different Linux distro for our Pi: PwnPi. PwnPi is a distribution of the Raspbian OS that contains many pre-installed packages for security and penetration testing which is naturally right up our alley. So, go ahead and download PwnPi. Once it’s downloaded we’ll need to load it onto our SD card. First, format your SD card using the SD card formatter from the SD association. If the “size” value shown in the formatter is less than the size of your card, be sure to choose “format size adjustment” in the card.

Once your card is formatted and you’ve downloaded PwnPi, extract it using a tool like 7-Zip. The result should be a .img file. We can now use a tool like Win32DiskImager to write the PwnPi image onto our SD card. For some reason Win32DiskImager always crashes on me when I click the folder icon to search for a file, so I had to manually type in the path to my PwnPi image. Once you’ve selected the image, go ahead and write it to your SD card.

Now, you would expect that we could plug this SD card in to our Pi and boot. But, attempting this will lead only frustration. This is because PwnPi doesn’t support Model B Pis. This is because the firmware for booting in the PwnPi is extremely out of date, but we can download the latest Pi firmware and replace the necessary files on our SD card to get the boot to work. These files can be found here. I’ve cached them all and you can download them directly from this site. The PwnPi image contains two partitions: a FAT partiton used to boot and a Linux-formatted partition that contains the OS. Thankfully Windows supports reading the FAT partition we need to modify; if you navigate to the SD card after writing the PwnPi image it should look merely like a 55.9 MB FAT partition with a few files in it.

Replace the files on the card with the files from the latest Pi firmware. Once you’ve done this your Pi Model B should successfully boot PwnPi.

A note about the Raspberry Pi: if you have a keyboard and mouse plugged in (which you should) the Pi often takes more power than a standard AC adapter can provide. I’m using a powered USB hub to ensure that all of my peripherals work. However, the default PwnPi image is pretty out of date and may not support your USB mouse/keyboard (it didn’t support mine, for example). Even if it does, it’s a good idea to update our Pi to the latest versions of software. Before we can do this however, we need to expand the file system to encompass our entire SD card. The .img we wrote to our SD card constituted a bit-by-bit image of the file system; unfortunately this included a minimally sized data partition. We need to expand this partition. To do this, start the Raspberry Pi Software Configuration Tool by entering the following at console:

1

raspi-config

The first choice should be “Expand filesystem”, which is what we want. Press enter and follow the prompts. Reboot when asked to. When the Pi has rebooted, we can now begin the process of updating its software. Enter Aptitude, the package management system on the Pi by entering the following:

1

aptitude

Once in Aptitude, press the ‘u’ key to get the list of latest updates available. The Pi will update the latest list of packages from the Raspbian sources. When it’s finally finished updating there should be a large amount of packages available for update (as of this writing 371 were available from a fresh install of PwnPi). Select “Upgradable Packages” and press the ‘+’ key. This will select all upgradable packages for installation. Press the ‘g’ key to view what packages will be installed and press ‘g’ again to begin downloading and installing. Wait a bit (for various definitions of bit) for all packages to finish download and install. When it’s all said and done you will be prompted to press return to continue. This will bring you back into aptitude, from which pressing ‘q’ will quit. The updates we installed included a new kernel which requires a reboot, so go ahead and do this at the console.

1

reboot

We’ve almost finished getting our Pi into a workable state. If you’re like me though and reside in the United States you will soon notice that the keyboard layout of the Pi doesn’t match what you would expect. This is because the Pi is setup by default to use the British keyboard layout. To change this, we first need to configure our locale. Do this by entering the following.

1

dpkg-reconfigure locales

Use the arrow keys to scroll down to “en_GB.UTF-8 UTF-8”. Press space to deselect this. Then, scroll down and select “en_US.UTF-8 UTF-8”. Press tab to select OK and press enter. You will then be asked to select the default locale for the system. Change the selection from “None” to “en_US.UTF-8 UTF-8”, and then press tab to select OK and press enter. A new locale will be generated on exit. Now we need to change our keyboard layout. Enter the following:

1

dpkg-configure keyboard-configuration

Press enter on “Generic 105-key (Intl) PC”. On the next screen scroll all the way down to “Other” and press enter. Then, select “English (US)” and press enter. On the next screen scroll all the way to the top and select “English (US)” again. Select “The default for the keyboard layout”, “No compose key”, and “No” on the subsequent screens. Finally, do a reboot for everything to take full effect.

1

reboot

Once the Pi has rebooted we can finally start being evil! Start up the graphical user interface by entering the following:

1

startx

We can confirm that our keyboard layout is correct by right-clicking and going to Applications->accessories->Notepad. If Shift-2 produces an ‘@’ then everything is good! If you’re feeling adventurous, explore the “PwnPi” menu to see all of the tools available to us.

We’ll be using a tool called mitmproxy to perform the actual man-in-the-middle attack. mitmproxy is a powerful tool that can capture and display all HTTP traffic when performing a MITM. It also has Python library named libmproxy which we can use to script our attack. Unfortunately mitmproxy isn’t pre-installed on PwnPi but we can fix this! First we need to install pip, which is a tool for installing and managing Python packages. We can do this by right-clicking, opening a Terminal, and executing the following:

1

2

3

wget https://raw.github.com/pypa/pip/master/contrib/get-pip.py

chmod +x get-pip.py

./get-pip.py

Once pip is installed we need to install a few prerequisites before mitmproxy will work.

1

2

3

apt-get install python-dev

apt-get install libxml2-dev

apt-get install libxslt-dev

These packages are needed because we will be compiling mitmproxy as well as its dependent packages from source. Once they’ve been installed we can download, compile, and install mitmproxy.

1

pip install mitmproxy

Note: this may take a very long (30 minutes+) time. Specifically, compiling libxml2 from source on a Raspberry Pi is quite a taxing task. Eventually pip and mitmproxy will be ready to be used! First though we need to insert our Pi between our victim computer and the rest of the internet. To do this we’ll need to know the victim’s IP address on the network and the IP address of the default gateway it uses to talk to the rest of the world (this is usually the local router). Once we have these, we’ll use a technique called ARP spoofing to fool the victim into thinking our Pi actually holds the IP address of the gateway. Likewise we’ll fool the gateway into thinking the Pi holds the IP address of the victim. In this manner we can insert ourselves between the victim and the gateway and intercept and modify all traffic.

For demonstration purposes I’ll be attacking a laptop running Windows 7 on my home network. For those who don’t know, ARP is the protocol used to resolve MAC addresses (the unique physical address every Ethernet controller has) to logical IP addresses. When a device first enters an Ethernet network, it has no idea how to talk to any given IP address. So, it sends broadcast messages asking which MAC address owns which IP addresses. We’ll be sending fraudulent ARP responses to make our victims think we have IP addresses we really do not. To see the current values in our local ARP table, we run the following in a command prompt on Windows

1

arp -a

The IP address of my laptop is 192.168.0.106 with a default gateway of 192.168.0.1. The left column shows the logical IP address and the right column shows the MAC address that each IP corresponds to. Now, on our Pi let’s trick the victim into thinking we hold 192.168.0.1. Open a terminal on the Pi and enter

1

2

arpspoof -i eth0 -t  

arpspoof -i eth0 -t

Obviously you’ll need to replace the brackets with whatever IPs you’re attacking. You’ll need to run each of the above commands in a seperate terminal and keep them running — we need to constantly keep the charade up lest the victim revert back to the correct MAC->IP mapping. Let’s recheck the ARP table on our target now.

We see now that the victim thinks that the gateway has the MAC address as our Raspberry Pi. Consequently, any requests that would go to the gateway will actually get sent to our Pi. As of now though our victim has no internet connectivity — all requests are being forwarded to the Pi but the Pi is not doing anything with them. So, we need to set up our Pi to transparently forward (and perhaps modify) these requests.

mitmproxy has two modes of operation: a regular proxy mode where it acts like a regular HTTP proxy. Unfortunately for this to work we need to configure the proxy on the victim computer. However, it also has a “transparent” mode which is what we’ll use. In transparent mode, it fakes an HTTP server on port 8080 (by default). But, all of our traffic from our victim is coming into the Pi on the default HTTP port (80). To fix this, we need to tell Linux to route all traffic from port 80 to port 8080. To do this, enter the following:

1

2

sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

Incoming HTTP traffic should now be forwarded to mitmproxy. Now all we have to do is actually start mitmproxy. This is done simply by executing

1

mitmproxy -T --host

Now let’s go to a website on our victim computer, say cnn.com. If all goes well the page should load. We should also see some interesting output on mitmproxy.

mitmproxy is showing us all of the HTTP traffic as it passes through the proxy. Our victim asks what it thinks is the router (but is really the Pi) for http://cnn.com. Our Pi then connects to cnn.com, fetches the result, and returns it to the victim. Let’s tell mitmproxy to intercept the response from cnn.com. When mitmproxy intercepts a request or response it does not immediately forward it but gives us a chance to edit it. Press the ‘i’ key to set an intercept filter and then type

1

~s ~h "Host: .*\.cnn\.com" ~u /$

This tells mitmproxy to intercept all responses from cnn.com that are the result of the “/” (root) page. Now, if we navigate to http://cnn.com on our victim computer, we’ll notice that the page won’t load. If we look at mitmproxy we’ll see there’s an orange-highlighted response. This has been intercepted and is awaiting our approval to send on.

We can use the arrow keys to scroll down and select this intercepted response. By pressing enter on it we can inspect it closer. Press tab to switch to the response (it currently is showing us the request).

This response is an HTTP/200 OK response (the normal response when a web server returns a page). We’re going to modify this into an HTTP/302 Found response, which will redirect the user to a different page. Now, press ‘e’ to edit this response. Then, press ‘c’ to change the code, and change it to 302. Then, press ‘e’ again to edit and press ‘h’ to edit the HTTP headers. Scroll all the way to the bottom and press enter on the “Content-Encoding” header. Change this to “Location”. Press the right arrow to select the value of the header and change it to “http://abc.com”

Press ‘q’ to go back to the main inspection screen. Now, by pressing ‘a’ we can send the response on its way. If we look over at our attack computer we can see that it’s being redirected to abc.com!

As we’ve seen, Raspberry Pi with mitmproxy and arpspoof can be a powerful tool to intercept and modify traffic on a local area network on the fly. mitmproxy also supports logging traffic, which could then later be retrieved and inspected for passwords or any other sensitive information.

Next post I’ll cover how we can use libmproxy to script the modification of the HTTP requests and responses.

http://jeffq.com/blog/setting-up-a-man-in-the-middle-device-with-raspberry-pi-part-1/

BLACK MASK

Tuesday, February 7, 2017

I wonder if i helped a friend with this research...they track you, (of course in TOR) because they add a mdf. file written in visual studio (of course) on your tables database (I'm not sure if its really temporary) ...so...wherever they are search them in here:

**Compare MySQL databases & automatically create schema & data change scripts/migrations rapidly (up & down SQL supported) for database version control. Supports most migration tools.https://github.com/DBDiff/DBDiff**

Download Symantec Root Certificates

Root 01 - SHA1 - RSA 1024 bits

Root 02 - SHA1 - RSA 1024 bits

Root 03 - SHA1 - RSA 2048 bits

Root 04 - SHA1 - RSA 2048 bits

Root 05 - SHA384 - ECC 384 bits

Root 06 - SHA1 - RSA 2048 bits

Root 07 - SHA1 - RSA 2048 bits

Root 10 - SHA256 - RSA 2048 bits

Root 11 - SHA1 - RSA 1024 bits

Root 12 - SHA256 - RSA 2048 bits

Root 13 - SHA256 - RSA 2048 bits

doc/TorBOX/Dev

https://aur.archlinux.org/packages/tor-browser-en/

AND THEN MODIFY THE REQUEST AND RESPONSE

Inline Scripts

Example Scripts

Events

start(ScriptContext, argv)

clientconnect(ScriptContext, ConnectionHandler)

serverconnect(ScriptContext, ConnectionHandler)

request(ScriptContext, HTTPFlow)

responseheaders(ScriptContext, HTTPFlow)

response(ScriptContext, HTTPFlow)

error(ScriptContext, HTTPFlow)

clientdisconnect(ScriptContext, ConnectionHandler)

done(ScriptContext)

API

Running scripts in parallel

Make scripts configurable with arguments

Running scripts on saved flows

Spaces in the script path

Setting up a man-in-the-middle device with Raspberry Pi, Part 1

Man in the Rain

Total Pageviews

Search Webcams:
by www.online-camera.de

Tuesday, February 7, 2017

Compare MySQL databases & automatically create schema & data change scripts/migrations rapidly (up & down SQL supported) for database version control. Supports *most* migration tools.https://github.com/DBDiff/DBDiff

Root 01 - SHA1 - RSA 1024 bits

Root 02 - SHA1 - RSA 1024 bits

Root 03 - SHA1 - RSA 2048 bits

Root 04 - SHA1 - RSA 2048 bits

Root 05 - SHA384 - ECC 384 bits

Root 06 - SHA1 - RSA 2048 bits

Root 07 - SHA1 - RSA 2048 bits

Root 10 - SHA256 - RSA 2048 bits

Root 11 - SHA1 - RSA 1024 bits

Root 12 - SHA256 - RSA 2048 bits

Root 13 - SHA256 - RSA 2048 bits

Inline Scripts

Example Scripts

Events

start(ScriptContext, argv)

clientconnect(ScriptContext, ConnectionHandler)

serverconnect(ScriptContext, ConnectionHandler)

request(ScriptContext, HTTPFlow)

responseheaders(ScriptContext, HTTPFlow)

response(ScriptContext, HTTPFlow)

error(ScriptContext, HTTPFlow)

clientdisconnect(ScriptContext, ConnectionHandler)

done(ScriptContext)

API

Running scripts in parallel

Make scripts configurable with arguments

Running scripts on saved flows

Spaces in the script path

**Compare MySQL databases & automatically create schema & data change scripts/migrations rapidly (up & down SQL supported) for database version control. Supports most migration tools.https://github.com/DBDiff/DBDiff**