Love, sweet love...

Luv, LOVE, LiKe, In Love, WT?

It occurs to me that there are many different understandings of the word Love. Although words may seem to provide the method of communicating thoughts, as cultures and languages progress, words actually change their meaning to represent what is thought about them. It's a symbiotic cycle. Each langauge has several words to describe the English word "Love". Heck, even English has different ways to use the one word "Love"

Let's talk about one facet of Love, specifically the Romantic/Dating/Courting/Marriage Love. In English, we actually use three different ways to talk about this type of Love. Oh, I'm sure that if you're reading this far, you have probably managed to find yourself in a romantic-type relationship and spent several hours of your life (or man-days or even man-years) simply trying to figure out "Do I LOVE <this person>? Am I IN LOVE WITH <this person>? Do I LIKE <this person>? Am I FOND of this person?" If none of the above apply, what the hack are you doing with the person? If it's for the sex, you might as well hire a hooker, it'd be better for both of you since you'd at least understand what you both wanted. (no, I'm not encouraging this route. I happen to take issue with sex outside of marriage. First off, God has a problem with it. Secondly, it causes immense amounts of pain.)

But what the hack are we really talking about? LOVE? IN LOVE? LIKE? (yes, Fond would make 4 ways of discussing it, but it doesn't count. It's more of a concept than a way we usually talk about Love).

The Christian faith seems to have the most comprehensive description of Love I've found. But I can sum it all up in one word: Commitment. Love is a commitment. It is commitment to the benefit of another person. Anyone who tries to talk about feelings or other mumbo-jumbo is fully of crap. Love is patient. Love is Kind. It's being humble, not full of yourself. There is a good list of what Love is all about in the Bible, starting at 1 Corinthians 13:4. Look it up. I particularly like "Love Always Perseveres."

Like, and fondness are all about the emotional (and physical) enjoyments we're graced with. Note: as with "happiness", these come and go.

Oh, and "in-love" is nothing more than a heated, super-powered version of Like.

More depth as Love plays into Marriage...

The love commitment is 100% your responsibility. When you say "I do", you are committing to a commitment with God. It may seem like a 1 way street, and indeed it is. You are responsible for your 100% of your commitment. It does not depend on your spouse's commitment or anything else. Hopefully you have selected a person who also understands this and will continue to recommit to his/her 100% commitment to love you. That is also between them and the creator, not between you and the person. To believe otherwise is to allow yourself to slip in your commitment when s/he does...

If all this doesn't encourage you to treat your spouse with kindness, think of this. Your commitment to God to love this person is for your entire life. Your actions will effect how nice it is to live those days.

Marriage is forever. Approach it that way, both of you. Wisdom and intelligent boundaries are good and tending to needs of both of you is important. Fully invest yourself into this friendship. There is no other relationship of this kind.

When you break your commitment, there is only one thing to do. Apologize and recommit. Constantly

For those of you who think this is a radical (or stodgy) view, try this one for size: Dating is for the birds. It's nothing more than tricking yourself and others. A confusion of intent. Courtship is the way to go. Don't be an Ordinary Girl

Here's another one. I believe in love at first sight... I don't think it's necessarily wise, but it can happen. More frequent is lust at first sight. But hey, if you learn what the Love commitment is all about, thats possible at the same time. Who knows? But that doesn't negate the fact that it's not necessarily wise.

Long time no chat

It's been a sickeningly full several months. I was working on an article on Love, Like, and In Love, but have been side-tracked

ARG! A few months ago, a customer began having odd issues with a product we designed and sold them. The appliance we developed has done rather nicely in the space, but this box seems abused. Such a turn of events, may I not witness again.

At the end of August I got a note saying that they had to reboot the box and the data that came up was missing the past week. Restoring from backup resolved the immediate concern, but the issue was strange elusive. It turns out one of a mirrored pair of hard drives failed, and the mirror had been out of sync for about a week.

So I decide to buy a complete new system to have all known goods to swap out... After dorking around with my supplier for a couple weeks trying to help them figure out their 455 from a hole in the ground, I get the dreaded call.... My customer's other drive failed. I found myself doing a complete restore from backup, on a new drive I had to purchase from BestBuy. :(

So I install the new drive, awaiting a new pair of drives to mirror. Unfortunately I created the RAID and LVM constructs using newer tools (Kubuntu-Live CD), which default to creating versions not supported my the kernel on the appliance... DOH! Starting off with the original Install CD and recovering that way ended up giving me the environment I wanted. Once I nailed that down, the restore process came off fine, except a few rights issues I ran into, probably due to a command line switch I didn't include... and this turned into a revamping of the documentation and scripts to recover from backup. All is well on that front now, and I've had several more times of vetting the new process to make sure. Several unbillable hours burned

So the drives come in, and I get to nervously rerun the compute restore process from scratch. I did this partly to test the process further, but also to make sure no hidden rights issues remained. More unbillable hours burned.

So I start thinking we're out of the woods... until I realize that the system doesn't work with all four drives installed and plugged in! What!? Troubleshooting turned up that if I disconnect power from any of them, the other three work great. With all four, I get strange errors in the logs. Fine, I have to get the unit back onsite and operational immediately, so we run on 3 drives for a while. A couple days later I replace the power supply. Everything works great. MANY unbilled hours.

So I still attempt to purchase a complete new system, that process having its own headaches. Between being nonresponsive and not being able to figure out how much to charge me, I decide to go with another vendor, one I've had some history with in the past and with comparable prices. I've learned something from all this, and that is that 3 year warrantees are a "Good Thing". Unfortunately, at this point in the process, I haven't learned that spending the additional $$$ to have the system assembled and tested is as well. The first unit is DOA. Tech support thinks the issue is BIOS not recognizing the processor. I send back the memory, processor, and mobo for a BIOS upgrade and testing. Because I didn't check the "Assembly and Testing" box originally when I ordered it, I pay shipping. I receive the parts back in about a week. They say it works for them, it no worky for me. I swap in a known good power supply. Still no worky. Now I'm significantly confused, and about to send the whole thing back and order another unit with assembly and testing. ARG! None of this is billable, just plain customer service. And not very timely, at that!

So then I get a call from the customer, the machine locked up during the night. A reboot doesn't fix it because the BIOS, seeing the primary drive disappear once, decides it isn't there and won't boot it. One simple fix later, I start to realize that the system locks up if I leave both backup drives (this is a second RAID Array, used for live backups). New problem! Drive controller issue. At this point, I disconnected the Primary mirror drive (in lead-climbing terms, I was setting an anchor to catch me if I fell). I then proceeded to disconnect the backup mirror drive as well. One primary, one backup drive. And things are happy... for the moment. And only a couple unbillable hours burned.

So I then get a phone call that the email subsystem was not delivering new mail! Apparently the hard lockup had stopped some indexing process to corrupt a database in the Cyrus email database. Troubleshooting this proved problematic, as the documentation does not delve into those depths of the inner workings of Cyrus, and I was under the gun. After many hours of looking, and finally finding a good IRC support bunch o' Cyrus hackers on freenode (#cyrus, very respectable), and getting feedback about some IRC naughties I was doing.... ;) I had learned a great deal about the inner-workings of the Cyrus IMAP Server. Maybe more on that later. I ended up whacking the meta-data and restoring from backup (funny how that works... backup locked it up, backup restored it... ;) Several unbillable hours burned.

So the end of month came, and the full monthly backup. This is intense. Thus, even though I was going to replace the entire system, I installed a new SATA drive controller and monitored the progress. December 1st came and went and the box continued to tick. The Monthly backup came off without a hitch. Happiness.

So then on December 3rd I became rather flustered to find the box was no longer sending Backup status emails. Further investigation showed that the Backup drive was no longer responding. 5**7! Thankfully, with all this work going on, the customer had temporarily given me a key, so I visited the site after church on Sunday, with two new backup drives. I was able to bring the drive back online, and upon doing so
I immediately installed one of the replacement drives as a mirror, booted into maintenance mode and started the sync-ing process, hoping to salvage the historical backups. After a while of making sure the sync process wouldn't lock up the box (as it had consistently ever so recently) I started the rest of the services (except cron) and left. A few unbillable hours lost.

So I get home, the box is still responding (ssh is a wonderful thing), slow as all getout. I had forgotten I left cron turned off (to keep the timed events from interfering with the recovery time, etc...), and found that the backups didn't happen. I started the DAILY backup about 7 this morning, and got a call from the customer that things were slow and emails weren't coming in... DOH! cron is responsible to kick off the fetchmail process. Turning cron back on and both backups and fetchmail are not operational... The [raid1] and [mdrecoveryd] processes aren't eating all the CPU, load-average is still at 5.xx, and I can't yet get a status on the RAID array. I'm back to seeing the "hda: lost interrupt" messages. 5**7! I should've used rsync. That drive has got to go...

So you see I've been using an excruciatingly annoying literary faux pas, beginning each paragraph with "So...". This is intentional, to help you get the feeling of frustration and annoyance I've been struggling with for the past three months. Nuf sed.

And this is mixed with family time, day-job, reverse-engineering, creating version 2.0 of this appliance - based on Ubuntu, and prepping/running a Local Mentor Program class for the almighty SANS. I used to remember a very depressing time of being bored... now I only remember that is happened. I'd still take now over then. This may be a post of frustration, but I am also thankful for the life I've been blessed with. Great family, great friends, amazing hobbies, relative business success, and the many faculties I cannot claim responsibility for. I thank the creator for them, and am thankful in all circumstances.

Kurios

The trouble with Open Source...

is that it just doesn't earn the big bucks!



I just finished reading an article from a British Computer Society member called

The trouble with open source

Now I'm both the first person to evangelize open source but also the first to point out that it, like everything else, is imperfect. This article happened to identify several issues, however, some of which I take issue.



The author, a certifiable fellow identified as "Stephen J Marshall CEng MBCS CITP" grants OSS some validity, if only as having academic value. He refers to it as a "widely talked about" and "influential" "phenominon" with a utopian vision of free software. He refers to the champions of this vision as "high-profile pressure groups", citing the Free Software Foundation and Electronic Frontier Foundation as two.

As the catalyst for widespread OSS adoption, he explains quite correctly about the fears associated with vendor lock-in: all-eggs/one-basket, dimishing (or lets face it, "NO") support from vendors, never-ending cycle of upgrades whence there is no return.


He continues to decry some of the most powerful business benefits of OSS: large developer-base, likelihood of longevity, the option to bring critical development in-house, should the project-owners disappear, etc...



The author then changes the tone of his article with the phrase "become captivated by the idea of a free-lunch," then launching into his opinions of OSS weaknesses. Below, I'll list his issues, a summary of his meaning, and my own perspective (which is, of course, why you read my blog, right? ;)



* Intellectual Property: code written by employees is owned by the company, regardless of when they write it. Only losers with zero experience are allowed to write OSS.



= I'll have to verify the laws in the US, but the UK sounds rather draconian in this regard. I quess it's a good thing we told 'em where to stick it when we did. Beyond the differing legal-systems between countries, many companies officially contribute their own IP to OSS, as well as providing employee work-hours to benefit OSS. Look at many of the software projects which have made it to the bigtime. Most of them have corporate backing and/or corporate ownership. Beyond even that, part of the draw of OSS is the ability of a developer or team to prove their value in an open forum where their software might get noticed. Some OSS code is resume-ware

= Still, the author's comments aren't without lessons:

== Investigate the code you use before you rely too heavily on it. Get to know the developer=base and background a little and get a feeling for its overall quality. This is know different from the proprietary world, except the proprietary vendors are much more skilled at deception.



* Conceptual Integrity: OSS projects don't have leadership with any vision or control. Quality control is done on the first adopters



= Hogwash. First of all, generalizing about OSS is like characterizing every person on the planet. That said, OSS projects are almost as likely to have leadership with vision and control as proprietary code. Either way, it's a gamble. The key difference is driving-force. OSS is not driven by a marketting sheet and budget as their proprietary cousins. OSS is driven primarily by features and quality, neither of which are guaranteed. Furthermore, OSS projects are often a labor of love, being conceptualized and owned by the project leader(ship). This relationship is very powerful, more powerful than a paycheck often ensures. As for quality control, I can't say there isn't a bit of truth there. I have fallen victim to the occasional bug finding me. I refuse to condone it, as the quality of software needs to improve. I will point out that I have been bitten equally by proprietary vendor bugs. The difference is that the OSS bugs are free. Yes, you may be able to get the bugs fixed quickly by pay-for products faster than free ones... but I haven't met a OSS developer which wouldn't fix your problem quickly for a marginal fee. Difference: much faster, much cheaper, pay-as-you-go.

= Still, there are lessons to be gained here as well. QC/QA *really* need to improve, industry-wide. The software industry was at an all-time-low just a few short years ago. It appears to be improving slowly. This *must* be a continued effort, learning from the experience we've gained. Heck, most of the *reason* OSS has gained popularity is the lack of software quality in the proprietary world.



* Professionalism: duh.



= Ok, I can't knock this one very hard. I've seen the bedside manner of certain OSS developers. I know that as a geek I have to work hard for professionalism... I will say that paid developers tend to be more willing to make the effort... particularly in the OSS space. Stop thinking that OSS means immonetary! That short-sighted viewpoint will continue to cause difficulties in the software world. Support for corporate use is practically a given, a requirement many corporations will demand. This is where SuSE/Novell has a great deal of appeal.

== What to learn? 1) Be nice, guys! 2) Consider the needs of those to whom you are communicating.



