Sitwon

"Hackers" (the one with Angelina Joli) is still one of my favorites. A lot of people mistakenly write it off because of the cheesy dialog and "hacking" scenes, but it was prophetic in terms of the hacker culture and aesthetic. When that movie came out there were almost no hackers that looked like the characters on the screen, but just ten years later conferences like DEFCON had turned into raves full of people straight out of that movie. The clothes got better, the music got better, and we even have hacking show that's all about technolust. All inspired by Hackers. Wargames with Matthew Broderick and Allie Sheedy is also a classic (and the hacking scenes are probably still the most accurate of any Hollywood film.)

It might be a downgrade in specs (on paper) but ThinkPads have a well-earned reputation for superior design and build quality. The end result is more rugged, durable, and trouble-free over a much longer lifespan than most other brands. And long after MSI has stopped supporting your gaming laptop, you will still be able to purchase replacement parts for your ThinkPad at a reasonable price. That's one reason why ThinkPads are often the choice of professionals who need a reliable workhorse. But if you only care about performance the MSI is a better value.

It works basically the same way a headphone splitter works, only a network cable transmits data in two directions so you have to split it twice (once for each direction.)

You can probably replace it with off-the-shelf parts. That case looks like it holds a normal 2.5" drive.

According to the MSI website the board will support a maximum of 32GB (8GBx4). http://www.msi.com/product/nb/GT600NF_Workstation.html#hero-specification

Personally, I have always trusted the ThinkPad T-series as the best laptops for programmers, admins, or security folks. However I'm not sure I'm a fan of Lenovo's most recent changes. They're messing with they keyboard, which had been one of the iconic features of the ThinkPad line for almost 30 years. Still, they have fantastic hardware and construction compared to the majority of what I see on the market from other manufacturers. So, worth a look. If you're just want power and are looking to gaming laptops for it, you should consider the MSI GS70. It packs a lot of power for it's size/price. http://www.newegg.com/Product/Product.aspx?Item=N82E16834152589&cm_re=gs70-_-34-152-589-_-Product Alienware laptops aren't bad, but they're really not designed for the working needs of an engineer. The keyboards are sufficient for gaming, but not fantastic for typing at all day. And unless you're also using it for gaming, that big GPU is just going to add bulk, weight, and drain your battery faster for no real benefit. There are a lot of alternatives to Alienware out there which are worth looking at, unless you're really married to the idea of buying from Dell.

