1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Getting Encoded file has expired error!! Please help

Discussion in 'PHP' started by createrk, May 18, 2008.

  1. #1
    Hi,

    I uploaded the files in my host and when i ran install for the first time i got the below error.

    The encoded file /home/reakam/public_html/install/index.php has expired.
    SEMrush
    I have given correct CHMOD permissions to files as given in the Readme.txt

    Please advice what can be the issue.

    Thanks.
     
    createrk, May 18, 2008 IP
    SEMrush
  2. jmhyer123

    jmhyer123 Peon

    Messages:
    542
    Likes Received:
    25
    Best Answers:
    0
    Trophy Points:
    0
    #2
    What type of encoding is it? Is it Zend or ionCube or something else? Send me a copy of the file/script so I can take a look at it.
     
    jmhyer123, May 18, 2008 IP
  3. createrk

    createrk Active Member

    Messages:
    847
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    58
    #3
    Its Ioncube. Sending u the script through PM
     
    createrk, May 18, 2008 IP
  4. jmhyer123

    jmhyer123 Peon

    Messages:
    542
    Likes Received:
    25
    Best Answers:
    0
    Trophy Points:
    0
    #4
    Oh, nvm, I can't do anything with ionCube...yet ;)

    If it was Zend I could decode it and deactivate the "expire date"...
     
    jmhyer123, May 18, 2008 IP
  5. ioncube

    ioncube Peon

    Messages:
    18
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #5
    If you send the file to us at support.ioncube.com then we can check to see whether this is an installation fault and let you know how to resolve it without doing anything illegal.

    Jeff: Please note that any attempt to reverse engineer or tamper with encoding technology might have serious repercussions, including but not limited to legal action that depending on circumstances in your case may also or instead affect A and E. Whatever one's own personal opinion with regards to whether closed source code is good or bad, and while some forums such as DP as well as some job boards support hacking activities, the desire of developers to safeguard their work and to enforce licensing conditions should be respected. For many, the option of providing their work in an open source form and deriving sufficient revenue from associated services such as selling support packages and merchandising is simply not a feasible option, and protecting their intellectual property be it just evaluation code or full products is necessary.
     
    ioncube, May 19, 2008 IP
  6. createrk

    createrk Active Member

    Messages:
    847
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    58
    #6
    I am not sure whether the code is legel or not.

    I downlaoded it from a site which says "Download Free PHP Scripts"

    Is this against violation?

    Please advice.
     
    createrk, May 19, 2008 IP
  7. jayshah

    jayshah Peon

    Messages:
    1,128
    Likes Received:
    68
    Best Answers:
    1
    Trophy Points:
    0
    #7
    Perhaps you should be knuckling on those sites actually OFFERING the service (not stating any names or sites), not just trying to scare poor people who want to get their sites working?
     
    jayshah, May 19, 2008 IP
  8. ioncube

    ioncube Peon

    Messages:
    18
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #8
    Sorry if my verbiage was unclear. CreaterK has a problem and we offered to help if he contacts our support helpdesk as there may be an installation error; Mr Hyer is offering decoding and license circumvention services for Zend and we advised him that this may not be a good idea.
     
    ioncube, May 19, 2008 IP
  9. jayshah

    jayshah Peon

    Messages:
    1,128
    Likes Received:
    68
    Best Answers:
    1
    Trophy Points:
    0
    #9
    Start Googling. I know of at least one site offering the service, and another offering patched Windows DLL's to decrypt them yourselves (Zend).

    Most people know none of your services are secure anyway (and please, don't bring out an IonCube Ltd. statement about how it is), whether is be IonCube or Zend, the bottom line is PHP is free and open-source, and you can't prevent anyone from manipulating PHP's core and dumping the operation codes (ring a bell?). Saying that, it is widely believed that IonCube is the way to go, and well done for creating that kind of awareness.

    There's some myth that is legal to decode if it was your script originally, but I'm no lawyer, so I don't know.

    All I'm saying is, remove the sites offering the service before anything else. Forums are the least of your worry.
     
    jayshah, May 19, 2008 IP
  10. ioncube

    ioncube Peon

    Messages:
    18
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #10
    Jay: you raise valid points. Hackers have been attacking Zend in particular for years, starting with the now defunct antizend.com (Russian IIRC) that was on the radar around 2004/5. More recently and hardly a surprise, the Chinese have been at it, and as you say, there's an automated Zend decoding tool available.

    For security, no software protection technique can ever be 100% secure against reverse engineering, and even some hardware systems such as Synchrosoft dongles have been worked around with software emulators. Some PHP encoding systems have misleadingly claimed "bullet proof encoding" while being, ironically, the most easy to attack without any reverse engineering effort at all.

    There are big differences between solutions. There are those that simply hide code, and where source is trivially exposed by modifying the PHP engine; standard bytecode systems that compile to bytecode but use the standard opensource execution engine so that bytecode can be obtained easily for decompilation (not a problem in the early days because there were no decompilers); and systems that use modified bytecode. Zend may still use standard bytecode but augment it with additional proprietary opcodes to support some of their code optimisations, and ionCube uses a modified form of bytecode where the restored bytecode is non-standard bytecode and effectively still encoded, and where a given native instruction is also represented by different binary data at different points in the instruction stream. Using closed sourced executors makes this possible and make it substantially more complicated to reverse engineer than more basic solutions by deviating from what can be understood about the PHP engine from studying the Zend engine sources, but you still can't stop someone single stepping through code at the machine code level, gradually over possibly many months piecing together some knowledge of how a system works, and then making machine code patches to change the behaviour of components. DRM systems and licensing systems on Windows programs get knocked out time after time through this type of analysis and reverse engineering.

    While PHP being open source is great on the one hand, it also places major limitations on how much code protection you can achieve. For example, no matter how you've encoded scripts, running scripts on a system that has modified the PHP wrapper modules or the library functions that implement the underlying operations will expose function parameters to those library functions. Using a closed source and ideally modified version of PHP could offer some advantages, but would be out of the question for all but a limited number of end users who probably wouldn't go for it anyway.

    Protection systems that require a heavy investment in reverse engineering to undermine are definitely doing a good job, but in our view, responsibility to support software developers also lies elsewhere. You mention hacker sites, and for example we've had discussions with the Chinese Embassy and contacted MofCom over the role of the Chinese in attacking PHP developers, but even though MofCom are trying to make inroads into the problems in China and clean up their act so to speak, getting action against the root cause may never happen as the problem of counterfeiting and copyright violation is so vast in China. With some domain registrars, hosting providers, forum providers, job boards, payment providers etc. all facilitating in one way or another activities such as software theft, taking down even the sites that are clearly and most blatantly violating copyright will forever be difficult or impossible.

    On a positive note, the hacker sites tend to serve people who are fundamentally dishonest and who have no intention to buy software or digital media, so may not be such an issue after all in the big scheme of things. For many PHP developers, the challenge is primarily to ensure that genuine potential sales prospects have a need to purchase, and to provide some enforcement of any licensing policy. This is difficult or impossible if the only way to provide code is in source form, particularly if you also want to provide evaluation copies, and this is where encoding delivers the most value.
     
    ioncube, May 19, 2008 IP
  11. jayshah

    jayshah Peon

    Messages:
    1,128
    Likes Received:
    68
    Best Answers:
    1
    Trophy Points:
    0
    #11
    [ From here on in, any opinions expressed are my own entirely and no implications should be assumed ]

    Why did they 'hack' Zend initially? I doubt they thought it's because they are the Core of then Engine, merely because they were the most popular platform. Credit where credit is due, very few sites can actually successfully decode without error. For example, Zending and reversing my own code for test, the decoders have major issues with classes, and anything beyond. Something like $MyClass::DoThis('Param'); will come back as DoThis('Param');.

    No technique is 100% secure, that's a fact. I just believe a lot of 'encoding' companies make out that its completely secure and nothing can be done to reverse it.

    I don't have enough time to comment on everything you've said. But the issue doesn't lie directly with the bytecode shifting - or whatever else you want to call it. It wasn't long ago your loaders were directly susceptible to OPCode dumping, was it?

    Closed source would never work, but it would be interesting if they made a 'free' encoding system, just like compiling (god forbid), Windows applications. A possibility? Doubt it. You for one wouldn't be happy :p

    I doubt you've got it that easy. Some smartass will come along and figure your magic out. It's happened to Zend, and I wouldn't be surprised if it's only a matter of time.

    I didn't mention the word 'hacker' - or similar - in any of my posts. I try to steer clear of stereotyping.

    There's that word again. To be perfectly honest with you, I don't see the full need for 'protection' systems. If you plan to make a one time script - generate some quick cash - you may be looking at it from the wrong angle. I've never had a need to encode any of my scripts, because by providing updates and such, it won't be long before the copy they have is useless. Some clever license checking is all it takes.

    Edit: I accept largescale corporate products may require them, but not smaller equivalents.

    I can't even remember what my original point was now. I've got nothing against you at all, I just think it's time to change the record.
     
    jayshah, May 19, 2008 IP
  12. ioncube

    ioncube Peon

    Messages:
    18
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #12
    Right, and we've as much an issue with this as you probably do. Anyone producing protection systems for anything should not make claims that it's impossible to break.

    "Long" is a relative term that depends on timescale, but in absolute terms it was about 2 and a half years ago now, and not really any issue prior to that. The end of 2005 was when things started to really kick off. Decompilers had emerged earlier in the year, and it was clear to us that simply compiling code was no longer enough, so we spent a few months changing things radically in the Encoder and Loaders. As with some solutions still today, previously code was compiled to native bytecode and a closed source Loader was used (as it always had been). This was fine at the time, and while there was something called VLD (a primitive disassembler), dumping opcodes that few people understood the meaning of anyway was a far cry from any kind of source code, and there were no decompilers. So there was good security for several years with typically faster than source performance thanks to precompiled code and little overhead for restoring the bytecode from encoded files. Changes to this included no longer storing bytecode in the PHP function table so that a hash table lookup would return an invalid memory pointer instead of pointing to the code for a given function, and no longer restoring original bytecode. This ensured that as well as making bytecode harder to obtain in the first place, if you did get a pointer to any, the bytecode was still garbage.

    If it was for the good of software developers then personally I don't see any problem. There are already some free encoding systems such as eaccelerator that people can play with, but they really need to be closed source because otherwise it's too easy to knock out important things such as license restrictions in the runtime components. There's also a system from one of our customers called Roadsend that does compile PHP, via Scheme and then via C, to native machine code. Performance isn't as good as you might expect due to the Scheme engine, but it's a fine tool and probably the best option if you do want to build a native app from PHP sources.

    In some cases there is no need. Clever license checking is of no use if it can be trivially changed or knocked out altogether though, which if opensource it will be, so this is one reason why people protect code. I didn't see the need for a £200+ soldering iron vs. a 15 quid one from Maplin until starting to do SMT prototype work, but realised the benefits as soon as I had one. The tools that are advisable always depend on what job you're doing and the desired outcome.

    Unintended digression after the initial advice to createrk, but some good points raised Jay.
     
    ioncube, May 19, 2008 IP
  13. jayshah

    jayshah Peon

    Messages:
    1,128
    Likes Received:
    68
    Best Answers:
    1
    Trophy Points:
    0
    #13
    We drifted severly off topic ;)

    Everything can be circumvented, which is the bottom line. Many scripts out there have be stripped of your encoding and been redistributed for all to use. It, so it can be done :p

    Interesting chat :) VLD, back then, could actually dump your opcodes. My only fear to those who use your service is not to rely 100% on it, many encode with a one file license check, and once that single file has been reversed ... the encoding is as good as useless.
     
    jayshah, May 19, 2008 IP
  14. createrk

    createrk Active Member

    Messages:
    847
    Likes Received:
    9
    Best Answers:
    0
    Trophy Points:
    58
    #14
    I am the Original thread starter. :) Remember guys.. :) Just for gigs... :)
     
    createrk, May 19, 2008 IP