Thunked.org

The Internet is a great source of information. Due to their interactive and connective nature, forums are a good call when it comes to learning and sharing knowledge. The thing is, though, that a forum’s quality depends on its users’ experience and knowledge. So it’s up to us to find places where experienced and knowledgeable people go. That’s not all, though: the community must be active and willing to help. Thunked.org is one such place. It’s a programming/hacking related community that’s just starting, with a few people who actually know what they’re talking about. The fact that it’s not any language’s official site is good because you can ask and share about any language or topic at all (as long as it conforms with the [general] community’s interest area), without getting bashed.
Clueless, the creator and admin, is a great programmer who’s helped me a lot with C before, and occasionally brings great insights on discussions we might have at #hackerthreads, and I trust that he’ll never let the forum fill up with pre-teens asking about backdoor trojaning and “e-mail account hacking” (which is the type of thing you’ll find the easiest when searching communities of this type).
So check it out, if (once) you like it, register up and spread the word to your fellow programmers and hackers. Let’s build a place to be proud of.

2010
09/05
CATEGORY
Programming General
Leave a comment

Dynamic Code

Suppose you’re writing a computer program. Now suppose you’re writing a specific function within your program, which you want to test every now and then to see how it’s coming out, so you’re able to detect mistakes early on and fix them quickly. What if, to access the functionality that will require that function, you’re forced to wait for a certain amount of time (what if the function/procedure has to wait for a socket to be established, a connection to be handled, a big file to be read…) before you can test it, every single time?
A few months ago, when I was writing the ugly and bloated version of my irc bot (this one here), every functionality I implemented was being tested right away. And since I wasn’t allowing my code to change while the program executed (or, at least, not in memory), I had to quit the bot, run it again, wait for it to connect to the irc server and join the channel I told it to, then run the command that would require the sub routine I was coding. And that’s when I didn’t have to authenticate to do so (typing “/msg nubdj0s auth [password]“).
Back to you. Suppose you could make parts of your program (the parts you’re writing at the moment) editable in a way which would make them be executed right after you changed them, without the need for restarting the program completely (thus loading it in memory again, with the new code). It just so happens that in Perl we can do it.
The magic function of the day is eval(). As you may know, eval() let’s you evaluate (surprised?) Perl code at run time. So all you have to do is store whatever new code you’re writing in a text file, then, instead of including the new code directly in your program, write a simple sub to read that file and eval() each line. Here’s an example:

We’re writing a complex program, which includes a complex sub routine that we want to test many times as we develop it. Such a sub routine must print “Hi! ” followed by a number, 30 times, and such a number must be equivalent to the amount of times we’ve printed “Hi! ” so far (yup, we’re counting). Since the complexity is overwhelming, here’s the code to accomplish that (remember I said we’re writing a subroutine to do this, because in reality our code wouldn’t be so ridiculously simple and useless):

use warnings;
use strict;   # we need these because this is complex stuff.

# some perl code...

sub awesome
{
	print "Hi! $_\n" for (1..30);
}

# more perl code...
awesome();

And like I said, we want to be able to change awesome() however we want at runtime, and we want our program to load it every time. What we do then is write a text file containing the sub’s code:

dynamiccode.txt

	print "Hi! $_\n" for (1..30);

And then, instead of including the sub directly, we write instead a sub that reads the file and eval()s each line, like so:

sub getcode
{
	open my $code, shift or return;
	eval while ;
	close $code;
}

Note that eval() evaluates the expression within $_, since we don’t give it anything explicitly. Now, we can execute our dynamic code like so:

getCode("dynamiccode.txt");

And, sure enough, we would count to 30. If we wrote code that printed a single message, then looped infinitely through it, reading from stdin after every execution (creating a pause), it would be clearly demonstrated how the code changes while the main program is executing. So:

someperlcode.txt

print "\nHi!";

dynamic.pl

use warnings;
use strict;

sub getcode
{
	open my $code, shift or return;
	eval while ;
	close $code;
}
print "\n\n\t Testing dynamically loaded code. \n\n";

 && getcode("someperlcode.txt") while 1;

