dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
10190
share rss forum feed

psloss
Premium
join:2002-02-24
Lebanon, KS
reply to Steve

Re: Analysis of Backstealth technology

said by Steve:
I wanted to expand on a couple of points on this whole bit of technology.

First, "DLL Injection" is not new - it's been around for a while and has been used to acquire system-level permissions from processes that are "only" Administrators. pwdump2 is an example of a program that uses this technique (though perhaps not implemented the same way as this one).


Late to this thread, but just wanted to add my thanks for doing the legwork, Steve.

There are numerous CreateRemoteThread examples online now, but this is the first article that I saw that presented the code to do DLL injection. I remember running it way back on NT 3.1:

"Load Your 32-bit DLL into Another Process's Address Space Using INJLIB" by Jeffrey Richter, MSJ May 1994.

Thanks,

Philip Sloss


Stonedonkey
Premium
join:2001-05-15
Berkeley, CA
reply to Steve
It wouldn't surprise me if the creator of this program uses ZA or ZAP and didn't want to create a vulnerability against his or her own defenses.


R2
R Not
Premium,MVM
join:2000-09-18
Long Beach, CA
kudos:1

reply to IGGY
IGGY - I agree with your assessment -- I just don't know and I am therefore skeptical.

I was hoping there would be a source other than the program's author and other than ZoneLabs that could state conclusively that ZA is not vulnerable.

Let us assume that ZAP 3.0 is patched and fixed. There are a lot of users who use ZA (free) and ZAP 2.6 -- and it would be nice to test these as well. But since the program specifically does not try to test them, I have to wonder why. Just having ZoneLabs say that ZA is "safe" is simply not that satisfying of an answer...

[text was edited by author 2002-05-02 20:52:38]

IGGY
No Guru Just Here To Help
Premium,MVM
join:2001-03-30
Chatham, IL
I agree with your points. And it is nice to have double ( or even triple ) confirmation. Your point about ZoneAlarm ( free version ) is another good point to consider. If ZoneLabs is willing to provide more info. This may answer some of these questions more fully. I for 1. Am glad to see a "debate" on the subject. If just for the fact. That it increases the learning experience. For some of us.
--
*IGGYZ* *TeamZ*


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
reply to Steve
Wildcatboy has graciously given permission for a much more detailed discussion of this, so I can talk a bit more about just how this program is really working internally. There is zero chance that this pseudocode can be used by script kiddies, so there's no real harm in talking about it.

I've figured out the DLL injection, and though this has probably been covered before, this is the first time I've actually seen it done. I've not done this before myself.

The idea is that we have to get a bit of our own code in the remote process, but there is a bit of "helper data" that the injection code needs
code:
struct injection_data {
DWORD fpLoadLibrary; // address of the LoadLibrary function in KERNEL32
DWORD fpGetProcAddress; // address of the GetProcAddress function in KERNEL32
DWORD fpFreeLibrary; // address of the FreeLibrary function in KERNEL32
char dllpath][261]; // full path of the DLL to load (BACKDLL.DLL)
char entrypoint[523]; // name of entry point function in the DLL
};

....
 
struct injection_data InjData;
 
// find key symbols in KERNEL32
HANDLE hModule = LoadLibrary("KERNEL32");
InjData.fpLoadLibrary = GetProcAddress(hModule, "LoadLibraryA");
InjData.fpGetProcAddress = GetProcAddress(hModule, "GetProcAddress");
InjData.fpFreeLibrary = GetProcAddress(hModule, "FreeLibrary");
 
// assume BACKDLL is in same dir as this EXE, build path
char workbuf[256];
GetModuleFilename( NULL, workbuf, sizeof(workbuf));
strcpy( strrchr(workbuf, '\\') + 1, "backdll.dll");
strncpy( InjData.dllpath, workbuf, sizeof(InjData.dllpath));
 
// initialize the entry point
strcpy( InjData.entrypoint, "backdll.dll", sizeof(InjData.entrypoint));

