The Zend Encoder Fiasco Part Deux - The Personal Attack

January 27, 2006

This story just keeps getting better. Some of you may recall I posted a story a few weeks back when to my SHOCK I found that websites were offering to decoded Zend Encoded files for $5. There were literally 10+ sites I found in a simple search. I emailed all my Zend contacts right away to find out what the status of this is. No reply. I had 2 high profile PHP developers email the CTO and VP of Tech at Zend... no reply. Forced with that issue and the fact my company's source code was now in the wild as a distributed product I went to the zend forums and made a post here: which asked for an official statement on the issue. NOTHING. In fact my message was censored and the text of the message changed.

Here comes the good part... Zend's Chief Marketing Officer Mark de Visser had the balls to say that I was just as bad as the people who were able to reverse engineer the zend encoding by showing people the websites. Mr de Visser, your company's ignorance to this issue and the fact you want users to pay $1400 to UPGRADE TO A MORE SECURE VERSION of your product is along the lines of Microsoft thinking. "If we ignore it, then it goes away".

I'm just as bad as them for posting the links? Mr de Visser how the hell do you think I found out about these sites? hmmm from your own website forums!
Zend Forums Link 1
Zend Forums Link 2
Zend Forums Link 3

how about a simple google search for "decoding zend encoded files"?
Google Link 1

Those posts were from August! Perhaps if you read your own forums you could have found this out sooner. My company stands to lose millions of dollars from this situation and I can't believe how irresponsible Zend is acting in this matter. So thank you Mr Visser for lumping me in with criminal behavior because I want answers to something you're trying to sweep under the covers long enough for people to pay $1400 for your new "more secure" version.

So how did I find out about all of this? Well apparently they were trying to buy a friend of mine off, while going on a tirade about me at the same time. Basically.. "we'll upgrade you for free if you leave us alone about this". Careful what you say next time my friend. Do I hate Zend? No. I have a good relationship with alot of folks at Zend and really support the work they do and their education programs. It just makes me sad that this situtation has come to this.

the end.