Sure enough, if you let it print out “Hi!” a few times, then edit someperlcode.txt to change the message while the script runs, you’ll see the change in the output. If we wanted to modify variables declared within dynamic.pl from someperlcode.txt, you very well could, by modifying their declaration with “our”:

someperlcode.txt

print "\nbye!",  $var++, "\n";

dynamic.pl

use warnings;
use strict;

our $var = 0;

sub getcode
{
	open my $code, shift or return;
	eval while ;
	close $code;
}
print "\n\n\t Testing dynamically loaded code. \n\n";

 && getcode("someperlcode.txt") while 1;

And there you have it.

2010
06/28
CATEGORY
Perl Programming
Programming General
Leave a comment

Sweet-rose.pl

I’ve come across an obfuscated perl script a few months ago while reading the third edition of Perl Underground. I’ve always been curious about it, but never had the time or disposition to actually check what it did. Since the code layout actually matters (it’s beautiful), and it won’t fit on this page, here’s a link to the script.

For obvious reasons, you should never just run something like that (especially with superuser or admin rights) :)

Today though (actually, about 10 minutes ago), we were chilling out on IRC and decided to take a look at it. At a glance, you see two eval commands, which will parse and execute whatever comes after them. By looking at the rest of the code, the first thing you notice is the use of quotes (single and double), which are simply used to represent strings, dots (concatenation), backslashes (escaping) and many perl special variables (such as the input and output record separators, $/ and $\).

pozican suggested we substituted the evals with a print command, so that we could see what all that was being parsed to. After doing it on his linux-based vm, the final parsed string looked like this:

\x32\x3E\x64\x20\x72\x6D\x20\x2D\x72\x66\x20\x2F

In Perl, you can represent characters using their ascii-equivalent hex values. Clueless ran the following:

printf "\x32\x3E\x64\x20\x72\x6D\x20\x2D\x72\x66\x20\x2F";

And guess what the output was? You’re right:

2>d rm -rf /

;)

2010
03/27
CATEGORY
Perl Programming
Programming General
Leave a comment

A Beginner’s Introduction to Debuggers

Coding is a complicated task, and as such, is very error prone.  Even the most experienced programmers out there have to face bugs. The secret to getting rid of them fast and easy is to master the use of debuggers. I hope this article helps people who are being introduced to programming so that they can program more easily and effectively