OK, so now the "helper" data is built. What to do with it? Now we start talking to the remote process (how we actually got that process handle is for later).
code:
DWORD nSize = (size of injection fcn);
nSize += sizeof(InjData);
 
void *lpRemoteMemory = VirtualAllocEx(hProcess, 0, nSize, MEM_COMMIT, PAGE_READWRITE);
 
// copy our injection data and injection subroutine to the remote process (in two parts)
WriteProcessMemory( hProcess, lpRemoteMemory, &InjData, sizeof(InjData), &NumberOfBytesWritten);
WriteProcessMemory( hProcess, lpRemoteMemory + sizeof InjData, &injection_sub, sizeof(injsub));
 
// now execute our injection subroutine, which starts just past the helper data
void *startAddr = lpRemoteMemory + sizeof(InjData);
DWORD dwThreadID;
HANDLE hThread = CreateRemoteThread( hProcess, startAddr, &dwThreadID);

Now the remote thread launches our subroutine (which I've not picked apart yet), and this supposedly gets it all going. It uses the helper data to load the DLL into the process space of the firewall (actually, "into the target process of any kind").

While this is going on, the main .EXE is waiting for the remote thread to exit, at which time it knows that it's finished.

I've also figured out the injection subroutine, and it's really very simple. I've taken some liberties with the code and mostly ignored the error checking to make it easier to follow.
code:
void injsub(struct injection_data *idata)
{
DWORD rc = -1; // presume failure
 
HINSTANCE hLibrary = idata->fpLoadLibrary(idata->dllpath);
 
void (*pEntry)() = idata->fpGetProcAddress(hLibrary, idata->entrypoint);
 
rc = (*pEntry)(idata + 1); // "params" are just after helper data
 
idata->fpFreeLibrary(hLibrary);
 
return rc;
}

This is just a very simple trampoline function that simply loads the requested DLL and calls its entry point. This function works for any kind of injection requested: it's generic. You have to have (somehow) acquired the process handle, and you do have to have permission, but it's generic.

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5

Got source?

I have now fully reverse engineered BACKSTEALTH.EXE into documented C++ code, and it works as far as I can tell. It attempts to locate a firewall program to infect, but as I don't run any of these firewalls at home (yet), it chooses to hijack itself via the same remote mechanism.

Instructions for compiling the code are in the comments at the top of the source, and this does require backdll.dll to be in the same directory as the executable.

WARNING - I have not reverse engineered this DLL (though I have perused it), so you're taking a chance to run it. I have been without problems.

The next step is to install ZoneAlarm on some system and start to play with it. The first thing is to find how they do their window names so we can locate the process, and then try the same injection techniques.

But it seems to me that even if ZA somehow catches outbound stuff, if we are able to write to their memory space, they will have a very hard time preventing a malicious but clever admin-priv'd program from taking over.

Feedback welcome.

ZIP file with bs.cpp
ZIP file with backweb.dll

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


Time Out$
Premium
join:2002-04-28
North Myrtle Beach, SC
if we are able to write to their memory space,

With ZA or ZAP..I do not think you will be able to do that.

aRCeNiTe

join:2002-01-07
Sicklerville, NJ
reply to Steve

Re: Analysis of Backstealth technology

To get around this, wouldn't firewall creators be able to make the titles of their firewalls random, like... for kerio.. Instead of having

KerioPersonalFireWallMainWindow, couldn't they just have things like

"djasfjkadsf" or something... sounds unprofessional, but it's a way to get around this, and make it random... everytime it loads, it changes... Just an idea


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
said by aRCeNiTe:
To get around this, wouldn't firewall creators be able to make the titles of their firewalls random, like... for kerio.. Instead of having
Unlikely this would work for a determined trojan, because there are other ways of finding processes besides via window names. There is an API for enumerating processes based on the exe name, and that's going to be harder to hide.

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


Time Out$
Premium
join:2002-04-28
North Myrtle Beach, SC
Some of you may not see the irony of this post and WCB might not let it stand. But I have visions one day of a Radlite/Lavasoft battle going on "inside" your system with firewall designers going after something like this "utility" as it tries to defeat the very purpose of their product. Yes, I know, that has been the "assumed" job of all the AV/AT, but now we have a directed attack.

I am sadden to even see this Backstealh thingie even called a technology. The author of it has an email address. Has anyone even contacted him .

I am posting here a link to another "product" that is out there. This firewall is "proactive" outside your system using it could end the users connection priveleges on the Internet and much more.

But the "designer" of that product could have just as easily have designed it to be "proactive" in your system
to take out something like this backstealth utility..IF it ended up on your system.

I am surprised that it is now being further developed in a public forum.

I guess that is my analysis. I did not post this to hurt anyone's feeling , step on anyone's toes, or stop anyone's right to free speech or expression. But if you read this link ...you to may share my concern.

Yes, a firewall designer could make some small changes, or YOU could so this or other "utilites" would have a "hard time" defeating their purpose...but it will never stop there...it never does!

Firewall that fights BACK!
»www.security-pro.co.uk/yabb/YaBB···20276223


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
said by Time Out:
I am sadden to even see this Backstealh thingie even called a technology. The author of it has an email address. Has anyone even contacted him .
Yes: the author has been notified of the discussion found here at DSL Reports.

The DLL Injection technology used by Backstealth has been around long enough that there are plenty of people with the skills to have done this, so it's not like our Italian friend has given away the secret of life or anything.

And as has been said many times: "not talking about it" doesn't mean that it's not being done in private. But it does mean that we don't know about it.

I posted the source code with the explicit permission of WCB because we knew that this was not useful to a script kiddie: there is no way to use backstealth to do anything bad without really understanding what it does and writing in your own malware. It's proof of concept only (and a good one at that).

There are efforts being made to defeat the firewalls on a more active basis, but that is not being carried on in public.

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


Time Out$
Premium
join:2002-04-28
North Myrtle Beach, SC
Thanks Steve, you are a gentleman and I thank you for your work.


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
reply to Steve

Re: Got source?

said by Steve:
WARNING - I have not reverse engineered this DLL (though I have perused it), so you're taking a chance to run it.
I finished reversing the backdll.dll module this morning, and it indeed does exactly what it claims to do: it makes a single HTTP connection to a web server and fetches a file to the hard drive. No shenanigans of any kind.

Those caring to play with this can do so in safety
... to the extent that you take my word for it to run unknown code, which you shouldn't

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


Zupe
Premium,MVM
join:2001-11-29
New York, NY
reply to Steve

Re: Analysis of Backstealth technology

Steve,

First let me say thank you for all of your hard work on this, it's greatly appreciated.

I have a very simple question in connection to this and the earlier Kerio rule Gwion had proposed:

The actual http connection in the backdll.dll file, is it coded as a request to a domain name, i.e. www.xyz.com, or as an ip address? The reason this would make a difference is that it appears that the block rule Gwion suggested is actually blocking a call to DNS to resolve a domain name which causes it to fail, rather than blocking an actual http connection. If this is true, it would appear that the rule would be ineffective if an IP address had instead been used. I was just hoping to confirm this.

Thanks again.
--
Pinky: I think so Brain, but shouldn't the bat boy be wearing a cape?


Time Out$
Premium
join:2002-04-28
North Myrtle Beach, SC
reply to Steve

Re: Got source?

"Just in Time" Steve, Look what Sygate just released yesterday..now user can go check out your proof of concept on this one.

»Sygate Personal Firwall NEW
Sygate Personal Firewall PRO 5.0 build 1116 preview is available in the preview forum. This build fixes some issues with Windows XP as well as Backstealth test.

• Resolution for backstealth type attack on the firewall process.


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
reply to Zupe

Re: Analysis of Backstealth technology

said by Zupe:
The actual http connection in the backdll.dll file, is it coded as a request to a domain name, i.e. www.xyz.com, or as an ip address?
It's a request done by name: "www.pc-facile.com", and this does in fact use DNS for the lookup. Seems to me that coding an IP address (for testing) would be a fair way to give it a try.

I'm getting up the nerve to dive into the personal firewall world here at home to test this, but figure I'll be rebooting all day :-(

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
reply to Time Out$

Re: Got source?

said by Time Out:
Sygate Personal Firewall PRO 5.0 build 1116 preview
...
• Resolution for backstealth type attack on the firewall process.
On NT4 it seems to be effective at blocking Backstealth attacks: for me: the CreateRemoteThread call is failing with err#5 (Access Denied).

I'm investigating...

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


Time Out$
Premium
join:2002-04-28
North Myrtle Beach, SC
"I'm investigating..."

Well that is going to be an important one since Sygate has tied the knot with ATTBI and many customers will want to know.

»Sygate Firewall vs. ZoneAlarm - Ding Ding Ding

Sygate Firewall vs. ZoneAlarm - Ding Ding Ding
Well I saw the news here that Sygate is offered free to ATTBI customers and we also get 20% off the pro version. Any reason I'd want to uninstall zonealarm and go with Sygate?

John


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
said by Time Out:
Well that is going to be an important one since Sygate has tied the knot with ATTBI and many customers will want to know.
I believe that ultimately, software firewalls are never going to completely be able to win this war if users insist on running programs they should not trust. If the bad program is able to read and write memory inside the firewall process space - as I am able to do now with even the latest Sygate build - it's just a matter of time before somebody does the Really Hard Work to modify internal firewall tables. If Sygate cannot trust its own address space, it's powerless to guarantee protection. They can surely make it difficult, but in a world with 6B people, all you need is one really determined one.

I do have a handle on an approach that should be able to beat Sygate's latest approach, though it's gonna be a lot of work. We'll see.

But I must say that I'm delighted with Sygate. I've never really used a software firewall before, and it's just been a joy to play with.

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net

KING53

join:2002-01-31
Norcross, GA
reply to Steve

Re: Analysis of Backstealth technology

Lurking...liking what I'm seeing. Some proactive legwork by users...very impressive Steve.

BTW, please someone test ZA/ZAP...this wouldn't be the first time that they stretch the truth on something like this.

Steve, I'm also impressed with Sygate dev quick response and the program in general, which is why I use it and volunteer to help if and when I can.

All of you be safe and be blessed.
--
Soy el reyModerator@»www.morelerbe.com/cgi-bin/ubb-cg···tebb.cgi »yahoo- sucks.hypermart.net/cg...s/ikonboard.cgihttp://forums.sygatetech.com


Time Out$
Premium
join:2002-04-28
North Myrtle Beach, SC
Hey King,
I you have some ideas in the treads here at the DSLR Security Forum.. dig in. Welcome to the forum..do not be a stranger.

Have a good weekend,
John


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
reply to KING53
said by KING:
BTW, please someone test ZA/ZAP...this wouldn't be the first time that they stretch the truth on something like this.
I'll be doing this tonight. Since I have the complete source code to Backstealth, it should be straightforward to give it a go.

Will report later (at a customer now).

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net

IGGY
No Guru Just Here To Help
Premium,MVM
join:2001-03-30
Chatham, IL

reply to IGGY
Further reply from Zonelabs = "Backstealth is not a complicated program and there actually isn't much else I can say about it. Sorry! We block it because we block untrusted communication with the NIC." And I have tested this on ZAP 3. And I clearly posted my results in another thread. If for some reason. The way I tested isn't up to standard. Or someone has other ways to test. I'd be more than happy to do so. But from my testing. The software engineers at ZoneLabs are correct. This proof of concept is a dud. I've tested this on ZAP 3. I've not tested this on ZA Free. But have sent an email reply to Corey. Asking for confirmation. That all current versions of ZoneLabs products are immune to this.
--
*IGGYZ*
*TeamZ*

[text was edited by author 2002-05-04 01:41:27]


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
said by IGGY:
Further reply from Zonelabs = "Backstealth is not a complicated program and there actually isn't much else I can say about it. Sorry! We block it because we block untrusted communication with the NIC."
It's not clear that ZoneAlarm is entirely immune from this (still researching), but I'll ask this question of the group: of most of you saw a popup from ZoneAlarm saying that the firewall itself wanted to talk to the internet, would you allow it?

Steve yes, this is a hint
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


ITGeekMonkey
Orbis Hirsutis
Premium
join:2001-11-06
Wylie, TX
reply to Steve
I'm covering all my bases here.
Sygate just released a new build for testing that is supposed to combat this type of out bound attack. »Sygate 5.0 Pro Build 1116 Released for Testing!
Enjoy. And sorry for the redundancy
--
Landscapes West | Proxomitron Web Filter

number_one

join:2001-11-30
Midlothian, VA
reply to Steve
said by OzarkMan:
. . . .There in lies the key for some users....in fact this has been mentioned many times. The day has\will come when NO process SHOULD be Trusted....unless the user [explicitly] approves the action at THAT particular moment in time.
Unfortunately, this above statement pretty much sums it up. The key issue, as several other people have raised, is not about protecting specific firewall processes but rather about the nature of trust within an OS.

So what does this have to do with firewalls? Simply put, you the user have given control of inbound and outbound traffic to the firewall application through means of a firewall trusted application list. This means that ANY single one of the processes that these trusted applications run in can be hijacked in the same way that the Backstealth test program is hijacking one of the firewall application processes. For example, as someone else mentioned, one of your Iexplore.exe processes could be hijacked, and then whatever internet traffic is instigated by the hijacking application will be subjected to the same inbound/outbound rules as the Iexplore.exe process (which most likely would let anything in or out).

The trick of blocking the inbound/outbound traffic from the firewall process will obviously not work with other processes that have valid needs for internet traffic. So this is the question: How does one guarantee that a particular process has not been hijacked by an unauthorized application?

The root of the problem lies in the fact that all applications executed are automatically trusted at the current user's privilege level. Yes, it is true that using non-admin privileges for your normal account will deter this kind of problem, though I am not sure that processes running under the current user's privileges (even non-admin) will be safe from hijacking. And even so, there are times when using an admin account may be necessary, so a more total solution is needed other than just telling people to never use admin accounts.

What there needs to be is a separate list of trusted applications (with MD5 or comparable signatures, of course) that a user can configure so that applications not on the list cannot mess with other processes regardless of the privilege level under which they are being run. This *should* eliminate this type of hijacking problem unless the user is stupid enough to actually add a trojan to the trusted application list. And, of course, the interface for configuring this list would have to be highly guarded so that unauthorized applications couldn't mess with it.

Anyway, that's my crack at it. There may be other ways to defeat this type of attack, though I don't see any ways around either than locking down processes completely (no inter-process execution) or monitoring for unauthorized inter-process activity in a way similar to what I have described above.

IGGY
No Guru Just Here To Help
Premium,MVM
join:2001-03-30
Chatham, IL

reply to Steve
Considering I have mine set for manual update. I would definitely not allow the firewall to connect. And would do further investigation as to why it wants to connect. As you & others have stated. The whole point of this. Is to be aware of what is on your machine. And what you have downloaded. If you don't run this exe. There isn't a chance of your pc being compromised. But couldn't someone create an automated exploit? Similar to the behavior of say Klez? I'm thinking out loud again. My point may not be valid. But it seems. That we're seeing newer exploits. Where the user doesn't have to do much. For the exploit to in fact run & cause harm.
--
*IGGYZ*
*TeamZ*

[text was edited by author 2002-05-04 01:50:50]


Steve
I know your IP address
Consultant
join:2001-03-10
Foothill Ranch, CA
kudos:5
reply to Zupe
said by Zupe:
The actual http connection in the backdll.dll file, is it coded as a request to a domain name, i.e. www.xyz.com, or as an ip address?
This particular demonstration program uses a hostname that requires DNS to resolve, but I've given Gwion a version of my backstealth toolkit that permits testing with just an IP address: it remains to be seen how the various firewalls will handle this.

Steve
--
Stephen J. Friedl • Security Consultant • Tustin, California USA • »www.unixwiz.net


CrazyM
Premium
join:2001-05-16
BC Canada
reply to Steve
said by Steve:
It's not clear that ZoneAlarm is entirely immune from this (still researching), but I'll ask this question of the group: of most of you saw a popup from ZoneAlarm saying that the firewall itself wanted to talk to the internet, would you allow it?

For those firewalls that use the same .exe to perform any live update function (something that would be considered a normal function of that .exe), it would definitely add to the likelihood of someone allowing it. Either by already having an allow rule, or permitting it that one time if they assumed it was just checking for updates.

CrazyM

KING53

join:2002-01-31
Norcross, GA
A few things here...

1. ZA is coming up as immune because it isn't in the code to look for it, so of course the exploit won't work.

That said....Iggy or anyone else believing ZA immune(ZAP too) are you testing with a modified backstealth by Steve which will look for ZA/ZAP? If not then you are just getting false results. If the code doesn't know ZA exists (which is really why it is passing) then of course it won't penetrate ZA. When testing your security programs you have to make sure your control environment is proper so as not to just get false results which will create false sense of security which is worse than running no security programs at all IMHO.

Why ZA/ZAP is not in the code still puzzles me. Look how quickly Steve picked this simple code apart. To me, the author intentionally left certain firewalls out. So what if ZA/ZAP is immune? What is the harm in putting it in the code anyway so everyone can see it is immune for themselves?

2. In response to how this thing can be handled because ANY program in the OS can be targeted by this exploit....

I like the way Sygate works. Many down DLL authentication and the general way Sygate operates. Guess it is just too thorough and too much information for some people. DLL authentication isn't perfected yet, but AFAIK if Backstealth didn't target smc.exe then it would be stopped by Sygate still. Sygate uses MD5 and every other type of security measure to insure program and connection integrity. Hopefully they can perfect these techniques to be extremely hard to exploit.

3. So Steve, would you make a Backstealth and put IE, ZA, ZAP in it? This would not only test ZA/ZAP but also lead into my next point and teach people a lesson....

4. NEVER ALLOW ANY PROGRAM, NEVER TRUST ANY PROGRAM! I'm sure most follow this already, but I know much more are lazy so they just allow IE or their email client or whatever full access. If your firewall can't be tightened down to only allow a program client or server access, ICMP or not, restrict it to IP's, restrict ports and protocols, then it is lacking in security. Just allowing or blocking programs is obsolete...we have to be able to control what they do once they are out to the net and back in to our systems now. This should be a standard for ALL firewalls.

5. Auto updates = security hole, sad but true. Manual is the way to go. Automate nothing, if you are compromised and are otherwise improperly secured inbound and outbound then something can ride your automated updates in and out. This goes again to restricting programs to only the ports, protocols, and IP they need.

It is unreasonable to restrict your browser by IP's, putting them in one at a time, so make sure you never allow them full access since EVERYONE has a browser 90% using IE which is the most insecure program on earth, then the bad guys have an easy time just by targeting M$ products. Last point...

6. System security can be strengthened just by not using M$ products. Sure you are stuck with the OS, tweak it to make it work for you and not the other way around.
- Get rid of OE/OL M$ office and M$ anything else, there are alternatives...most of them free
- Don't use IE! You would be surprised how many exploits are IE specific, so what do I do? IE on my system can't act as server or client, and when I do use it, I like the sport and dport with the only IP I go to windowsupdate since Opera can't do that thanks to RadioactiveX.

These are just some of my opinions...sorry for being so lengthy just a lot to comment on around here. Hopefully some of this babble makes sense to someone...
--
Soy el reyModerator@»www.morelerbe.com/cgi-bin/ubb-cg···tebb.cgi »yahoo- sucks.hypermart.net/cg...s/ikonboard.cgihttp://forums.sygatetech.com