Sitwon

W3Schools is known for having misleading, confusing, ill-advised, or just plain incorrect information. They might occasionally have a bit of useful information here and there, but the same could be said of monkeys and typewriters. At the end of the day, the point is why continue to propagate a resource that is known to be dangerously flawed when there are plenty of clear and accurate alternatives which provide more and better information? This is why that page is called an intervention, you need to break yourself of the habit. Every time you recommend W3Schools (or allow someone else to use it as a resource without informing them of these issues) you are doing EVERYONE a disservice. Every wonder why there are so many horrible, broken, ugly, and insecure web pages all over the Internet? It's due, in part, to resources like W3Schools which teach people bad habits and insecure patterns. You're right, there is more than one way to skin a cat. And the W3fools.org page lists at least a half-dozen better ways to do it. So why defend and promote the method that is known to be less effective and more dangerous? Defending W3Schools, in this case, is like defending bloodletting on the grounds that it was occasionally useful to the leading physicians over a century ago.

Did you actually read the page I linked? Nearly all the resources I link there are completely free. The only exceptions are: 1. Some C++ books (which are more than worth the price) 2. A couple of chapters of the TECS book are not published online, but you can still get a LOT of value from the other 12 chapters that are published. 3. The Just Java book is not free, but you haven't expressed an interest in learning Java so far. 4. The K&R C book isn't free, but Programming in C which is linked right beneath it is. The Python book that I linked is free, in numerous formats. The same is true of nearly all the other resources linked to in the guide. Not only are those resources free, but they've been vetted by several experience programmers for quality and accuracy of information.

I would actually recommend C, not C++. Everything you need to know about the low-level inner workings (pointers, memory addresses, etc.) are taught in C. C is a very simple, yet very powerful language. And most of the example exploit code I've seen attached to vulnerability disclosures are written in C. (Also, Python is written in and based upon C, not C++. Python was created to be an easier way to write small C apps.) C++ is whole different beast. It takes the power and simplicity of C, and then tries to "enhance" it by bolting on a bunch of power tools that don't necessarily fit or play nice together. C++ is an extremely complicated and convoluted language in comparison to C. Sure, it gives you some higher-level abstractions and a metric tonne of new syntax to use those abstractions, but it also introduces a lot of unintuitive behaviors and endless corner cases. Where C is a hammer, C++ is a nail-gun. It might be marginally faster for big jobs, but it also has a lot more moving parts, it can jam or break, and it's far more likely to shoot you in the foot. If you chose to learn C++ at all, I strongly recommend that you start with C first. Learn the hard stuff (mostly pointers and how to manage memory) in C, away from the distractions of C++'s extra "features" and syntax. Or you could start with Python by Learning Python the Hard Way (hint: the "hard way" is actually easier). As I might have mentioned before, I helped write this guide that talks about one approach to learning programming and computer science, and links to lots of good resources for various languages.

Cool story, bro.

I use one similar to this. http://www.thinkgeek.com/computing/keyboards-mice/e0e7/?srp=1 Mine is a different brand, and slightly different design, but the same concept. It works pretty well as a HTPC remote. Not so good if you're trying to play games from your couch.

It's not the math that makes it complicated. http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

That depends on what language(s) you already know.

If you're trying to encrypt a remote shell connection, I would look into something like dropbear if you think you could compile and fit it on the system. I'm not too familiar with the OS you're using, but security is persistent concern in computing and cryptography is such a common tool that I would be very surprised if there was not some existing libraries or utilities available for that OS. Let someone else do the heavy lifting of implementing cryptography securely and optimizing it for the platform. It's actually harder than it sounds to get it right, which is why you should rely on well-vetted code written by experts. As long as that critical piece is solid, you should can focus on your application rather than worrying about the security of the protocol/transport.

I would recommend the ThinkPads over the MBA. They have user-replaceable batteries (and support multiple batteries). Pretty much every part is available as an FRU so you can repair it yourself, even long after the model is out of production. I love the TrackPoint, it lets you move the mouse or scroll on a page without lifting your hands off the home row. They keyboards feel more comfortable to me than the Apple keyboards (personal preference).