Hacking and pentesting is not really about writing code. It's more about creativity, and solving puzzles. Programming languages, like all other knowledge, are just tools that you can apply to try and solve the puzzle. The question isn't really what to learn, because you should learn everything you can to have the broadest set of tools to help you in solving puzzles. The real question is which tools you want to learn first. Learning to use a programming language is important because programming languages are one of a hacker's most useful and versatile tools. If you can write programs, you can automate tasks, compute important values, or poke and probe at the inner workings of an otherwise closed system. But often it's not the language itself, or even the programs you write, that is most valuable to a hacker. Rather, it's the deeper understanding of the underlying system. Understanding how software is made, how it works, how things are likely to be implemented, which approaches are easier or more obvious versus those which are cumbersome. The insight into what is happening, or likely to be happening, behind the scenes is what will really pay off when you're trying to solve the puzzle of breaking the system. Cracks tend to appear at the boundaries between different abstraction layers, so learn each layer well. Learning C is a very good start, because it is a lingua franca, or universal second language, in most of the field. Much like Latin is to the scientific community. If you can understand C, you can understand virtually any language you are likely to see published, as most of them are either direct descendants or were originally implemented in C. (There are some notable exceptions, but they are uncommon enough to ignore for now.) There is no bad language to learn, but there are some which you will want to put at the top of your list. First, figure out where you spend the majority of your time, and then learn the language which will help you best in that context. For some people, they spend a lot of time in the browser poking around at web applications. If that sounds like you, learn to use JavaScript and start writing user scripts to automate or transform the pages you interact with. Other people spend a lot of time in the shell. If you're a command-line junkie you should devote some time to really learning the ins and outs of Bash (or which ever shell you use). You might be surprised how powerful your shell's scripting language can be, and often a small investment can pay very large dividends in terms of automating or simplifying the tasks you do the most. For some tasks you may find that you need to write stand alone applications, but shell scripts are just not suitable. Since you already know C, that's a good option to turn to. However you may find that Python or Ruby or Perl is a bit quicker and easier than writing, compiling, and linking together a C application. If you've already been learning JavaScript, you might use that in conjunction with Node.js to similar kinds of applications. It's somewhat less common for hackers or pentesters to write code in Java, but it is still worthwhile to learn either Java or .Net to become familiar with languages which run in a VM and the ways in which their development cycle differs from other types of languages. It's primarily useful if you plan on attacking these languages. Java applications are commonly vulnerable to manipulation of the classpath, for example. I would point out, though, that even if you don't end up using every language you learn, it is usually still valuable to have learned them. Learning a new language gives you a different perspective on familiar problem sets. It shows you new ways of looking at problems and different approaches to solving them. Often, even if you don't end up using a language that you've learned, you will find yourself re-apply patterns from one language in a different language. And as I mentioned before, understanding the design and trade-offs of a given language can leak information about where to find mistakes or weaknesses in applications written in that language. Once you have a couple of languages under your belt, you might take a pass at Seven Languages in Seven Weeks. http://pragprog.com/book/btlang/seven-languages-in-seven-weeks Or even the sequel, Seven More Languages in Seven Weeks. http://pragprog.com/news/seven-more-languages-in-seven-weeks Remember, the point is not that you will ever have a need to directly use any of these languages. Rather, the point is to inspire you with different ways of looking at familiar problems. Because at the end of the day, hacking and pentesting are about your ability to be creative and solve puzzles with the tools available to you, not your ability to write code.

While I am often the first (only?) to point out that there's no such thing as a bad first-language, I think there are many better first-languages to choose from. If I were teaching programming to young children (such as 5 year olds) I would most likely choose Scratch, Python, Lua, or JavaScript.

Ruhm Barbancourt http://www.barbancourt.net/

I agree with Elk, perl is in the same class (in terms of features and performance) to languages like Python or Ruby rather than Bash or other Bourne shell derivatives. In fact, Python started as a replacement for Perl, and has pretty much succeeded at displacing it. On a typical *nix system these day you will find far more Python than Perl, even for the type of scripts that would have been Perl's domain a decade or two ago. Personally, I tend to prefer Python over Perl. The performance is similar, but the grammar is simpler and the syntax is cleaner. Between Python and Ruby it's a toss up these days. Ruby has generally close the performance gap, and it offers some powerful language features which Python lacks, but still hasn't caught fire with sysadmins the way Python has. Despite its limitations, I think Bash is still a beautiful language. It's a lot more sophisticated and capable than most people give it credit for.

To me, one of the most compelling reasons to use Python is that is has one of the easiest FFI (foreign function interface) implementations of any popular language I've seen. Using the 'ctypes' module you can load and execute nearly any shared library. You can even write Python functions and pass them to a native library as a callback. It may seem like just a novelty, but that ability to seamlessly tie together shared libraries with a simple and readable scripting language is pretty powerful. Now Python is not going to be the right tool for EVERY job, but it's a useful multitool to keep in your bag.

