Sitwon

Asking people to buy closed-source software that isn't written yet? Based on nothing but your promises? And you're going to be borrowing heavily from Free and Open Source Software to build your closed-source, commercial project? O_o I'm with Oli, sounds pretty sketchy to me.

Ubuntu probably isn't actually reading the FN key, just the key codes for ALT and F2. Holding FN is an implementation detail of your keyboard to allow it to send the F2 key code instead of whatever keycode it normally sends for that key. You can check which key codes are actually being received by the system with the 'xev' utility.

The most trivial solution would look like this: while [ true ] do aireplay-ng -# # -a<MAC> -h<MAC> mon0 & PID=$! sleep 300 kill $PID sleep 300 done In bash (and pretty much any other derivative of 'sh'), '$!' is a special variable which holds the PID of the last command to be executed in the background (with '&'). Once we have the PID, we can use it to inspect or control that process. For example, by using the 'kill' command to send it a TERMinate signal. If it were me, I'd write a much more sophisticated function for ensuring that the process actually terminates before the next iteration. (Eg, send a KILL signal if the PID is still active after a reasonable timeout.)

To slightly extend Cooper's explanation. 1. Don't forget about swap space. Even if you have only 16GB of physical RAM, you could extend that (as far at the running program is concerned) by periodically swapping inactive pages of memory to disk. There is, of course, a performance penalty, but for some applications it's worth it. 2. The way virtual address space works is that your program doesn't access the RAM directly, rather it makes system calls and tells your Operating System's kernel to do it. That's how each application can think it has it's own 8TB even though your system doesn't actually have that much space. The virtual address space of a given process doesn't even have to be contiguous. When your application requests more memory and the OS determines that there is none left to allocated, there OS can generally do one of two things: a) It could terminate the application with an out-of-memory error, or b) it could simply block until the requested memory is available.

What you're seeing there is the public half of the host key. It won't help you with logging in, it's just there to allow clients to authenticate that they're connecting to the SSH server that they intended to. Even if you cracked the private key, all that would allow you to do would be to impersonate that SSH server to other clients. It wouldn't help you with logging in.

ClusterKnoppix will almost certainly not do anything useful for you. Development of the upstream project was abandoned because there was no longer any pragmatic benefit to be had on the commodity hardware of the time.

That would not work. You need to capture the output of nc into the $STATUS variable, otherwise your else clause will just result in $STATUS=="".

Easier? I don't know. It would also work. I guess I could have written it like this. get_status(){ STATUS="$( nc -w "${TIMEOUT}" -z ${DOMAIN} ${PORT} 2>&1 )" if [ "$?" -eq 0 ]; then STATUS="Success" else STATUS="${STATUS##*: }" fi } Or even like this. get_status(){ STATUS="$( nc -w "${TIMEOUT}" -z ${DOMAIN} ${PORT} 2>&1 )" \ && STATUS="Success" \ || STATUS="${STATUS##*: }" } Just up to your style/preference I suppose.

Trying to emulate your example relatively closely... #!/usr/bin/env bash TIMEOUT=30 stime(){ local START="$( date +%s )" "$@" local END="$( date +%s )" TIME=$(( END - START )) } get_status(){ STATUS="$( nc -w "${TIMEOUT}" -z ${DOMAIN} ${PORT} 2>&1 && echo Success )" if [ "${STATUS}" != "Success" ]; then STATUS="${STATUS##*: }" fi } report_status(){ stime get_status echo "${STATUS} | ${TIME}s" } while read LINE ; do DOMAIN="${LINE%%:*}" # alternatively: "$( cut -d : -f 1 <<<"${LINE}" )" PORT="${LINE##*:}" # alternatively: "$( cut -d : -f 2 <<<"${LINE}" )" echo "${DOMAIN}:${PORT} | $( report_status )" done < "${1}" The output doesn't exactly match your examples, but it's pretty close. There are many potential improvements that could be made, such as testing servers in parallel rather than sequential, improving the resolution of the timer, or performing additional diagnostics on failed connections. If I get bored today I may continue poking at this and update the thread.