* Innovation: wimpy little wannabe developers can't think up anything fun and new.



= Wow! I'm pissed off *for* the developers! They should be quite insulted. Is this guy a lunie or simply on the corporate payroll? He has obviously never used Mozilla, Linux (for so *many* innovations), Thunderbird, Apache, GAIM, Konqueror, KDE, Gnome, Unison, rsync, APT, and so many others which have put their proprietary cousins to innovative shame on countless occasions.



= Lessons? There are many who have opinions. Use those opinions to limit *test-driving* solutions, not negating them.



The paper goes on to mention some drivel, particularly focusing on the detriment of software vendors who cannot compete. I can understand how this space can be difficult. Problem: many corporate software vendors get outrageous amounts of money for limited value, buggy software I could write in a couple months. Why shouldn't OSS projects put the pressure on these? The software industry is certainly being shaken up with the acceptance (and relative maturing) of OSS. The reasonably-priced, higher-value software should have less to worry about from the OSS world. If they are offering significant value, OSS developers are less likely to target the space (ok, this isn't a scientific view, I suppose they might get an itch). $100k for a piece of software which could be written by a team of 3 in a month... Something is specifically wrong with that. It's why I rejoined the development community ;)

However, there are new areas of development which OSS has opened up, building upon OSS. ISVs are starting to harness the Linux platform to lower the costs of development, deployment, and improve visibility into the OS. Smart ISVs are learning to harness the power of OSS, even when they do not offer their own. The author is correct in stating the importance of the "middle-class" developer. I offer my respect and support to those, and hope for them intelligent business decisionmaking. Software companies have so much to offer, even in the OSS world we seem to be increasingly embracing.