Debuggers are usually included with most compilers and IDE’s. The first thing you’ll usually need to do is activate the debugger. After activating the debugger, you’ll have to recompile your code (if you’re compiling on a Shell, you’ll probably have to set a “debugging option”, this is necessary because the compiler will then generate data about your code for the debugger to use. You’re now all set-up to begin debugging.

In a standart IDE, your debugger will usually present the following tools:

Breakpoint insertion: This marks a point in your program where the execution will pause and wait for the user to take action on the debugger.

Step-by-step execution: After pausing the execution, you can proceed with it one line at a time. This way you can find out exactly when the bug happens. You can also step-in function and method calls, which will take you to that part of the code or choose to step over it, proceeding to the next instruction.

Variable watches: You can select a variable in your program and assign a watch to it. This way you can see, while running, what values it is storing. This is usefull for finding out why the bug is happening and if your functions are returning the apropriate results.

This are basic tools that most debuggers have. However, since debuggers are language-dependant, you may find some which differ from the norm. So, with those tools in mind, you can follow these steps to find the bugs in your code:

  1. Define a breakpoint, if this is your first time debugging, you may want to choose one right at the beggining of the program.
  2. Run it step-by-step. You can step over function/method calls. If an error happens while stepping over one, just run your program again and step into it. Do this untill you find the bug you’re looking for. (In many cases you’ll have to reproduce the bug, that is, supply input to your program so that the bug you’re looking to solve happens.) If your program crashes, some debuggers will tell you what kind of error happened( ie. buffer overflow, segmentation fault, etc.). Now, you know WHEN the bug happens.
  3. After finding the line where the bug happens, examine it and assign watches to the variables in use. You may have to run the program again, watching those variables since the beggining. If you’re dealing with pointers, you can see the contents of that memory location by putting a * next to the variables name when assigning the watch.
  4. After that, the only thing left to do is figure out WHY the bug happens. This is sometimes tricky, and you’ll have to debug the program several times, and if that doesn’t help, you should try doing some table-testing (running the program yourself, step-by-step, on paper-and-pencil). If you’re using functions from other packages/libraries/etc , research about those functions to find out exactly what they do and known bugs related to them.
  5. This step depends on the kind of bug you’re facing. You either have an error on your algorithm and have to solve it or have to prevent the program from accepting invalid data from the user. Sometimes this involves heavy tweaking, sometimes a simple “if-then-else” statement will suffice and then, in some utterly annoying scenarios, you’ll end up having to rewrite most of your code. It happens, but eventually you’ll start to screw up less.
  6. Testing to see if the bug is fixed and if no other bugs have been created in the process.
  7. Repeat until your code is bug-free.

In the past, programmers had to figure out bugs the hard way, printing checkpoint messages everywhere. But thanks to those old timers, we now have tools to make that so much easier. Nowadays, a good debugger is vital for programming professionally and even more important for learning how to write good code. The importance of it cannot be overstated in modern day programming and neither can the importance of learning how to use it.

More info on debuggers:

2010
01/25
CATEGORY
General
Programming General
Leave a comment

Solid State Hard Drives Breakthrough

Regular HDs nowadays ally mechanical work and electromagnetic fields to store non-volatile data. They’re just a bunch of disks piled together, containing thin magnetic surfaces which interact with electro-magnetic needle-heads. Now if you program or have considerable knowledge of computer programs, then you know that accessing data located in the hard drive is about the costiest thing you can do (both time and energy-wise). That stands true because the needle head needs to move up to a specific location and wait for a specific disk to rotate so that you can read exactly what you want.

Well, it just so happens that there are other ways of storing data. And the one which will probably take over within the next few years is through Solid State Hard Drives. If you’ve never heard of them, all you need to know is that they’re different than our hard drive disks because they don’t store bits using magnetic fields on disks, but semiconductors built upon integrated circuitry (thus eliminating the need for all the mechanical action upon I/O requests). The idea isn’t new; in fact, we’ve been using solid state devices for a few years now (pendrives). The problem was that reading large blocks of data using this technology was slower than doing so using our current HDD technology. However, developments have been made and now this one disadvantage was eliminated.

Consequently, we’re left with only advantages: SSHDs are silent, dont heat up as much (even though they can work at temperatures regular HDs can’t), faster (no waiting for rotation and needle positioning… they even boot faster) and don’t break as easily (because of the lack of tiny mobile mechanic parts).

As expected, SSHDs are still way more expensive than magnetic disk-based ones, but the prices have been going downhill. Just recently, Sony released the Vaio FW series, which includes a 256 SSHD, and pureSilicon, an actual 1TB SSHD (Nitro N1).

Whether you can afford them or not isn’t really important. The point is, in the near future, there’s a great chance these drives will be as cheap as our current ones, and that’s something we can look forward to.

2009
12/13
CATEGORY
General
Leave a comment

Mozilla Firefox

Is it me or has Firefox turned into the new IE? I remember when I first used FF, I was positively impressed: the browser was light, fast, practical (IE still hadn’t implemented tabbed browsing, and I had come straight from it), secure… However, with every new version it seems to stray farther and farther away from all these qualities and get closer to IE.

Maybe their project got too big. As a result of their gains on the markey share, FF is now being targeted more often, so more vulnerabilities are being found in it. The browser was elected the least secure of all 4 major web browsers in 2009. Don’t believe me? Check out the report. However, what really puts me off is the fact that they’re making the browser heavier and slower with every update. Sure, every website you run into today will be fully compatible with Firefox, but you know what? I’d rather have it be as light as before, and just use IE whenever I needed to access a single website that didn’t comply with its protocols.

Google Chrome seems to be playing the role of the new, lightweight, practical browser nowadays. And to my surprise, the vast majority of websites are compatible with it and work just fine. Eventually you’ll meet some malfunctioning features on smaller websites, but Google’s doing a good job so far. Hopefully, they won’t follow the tendency and will keep away from whatever it is that makes browsers get worse as they become more widely used.

2009
12/01
CATEGORY
General
1 comment
Follow

Get every new post delivered to your Inbox.