I never said commit every single time you save, but you should still be committing very frequently. Since it's a local operation (and performance-wise much faster than copying the file) it's extremely cheap in Git, and it pays dividends in giving you the ability to track changes and regressions over time. Have you ever used git-bisect? But sure, let's say that you're using CVS because you still live in the stone age. You can still avoid breaking the build by using a feature branch while you're working. Also, I would argue that if you're working on the same piece of code for "a few days" without having anything to commit, your change is probably too big or convoluted and should be re-thought or broken up anyways. I know this is a touch subject because developers don't like having their "process" criticized, but going "a few days" between commits tends to correlate with bad developer habits, sloppy change history, and spaghetti code. I'm not sure what you're getting at here. Are you saying that someone who accidentally deletes a file is not fit to be a programmer? People make mistakes. Shit happens. The only thing that would make someone "unfit" in my view would be if they refuse to learn from the experience. Yes, backup is not 100% idiot-proof and you can still potentially lose data. But are you really going to sit there and neg on one of the most obvious and simple ways to MITIGATE THE RISK of losing valuable data? Sure, user error is a thing, but throwing your hands up and saying "well there's nothing to be done about" when existing tools can actually protect you in 95% of cases is pretty ridiculous. Wow, that's a really good point. Storing full copies of every permutation of a file would take a lot of space and be really expensive. I wonder why nobody else has ever thought of that before... ... because it's not like we ever developed advanced compression or differential backup technology. How often do I lose data and need to recover it? Not that often. I follow a number of best practices and good habits to help minimize my risk of losing data in the first place. But even still, I've had accidents and needed to recover data before. More often, I've had other people come to me for help when they've lost important files to accidents or hardware failures. Data loss which could have been trivially prevented by the use of backup software. The last time I had significant data loss was a multi-drive failure of my principal RAID-5 array. I am still in the process of re-downloading some of the content I lost, and despite the best efforts of tools like TestDisk some of my data will never be recovered. At the time I did not use remote backups on that system because either buying the disks or using online storage for over 3TB of data were both seemed prohibitively expensive. But after rebuilding that system (with RAID-6 this time) I looked around and found that CrashPlan's unlimited storage plans were actually quite reasonably priced. Compared to the value of my data and the time lost trying to recover it, CrashPlan was absolutely worth the cost. CrashPlan is free if you (or your friends) have the storage space to hold your own backups. You only pay if you want to use their cloud storage options, which are quite reasonably priced. As for the "hassle"... well there's not much hassle. The software takes about five minutes to install and configure, and then you can just forget about and let it do its own thing. It stays out of your way and runs at a low priority so it's only consume idle resources. Your objections to this simple, common sense mitigation technique seem overblown compared to the reality.

Use Git, work in your own branch, you can even use a private branch that you don't push if you want. At least that way you have historic copies of the file, even if they're only on your machine. Your excuse is weak. Also... what exactly is your argument against backups? Automated backup software (like CrashPlan) will ABSOLUTELY help with simple user errors like this one. CrashPlan continuously monitors your filesystem and backs up changes, so you're protected if you accidentally delete a file that you were working on.

Everything on this list: http://www.gaiaonline.com/forum/c-t-tech-talk/suggested-reading-technology-and-programming/t.69647195_1/ Also, these two: http://www.amazon.com/Elements-Computing-Systems-Building-Principles/dp/0262640686/?tag=hacdc-20 http://www.amazon.com/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441/?tag=hacdc-20 The Elements of Computing Systems is a MUST READ if you don't have a solid grasp of the full stack. It takes you through logic gates -> CPU -> machine language -> assembly language -> low-level language/VM -> high-level language -> operating system/standard library. This kind of full-stack perspective is absolutely essential to understanding how things work and where to look for weak spots. Exploits are almost always lurking in the boundaries between different abstraction layers. Code by Charles Petzold, or MIT's Structure and Interpretation of Computer Programs (SICP) are also good full-stack introductions. SICP is particularly rigorous, but well worth it.

I have a Baofeng UV-5R and we have a few more at HacDC which we used when testing AX.25 over HAM as a potential medium-distance transport for Project Byzantium. The Baofengs in general are decent, capable HTs. They're not as nice as a Yaesu or Kenwood (which cost about 10x as much) but they can still hit the local repeaters from a decent distance and they are a lot better value, especially when you're just starting out. It's good enough for you to practice on while you get licensed and figure out what features you want/need in the long-run. And since they're so cheap, they're easy project fodder. You won't feel bad about cracking them open to solder bits on or tossing them into projects which might get vandalized or destroyed. It's only $30-50. Also, the Baofengs ship with the ability to transmit and receive on some other frequencies, like the FRS/GMRS frequencies, which can be useful. I've set the presets on my radio to match the FRS/GMRS channels so that I can use it to communicate with people who have FRS/GMRS radios in a pinch. Technically this violates the FCC rules for FRS/GMRS, because these radios are not certified for operation those frequencies, but in an emergency situation it could come in handy. My only complaint about the UV-5R is that it doesn't charge off 5V and requires a special power brick. The UV-3R does charge off 5V, so you can use any common USB charger, but it also has less transmit power and lacks the number-pad so it's a pain to program without a computer.

