All Windows software since '95-based applications run on every flavor of Microsoft Windows.
I'm totally and utterly fascinated, yes fascinated, that this self-prescribed computer genius doesn't realize that you can make one right click of the mouse and tell Windows XP to run in compatibility mode for applications that were optimized for the Windows 95/98 kernel.
This is kind of like some Chevrolet auto mechanic writing into a Chevy fan club Web site to ask how to ween his teenagers away from sporty, sleek, and reliable Hondas, Toyotas, and Mitsubishis and toward Chevrolets (and Fords, and Dodges) because American cars mostly have only manual door locks and windows, which is obviously the only way to go. Why press button A and button B to roll down your window and lock the door when it's much more stable and interesting to spend 15 seconds rolling the window down yourself and 3 seconds reacher over with your right arm to press the door lock down.
What everyone really wants to know:
on
Ask William Shatner
·
· Score: -1, Offtopic
Dell has released its Axim X5 handheld as as promised . At $299 after rebate, a reasonable buy, price-wise.
Listen, just because the entire world of 6 billion people is motivated by money, it doesn't mean that the few thousand of us here at Slashdot have to be as well. Why was such capitalistic nonsense included in the story writeup? Most of us here don't really care about money; I personally work only out of curiosity of science as a whole and don't even care about the money. In fact, I give half (25,000 Canadian) of my yearly salary away to various charities.
When we're all dead, people will remember us for the kind deeds we did while we were walking the streets and talking the talk. The little league team you coached, volunteering at a Mormon church, and all those bake sales for the PTA will be what you were best known for. Contract #189533 for $1,730.39 will not be relevant and no one will care how much money you made.
The only shitty part is you'll just be tossed into the Hudson River because you and your socialist family members don't have the money for a proper funeral and burial.
This comment is sad and mean, but one of the few truths in this world is that truth hurts.
With all due respect, I can't quite understand how you could discredit the entire CERT working group of computer scientists at Carnegie Mellon University.
People like them and myself learn and do more in one day than you do in an entire year.
I don't mean to offend, but if you're trying to play the "just look at the facts" card, at least be truthful about it.
I stopped watching cartoons when I was 10 years old.
I live in my own house that I pay for myself and drive my own car.
I buy and make my meals.
I mean, have I simply lost touch with all of you that much over the past few years? Or are all of these Harry Potter, anime, cartoon, and Nintendo articles as childish as I think they are?
Don't get me wrong -- I love Slashdot and have no grudges against any editors. But really, who the hell cares about this kiddie crap?
Let's see, so if a byte is 8 bits, and picoGUI is supposed to take 1/1000 of a byte, then the code for the entire graphical user interface subsystem has been compressed into 0.008 bits.
The entire source probably looks something like the following:.
I didn't realize DNA computing had arrived so quickly. God bless those researchers!
So I wonder: what would it take (apart porting tons of applications) to make it a suitable alternative to X+[your toolkit of choice]+[your window manager of choice]?"
Most of my physics software packages simply do not run on any machine without a Microsoft Windows operating system.
All of the lab machines here run Windows 2000, as it was the first stable and well-rounded operating system to ever come out of Redmond, Washington (Microsoft headquarters).
It's all about the applications, and not just conusmer ones either. I'm talking about the apps used by researchers in the area of physics, mechanics, thermodynamics, etc.
I know everyone here probably knows what an eclipse is, and you all probably appreciate the grandeur exhibited by shadows created with celestial entities.
But I myself wasn't quite sure why Ceduna in southern Australia was a good place to view it. However, after some research, I found the following information:
To witness all that this total solar eclipse has to offer, viewing must be within the narrow path of the moon's umbral shadow, which passes directly over Ceduna.
Although the sun will be partly eclipsed throughout South Australia, and 88% eclipsed from Adelaide, the spectacular effects of this eclipse will not be visible outside the shadow's path due to the intensity of remaining light from the sun.
Even 99% eclipsed gives you much less than 99% of the 'total eclipse experience'!
The bottom line: if you are in your parents' basement at the time, you will miss the total eclipse.
It's impossible to get a speedup of more than 10 with any processor-related activities.
Using Amdahl's Law, one can find that Speedup = (s + p ) / (s + p / N ) where N is the number of processors, s is the amount of time spent (by a serial processor) on serial parts of a program and p is the amount of time spent (by a serial processor) on parts of the program that can be done in parallel.
So, while we see a speedup of about 3 based on these latest tests of Linux kernel 2.5, don't expect it to get much faster despite the millions of eyes looking over the code.
The not-so-great thing about Security Focus is that their Web servers can't handle 10,000 hits in 10 minutes.
So, here's the text of the article just in case:
Reverse Engineering Hostile Code by Jon Stewart last updated October 23, 2002
Computer criminals are always ready and waiting to compromise a weakness in a system. When they do, they usually leave programs on the system to maintain their control. We refer to these programs as "Trojans" after the story of the ancient Greek Trojan horse. Often these programs are custom compiled and not widely distributed. Because of this, anti-virus software will not often detect their presence. It also means information about what any particular custom Trojan does is also not generally available, so a custom analysis of the code is necessary to determine the extent of the threat and to pinpoint the origin of the attack if possible.
This article outlines the process of reverse engineering hostile code. By "hostile code", we mean any process running on a system that is not authorized by the system administrator, such as Trojans, viruses, or spyware. This article is not intended to be an in-depth tutorial, but rather a description of the tools and steps involved. Armed with this knowledge, even someone who is not an expert at assembly language programming should be able to look at the internals of a hostile program and determine what it is doing, at least on a surface level.
Tools Required
As with most types of engineering, you'll need some tools. We'll cover tools native to both Unix and Windows. While Unix is the ideal platform to perform the initial reverse engineering process, you can still make do on Windows, especially if you install tools such as Cygwin, a Unix environment that runs on Win32 platforms. Most of these commands are also available for Windows when running Cygwin. However, when you get to the decompile/disassemble/debug steps ahead, going the Windows route will cost a lot of money, whereas the Unix solutions are all free. Be sure to weigh the costs of working on Windows versus the benefits before making it your reverse-engineering platform of choice.
Some useful commands are:
dd - byte-for-byte copying of raw devices. Useful to perform analysis on a compromised system's hard drive without affecting the integrity of evidence of the intrusion. file - tries to identify the type of a file based on content strings - outputs the readable strings from an executable program. hexedit - allows you to read and edit binary files md5sum - creates a unique checksum for a file for comparison diff - outputs differences between files lsof - shows all open files and sockets by process tcpdump - network packet sniffer grep - search for strings within a file Compressed Executables
Trojans are often compressed with an executable packer. This not only makes the code more compact, it also prevents much of the internal string data from being viewed by the strings or hexedit commands. The most commonly used executable packer is UPX, which can compress Linux or Windows binaries. There are several other packers available, but they are typically Windows-only. Fortunately, UPX is one of the few that also provide a manual decompression to restore the original file. This prevents us from having to use advanced techniques to decompress the file into its original format.
In an ordinary executable, running the "strings" command or examining the Trojan with hexedit should show many readable and complete strings in the file. If you only see random binary characters or mostly truncated and scattered pieces of text, the executable has likely been packed. Using grep or hexedit, you should be able to find the string "UPX" somewhere in the file if it was packed by UPX. Otherwise you may be dealing with one of the many other executable packers. Dealing with these other formats is beyond the scope of this article, but you can find resources to help work with these files.
Decompiling
Occasionally you will get lucky and find that the Trojan was written in an interpreted or semi-interpreted language such as Visual Basic, Java or even compiled Perl. There are tools available to decompile these languages to varying degrees.
Visual Basic - There is a decompiler floating around the Net for VB version 3. For newer versions, there are no decompilers known, but you can use a tool such as Compuware's SmartCheck to trace calls in the program. While its output is not a source code listing, you can see just about everything the program is doing internally. Java - There is the excellent decompiler jad, which decompiles to a complete source code listing which can be recompiled again. Several other java decompilers are also known to exist. Perl - Perl programs compiled into Windows executables can be reduced to their bare script using exe2perl. Disassembly
If the Trojan was written in a true compiled language, you'll have to bite the bullet and disassemble the code into assembly language. For Unix executables, objdump is the way to go. For Windows executables, you'll want IDA Pro or W32dasm There is a free version of IDA that is just as powerful as IDA Pro but has a console-based interface. These programs will disassemble your code, then match up strings in the data segment to where they are used in the program, as well as show you separation between subroutines. They will attempt to show you Windows API calls by name instead of by offset. This kind of output is known as a deadlisting, and can give you a good idea of what the program is doing internally. The GNU objdump program does not provide such useful features, but there is a perl-based wrapper for objdump called dasm, which will give you much of the same functionality as the Windows disassemblers.
Debuggers
While a deadlisting can be quite valuable, you will still want to use a debugger to step through the program code, especially if the Trojan is communicating via network sockets. This gives you access to the memory and temporary variables stored in the program, as well as all data it is sending and receiving from socket communications. On Unix, gdb is the debugger of choice. It has a long history on Unix, is well documented, and best of all, is available free of charge. Under Windows, the choices are far more varied, but most tutorials on reverse engineering under Win32 assume you are using SoftICE. It does cost a fair amount of money, but is worth getting if you can afford it.
Preparing to Debug
You must take precautions when running hostile code, even under a debugger. You should never debug a Trojan on a production network. Ideally, you should set up a lab network, as shown in figure 1.
Figure 1: A typical debugging network
The debug system should have a clean install of whatever OS the Trojan is intended for, with a second box acting as a firewall. A third system on the network allows you to emulate services and capture the network traffic generated by the Trojan. Capturing this traffic can be invaluable in tracing the source of the infection. Ensure that you firewall all outbound connections, allowing only the Trojan's control connection through. If you don't want the master controller to know your lab network is running the Trojan, you can set up services to mimic the resources the Trojan needs, such as an IRC or FTP/TFTP server.
Stepping Through the Code
Now that we have constructed a proper quarantined lab environment, we can begin debugging the code. Using the deadlisting, we look for key functions in the program, such as Winsock and file I/O calls. The debugger allows us to set breakpoints in the program based on offset values, so we can interrupt the flow of the program and examine the program memory and CPU registers at that point. The remainder of this article will look at an example of how such a debugging session might look on an x86 Linux platform.
Running the Debugger
We want to know how the Trojan communicates with its controller. Often, sniffing the network traffic will be sufficient. However, many newer Trojans are incorporating encryption into their network traffic, making network sniffing a lost cause. However, with some cleverness we can grab the messages from memory before they are encrypted. By setting a breakpoint on the "send" socket library call, we can interrupt the code just prior to the packet being sent. Then, by getting a stack trace, we can see where we are in the program. For example, the Trojan source code might look something like:/* encrypt output to master */ elen = encrypt(crypted,buf,len);/* write crypted output to socket */ send(s, crypted, elen, 0);
Examining the compiled Trojan in gdb might give us the following output [note that the bolded statement represent the author's comments on the output]:
[test@debugger test]$ gdb./Trojan GNU gdb 5.2.1-2mdk (Mandrake Linux) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-mandrake-linux-gnu"... (no debugging symbols found)... (gdb) set disassembly-flavor intel [Switch syntax output from AT&T] (gdb) b send [Set a breakpoint on the "send" library call] Breakpoint 1 at 0x400f5c10 (gdb) run Starting program:/home/test/Trojan
Breakpoint 1, 0x400f5c10 in send () [We hit a breakpoint] (gdb) where [Do a stack trace to see where we are at in the program] #0 0x400f5c10 in send () from/lib/i686/libc.so.6 #1 0x080487fa in socket () #2 0x40040082 in __libc_start_main () from/lib/i686/libc.so.6
The above output from the "where" command in gdb shows us the offset each subroutine will return to after execution. Since we know that the "send" call was right after our encrypt call, we need only to examine the previous subroutine, which encompasses the return offset 0x080487fa. We are interested in the assembly language code just prior to this offset. Using gdb, we can disassemble the code at this point.
We see that just prior to the call to "send", there was a call to 0x8048804 . In reality, this is our "encrypt" subroutine. When programs are stripped of their symbols, gdb is often confused about where subroutines begin and end, so it continues the name of the last one it recognizes for all following subroutines, often the previous dynamic library call. In this case, it is mislabeled as being part of the "socket" function.
To examine the contents of the unencrypted packet, we need only know how the "call" instruction works. The arguments to our subroutine were pushed onto the "stack", a place where temporary data and return offsets are stored. We can access the contents of the variables by setting a breakpoint on the call and then using an offset from an internal CPU register known as the stack pointer, ESP. ESP+4 will be a pointer to the first argument, ESP+8 will be a pointer to the second argument, ESP+12 will be a pointer to the third argument, and so forth. Just keep poking at the stack until something useful comes up. In this case, the useful information (the plaintext data) is in the second argument to "encrypt". Let's set a breakpoint at the encrypt call, and examine the stack [Again, the bolded statement represent the author's comments on the output.]
(gdb) b * 0x80487d2 [Set a breakpoint on the "encrypt" call] Breakpoint 2 at 0x80487d2 (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y
Starting program:/home/test/Trojan (no debugging symbols found)... Breakpoint 2, 0x080487d2 in socket () (gdb) x/x $esp+8 [Get the offset of the second argument ESP+8] 0xbffff5e4: 0x0806fe20 (gdb) x/fs 0x0806fe20 [Examine the contents of the memory at 0x0806fe20] 0x806fe20: "root pts/0 Oct 11 14:22\n"
From this output we can see that the Trojan is reporting back on who is currently logged on to the system. Of course, it could send any kind of data; network packet captures, keystroke logs, etc. Fortunately, we have our network set up so this traffic will be redirected to the sniffer host instead.
Conclusion
The Trojan above is not real. Had it been an actual Trojan, we might have followed additional courses of action. Often times a Trojan will use established channels such as IRC to reach its master. We can take advantage of this fact, and use it to track down the source of the attack, even gaining control of the entire network of Trojaned hosts if the Trojan writer has been careless. If the Trojan uses FTP to update itself, you might find additional code on the FTP server and possibly clues to the identity of the Trojan writer.
Although we've only scratched the surface of reverse engineering, you should be able to take the basic information above and put it to work. Read the documentation for your debugger; you'll be surprised at how powerful it can be, and how much it can tell you; even if you're not the best at reading assembly code. If it seems overwhelming at first, don't give up hope. The payoff can be quite gratifying. During one reverse-engineering session the author of this article found the real name of the Trojan author unintentionally embedded in the program's source code (hint: don't write Trojans in VB when logged in to your NT workstation at work). With a quick trip to Google the author's email address and picture was available, posted to a VB discussion site. One "whois" later and his home address and phone number was found. Somewhere in Brazil, a Trojan writer slaps his forehead and says (in Portuguese), Doh!
I don't have use Win32 platforms or do virus work, but I use GNU/Linux and can't get a girlfriend, no matter what I do. From what I can tell, not too many of you have girlfriends either; I must make it clear right now that I do not want advice from you. I am seeking the advice of those who have consentual, regular, heterosexual intercourse with a well adjusted woman.
You may be wondering why I placed so many restrictions on the type of sexual intercourse. Being a GNU/Linux user, I can get all the men I want, but my ass hurts from years of anal sex. I am tired of pillow-biting. I have met women at Linux User Groups (LUGs) but they didnt want sex the way I wanted it - they brought their strap on and rode my chute like the men did. The date would end with her taking me to a gay bar and selling my ass to a drunk and bearded kernel hacker.
I am convinced, therefore, that I need to meet women that do not use GNU/Linux.
I have tried dating regular women, but find it hard to make conversation. I was surprised that regular women do not give a shit about Free Software or the Microsoft monopoly which leaves me with nothing to discuss. Some women tried to talk about the weather, but I don't keep up with the weather from my mums' basement.
I have had some success, I dated one girl several times. She picked me up from home, mum liked her. I am sure dad would have too, but he left us soon after I installed Slackware on the family computer. I can still hear him crying and see him moping around the house, saying "I knew he was different; I could handle a gay son, but this.... a fucking GNU/Linux hippy". He sounded so defeated. She wanted to go to the beach, but my skin is not adjusted to the sun and my skin peels while at the beach. This was not a turn on for her and when she came back to my mum's basement that night we were going to have sex but the raw skin was too much for her.
Going out at night for a meal can be difficult too; all restaurants refuse to serve smelly GNU/Linux hippies. The only place we can go for food is the McDonald's drive through, but she doesnt like waiting in her car in the heat of the day when I tend to smell the most. She doesn't like the stares she gets from the drive through staff.
I could go on, but I won't. I now seek your advice.
Listen, just because the entire world of 6 billion people is motivated by money, it doesn't mean that the few thousand of us here at Slashdot have to be as well.
When we're all dead, people will remember us for the kind deeds we did while we were walking the streets and talking the talk. The little league team you coached, volunteering at a Mormon church, and all those bake sales for the PTA will be what you were best known for. Contract #189533 for $1,730.39 will not be relevant and no one will care how much money you made.
The only shitty part is you'll just be tossed into the Hudson River because you and your socialist family members don't have the money for a proper funeral and burial.
This comment is sad and mean, but one of the few truths in this world is that truth hurts.
How do you separate "work" from being a "kind" person?
I often to favors for others. Most recently, a friend who attended grad school with me called panicking during the night and said that he couldn't feel his toes.
No one else was home at his house, so I had to walk him through the steps of logically evaluating the situation to determine the cause of the numbness in his lower appendages.
I didn't even think twice about whether or not to charge him. He was in great pain, so I billed his Visa card for $1,200.00 after diagnosing the problem -- he had left the window open and a cold front had arrived over the night. Without a blanket (it was late August), his toes had nearly froze.
True story. But after spending 14 years in grad school, I'm just not a nice guy anymore. I wouldn't think twice about charging people for services rendered. I even charge the people at Blockbuster Video when I return the video before it's due since I paid for the full time, and since they charge me for a late fee if it's not back on time. The best part is they usually compensate me for early returns!
Re:Planned or measured?
on
Landshark
·
· Score: 2, Informative
If I've learned anything at all through decades of education, it's that one should never underestimate the power of Type R decals and fart can exhaust pipe caps.
For $199.99 at any old Wal-mart store, you can get the following:
VIA C3 800 MHz processor offers comparable performance to the 800 MHz Celeron processor 133 MHz frontside bus 128 MB SDRAM, expandable to 1 GB 133 MHz memory speed 10 GB Ultra-ATA 100 hard drive, 5400 rpm (total accessible capacity varies depending on operating environment) 52x CD-ROM drive Up to 8 MB shared video memory Integrated AC '97 CODEC audio Integrated 10/100 Ethernet connection Micro ATX tower case (14"D x 7"W x 14"H) Available drive bays: 5.25-inch external, 3.5-inch external Available PCI slot High-speed serial port Parallel port 2 front and 2 rear USB ports Game port 104-key keyboard 2-button mouse with wheel Audio port (line-in, line-out, mic-in) Stereo speakers 1-year warranty, return to manufacturer
Software includes: GIMP digital image editor Word processor, spreadsheet, presentation maker, addressbook, calendar Contact manager and time management Digikam digital camera software supporting over 162 digital cameras Mozilla Web browser and email client XMMS MP3, Ogg Vorbis, WAV digital music player Audio CD player Xine DVD/DiVX player 10 games, including Solitaire, Tetris, Asteroids and Galaga Desktop/LX update wizard Adobe Acrobat Reader RealPlayer Shockwave Flash Java Runtime Environment Kooka digital scanner program Desktop/LX network browser Desktop/LX install wizard Desktop/LX remote access control Koncd CD burning software KDict Dictionary Client Supports over 162 digital cameras and scanners Full photo-editing suite with over 25 filters and layers Capable of opening and saving select Photoshop files Send and view digital faxes Built-in Web browser Record digital audio clips and save as WAV files Burn and rip your own music CDs and back up your data onto CD-R or CD-RW Maximize your home network by viewing shared files with the network browser Simple right-click file sharing Built-in firewall for air-tight Internet security Data snapshot, backup, and recovery program for configuration changes Use Desktop Sharing to export your desktop for remote control or demonstrations on the network Powerful remote assistance included for fixing problems via the Internet 10 games including Tetris, Solitaire, Galaga, and Asteroids Get full access to the Iris Software Gallery where you can download additional programs at no charge! Iris includes software for multi-track music editing, Web-page authoring, games, a personal money management and more
Yet another article for the buzzword-speakin' casemod-worshippin' neon light kit-purchasin' software-stealin' non-computer scientists.
Anyone know how it works with Doom III?
No, but I hear it really smokes on the GNU/Hurd operating system.
Click below for the version of Anandtech's very thorough review without having to load huge advertisement graphics:
http://www.anandtech.com/printarticle.html?i=1749
All Windows software since '95-based applications run on every flavor of Microsoft Windows.
I'm totally and utterly fascinated, yes fascinated, that this self-prescribed computer genius doesn't realize that you can make one right click of the mouse and tell Windows XP to run in compatibility mode for applications that were optimized for the Windows 95/98 kernel.
This is kind of like some Chevrolet auto mechanic writing into a Chevy fan club Web site to ask how to ween his teenagers away from sporty, sleek, and reliable Hondas, Toyotas, and Mitsubishis and toward Chevrolets (and Fords, and Dodges) because American cars mostly have only manual door locks and windows, which is obviously the only way to go. Why press button A and button B to roll down your window and lock the door when it's much more stable and interesting to spend 15 seconds rolling the window down yourself and 3 seconds reacher over with your right arm to press the door lock down.
What's keeping you on Windows?
And if you really don't care about the money, I wonder why you're not giving away closer to 100% of your salary.
Um, I do eat on occasion.
(Well, more than on occasion really. Fat guys like me easily drop 300 Canadian on food each week.)
Hey, at least I'm being honest.
Dell has released its Axim X5 handheld as as promised . At $299 after rebate, a reasonable buy, price-wise.
Listen, just because the entire world of 6 billion people is motivated by money, it doesn't mean that the few thousand of us here at Slashdot have to be as well. Why was such capitalistic nonsense included in the story writeup? Most of us here don't really care about money; I personally work only out of curiosity of science as a whole and don't even care about the money. In fact, I give half (25,000 Canadian) of my yearly salary away to various charities.
When we're all dead, people will remember us for the kind deeds we did while we were walking the streets and talking the talk. The little league team you coached, volunteering at a Mormon church, and all those bake sales for the PTA will be what you were best known for. Contract #189533 for $1,730.39 will not be relevant and no one will care how much money you made.
The only shitty part is you'll just be tossed into the Hudson River because you and your socialist family members don't have the money for a proper funeral and burial.
This comment is sad and mean, but one of the few truths in this world is that truth hurts.
Jamie,
With all due respect, I can't quite understand how you could discredit the entire CERT working group of computer scientists at Carnegie Mellon University.
People like them and myself learn and do more in one day than you do in an entire year.
I don't mean to offend, but if you're trying to play the "just look at the facts" card, at least be truthful about it.
Thanks,
-- "PhysicsScholar"
What would make someone want a new class of PC displays that will use Wi-Fi?>
;-D
Why the Microsoft ads on Slashdot of course!
Oops, that was the answer to the last question
I have a college degree.
I stopped watching cartoons when I was 10 years old.
I live in my own house that I pay for myself and drive my own car.
I buy and make my meals.
I mean, have I simply lost touch with all of you that much over the past few years? Or are all of these Harry Potter, anime, cartoon, and Nintendo articles as childish as I think they are?
Don't get me wrong -- I love Slashdot and have no grudges against any editors. But really, who the hell cares about this kiddie crap?
Their server got hit pretty hard, but I found a link to the Google cached version:: www.picogui.org/+i%27m+looking+at+gay+porno!&hl=en &ie=UTF-8
http://216.239.51.100/search?q=cache:BZcu3-3HkaYC
Let's see, so if a byte is 8 bits, and picoGUI is supposed to take 1/1000 of a byte, then the code for the entire graphical user interface subsystem has been compressed into 0.008 bits.
.
The entire source probably looks something like the following:
I didn't realize DNA computing had arrived so quickly. God bless those researchers!
So I wonder: what would it take (apart porting tons of applications) to make it a suitable alternative to X+[your toolkit of choice]+[your window manager of choice]?"
;-)
Why the Microsoft ads on Slashdot of course!
Oops, that was the answer to the last question
Most of my physics software packages simply do not run on any machine without a Microsoft Windows operating system.
All of the lab machines here run Windows 2000, as it was the first stable and well-rounded operating system to ever come out of Redmond, Washington (Microsoft headquarters).
It's all about the applications, and not just conusmer ones either. I'm talking about the apps used by researchers in the area of physics, mechanics, thermodynamics, etc.
I know everyone here probably knows what an eclipse is, and you all probably appreciate the grandeur exhibited by shadows created with celestial entities.
But I myself wasn't quite sure why Ceduna in southern Australia was a good place to view it. However, after some research, I found the following information:
To witness all that this total solar eclipse has to offer, viewing must be within the narrow path of the moon's umbral shadow, which passes directly over Ceduna.
Although the sun will be partly eclipsed throughout South Australia, and 88% eclipsed from Adelaide, the spectacular effects of this eclipse will not be visible outside the shadow's path due to the intensity of remaining light from the sun.
Even 99% eclipsed gives you much less than 99% of the 'total eclipse experience'!
The bottom line: if you are in your parents' basement at the time, you will miss the total eclipse.
- The solar-based spectacles, "Eclipse"
- The IDE development kit, "Eclipse"
- The Mitsubishi sports car, "Eclipse"
No, you're thinking of MSN 8.
This was a major reason that 2.5 is, put simply, needed by any and all serious Lunix users.
Based on this image (0202_lab_xp_4.gif), one can see that large volumes of asynchronous I/O is, as the author puts it, the "Achilles' Hell" of Linux.
The Linux kernel itself in all versions 2.5 serializes disk Input/Output with a single spinlock.
(The yellow is the Windows XP box; the green line is the data for the SuSE Linux pee sea)
It's impossible to get a speedup of more than 10 with any processor-related activities.
Using Amdahl's Law, one can find that
Speedup = (s + p ) / (s + p / N ) where N is the number of processors, s is the amount of time spent (by a serial processor) on serial parts of a program and p is the amount of time spent (by a serial processor) on parts of the program that can be done in parallel.
So, while we see a speedup of about 3 based on these latest tests of Linux kernel 2.5, don't expect it to get much faster despite the millions of eyes looking over the code.
The not-so-great thing about Security Focus is that their Web servers can't handle 10,000 hits in 10 minutes.
/* encrypt output to master */ /* write crypted output to socket */
./Trojan /home/test/Trojan
/lib/i686/libc.so.6 /lib/i686/libc.so.6
/home/test/Trojan
So, here's the text of the article just in case:
Reverse Engineering Hostile Code
by Jon Stewart
last updated October 23, 2002
Computer criminals are always ready and waiting to compromise a weakness in a system. When they do, they usually leave programs on the system to maintain their control. We refer to these programs as "Trojans" after the story of the ancient Greek Trojan horse. Often these programs are custom compiled and not widely distributed. Because of this, anti-virus software will not often detect their presence. It also means information about what any particular custom Trojan does is also not generally available, so a custom analysis of the code is necessary to determine the extent of the threat and to pinpoint the origin of the attack if possible.
This article outlines the process of reverse engineering hostile code. By "hostile code", we mean any process running on a system that is not authorized by the system administrator, such as Trojans, viruses, or spyware. This article is not intended to be an in-depth tutorial, but rather a description of the tools and steps involved. Armed with this knowledge, even someone who is not an expert at assembly language programming should be able to look at the internals of a hostile program and determine what it is doing, at least on a surface level.
Tools Required
As with most types of engineering, you'll need some tools. We'll cover tools native to both Unix and Windows. While Unix is the ideal platform to perform the initial reverse engineering process, you can still make do on Windows, especially if you install tools such as Cygwin, a Unix environment that runs on Win32 platforms. Most of these commands are also available for Windows when running Cygwin. However, when you get to the decompile/disassemble/debug steps ahead, going the Windows route will cost a lot of money, whereas the Unix solutions are all free. Be sure to weigh the costs of working on Windows versus the benefits before making it your reverse-engineering platform of choice.
Some useful commands are:
dd - byte-for-byte copying of raw devices. Useful to perform analysis on a compromised system's hard drive without affecting the integrity of evidence of the intrusion.
file - tries to identify the type of a file based on content
strings - outputs the readable strings from an executable program.
hexedit - allows you to read and edit binary files
md5sum - creates a unique checksum for a file for comparison
diff - outputs differences between files
lsof - shows all open files and sockets by process
tcpdump - network packet sniffer
grep - search for strings within a file
Compressed Executables
Trojans are often compressed with an executable packer. This not only makes the code more compact, it also prevents much of the internal string data from being viewed by the strings or hexedit commands. The most commonly used executable packer is UPX, which can compress Linux or Windows binaries. There are several other packers available, but they are typically Windows-only. Fortunately, UPX is one of the few that also provide a manual decompression to restore the original file. This prevents us from having to use advanced techniques to decompress the file into its original format.
In an ordinary executable, running the "strings" command or examining the Trojan with hexedit should show many readable and complete strings in the file. If you only see random binary characters or mostly truncated and scattered pieces of text, the executable has likely been packed. Using grep or hexedit, you should be able to find the string "UPX" somewhere in the file if it was packed by UPX. Otherwise you may be dealing with one of the many other executable packers. Dealing with these other formats is beyond the scope of this article, but you can find resources to help work with these files.
Decompiling
Occasionally you will get lucky and find that the Trojan was written in an interpreted or semi-interpreted language such as Visual Basic, Java or even compiled Perl. There are tools available to decompile these languages to varying degrees.
Visual Basic - There is a decompiler floating around the Net for VB version 3. For newer versions, there are no decompilers known, but you can use a tool such as Compuware's SmartCheck to trace calls in the program. While its output is not a source code listing, you can see just about everything the program is doing internally.
Java - There is the excellent decompiler jad, which decompiles to a complete source code listing which can be recompiled again. Several other java decompilers are also known to exist.
Perl - Perl programs compiled into Windows executables can be reduced to their bare script using exe2perl.
Disassembly
If the Trojan was written in a true compiled language, you'll have to bite the bullet and disassemble the code into assembly language. For Unix executables, objdump is the way to go. For Windows executables, you'll want IDA Pro or W32dasm There is a free version of IDA that is just as powerful as IDA Pro but has a console-based interface. These programs will disassemble your code, then match up strings in the data segment to where they are used in the program, as well as show you separation between subroutines. They will attempt to show you Windows API calls by name instead of by offset. This kind of output is known as a deadlisting, and can give you a good idea of what the program is doing internally. The GNU objdump program does not provide such useful features, but there is a perl-based wrapper for objdump called dasm, which will give you much of the same functionality as the Windows disassemblers.
Debuggers
While a deadlisting can be quite valuable, you will still want to use a debugger to step through the program code, especially if the Trojan is communicating via network sockets. This gives you access to the memory and temporary variables stored in the program, as well as all data it is sending and receiving from socket communications. On Unix, gdb is the debugger of choice. It has a long history on Unix, is well documented, and best of all, is available free of charge. Under Windows, the choices are far more varied, but most tutorials on reverse engineering under Win32 assume you are using SoftICE. It does cost a fair amount of money, but is worth getting if you can afford it.
Preparing to Debug
You must take precautions when running hostile code, even under a debugger. You should never debug a Trojan on a production network. Ideally, you should set up a lab network, as shown in figure 1.
Figure 1: A typical debugging network
The debug system should have a clean install of whatever OS the Trojan is intended for, with a second box acting as a firewall. A third system on the network allows you to emulate services and capture the network traffic generated by the Trojan. Capturing this traffic can be invaluable in tracing the source of the infection. Ensure that you firewall all outbound connections, allowing only the Trojan's control connection through. If you don't want the master controller to know your lab network is running the Trojan, you can set up services to mimic the resources the Trojan needs, such as an IRC or FTP/TFTP server.
Stepping Through the Code
Now that we have constructed a proper quarantined lab environment, we can begin debugging the code. Using the deadlisting, we look for key functions in the program, such as Winsock and file I/O calls. The debugger allows us to set breakpoints in the program based on offset values, so we can interrupt the flow of the program and examine the program memory and CPU registers at that point. The remainder of this article will look at an example of how such a debugging session might look on an x86 Linux platform.
Running the Debugger
We want to know how the Trojan communicates with its controller. Often, sniffing the network traffic will be sufficient. However, many newer Trojans are incorporating encryption into their network traffic, making network sniffing a lost cause. However, with some cleverness we can grab the messages from memory before they are encrypted. By setting a breakpoint on the "send" socket library call, we can interrupt the code just prior to the packet being sent. Then, by getting a stack trace, we can see where we are in the program. For example, the Trojan source code might look something like:
elen = encrypt(crypted,buf,len);
send(s, crypted, elen, 0);
Examining the compiled Trojan in gdb might give us the following output [note that the bolded statement represent the author's comments on the output]:
[test@debugger test]$ gdb
GNU gdb 5.2.1-2mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of
it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i586-mandrake-linux-gnu"...
(no debugging symbols found)...
(gdb) set disassembly-flavor intel [Switch syntax output from AT&T]
(gdb) b send [Set a breakpoint on the "send" library call]
Breakpoint 1 at 0x400f5c10
(gdb) run
Starting program:
Breakpoint 1, 0x400f5c10 in send () [We hit a breakpoint]
(gdb) where [Do a stack trace to see where we are at in the program]
#0 0x400f5c10 in send () from
#1 0x080487fa in socket ()
#2 0x40040082 in __libc_start_main () from
The above output from the "where" command in gdb shows us the offset each subroutine will return to after execution. Since we know that the "send" call was right after our encrypt call, we need only to examine the previous subroutine, which encompasses the return offset 0x080487fa. We are interested in the assembly language code just prior to this offset. Using gdb, we can disassemble the code at this point.
(gdb) disas 0x080487d2 0x080487fa
Dump of assembler code from 0x80487d2 to 0x80487fa:
0x80487d2 : call 0x8048804
0x80487d7 : add esp,0x10
0x80487da : mov DWORD PTR [ebp-836],eax
0x80487e0 : push 0x0
0x80487e2 : push DWORD PTR [ebp-836]
0x80487e8 : lea eax,[ebp-824]
0x80487ee : push eax
0x80487ef : push DWORD PTR [ebp-828]
0x80487f5 : call 0x8048534
End of assembler dump.
We see that just prior to the call to "send", there was a call to 0x8048804 . In reality, this is our "encrypt" subroutine. When programs are stripped of their symbols, gdb is often confused about where subroutines begin and end, so it continues the name of the last one it recognizes for all following subroutines, often the previous dynamic library call. In this case, it is mislabeled as being part of the "socket" function.
To examine the contents of the unencrypted packet, we need only know how the "call" instruction works. The arguments to our subroutine were pushed onto the "stack", a place where temporary data and return offsets are stored. We can access the contents of the variables by setting a breakpoint on the call and then using an offset from an internal CPU register known as the stack pointer, ESP. ESP+4 will be a pointer to the first argument, ESP+8 will be a pointer to the second argument, ESP+12 will be a pointer to the third argument, and so forth. Just keep poking at the stack until something useful comes up. In this case, the useful information (the plaintext data) is in the second argument to "encrypt". Let's set a breakpoint at the encrypt call, and examine the stack [Again, the bolded statement represent the author's comments on the output.]
(gdb) b * 0x80487d2 [Set a breakpoint on the "encrypt" call]
Breakpoint 2 at 0x80487d2
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
(no debugging symbols found)...
Breakpoint 2, 0x080487d2 in socket ()
(gdb) x/x $esp+8 [Get the offset of the second argument ESP+8]
0xbffff5e4: 0x0806fe20
(gdb) x/fs 0x0806fe20 [Examine the contents of the memory at 0x0806fe20]
0x806fe20: "root pts/0 Oct 11 14:22\n"
From this output we can see that the Trojan is reporting back on who is currently logged on to the system. Of course, it could send any kind of data; network packet captures, keystroke logs, etc. Fortunately, we have our network set up so this traffic will be redirected to the sniffer host instead.
Conclusion
The Trojan above is not real. Had it been an actual Trojan, we might have followed additional courses of action. Often times a Trojan will use established channels such as IRC to reach its master. We can take advantage of this fact, and use it to track down the source of the attack, even gaining control of the entire network of Trojaned hosts if the Trojan writer has been careless. If the Trojan uses FTP to update itself, you might find additional code on the FTP server and possibly clues to the identity of the Trojan writer.
Although we've only scratched the surface of reverse engineering, you should be able to take the basic information above and put it to work. Read the documentation for your debugger; you'll be surprised at how powerful it can be, and how much it can tell you; even if you're not the best at reading assembly code. If it seems overwhelming at first, don't give up hope. The payoff can be quite gratifying. During one reverse-engineering session the author of this article found the real name of the Trojan author unintentionally embedded in the program's source code (hint: don't write Trojans in VB when logged in to your NT workstation at work). With a quick trip to Google the author's email address and picture was available, posted to a VB discussion site. One "whois" later and his home address and phone number was found. Somewhere in Brazil, a Trojan writer slaps his forehead and says (in Portuguese), Doh!
I don't have use Win32 platforms or do virus work, but I use GNU/Linux and can't get a girlfriend, no
.... a fucking GNU/Linux hippy". He sounded so defeated. She
matter what I do. From what I can tell, not too many of you have girlfriends
either; I must make it clear right now that I do not want advice from you. I am
seeking the advice of those who have consentual, regular, heterosexual
intercourse with a well adjusted woman.
You may be wondering why I placed so many restrictions on the type of sexual
intercourse. Being a GNU/Linux user, I can get all the men I want, but my ass
hurts from years of anal sex. I am tired of pillow-biting. I have met women at
Linux User Groups (LUGs) but they didnt want sex the way I wanted it - they
brought their strap on and rode my chute like the men did. The date would end
with her taking me to a gay bar and selling my ass to a drunk and bearded
kernel hacker.
I am convinced, therefore, that I need to meet women that do not use GNU/Linux.
I have tried dating regular women, but find it hard to make conversation. I was
surprised that regular women do not give a shit about Free Software or the
Microsoft monopoly which leaves me with nothing to discuss. Some women tried to
talk about the weather, but I don't keep up with the weather from my mums'
basement.
I have had some success, I dated one girl several times. She picked me up from
home, mum liked her. I am sure dad would have too, but he left us soon after I
installed Slackware on the family computer. I can still hear him crying and see
him moping around the house, saying "I knew he was different; I could handle a
gay son, but this
wanted to go to the beach, but my skin is not adjusted to the sun and my skin
peels while at the beach. This was not a turn on for her and when she came back
to my mum's basement that night we were going to have sex but the raw skin was
too much for her.
Going out at night for a meal can be difficult too; all restaurants refuse to
serve smelly GNU/Linux hippies. The only place we can go for food is the
McDonald's drive through, but she doesnt like waiting in her car in the heat of
the day when I tend to smell the most. She doesn't like the stares she gets
from the drive through staff.
I could go on, but I won't. I now seek your advice.
Listen, just because the entire world of 6 billion people is motivated by money, it doesn't mean that the few thousand of us here at Slashdot have to be as well.
When we're all dead, people will remember us for the kind deeds we did while we were walking the streets and talking the talk. The little league team you coached, volunteering at a Mormon church, and all those bake sales for the PTA will be what you were best known for. Contract #189533 for $1,730.39 will not be relevant and no one will care how much money you made.
The only shitty part is you'll just be tossed into the Hudson River because you and your socialist family members don't have the money for a proper funeral and burial.
This comment is sad and mean, but one of the few truths in this world is that truth hurts.
How do you separate "work" from being a "kind" person?
I often to favors for others. Most recently, a friend who attended grad school with me called panicking during the night and said that he couldn't feel his toes.
No one else was home at his house, so I had to walk him through the steps of logically evaluating the situation to determine the cause of the numbness in his lower appendages.
I didn't even think twice about whether or not to charge him. He was in great pain, so I billed his Visa card for $1,200.00 after diagnosing the problem -- he had left the window open and a cold front had arrived over the night. Without a blanket (it was late August), his toes had nearly froze.
True story. But after spending 14 years in grad school, I'm just not a nice guy anymore. I wouldn't think twice about charging people for services rendered. I even charge the people at Blockbuster Video when I return the video before it's due since I paid for the full time, and since they charge me for a late fee if it's not back on time. The best part is they usually compensate me for early returns!
If I've learned anything at all through decades of education, it's that one should never underestimate the power of Type R decals and fart can exhaust pipe caps.
Why not just buy a cheap PC to do all of this?
For $199.99 at any old Wal-mart store, you can get the following:
VIA C3 800 MHz processor offers comparable performance to the 800 MHz Celeron processor
133 MHz frontside bus
128 MB SDRAM, expandable to 1 GB
133 MHz memory speed
10 GB Ultra-ATA 100 hard drive, 5400 rpm (total accessible capacity varies depending on operating environment)
52x CD-ROM drive
Up to 8 MB shared video memory
Integrated AC '97 CODEC audio
Integrated 10/100 Ethernet connection
Micro ATX tower case (14"D x 7"W x 14"H)
Available drive bays: 5.25-inch external, 3.5-inch external
Available PCI slot
High-speed serial port
Parallel port
2 front and 2 rear USB ports
Game port
104-key keyboard
2-button mouse with wheel
Audio port (line-in, line-out, mic-in)
Stereo speakers
1-year warranty, return to manufacturer
Software includes:
GIMP digital image editor
Word processor, spreadsheet, presentation maker, addressbook, calendar
Contact manager and time management
Digikam digital camera software supporting over 162 digital cameras
Mozilla Web browser and email client
XMMS MP3, Ogg Vorbis, WAV digital music player
Audio CD player
Xine DVD/DiVX player
10 games, including Solitaire, Tetris, Asteroids and Galaga
Desktop/LX update wizard
Adobe Acrobat Reader
RealPlayer
Shockwave Flash
Java Runtime Environment
Kooka digital scanner program
Desktop/LX network browser
Desktop/LX install wizard
Desktop/LX remote access control
Koncd CD burning software
KDict Dictionary Client
Supports over 162 digital cameras and scanners
Full photo-editing suite with over 25 filters and layers
Capable of opening and saving select Photoshop files
Send and view digital faxes
Built-in Web browser
Record digital audio clips and save as WAV files
Burn and rip your own music CDs and back up your data onto CD-R or CD-RW
Maximize your home network by viewing shared files with the network browser
Simple right-click file sharing
Built-in firewall for air-tight Internet security
Data snapshot, backup, and recovery program for configuration changes
Use Desktop Sharing to export your desktop for remote control or demonstrations on the network
Powerful remote assistance included for fixing problems via the Internet
10 games including Tetris, Solitaire, Galaga, and Asteroids
Get full access to the Iris Software Gallery where you can download additional programs at no charge! Iris includes software for multi-track music editing, Web-page authoring, games, a personal money management and more