ioncube

maybe you should talk to THIS GUY. Maybe he can help.

No luck but he did say my grandfather wishes me luck with finding a solution.

*chuckles*

you gotta admit - it was kind of an amusing reply. Hope you smiled a little bit at least.

Yes it was amusing. That guy John Edward looks sort of like Lars from Metallica.

Anyway, I really do need a solution to this, so if you have something other then making me chuckle, fire away.

My grand father anally abused me when i was 6 and a half and my stepfather took over there and sold me to a next door neighbor a few times when i was 9 who had also molested a friend of mine but we moved away and i was afraid to tell anyone so God knows how many were molested after that, then i think my stepfather went on to molest another step daughter of his by something odd that she said to me once, if you can walk to the police station start talking to them or tell your school,if nothing else call 1 month ago 1 Rating: Good Answer 0 Rating: Bad Answer Report Abuse by Me Member since: May Total points: (Level 2) Add to My Contacts Block User My dear, I'm so sorry to hear that such a thing is happening.

Thats an astoundingly shitty situation. Though, the now-dead coder was an ass. I mean, crypting hired code? Totally not cool.

Yes a crappy situation indeed.

Still looking for a solution.

have you posted anything to the forums on astalavista.net since even the developers have admitted a way to reverse the code back
"Encoding PHP scripts with optimised compiled bytecodes for optimum runtime performance and maximum security

This means that it most definately *IS* crackable. All bytecode can be converted back into a readable source. As far as I'm aware, understanding PHP internals, there is *NO SUCH THING* as a non-reversable PHP encoder. It just makes it very difficult to do so for the majority of people.

It's like a lock on a glass door. What's the point? It'll only keep out those that wouldn't have opened the door without permission in the first place."

cut from astalavista

ouch, so effectively you could have just replied with " www.justfuckinggoogleit.com " ? heheh.. ;)

sorry been up writing new code for this emergency raid recovery doing since stuck in lab all weekend rebuilding. so the mind is stuck in multi-dimensional algorithms to rebuild data. one of those sucky things when being in one of the largest data recovery companies worldwide.

also sorry for being a bit pointed i also got this dropped on my lap on friday trying to decode these http://www.seagate.com/products/notebook/momentus.html
fuckers are "TDEA 192 bit" encoded by the logic board

Haven't posted anything but I've done some research and apparently ioncube uses something called "loaders" and from what I can tell, I'm S.O.L. on this... if anyone has a solution or can point me in the right direction, please contact me off forum.

hi2u read this lol ^_^

http://forums.invisionpower.com/index.php?showtopic=203505
http://www.akbkhome.com/blog.php/View/105/Code_encryption__funny_solutions.html

there's more out there... just the most relevant links I quickly found. heh

Snip from another memeber at Astalavista

this is a group that just reverses the ioncube http://www.phprecovery.com/

since

****
These are *NOT* encryption methods. All of the so-called lockers are really nothing more than obfuscators

The output of the obfuscator must still be readable by the PHP interpreter, as Spoofed has shown. They can add 'white-noise' and 'do-nothings' and reduce the PHP to intermediate p-code constructs, but ultimately it *MUST* be understandable to the interpreter and therefore are all reversable.
****

Almost 100% wrong

Unfortunately the snip from Nebusoku is almost entirely incorrect, and demonstrates the problem of misinformation from both people posting originally, and with respect to nebusoku reading and reposting, who do not actually understand the technology.

Firstly, phprecovery.com is not just reversing ioncube. It claims to reverse source guardian, ioncube, zend..., basically any compiled code system.

Second, it cannot reverse ioncube 6.5 or Zend gaspra. It may be able to still reverse SG's latest version as they do not use their own execution engine.

On encryption, whether or not there is encryption is irrelevant because encrypted or not, something has to be extracted from the encoded files in order to be executed. The weak point in any system is not the encoding or encryption technique, but the form that the data is extracted to ready for execution.

ioncube, zend, sg are not obfuscators at all, although they may have that as a feature, but are optimising compilers. The compilation is not "white-noise" and "do-nothings", but a transformation from source into binary data, acutally *before* any encoding takes place. The binary data is high level bytecodes, sometimes called p-codes, a term that comes from the early pascal systems. These are very different to source, and there is not a one to one correspondance between bytecode and original source.

These bytecodes are processed by an execution engine in a virtual machine, however this is not the execution engine inside PHP, but one that is inside closed source engines (for zend and ioncube, not for SG). Given this, the compiled code does not need to conform to the same compiled code format that the standard compiler uses.

Bytecodes are not inherently reversible back to source, but a technique called decompilation could be used to reconstruct what source code could have been given bytecodes. This is nothing new, and decompilation from native processor instructions, e.g. from machine code back to C, is also possible.