Tor may be reasonably secure at anonymizing your traffic at OSI Layer 4, however all the layers above that are unprotected by Tor. Unless you are using applications which were specifically configured/designed to protect your anonymity, your computer/devices are likely to leak identifiable information about you and undo the advantages of using Tor. Devices like the Anonabox or Onion Pi are designed for convenience. To allow you to use your normal web browser over the Tor network. However convenience and security are always at odds with each other. Your normal browser for web surfing is almost certainly not properly secured for protecting your anonymity on Tor. It's for these very reasons that the Tor Browser Bundle and Tails were created. They provide you with a safe(er) environment in which to browse the web without leaking as much about your identity. So Anonabox and Onion Pi both encourage an unsafe way of using Tor. They give you a false sense of security, where you expect your identity to be protected but the rest of the system is actually giving away identifiable information about you. This is dangerous. The recent Hak5 episode on OpenGarden discusses some very similar issues. The OpenGarden mesh is promoting itself as a tool for protesters, but by using OpenGarden they are literally broadcasting their position and identity in the clear over 2.4GHz (whether over WiFi or Bluetooth). So a government goon could easily single them out. Talk to your local Hams about "fox hunting" if you want to learn about how easy it is to find an offending station.

The OnionPi already does exactly the same thing. A $30 RaspberryPi plus some free software and documentation are already available on the market right now to do this. But it's not secure, so if you build one, don't use it to do anything stupid.

The broader problem with Anonabox is that it's just plain dangerous. It's the type of product that gets people killed. Anonymity is hard. Very hard. It's never going to be as simple or as easy as plugging a box into your network. The developers of Tor recommend using TBB or Tails for very good reasons. Your browser (and all your other network-aware applications) will leak far more information than even sophisticated users tend to realize, and it is far from trivial to configure your browser securely and browse the Internet safely while remaining anonymous. So difficult, that if you manage to do everything properly you would probably stick out like a sore thumb because you'd be one of a very small number of users to do so. Products like this prey on people who need real security but lack the skills and sophistication to do it properly. It lulls them into a false sense of security where they are more likely to put themselves at risk and put themselves and/or those they care about in harms way. I don't recommend this project.

Where about in Maryland? I live in Silver Spring (just north of DC). The cheapest/easiest option will probably be StraightTalk. http://www.straighttalkbyop.com/ The 3GB of 4G is a bit lower than what you can get from T-Mobile, but for a week it should be plenty.

Sounds like the OP wants to be sure that all traffic is going through the proxy (much like the TOR liveCD claims to do). It's easier to proxy specific applications. If the application supports SOCKS proxies you can configure it directly. If it does not you can use a utility like tsocks or proxychains to sort of trick it into using a SOCKS proxy (it hijacks the system-calls and redirect network traffic through the proxy.) Doing it system-wide is a bit more complicated, and depending on the circumstances, potentially ill-advised.

Have you checked if Cyanogen will work with your tablet? They seem to support a lot of devices, and it would save you from re-inventing the wheel. Seems like most of the custom ROMs out there are using Cyanogen as a starting point.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

1) you have previously exchanged contact information through some other secure method, or 2) you rely on a web of trust to establish their identity as the person you intend to communicate with (which does not necessarily leak a legal identity, just that the pseudonym is trusted by others whom you may have independently verified.) Or possibly: 3) If you are mutually pseudonymous you may not actually care to have any guarantees of their identity other than it's the same person (or entity) each time. Their real world identity might not be relevant to your conversations with them. For example, many agents of Telecomix are pseudonymous. They may not actually care about the real-world identities of their collaborators so long as they can make the reasonable assumption that they are always talking to the same person or entity. To the extent that their operations might be compromised by a MITM attack... if the adversary takes direct action based on information they obtain then both parties will know that the communications channel has been compromised and will abandon it. So even with active surveillance they can still be at least marginally effective at achieving their goals, because the adversary can't effectively respond without giving up their ability to tap the comms.