If they strip the SSL you would be able to see that in the browser. If they provide their own cert, the browser should still warn you because it's not signed by a trusted root. If they used heartbleed to steal the target's cert or they have a "valid" signature from a trusted root (or can fake it) then I guess you're boned. But that requires a lot more sophistication, making it less likely, and there's nothing you can do about this scenario anyways. Now back to the question at hand. I just tested Tails in a VM and you can chain proxies, but not easily with the tools that come pre-packaged. What you need to do is install proxychains (apt-get update; apt-get install proxychains), then edit /etc/proxychains.conf to add your open proxy after the default line for Tor, then start your browser using proxychains and disable the proxy settings inside the browser itself (you want proxychains to handle the proxy connections, the browser's proxy settings will just confuse things). Tor itself works by creating a socks4 proxy that listens on localhost:9050, so you have to nest the socks connection to your open proxy inside the socks connection to your local Tor proxy, otherwise you're just bypassing Tor and directly-connecting to the second proxy. Proxychains will automate the nesting for you, and you can chain as many proxies together as you like.

Going through Tor does allow you to hide your originating IP address from the open proxy. Tor sees that you're making an encrypted connection to an open proxy, the open proxy sees that someone on the Tor network is visiting the target website. If the target website uses SSL/TLS then the open proxy knows neither your original IP address nor the contents of your communication. Tor knows your original IP, but not who you were talking to or what you were saying.

The board labeled Questions was probably the correct place to put this... https://forums.hak5.org/index.php?/forum/11-questions/ It's possible to nest/chain proxies. I've done it in Linux, so I'm sure Tails could do it. However I've never used Tails before so I can't give Tails-specific instructions. I'm downloading it now.

1. You should keep your source files in a VCS repository. I recommend Git. 2. We've only been saying it since the 1980's, BACKUP YOUR FILES. CrashPlan (as pimp'd by Darren) works quite well. TestDisk is great, but you shouldn't rely on it. It can fail. Even when it works, you lose the paths/filenames since it can't recover inodes.

That doesn't sound all that different from a captive portal.

hackerspaces.org, there's probably one not too far from you.

USB-Ethernet adapters are not rare. You can find dozens of them on Amazon or NewEgg.

The hackRF is pretty nifty and all, but I don't really see myself taking advantage of one in the near future. If I was spending it on ham gear, I'd probably get a Sena SR10 so that I could use a bluetooth headset with my radios. Speaking of bluetooth, the Ubertooth One is a pretty good buy as well. There are lots of things using bluetooth these days, and not a whole lot of people playing in that space. I kind of like toys. I might buy some Cubelets if I had money to blow. You could get a Pebble watch. I own one, and it's pretty fantastic. The ISOstick is a surprisingly useful tool to keep in your kit. $250 is nearly enough to get you a tiny 3D printer. Or for that price you could probably build your own.

That repo was the current sources from dedected.org as of 2 years ago. I created that fork to make some requested changes for someone on this forum. If you don't want my changes, just roll back the last three commits. I don't think dedected was being updated anymore, so that's probably still the most up-to-date copy of the source code.

AWUS036H has a Realtek chip that supports b/g using the rtl8187 driver in Linux. AWUS036NH has a Ralink chip that supports b/g/n using the rt2800usb driver in Linux. AWUS036NHA has an Atheros chip that supports b/g/n using the ath9k_htc driver in Linux. I've tested each of these for Project Byzantium. All three are fully supported in Linux including IBSS. Personally, I prefer the Atheros drivers so I'd go with the AWUS036NHA as Sebkinne suggested. It's a bit more expensive, but I also really like the Ubiquiti SR71-USB, which supports b/g using the carl9170 driver (Atheros). High power and two antennas.