To finish off the article, we find the author's fear of UK governmental preference tending toward OSS in detriment to software vendors, listing cost as the primary decisionmaker for the UK government. (wait a minute, I thought OSS was illegal!) I believe this is the cause for this article. Some valuable insights were shared, but overall it did indeed seem to be very closed-minded and old-school, neither of which work very well in the new technology age. No disrespect to the author, the article was well-articulated. The opinions are his, and his right to express them is what makes the web and open governments so great.



Before writing him off, however, let's be sure to keep in mind the lessons and concerns listed above. Learn from all you can, whether the opinion be pro or con.

Suck butt!

Man, this has not been my week! Last Friday I received a deadline for a project I was not really ready for (deadline: change by Thursday with international communication and preparation, usually requiring nearly a week of lead-time).


Friday was also a meeting with my local IT Security professional group. I should not have gone, given my deadline. But like the moron I continually prove myself to be, I went... but wait, the moron story continues.

Thinking the location had wireless Internet for visitors, I fired up Kismet to figure out what settings I needed for Internet access to VPN back and keep abreast of the developments in my project. I would have asked but I was already 15 minutes late and didn't want to disrupt the meeting further. There was one unencrypted network, but the SSID wasn't broadcast. Hoping for something identifiable as "visitor" or "public" or something else, I thought I'd let it sit for a minute and pick up the SSID. I got distracted by the meeting (and a little bit of tinkering to get echod to return correctly), I forgot about Kismet running until the location security officer came and squatted next to me.