See also: http://w3fools.com/ And delete your bookmarks to w3schools.

CouchIt has been down recently so I've mirrored this to Github. http://sitwon.github.com/learnproglang/Home.html

How "embedded" are we talking. And are you sure that you *need* to code it yourself, or do you want to code it yourself? If it's an embedded Linux system, you might be able to fit a stripped down build of GPG and use it to symmetrically encrypt files. (See '--symmetric' or '-c' in the man pages.) Or you could use openssl to do it. Implementing your own crypto from source is generally considered to be a bad idea.

Well the traditional solution is to us a SQL database such as MySQL, Postgres, or SQLite. The hip new thing is using is to use a NoSQL database such as CouchDB or MongoDB. If you're just going to be running it locally you might even use something simpler like Berkeley DB. Regardless of what you pick, you're free to use any programming language you're already familiar with. All these major database implementations have a very wide and inclusive set of programming language bindings to their APIs allowing you to use any programming language you're already comfortable in to manipulate the database.

You can download free PDF versions of most of the chapters online. The book itself is about $20, so probably the cheapest textbook you'll ever buy. Other resources (mostly free) are listed on that second link I posted. For years, MIT students uses the "Structure and Interpretation of Computer Programs" to essentially learn many of the same lessons as TECS (although from a slightly different perspective). TECS can be thought of as computer science from the perspective of Turing Machines (Alan Turing), where as SICP is computer science from the perspective of Lambda Calculus (Alonzo Church). SICP is a pretty rigorous and math-heavy course.