I think this test a slightly more straight-forward: env x="() { :;}; echo vulnerable" bash -c ":" If it prints "vulnerable" to the screen, you are vulnerable. Test also with other shells on your system such as ash or zsh, sh is usually a symlink to bash. ':' is the no-op command in Bourne Shell. It's equivalent to 'true', but three characters shorter.

I'm not sure I understand what you're saying. 1. If what you mean is that you're trying to protect the contents of your message, than this is a solved problem. For example, If Alice and Bob want to have a conversation, and they don't care that anyone knows that they're talking to each other (just so long as nobody knows what they're saying) then there are many many options out there. This is basically the OpenPGP model, where everyone can see who you are exchanging emails with, and all of the metadata of your emails, but the contents themselves are encrypted. (Though, they can still estimate the size of the message and make inferences from there about the contents.) Tools like Pidgin OTR or TextSecure do the same thing as OpenPGP, just over transport channel. This may be sufficient security if you're exchanging messages with people who you already have very strong connections to, for example family members, friends, or coworkers. There are plenty of other ways to tell that you have a relationship with these people, and there are plausible explanations for why you are exchanging messages with them. 2. This is the real problem that is not addressed by the current tools. How do you communicate with someone securely without a) revealing who you are to them, and b) revealing to an observer that you are communicating with them? This is a problem that a lot of people actually have when they try to communicate anonymously or pseudonymously on the Internet. Metadata is the real killer (as described in detail by the Snowden leaks.) With near-real-time communication you will always be giving away some amount of metadata (such as when you are talking to them) but by using Tor you can prevent an outside observer from discovering that you are having the conversation at all, and you prevent the person you are conversing with from discovering your identity. There are very few tools out there that try to address this much more challenging problem of metadata, but metadata is currently the Achilles Heel of security. It's not just the three-letter agencies, but also commercial advertisers and service providers who collect and analyze your metadata in order to profile you. Companies like Google and Amazon can almost know more about you from your metadata than from your actual content. If you like Anime, and you're familiar with Death Note, this article is a light introduction to how Information Theory can be applied to identify a unique individual from their metadata. http://www.gwern.net/Death%20Note%20Anonymity

Fucking bash... http://www.reddit.com/r/netsec/comments/2hbxtc/cve20146271_remote_code_execution_through_bash Comparisons to Heartbleed would not be misplaced.

Ricochet was designed to solve the problem of communications metadata. It's all well and good to encrypt the content, but often the metadata alone is enough to be damning in an investigation or court room. It doesn't actually matter what's in the message, the fact that you sent or received it is evidence in and of itself. Comparing TOR to Morse Code makes me think you haven't touched it in many many years. I'm not gonna say it's "blazing" fast, but it's not nearly as bad as it once was. And for the security it affords you... well there's no free lunch. You're not going to get that kind of mitigation of plain-view metadata without making some kind of compromise. If you're satisfied with encrypted contents, there are plenty of established options on the table, including Pidgin's OTR plugin.

Based on the amount of "TODO" labels I'm seeing, the poor quality of the documentation, and a stark lack of technical discussion about their security model, I don't have a lot of confidence in this project. It may eventually develop into something cool, but for now I'd stay away. I think this effort shows more promise, especially considering the names behind it: http://invisible.im/#

Hmm, not sure how I missed this. I agree with Cooper, but Tox deserves at least a cursory investigation. It's making some big claims regarding privacy. Not impossible claims, but the type that are easy to subtly mess up.

1. Try the default password. Often people don't change the password. 2. Try other common passwords. Often people pick really terrible or obvious passwords. 3. Brute-force the login page. Most router web interfaces have very weak protections against brute-force login attacks. Edit: 4. Bypass the router by replacing it with a new one, or just plugging a new one in to an unfiltered LAN port and using that to provide unfiltered WiFi.

If you know the ins and outs of portage and emerge, you can write/edit complicated ebuilds, you have experience merging packages to a target system which is different from the host system, and you can resolve mutual dependency conflicts ...and you _still_ like Gentoo... then there's a job for you at the company where I work.