The gentleman asked me what I was doing on wireless. I was about to say "nothing" when I remembered Kismet was running. Kismet is undetectable, but honesty is important to me, so I showed him the Kismet window. I honestly didn't expect him to get angry, but he did. Visibly disturbed, he asked me to delete the datafiles collected by Kismet. I obviously didn't have any problem with that, so not only did I remove the data files, but passed them through the shredder first (unix command "shred") to make sure they were unrecoverable.

The gentleman still didn't seem very pleased, so I suggested that we take a walk. I apologized profusely, he told me quite firmly that this was unacceptable. He then asked me to never again bring a computer or other device/tool to their location. While I thought that was a bit harsh, I agreed.



Let me take a moment for an aside. Kismet is a wireless audit tool which is completely passive, leaving no indication of its use. It does not cause damage or disruption of service. Due to its invisible nature, I expect that everyone is running Kismet on my network at some point or another. Educated defense must expect this, in my opinion. Still, I need to capitalize on this opportunity to learn...



Back on track. I get a voice-mail from my boss at 6:45pm. Although I was feeding my infant and packing for a trip, I knew I'd better call him back (I'd have talked to him sooner but he forgot to turn on his cell-phone ringer).

The gentleman had contacted my boss, and was very angry (partly because *he too* had to wait for my boss's cell-phone issue), and demanded that my laptop be siezed and wiped. (let's be reasonable, this is *my* laptop!)