That's not the "original" assembly code. That's just the nearest estimation the disassembler could managed based on the machine language. In any case, assembly is little more than a human-readable notation for machine language. Since the AV scanner is not a human it doesn't care about human readability. It can analyze the actual binary machine language just as efficiently (if not more efficiently) than the assembly representation of the same code. So doing it at the machine language level skips the unnecessary disassembly step. One heuristic that many AV scanners use is to look for nop sleds or other common patterns of bytes that are more likely to occur in viruses than in legitimate applications. However most of the time they are just looking for sequences of bytes that are unique or identifying of particular viruses or shellcode. In your C source code all those /x numbers get converted into raw bytes in the file and it's those sequences of raw bytes that it's searching for. If it's a shellcode that it's seen before (or substantially similar to one that it's seen before) it will flag it as a possible match. Actually, it's tough but generally believed to be possible. The AV vendors all tend to have similar batches of signatures and similar heuristics so if you have something that won't be flagged by a signature check and slides by most of the heuristic techniques then you might be able to evade everyone's detection (at least until someone finds a sample of it and write a new signature for it). UPX and Metasploit are known tools that are highly associated with malware packing. The could potentially be used for legitimate software, but because of the relatively high rate of malware that uses them they are a strong indicator of potential malware. Basically, with UPX you are assumed malicious unless specifically whitelisted. Also, UPX compresses and thereby encrypts your binary, but it's relatively trivial to unpack as well (UPX doesn't try hard to make that difficult, it's optimizing for size and speed). There are other packers out there that will make it harder for the AV to unpack and analyze your code. There are also other techniques for breaking up how your shellcode is stored in the binary so that it won't match existing signatures (and then you would reassemble it at run-time). There are lots of sneaky tricks you can do. Some of those trick the AV vendors are wise to and have heuristics that will catch them. I'm not going into detail for two reasons. 1. I don't actually have first-hand experience trying to evade AV heuristics. It's just not something that I've ever needed to do. 2. I'm not so sure I really want to discuss these kinds of techniques on a public forum. I'm just not sure if it's ethically sound to lower the bar for creating better malware. It's one of those things that anyone can learn to do, but if you're going to play in that arena you should probably earn your place by learning and understanding all the background and theory. (In general, you're playing with fire so you had better have an intimate understanding of exactly what you're doing. I'm not gonna give you short-cuts to shooting yourself in the face.) I think you need a refresher on the fundamentals of computer science and how code works at the machine level. "The Elements of Computing Systems" is a great book/course for introducing these topics. http://www1.idc.ac.il/tecs/ http://sitwon.github.com/learnproglang/Home.html http://wiki.hacdc.org/index.php/TECS Additionally I would also recommend reading "Art of Assembly". http://nostarch.com/assembly2.htm

Ok, so obviously the AV scanner doesn't have the original C code or assembly code to look at. All it can see is the binary result in front of it. AV scanners actually use a combination of techniques to determine if a file is a threat. One technique is to search the actual binary for specific patterns (signatures) that indicate known viruses or shell-code. In the process of searching for these signatures, if it finds that the binary is compresses or packed by a known packer it will try to decompress or unpack the binary (or binaries) and scan the decompressed files (and will recurse in this way to a vendor-specific depth). Certain packers are rather closely associated with viruses and malware so seeing evidence of such a packer might be enough, in some cases, to flag the file as a potential threat. In addition to de-compressing binaries, the AV scanner will try to decode (to some extent) binaries that appear to be encrypted. Compression is really just a special case of encryption. Beyond just looking for signatures of known viruses, scanners will also look for specific behaviors which may be associated with viruses or malware (such as code to escalate privileges, hide processes, pack other binaries, etc.). In some cases this may involve some mild disassembly, but mostly they search for matching patterns at the machine-code level. On top of these, the major AV vendors like to add their own secret sauce techniques to try and catch threats both known and unknown. For essentially the same reason as the halting problem, no AV scanner will ever be able to catch all viruses. Alan Turing and Alonzo Church proved this in 1936.

Diet coke tastes like disgusting "diet" sweeteners. Lite beer generally tastes like watery beer. You can make a lite soda by filling a glass with ice, pouring in soda, waiting for all the ice to melt. You can't make a "diet" beer with artificial sweeteners because yeast requires real sugar.

I would suggest using a version control system to organize your archive of files. Git is notoriously bad with large binary files, but Subversion handles them pretty well. Setup a Subversion repository (either on your local machine or on whatever you use as a file server) and check-in files one at a time with a descriptive commit message. When you add a new version of QuickTime you don't have to rename the binary, go ahead and replace the old one and check it in putting the date and version information in the commit message. This way you know that all the copies in the folder are only the latest revision of the file and you can roll back to any previous version of the file and use the commit messages to figure out which version you want.

I would recommend you start here: http://sitwon.github.com/learnproglang/Home.html

I don't believe so, but what it does isn't very complicated. You could probably rewrite it yourself. It's just ngrep-ing for an HTTP request and then injecting a forged packet with a HTTP reply.

Google for how to make backup copies of your N64 or Nintendo cartridges. There are usually tools you can build/buy to help backup the data on the cartridge and make your own ROMs.

http://docs.oracle.com/javase/1.4.2/docs/guide/misc/applet.html

You want the captive portal page to run it as an applet. Keep in mind that applets sometimes have additional security restrictions so you'll probably want to test it in a browser to make sure it behaves the way you think it will when loaded over the captive portal.

Go check out the work done by Georgia Weidman in the area of smartphone security. Basically, there isn't any.

It doesn't really matter which one you pick. Linux is Linux is Linux. Aside from a few minor differences (which will become increasingly superficial the more you learn about them) all the distros are effectively the same. Although I don't particularly recommend it, it's quite common for beginners to spend a lot of time distro-hopping and using LiveCDs at the beginning. You will learn some lessons from trying out different distributions and seeing how they do things differently, but I think you'll learn more if you just pick one and stick to it. What's most important is to not let yourself get too comfortable. Always keep challenging yourself. Do things the "hard way" to force yourself to learn about what is actually going on under the hood. If you're going to follow along with the segments in Hak5, Darren and crew are typically using either Ubuntu or BackTrack (which is forked from Ubuntu). Picking one of those might make it a little easier to follow along with the show.