RSS feed for comments on this post.

  1. Mike says:
    January 27, 2006 @ 11:09 — Reply

    Unexpectedly disapointing behavior from a company like Zend. Not just the personal attack but the way this entire issue is being handled. Seems like a good time to research the alternative encoding options on the market.

  2. Anonymous says:
    January 27, 2006 @ 12:57 — Reply

    come on now... we all know that encrpyption technology can and does get broken; it's part and parcel of life now. i use zends encoder too and now i'm to lose as well but just take it easy huh? relax... do the upgrade like everyone else and just accept it; reckon you'll save yourself money anyways due to the better encrpytion the upgrade offers - well, until that gets broken, that is :p

  3. Tim says:
    January 27, 2006 @ 13:00 — Reply

    "i'm to lose as well but just take it easy huh? relax... do the upgrade like everyone else and just accept it; " dude thats the dumbest comment I've ever seen

  4. Jacques Marneweck says:
    January 27, 2006 @ 13:12 — Reply

    At least you got a comment from somebody at Zend. I've still had no reponse from Andi or Zeev regarding my mails to them previously. At least they still think having their heads burried in sand like ostriches is going to be productive :(

  5. Andi Gutmans says:
    January 27, 2006 @ 15:41 — Reply

    Jim, Since this issue first appeared, we have allocated a lot of resources to come up with better technology, mainly based on obfuscation, in order to improve the Zend SafeGuard. During this process, the main problem is how not to further expose your customers while diligently working on a solution. Posting a notice too early can do more harm than good. This was done with the customer's interested in mind. In any case, Zend has informed all of its Zend SafeGuard customers of the issue, and we are working with all customers to find a satisfactory way to resolve the situation. No doubt, that the new technology that we will shortly be offering will very much improve the protection. That said, all languages including C and Java can be reverse-engineered to some extent, so even after obfuscating part of the source code, with unlimited efforts you will never be 100% safe in any language that I know. I am truly sorry that you feel you haven't received the level of service and response from Zend as you expected. I can assure you this has been top priority for us and we are doing our very best to address this quickly and in a responsible manner. Best, Andi

  6. Mark de Visser says:
    January 27, 2006 @ 16:13 — Reply

    Let me add to Andi's response: We have sent out a message to each customer to alert them to the situation and offer a solution. We are currently calling out to all, and have offered a free upgrade to the new product in all cases. It is regrettable that this is seen as a "buy off". We'll make clear that this free upgrade is available to all previous buyers of Encoder, Safeguard Suite and/or Small Business Program (upon availability of Safeguard 4.0). I assume that the reference to 'criminal behavior' is because I expressed regret that the issue had not been raised with us directly before it was posted on our forum (although I certainly did not refer to that as criminal). I was not aware of the other efforts you had already taken to alert us - if you have I fully support the fact that you took the logical next step - I'll find out why we did not see these messages and will make sure clear and transparent communication lines are available to our customers. - Mark de Visser

  7. Jeremy Johnstone says:
    January 27, 2006 @ 16:47 — Reply

    Sure, offering a free upgrade is grand and all, but nowhere (even when talking to Mark on the phone directly) did I get any indication of acceptance of responsibility for this matter. You seem to claim this was inevitable, but yet you never did ANYTHING to stop it until it was already a problem. As much involvement as your company had in developing the Zend Engine, one would think you would have known well in advance that Zend Encoder was not the least bit secure in any fashion. Code obfuscation should have been in from the very first release. Of course no language is ever 100% "secure" from decoding, but atleast you could have put even the slightest effort into making it more difficult for those trying to get access to the original source. From my understanding of the decoders which have sprung up, even the original code comments are available upon decoding. Basically that shows you had piss poor concern for the customers who were buying your product and frankly took them for a ride. I'm more than sure I can collect the necessary number of companies who have been wronged by your (criminal?) negligance to file a class action lawsuit against Zend.

  8. Jim Plush says:
    January 27, 2006 @ 16:48 — Reply

    Andi, Mark I appreciate you addressing this issue. I don't want to drag this out publically any longer but just want to add for the record. 1. My company received no such notice and in fact the only notice I'm aware of went out this week, when this problem has been around for half a year. 2. When sales are involved Zend is quick to respond. When emailing at least 4 Zend Staff members (including yourself Andi) I received no word back on this. 3. This was all available publically on your website. Imagine my shock to find it for the first time there.

  9. Mark de Visser says:
    January 27, 2006 @ 18:18 — Reply

    Jim, in our records you are connected to two firms, both of which do not have a record of owning Encoder. So you did not receive the notice. Please contact us directly to resolve that. - Mark

  10. Lewis says:
    January 31, 2006 @ 07:49 — Reply

    There have been sites decoding Zend for ages. Like all encryption methods, it's not impossible to break, despite what they advertise. The thing is, if people are that desperate to get your script that they'll deal with crooks and break the law. Do you really want them as your customers? If they go to that much trouble, they're obviously not going to pay for your script.

  11. Lewis says:
    January 31, 2006 @ 07:51 — Reply

    "which asked for an official statement on the issue." - Look at the first result on your Google search...

  12. Jim Plush says:
    January 31, 2006 @ 08:42 — Reply

    Lewis, perhaps you didn't notice the date of that first search result. It was only a few days before I posted this. It wasn't added until I posted in the forums.

  13. Jim Plush says:
    January 31, 2006 @ 08:45 — Reply

    Lewis, regarding the customers decoding files... thats not what I worry about. Competitors decoding scripts and using it to post exploits or other issues in the codebase is what worries me. For example we have 300,000 lines of code with probably 100,000 written by someone who barely knew php 4 years ago let alone proper security practices, we're still going through cleaning up his messes 4 years later.

  14. ManiKanth Athyala says:
    March 11, 2006 @ 19:31 — Reply

    Is there any encoder presently available on which we can rely on?

  15. Jim says:
    March 12, 2006 @ 11:07 — Reply

    ManiKanth, I would look to IONCUBE's products at this time.

  16. nick carter says:
    March 31, 2006 @ 17:50 — Reply

    php recovery put on line to 1 user only recovery opcode encoded gaspra it work really check here

  17. Anonymous says:
    April 16, 2006 @ 16:55 — Reply

    i use php shield it work on 90% of servers without any pphp.ini modification, loaders are dinamically loaded and it costs only 99$ and its full bytecode protection. zend are crazy $995 annual

  18. Author20 says:
    April 17, 2006 @ 18:48 — Reply

    Why are both Zend and IonCube not using white hat firms to test the weaknesses? Why are they waiting until their customers get attacked? It is like the open source world watches microsoft lose billions because they neglect security, and they laugh at microsoft, while their own technology is being hacked and compromised. I think if the same mentality were involved with transportation, or a more serious industry -- millions would be dead. Software developers - open source and commercial -- are lax. This is a disgrace. Imagine, the inventors of PHP being caught with their pants down -- and not even having the integrity to admit it. Do we now shift back to ASP? Wonder if anybody is investigating the companies causing this? It took Microsoft about 15 years to figure out how dangerous a teenager could be, then they started offering rewards.

  19. ionCube says:
    April 18, 2006 @ 05:09 — Reply

    It was surprising to see how Zend chose to react to these problems, but companies have different ways of handling problems. Some are open and put their resources into dealing with the issues head on as a proirity, and this is the ionCube way, and others may take a different path. It should be noted though that one or two unscrupulous and morally delinquent Chinese having produced a decompiler for PHP, using reverse engineering techniques and making binary level patches of security tools in order to change their behaviour is not indicative of any inherent weakness in these tools. Decompling Java bytecode back to Java is easily done, decompiling machine code back to C is (less easily) done, and PHP is no different. Patching programs is standard for hackers to do, and there's nothing that can be done about that without more support at the processor level. PHP being OpenSource is also the biggest problem in itself, and adding security to something that is by design inherently insecure is a challenge, but there are things that can be done. The most crucial thing is a) use a compiled code solution, and b) use one with a closed source executor. Prior to a decompiler existing, it was enough to satisfy point a), but now it is essential for the second point too. Both Zend and ionCube use closed source executors, but AFAIK, all other compiled code tools currently rely on the OpenSource executor, (this is why the ionCube Loaders and Zend Optimiser are relatively large btw. copmared to, say, a SourceGuardian Loader). With the PHP being OpenSource as we said, using the regular executor is a major flaw as the bytecodes, that must also be standard ones, are easily obtainable. Using a closed source executor not only keeps opcodes away from the OpenSource engine, but provides opportunities to actually do things differently in the closed source execution engine. ionCube has always had a closed source executor, and the possibilities are exploited even further and to good effect in 6.5 Preventing hackers analysing how programs work and patching binaries to change behaviour cannot currently be stopped, and indeed, the same goes on at the hardware level with the likes of logic analysers, oscilloscopes and a soldering iron. However, analysis can be made as hard and as time consuming as possible without imposing too many compromises and constraints on the end user, and whilst there's a conflict between maximising security and feasibility of solution, a good balance can be found. As things stand, using the full security features such as obfuscation of ionCube 6.5 gives the best possible compiled code protection for PHP, but now that PHP is on the radar with the hackers, equally sure is that hackers will be trying to reverse engineer any security system. As always, we'll be on the case however!

  20. ionCube says:
    April 18, 2006 @ 05:53 — Reply

    Something else that one should note is that the compiled code solutions have historically proven to be highly effective, and they continue to be. It's taken 3 years or so before any successful reverse engineering of the better compiled code solutions was made, and we know from reading posts here and there that this isn't for the want of people trying. A year or two ago, a Russian PHP group site even posted a competition inviting their members to try and attack our solution, and perhaps others too. They kindly let us know about this, and the upshot was that those who tried got nowhere. In the previous post I mentioned that there is a compromise that has to be made between security and feasibility of solution, and this is very real where PHP is concerned. An approach that would offer some significant advantages, not just where code protection is concerned, would be for us to close source PHP, make some improvements and changes to how PHP and the engine in particular are implemented, and then to release a closed source version that was required to run encoded files. However, despite the much better security, particularly for runtime state, that would be offered, this would be a total non-starter for most end users and entirely infeasible. Another idea would be to change some of the encoding techniques every so often, keeping the hackers constantly working to keep up, and requiring new Loaders to process files encoded by newer algorithms. This sounds great in theory, but would again be totally unworkable for most cases. The problem with this approach is in particular for the shared hosts, and the need to deploy encoded files to target systems that may have older Loaders because not all hosts update as soon as they could. The latest release is a perfect example of this, as despite the increased security and clear benefits of the latest generation of ionCube Encoder, some prefer to use the older Encoder so as to avoid end users possibly having to also update their Loader. If our solution did not have a feature whereby Loaders can often be installed from a users own area, allowing Loader updates to be made as easily as updating a PHP script, more users may be resistant to such an update. So a balance has to be found, with offering maximum possible security clearly at the top of the list, but keeping in mind issues such as performance, end user (in)convenience and practicality of solution, as well as maintainability and product quality because making any major changes to a product inevitably increases the probability of more bugs and the length of the testing phase, which in turn increases the rollout time, and with these quite possibly having a negative impact for end users in their own right.

  21. G. Howard says:
    April 18, 2006 @ 14:15 — Reply

    Excellent points, IonCube. I am afraid we must follow your recommendations. PHP is not secure. C and Java must be used to protect critical code. Sometimes it isn't commercial versus open source. It is really a question of security, integrity, intellectual property rights and privacy. So, commies -- please stay out of this discussion. It isn't that anybody expected PHP to withstand the inevitable attack of rogues from Asia. But couldn't there be more pro-active testing so that the code was much more expensive to bust? If you are far enough ahead of the hackers, it is simply too expensive for them to try. It seems they had a long time, and the folks at Zend have been on a 2 year honeymoon. This event is probably a good thing, since it gives all PHP users enough of a reality check to make us refrain from designing critical applications 100% in PHP. We're going to have to code key routines in C or java. I still believe that if the software industry were worth it's revenue -- it would go after these folks like terrorists. They are. Hackers, crackers and the lot of them. Let's face it -- they have -- in many respects -- shut down the Internet, slowed down programing and severely impacted the tech economy. One thing I would like to know -- if the Chinese and Korean governments were educated on how this will hurt their economies -- wouldn't they arrest these folks like they arrest Christians and democrocy advocates? PHP is very important to this so-called global economy. Obviously Zend is still learning how important PHP is. Even the hackers don't seem to have much forsight. If they trash PHP enough, it will be universally abandoned. Hmmm. Microsoft would love that. Perhaps we need to start erecting firewalls. Certain countries do not deserve to be admitted to the Internet. Maybe it is time to start talking about bans, sanctions and reprisals against hacker states. Just talking about bans will send a cold chill up the Yangtze, perhaps cold enough to get the thug leaders to put an end to a culture hell-bent on stealing all the intellectual property on earth.

  22. ionCube says:
    April 18, 2006 @ 18:23 — Reply

    Unfortunately, where there's software there are hackers, but it's not all doom and gloom with PHP, far from it in fact. Even if hackers make any progress against the latest challenges in the encoding tools, this doesn't render the tools useless and make it pointless to encode PHP. Whilst not recommended for everyone, some ionCube customers actually provide their main products in source form, just encoding their evaluations so as not to be giving away their code to everyone themselves, and removing the easy opportunity to cheat and not purchase was enough to ensure their longevity and success. That there are now people trying to reverse engineer PHP based products was an almost inevitable step in the timeline of PHP. Coding in C or C++ is going to make it harder to reverse engineer, but has some major downsides compared to PHP or Java, and Java has historically been more decompilable to source than PHP, e.g. With regards to C, here are couple of links that refer to decompilation. The first relates to the Morris internet worm from the late 80's. The section on the Crackdown describes how some teams decompiled the worm back to C source, and even started poking fun at the code and supplying bug fixes for it :) This is more recent, and relates the Sony DRM Rootkit trouble from the end of last year, and how First4Internet were found to have used GPL code in their product. It's fair to say though that decompiling machine code back to C or C++ is very time consuming and substantially harder than doing so for systems such as PHP or Java, but it's not impossible, and if patching binaries to change their behaviour is all that the hackers are going for, well that happens all the time. People such as Jon "so sue me" Johansen even proudly advertise their DRM reverse engineering exploits on their CV As objectionable as it is that people should seek to profit from charging money to try and hack peoples code, unless you are giving away your own code by not encoding evaluations, for example, people will only get stolen code if they go looking for it. The types that actively go looking for hacked products tend not to have the means nor inclination to pay for software in the first place so don't represent a lost sale or even necessarily an end user, and those that are serious about their business realise the folly and potential business risks from using hacked and unsupported code. Lastly, there are other reasons for encoding PHP such as protecting hackers from editing or observing website code, particularly on shared servers where it's not uncommon to be able to browse files from other peoples accounts, or even by companies to protect their code from their own employees making uncontrolled changes to code. Irritating though it is to see hackers attacking PHP, with the ever growing popularity of PHP and associated infrastructure, I think that the outlook and potental for PHP developers to introduce successful products or plugin components has never been greater.

  23. PMan says:
    May 16, 2006 @ 09:48 — Reply

    So here can i find this decoder?

  24. microsoft says:
    June 26, 2006 @ 06:36 — Reply

    Hello ionCube suckers "Unfortunately, where there's software there are hackers" Unfortunately, where there's software there is big $$ companies that make even more $$ using technological lockdown. Your business is build on top of php, php was started by hackers for developer as open source. If you are not happy why don't you shut up and leave the php market that was sane before close source crapware arrived. Maybe you should work with microsoft to secure .NET, it's a sane closed source business out there.

  25. PHP developer says:
    June 27, 2006 @ 05:39 — Reply

    Hello "microsoft". PHP is great, but one of the problems is that it is open source and scripts are unprotected. Sure this is fine for tinkering and developing code locally, but often it is a problem. * Say we want to develop a PHP application that has to be commercial because we need to make money to survive, pay the bills and keep the product alive, and this is our only source of income as we don't want to work for some other software company. If we can host our evals then maybe we do not need to protect the code, but if we want to give out eval copies then even if we sell the source code, these evals must be protected. * If we run an ecommerce website on a shared host then because many shared hosts have security loopholes we may benefit from protecting code. * If we start a web development or custom script company then we may want to protect scripts that we develop. When PHP was less evolved, and when Java and ASP were more popular, fewer people developed PHP applications that needed protecting. Now that PHP is a far more feasible technology for serious development than it was a few years ago, and decent IDE's and frameworks are emerging, protection systems are essential to support serious development and keep PHP as a serious technology.

  26. Anonymous says:
    July 7, 2006 @ 14:28 — Reply


  27. Kaveh says:
    August 18, 2006 @ 03:41 — Reply

    try other protections for your php files , because (sorry to say this) zend has got a very cheap algorithm and can be decoded very fast as we seen recently. there some outside that seems to be fine like ea one , phpshield , but always have it in mind , those could be cracked easy too because some decoded data should be in the memory and an attacker can easily read the memory but this offers higher level of security and you just can't crack the php file with 5$, you should have a good access to the box you should know how to deal with the memory and these are not the things that many scrept kiddies around would able to be do. that was my 2 cent.

  28. Anonymous says:
    December 26, 2006 @ 10:02 — Reply

    I'd like to explain a few details which you people seem to have missed, first its not ZEND's fault for their product being cracked.Actually ANY client-side protection is perfectly crackable. IF IT RUNS IT CAN BE CRACKED. Think about it: the crypted data is passed to the loader dll, which decrypts it(data can be captured , or the crypto algo can be reversed or ripped from the dll). Now there can be 3 cases: 1)Source code is kept in its original format -> END 2)You obtain decrypted byte-code (original php bytecode). Analyse the php source code to get each opcode value then write a decompiler 3)You obtain decrypted byte-code, however it is either transformed on the fly in php bytecode or the engine executes it itself. In which case you just have to analyse the engine for the new opcodes and write the same decryptor. While i have no knowledge whatsoever about the actual bytecode used in PHP , i think it might be possible to obsfucate it, in which case an de-obsfucator should probably be written before the actual decompilator. That's it, source code can be recovered,however the actual names of variables/functions or comments may be missing if the obsfucation was done properly. As you can see this is a straightforward process any reverser would think of when wanting to make a decoder for php encryptors.ZEND is not at fault here,because anything that runs can be cracked.They're true goal is to last as long as possible without being cracked, which can be a hard thing to do since the rules of php are much less flexible than lets say what you can do with obsfucating i386+ bytecode. The only reason it didnt get cracked is because no skilled crackers/reversers wanted to do it,however once PHP encoders got popular people did it. If your product doesn't get cracked in one year there are only 2 possibilities: 1)Your product does not interest any crackers or is not widely known 2)Your protection is very good.(doubtful , ALL current protections have been cracked, and only one of them actually lasted 7 months to be figured out (Starforce), nowadays people can crack it within hours to a few weeks depending ontheir skill) Regards, a random reverser passing by ;)

  29. Chris says:
    August 3, 2007 @ 01:45 — Reply

    Some things about this post that I find humorous.... "My company stands to lose millions of dollars from this situation " If your company has managed to write software worth millions of dollars, they should have been smart enough to realize that interpreted code is useless. The whole point of zend is to stop the average guy from poking around your code. Thats it. You want something secure? Forget it. It doesn't exist. The only function of security in computers is to give you a semblance of control over how long it will be before your code is released. It is has been proven MANY times that even the operating systems of your computer have been sourced. In all of the code I have collected over the years I have source for almost every 8 bit operating system there is, various windows versions, etc. Heres a bit of advice from someone who actually writes code for a living, #1 quit taking the I think I am a programmer because I write php code route. #2 write your programs in something like c which is compiled. #3 plan for your code to be read within 6 months of it's release #4 make sure that you read #3 #5 figure out ways to remove portions of the "genius" of your program from the wild Most likely, if you had thought about it you would have realized that any php program can be made to call parts of itself from elsewhere. While this would be helpful in adding to the security it doesn't fix it, but lets say that you did something like a client // server. Maybe store all the tricky math, or the juicy feed pulling, or the particular sorting routine, or whatever makes your program unique on a server somewhere and only allow the client to query it not execute it..... hmmm..... but if you did something like that you would be acting like a real programmer instead of whining. In my opinion you should have studied the problems faced by security before you wrote the first line of code. Too many people think that they can buy a simple patch and fix thier broken ideas. Sorry friend but the world doesn't work that way. Just as a side note, this is a cute little captcha down here. takes all of about .025 seconds to decode it using a very simple program I wrote 5 years ago...... If you are worried about security maybe you should look into it LOL

  30. Ghayath says:
    January 11, 2007 @ 02:02 — Reply

    Thx. alot

  31. Ganesh Rao says:
    June 19, 2007 @ 07:23 — Reply

    I'll give a million applauds to "microsoft". Yes, indeed. If you want to close the source for any kind of bullshit script. Write them initially in ASP and get your ass of PHP. PHP is meant to be open source. No, I am not just telling anything about the source of the PHP parsing Engine, even the source of the script ought to be in plain readable source code. If you really want to keep it... "mommy, its my work! I don like sharing it with my e-buddies" then move on the ASP. That community is more willing than welcoming you. Go,...! Huh! Its only me that is telling you to go? Even the captcha code below is showing.. "GOPHP". Here is the proof... If you guys want to meet the decoder, her is his MSN... lkq[@at@]kali[]com[]cn If you are planning to begging him to decode it any php encoded file (zend and ioncube) forget it, he wont. But send $15 to his eGold and then he will, lol! Seriously, I even tried him bulling around, doesn't work. Let me know if you really get hooked with him and are really able to get the source code off.

  32. Magento Development says:
    April 2, 2010 @ 01:03 — Reply

    Comment pending moderation

  33. blu ray ripper says:
    April 18, 2010 @ 03:56 — Reply

    Comment pending moderation

  34. china laptop battery says:
    May 29, 2010 @ 00:16 — Reply

    Comment pending moderation

  35. personal injury claim says:
    June 3, 2010 @ 17:30 — Reply

    Comment pending moderation

  36. nike shox says:
    June 4, 2010 @ 20:06 — Reply

    Comment pending moderation

  37. virbram five fingers says:
    June 4, 2010 @ 20:16 — Reply

    Comment pending moderation

  38. Gucci bags says:
    June 7, 2010 @ 18:42 — Reply

    Comment pending moderation

  39. MKV to iPad says:
    June 9, 2010 @ 00:54 — Reply

    Comment pending moderation

  40. r9 irons says:
    June 12, 2010 @ 00:57 — Reply

    Comment pending moderation

  41. writing essay says:
    June 15, 2010 @ 18:41 — Reply

    Comment pending moderation

  42. coach purses says:
    June 17, 2010 @ 02:59 — Reply

    Comment pending moderation

  43. replica watches says:
    June 21, 2010 @ 07:05 — Reply

    Comment pending moderation

  44. air jordan says:
    June 24, 2010 @ 01:24 — Reply

    Comment pending moderation

  45. air max says:
    June 24, 2010 @ 01:34 — Reply

    Comment pending moderation

  46. rolex watches says:
    June 24, 2010 @ 02:33 — Reply

    Comment pending moderation

Leave a Comment

Line and paragraph breaks automatic, HTML allowed: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <code> <em> <i> <strike> <strong>

Comments disabled due to spammers being losers that lead sad lives.