My boss kindly asked what was planned for the laptop over the weekend. He asked if I could bring it in just to have my counterpart forensic analyst verify that I did what I said to the other gentleman. Wanting to be helpful (I have nothing to hide) I told him I would leave it home and not touch it. Of course, I started having hard drive issues the day before. @#$%!



I'm running out of time, and you're likely out of interest. To make a long story short, my hard drive was failing, but we were able to get a good image (like the third or fourth try), of course I hadn't done anything nepharious, and I had nothing to hide. They were able to clear my name (as much as was possible), mid-week... It was a difficult week, busy and hectic and draining.

Thank God it's over. It's still hectic and crazy, but at least I learned a few things:

1. There are many people driven by fear (or worse), not knowledge


2. I must learn to keep out of danger from those people


3. Honesty has a slow ROI, but a very powerful one

My boss and team lead were both very supportive, because they know and have come to trust me and my intentions. They know I value and effort integrity. Their support was very well appreciated.

bon voyage, Atlas!

Not only is atlas going on vacation, but he's not coming back! (well, at least not to this blog)

atlas has his new own blogspace set up here:

http://atlas.r4780y.com/

Enjoy and farewell, my friend.

Stick a fork in echod - atlas again

echod is now on life support only. Officially dead, I now wish to clean up my sploit to have it continue execution. We'll have to see about that one. :\ Can't say I've ever written a sploit to return, but this seems like a great time to start.

It's actually been a week since I've been able to touch it, so I'm not feeling quite as lame as I was last week. Work has extended into the evenings and then there was the wedding I had to liven up :) (kudos to Ryan and Rachel!)

This round in my fight with echod was much less confounding. I had already structured the exploit code so I could tinker with the header (as the term suggests, I'm speaking of the initial set of bytes which hold the address to overwrite the return pointer and some other goodies used to reconstruct the stack... remember that everything is reversed). The string dynamically generates NOPs to correct the buffer size from any changes.

Since that was already in place, I simply pumped some net-bind shellcode through "reverse()" and appended the resulting string to the sploit header (thanks again, Metasploit!). This broke stuff at first. It seems some of the memory the shellcode was occupying gets altered before execution. Solution? Add some NOPs after the header, before the shellcode, and check again. I ended up using 96 (nice round number) NOPs for this as 32 and 56 were not enough. Surprisingly, that provided a stable/consistent exploit.

As an exercize, I then wrote three while loops:

*) one to check the service and restart it if dead

*) one to run the exploit, connect using netcat, read, then overwrite a simulated "key" file, like in the CTF

*) one to check the "key" file and overwrite it with the correct value if overwritten

These have been going now for some time and working quite nicely. Now, I just need to turn my attention to returning gracefully. I believe the appropriate course of action is to "mov 0x 0x4(%ebp)" and then call "ret" instead of calling "exit()". We'll see how that works out.

I'll let you know. I feel awful right now and am driving home from Skelletones, so coding has stopped. Between the fog and deer-hazards, blogging is all I can manage! Perhaps if I felt better ;)

@

echod bleeds... -by atlas