Re: Almost 100% wrong

i have found on site 1 beta recovery of gaspra encoder...


http://www.phprecovery.com/forum/zend-test/60-test.html

Re: Almost 100% wrong

Ioncube does not provide any security whatsoever and it is rediculously
simple to covert any Ioncube encoded PHP program back to plain text source
before IonCube and that included the latest IonCube 6.5 as well.

Most everyone seems to have a one track mind of trying to decode the
encryption but all seem to commonly miss that you can just go around it!
(I've said enough else Ioncube will probably figure out their mistake)

Anyway to the original poster of this thread, I am sorry that I didn't see
your post until now more than 4 months after you posted your post. If you
still need help decoding the program, contact me and I'll be glad to
reverse the program to the original source for you that you lost when
the programmer died.

Re: Almost 100% wrong

Please i would love to know how to do this, how do i contact you?

Re: Almost 100% wrong

This was a nonsense post, maybe from a competitor to ioncube lol :) The reality is indeed that disassemblers and reverse compilers exist for PHP, and have since early 2005 (not 2006), and if a skilled hacker can get at the compiled code and also reverse any obfuscation that has been used, then source can of course be *reconstructed* that may work. However, in addition to being a criminal offence to try, this is also *exceptionally* non-trivial.

A popular tool that has been used in the past for cracking files is the PHP disassembler VLD. Whilst not revealing source, it shows the compiled code that was generated from the source code, and this is the route back to source code. Seeing the raw opcode output from VLD is enough to recreate source manually, but takes time. So we looked at this, and on an ioncube encoded phpinfo file, this is what VLD made of the opcodes:

function name: (null)
number of ops: 3
line # op fetch ext operands
-------------------------------------------------------------------------------
2 0 <255>
1606587450 1 BOOL_XOR , ,
1146101909 2 <116> , ,

VLD, which we also had to patch to get at the opcodes, shows that opcodes are actually wrong even before execution, which is where VLD and anyone else would see the opcodes, and VLD was unable to disassemble the opcodes or show any operands (opcode parameters). Looking in the function table for the opcodes of functions also did not work because the opcode pointers in the oparray (the memory structure that is supposed to point to the compiled code) was wrong and so pointed not even to obfuscated code, but pointed to no code at all! Pointers to the code of functions are therefore stored somewhere secret and not in the usual place. This made using VLD effectively useless.

The non-trivial encoding systems, and there are plenty of them, are those that use source based encoding and rely on eval, because these are relatively easily exposed by patching PHP with a printf statement and a bit of string matching to filter out supporting code. Those that pass original opcodes to the main executor and do not use a closed source executor are also weak because VLD can be used. Compiled code systems such as ioncube and zend are the best way to go, but nothing can be totally secure as code ultimately has to execute at some point. Even if compiled code is obfuscated right up to the point of execution of each individual bytecode instruction, someone with sufficient skill at machine code programming and analysis, ideally machine code decompilation back to C source, program tracing and patching plus knowledge of specialiesd algorithms, as well as copious amounts of concetrated and non-interrupted time, could actually reverse anything. Reversing compiled C back to source, DRM cracking, cracking of hardware dongles or hardware in general, chemical composition analysis, and basically any kind of reverse engineering exploit is possible, and there are criminals for hire that specialise in breaking into computers and reverse engineering. Most commonly they are located in China and Vietnam. It's always possible to someone with criminal intent and being exceptionally and uniquely skilled with *plenty* of time!

The challenge for providers of any product of sufficient desirability and recognition as being worth reverse engineering in the first place is to put as many barriers as possible in place to make this difficult whilst not compromising product usability, and particularly when trying to add security to something like PHP which is inherently insecure by being opensource, to educate the end user base on the compromises that may ultimately be required in order to achieve the best possible protection against criminals.

I can decode Ioncube

So if you need a Ioncube file decoded just send me a e-mail snipergreer2010@yahoo.com

I have a similair problem myself, did you manage to find someone who could decode ioncube. Im in a real dilemma as if i cant find someone i would need to rewrite everything which has taken about 2 years. Anerley Locksmiths

Picka I can decode it

Picka simply e-mail me at support@nulleverything.com and I will decode the files for you for free......

Re: Picka I can decode it

Unfortunately They shut my site down, But I still am decoding files.. You can reach me at myistermedia@gmail.com or jgreer2009@gmail.com..

I would be happy to decoded ioncube file(s) For FREE

Re: Picka I can decode it

Just sent you an email as i have original scripts need help with errors pls.
thanks

this is an excellent share.!! looking forward to more such posts.. keep up the good work!! I really appreciate it!
George Nelson:
http://www.chequethis.com/