(One of these days I'm going to make atlas get his own blog, but probably not until I start posting more)

Program received signal SIGSEGV, Segmentation fault.
0xbfaedf4d in ?? ()


Finally, after weeks of teeth-gnashing I have been able to get echod to consistently bleed, yet some of the blood is my own.
(for those you not fortunate enough to understand it, this indicates that I have changed the instruction pointer to someplace in the stack where it doesn't belong... one or two steps from shell-access)

It's bleeding, not dead yet. I have to inject shellcode (in reverse for this vuln) before I can stick a fork in this baby.
I wish I could say "I finally got around to looking at it..." but I've been working on it ever since Def Con (many times only 1/2 hour at a time, which is awful). I have learned quite a bit, however, and have been intentionally taking my time, capitalizing on the opportunity to improve my skills (I've played and explored a bit. Big fun the "pay-for" guys might not get to enjoy as much). Still, I gotta get faster, even with the tough ones.

echod presents challenges, although much of my pain was self-inflicted. echod is multi-threaded, presenting oddities with both debugging and fuzzing. gdb would be piping along and suddenly it would inform me that it just thread-hopped and I was starting from a different location, working different logic. It became particularly difficult because I had my pseudo-fuzzer (it doesn't deserve to be called a real one) set in a loop most of the time... which I think somehow caused several threads to be pumping information into the binary, while I'm also attempting to debug and make sense out of the assembly. argggh! Aside from turning "0x0a" to "0x00" and splitting stings on "0x20", the string was pretty much straightforward, although the "reversing" functionality employed some logic I couldn't quite follow without stepping through it (and even then, it's up in the air).

That isn't to say that I didn't learn a great deal along the way.. You could say that I learned many things about reverse engineering, particularly threaded apps. Here are a few:

• Printing the dis/assembly is invaluable!


• Rather than avoiding "jump" calls to focus on the "meat", recognize that they are the structure. Capitalize on the opportunity to determine program flow. Draw the jumps with an arrow for each early in the reversing process


• Determine the "conditional statements" from the "jump" statements. Is it a "while (???) { }" or an "if (???){ } and what are the constraints? This helps determine where the "edges" of the program are


• "Ignore %reg, look around for meaning!" ie. Pay more attention to what memory location each register *represents*, instead of focusing on %eax specifically. Map this out on paper, being interested more in 0xffffffbe(%ebp) or 0x8(ebp) instead.


• Each sub has a finite number or variables (locals, parms, and heap)... know them. Label them if you can tell their purpose.


• For (%reg), look for %reg assignment BEFORE this line


• For %reg, look for %reg storage AFTER this line

So I sit down at a coffeeshop I don't frequently visit, because Skeletones (Coffee for the coming apocolypse!) is having a concert I'm too focused to enjoy. I end up sitting in 5 different spots throughout the night, making them hate the "bottomless mug" deal I chose, and being slightly distracted as the two employees mash right at the counter. I was expecting some wetware to come out but thankfully was wrong. After doing some Biblestudy (which is the real reason for my night out), I figure out that I left my reverse-dump hardcopy at work and they had all my scribblings and notes! SUCK BUTT! So, I tinkered and played. Probably the best thing, since I happened upon the "chink in the armor" by doing so. I continued having bad results until I changed approaches in fuzzing and reveng. more on that in a minute.

If this all seems a bit confusing, it's because I'm still somewhat unsure of what went wrong... I know that I was unable to produce consistent results when piping "perl -e" commands to netcat. I know I was able to produce some consistency with a total rewrite in perl. I also know that I've been rather cavalier with my fuzzing, which probably caused issues with consistency (not paying close attention to having multiple threads going at once, so long as I kept data pumping into my gdb/echod session for analysis. Again, ni puta idea!

This perl/bash combo was similar to what I used with poor results:

CX=1100; while true ; do CX=`expr $CX - 1`;echo $CX; perl -e "print(\"REV \" . \"\\x1\"x$CX);" | nc -v localhost 2000 ;done

I first started getting consistent results when I scrapped the command-line approach and used Perl's networking Socket interface to handle the network connectivity. Not as "slim" as using NetCat, but it works. And I was able to build the loop for fuzzing right into my perl-based sploit engine rather than the ugly bash code listed above. But consistency is key.

I have to take back all the evil wicked things I cursed about the author of echod. He may still be an evil bastard, but not nearly so much as I was giving him credit for. (sorry Visi)
Thanks to the nologin folks (thanks slow!) for helping me figure out the stack alignment oddities. Many thanks to Visigoth, Snit and the other kenshoto guys for the hours of wholesome fun ;D

I still have a few questions bouncing around:

* How do I get gdb to hold on to Display and Breakpoint settings between sessions (or perhaps simply preload them from a file at startup)?
* How do I get a service like echod to dump core? (a core dump is the contents of program memory at the time of a program fault. It allows a debugger to recreate the environment to better troubleshoot and correct issues)

Any comments can be sent to atlas@r4780y.com (thanks for the account, r4780y!)
@