As much as I don't want to sound like a douche... why do you think this project was started? Because MCP turned straight around and said "hey, you can use our mappings for whatever you want :D"?
That's before I direct you to like... idk... like... read?
The MCP mappings are released under a restrictive license that prohibits other projects from using the mappings. I've tried to negotiate with the MCP project maintainers (eg Searge), but they don't return my messages in any timely manner. I'm sure they're just too busy.
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
My quote above is from a different thread I think. "Why not MCP?" is a perfectly legitimate question and I don't think I actually said anything about that in this thread. When I get time, I'll make a big update to the OP to better explain the point of Enigma.
My quote above is from a different thread I think.
It was the first part of your last post on the previous page. That said; I do see the point... I'm just a little... short fused with people who ask questions which have either obvious answers (in this case arguably not obvious since the project is labelled as a deobfuscation tool in general, not necessarily specific to MC), or that have already been asked and answered, on the previous page no less *is already starting to sound hostile again *
*prostrates and begs forgiveness for acting like a douche*
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Ah, you're right. That quote was from the last page. If I can't even remember what was on the last page, I don't expect anyone else to do better than that. =P
It was the first part of your last post on the previous page. That said; I do see the point... I'm just a little... short fused with people who ask questions which have either obvious answers (in this case arguably not obvious since the project is labelled as a deobfuscation tool in general, not necessarily specific to MC), or that have already been asked and answered, on the previous page no less *is already starting to sound hostile again *
*prostrates and begs forgiveness for acting like a douche*
I know how you feel, no worries
I've got a more interesting question though, are inner classes supported yet? Because I converted the MCP class (and field) mappings for test purposes, and when I tried to open the mappings, nothing happened. So I started Enigma from cmd and I found out that Enigma had thrown an exception because it doesn't like $ being in the name.
It was the first part of your last post on the previous page. That said; I do see the point... I'm just a little... short fused with people who ask questions which have either obvious answers (in this case arguably not obvious since the project is labelled as a deobfuscation tool in general, not necessarily specific to MC), or that have already been asked and answered, on the previous page no less *is already starting to sound hostile again *
*prostrates and begs forgiveness for acting like a douche*
Eh, can't say I would have handled it any differently. I tend to get highly irritated when someone asks a question that has recently been answered, or asks a question that has already been asked multiple times on the same page.
I've got a more interesting question though, are inner classes supported yet? Because I converted the MCP class (and field) mappings for test purposes, and when I tried to open the mappings, nothing happened. So I started Enigma from cmd and I found out that Enigma had thrown an exception because it doesn't like $ being in the name.
From what I understand, the JVM doesn't care if a class is inner or not. It might not even be able to tell. After obfuscation, all class names are replaced with eg "a", "ft". There are no longer any classes named things like "Foo$Bar" and I think the InnerClass attributes are all stripped out of the bytecode by the obfuscator. That means the deobfuscator can never hope to recover inner classes and we'll just have to treat them as top-level classes.
EDIT: looks like the decompiler does support inner classes (see http://stackoverflow.com/questions/23376498/restore-original-source-from-apk#comment35845216_23378607). I think the obfuscation destroys the inner class relationships though. The trouble is, if you just decompile an inner class and treat it as a top-level class, the source will contain "illegal" things in it like statements before superconstructors. The JVM allows these things, but the compiler does not. We may need to find a way to deobfuscate the inner class relationships.
I haven't worked at all yet on getting the decompiled sources to compile. I figured I could push that problem back until later. It could be done in parallel to building the mappings anyway.
EDIT: looks like the decompiler does support inner classes (see http://stackoverflow.com/questions/23376498/restore-original-source-from-apk#comment35845216_23378607). I think the obfuscation destroys the inner class relationships though. The trouble is, if you just decompile an inner class and treat it as a top-level class, the source will contain "illegal" things in it like statements before superconstructors. The JVM allows these things, but the compiler does not. We may need to find a way to deobfuscate the inner class relationships.
Can you heuristically detect when this sort of illegal thing happening and use that to identify inner classes? Otherwise, we could just make that relation something user-defined in the mapping tables.
Actually, that's probably the better choice anyway, since it would give us the option of specifying inner classes even if they aren't breaking any rules..
I did some testing, inner classes should work (no illegal stuff), but anonymous classes (look here) won't.
I think anonymous classes are necessarily inner classes. That example you pasted does indeed have illegal source. I'll see what I can do to get anonymous/inner classes working. That will be a good example to test.
Can you heuristically detect when this sort of illegal thing happening and use that to identify inner classes? Otherwise, we could just make that relation something user-defined in the mapping tables.
Actually, that's probably the better choice anyway, since it would give us the option of specifying inner classes even if they aren't breaking any rules..
I was thinking about using heuristics to do this. For anonymous classes, they all follow a simple pattern. The constructor for the anonymous class is always called from exactly one location. It always has a synthetic field for the outer class. The synthetic field is always set in a private constructor before calling another constructor. That pattern should be enough to automatically detect anonymous classes.
For more generic inner classes, that probably won't work. We might be able to come up with a more general heuristic to detect those, or just make that relationship specifiable by the user.
My heuristics for detecting anonymous classes seem to work rather well. Now if I can just get Procyon to recognize the relationship, we should have working inner class support for Enigma soon! =)
Ahhh, I forgot to start testing/deobfuscating... I got distracted with stuff (moar threading fluids mod now with full support for 40 core workstations, and more notably: water pressure)... hopefully tomorrow I can stop neurotically working on this stuff for long enough to try out Enigma...
Inner class support sounds pretty important... though... how often do inner classes actually get used in MC?
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Ahhh, I forgot to start testing/deobfuscating... I got distracted with stuff (moar threading fluids mod now with full support for 40 core workstations, and more notably: water pressure)... hopefully tomorrow I can stop neurotically working on this stuff for long enough to try out Enigma...
Inner class support sounds pretty important... though... how often do inner classes actually get used in MC?
Small anonymous classes are used frequently, but not all the time. I'm not sure how often named inner classes are used though. I should have Enigma working with at least anonymous classes in a day or two. I actually made a little progress last night. I found out how to get Procyon to decompile inner classes correctly, so now I just have to do a little tweaking to get everything to look nice.
Small anonymous classes are used frequently, but not all the time. I'm not sure how often named inner classes are used though. I should have Enigma working with at least anonymous classes in a day or two. I actually made a little progress last night. I found out how to get Procyon to decompile inner classes correctly, so now I just have to do a little tweaking to get everything to look nice.
On 1.7.10 there are 223 inner classes in total (not counting anonymous ones).
Edit: And the amount of anonymous classes should be 232.
Small anonymous classes are used frequently, but not all the time. I'm not sure how often named inner classes are used though. I should have Enigma working with at least anonymous classes in a day or two. I actually made a little progress last night. I found out how to get Procyon to decompile inner classes correctly, so now I just have to do a little tweaking to get everything to look nice.
Lol, everyone starts brainstorming how to do it, then you discover that there's already something in the decompiler that can actually do it automatigically anyway
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
On 1.7.10 there are 223 inner classes in total (not counting anonymous ones).
Edit: And the amount of anonymous classes should be 232.
Wow, that seems like a lot. My Heuristics found 20 or so inner classes and maybe a few times more than that in anonymous classes. Looks like I'm being far too strict. Want to send me a list? =)
Lol, everyone starts brainstorming how to do it, then you discover that there's already something in the decompiler that can actually do it automatigically anyway
Lol, it's not really a matter of finding which knobs and levers on Procyon get inner classes working. It's more of a matter of finding out just how much information the obfuscator threw away, and then doing inference to put it back in so Procyon has enough information to get the right answer.
Lol, it's not really a matter of finding which knobs and levers on Procyon get inner classes working. It's more of a matter of finding out just how much information the obfuscator threw away, and then doing inference to put it back in so Procyon has enough information to get the right answer.
Man, sounds like the obfuscator really hacks the code up more than I thought... or is some of it the fault of compilation in general?
Rollback Post to RevisionRollBack
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
As much as I don't want to sound like a douche... why do you think this project was started? Because MCP turned straight around and said "hey, you can use our mappings for whatever you want :D"?
That's before I direct you to like... idk... like... read?
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
My quote above is from a different thread I think."Why not MCP?" is a perfectly legitimate question and I don't think I actually said anything about that in this thread. When I get time, I'll make a big update to the OP to better explain the point of Enigma.It was the first part of your last post on the previous page. That said; I do see the point... I'm just a little... short fused with people who ask questions which have either obvious answers (in this case arguably not obvious since the project is labelled as a deobfuscation tool in general, not necessarily specific to MC), or that have already been asked and answered, on the previous page no less *is already starting to sound hostile again *
*prostrates and begs forgiveness for acting like a douche*
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
I know how you feel, no worries
I've got a more interesting question though, are inner classes supported yet? Because I converted the MCP class (and field) mappings for test purposes, and when I tried to open the mappings, nothing happened. So I started Enigma from cmd and I found out that Enigma had thrown an exception because it doesn't like $ being in the name.
Edit: I'll create an issue on Bitbucket
Eh, can't say I would have handled it any differently. I tend to get highly irritated when someone asks a question that has recently been answered, or asks a question that has already been asked multiple times on the same page.
From what I understand, the JVM doesn't care if a class is inner or not. It might not even be able to tell. After obfuscation, all class names are replaced with eg "a", "ft". There are no longer any classes named things like "Foo$Bar" and I think the InnerClass attributes are all stripped out of the bytecode by the obfuscator. That means the deobfuscator can never hope to recover inner classes and we'll just have to treat them as top-level classes.
EDIT: looks like the decompiler does support inner classes (see http://stackoverflow.com/questions/23376498/restore-original-source-from-apk#comment35845216_23378607). I think the obfuscation destroys the inner class relationships though. The trouble is, if you just decompile an inner class and treat it as a top-level class, the source will contain "illegal" things in it like statements before superconstructors. The JVM allows these things, but the compiler does not. We may need to find a way to deobfuscate the inner class relationships.
I haven't worked at all yet on getting the decompiled sources to compile. I figured I could push that problem back until later. It could be done in parallel to building the mappings anyway.
Can you heuristically detect when this sort of illegal thing happening and use that to identify inner classes? Otherwise, we could just make that relation something user-defined in the mapping tables.
Actually, that's probably the better choice anyway, since it would give us the option of specifying inner classes even if they aren't breaking any rules..
I think anonymous classes are necessarily inner classes. That example you pasted does indeed have illegal source. I'll see what I can do to get anonymous/inner classes working. That will be a good example to test.
I was thinking about using heuristics to do this. For anonymous classes, they all follow a simple pattern. The constructor for the anonymous class is always called from exactly one location. It always has a synthetic field for the outer class. The synthetic field is always set in a private constructor before calling another constructor. That pattern should be enough to automatically detect anonymous classes.
For more generic inner classes, that probably won't work. We might be able to come up with a more general heuristic to detect those, or just make that relationship specifiable by the user.
Inner class support sounds pretty important... though... how often do inner classes actually get used in MC?
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Small anonymous classes are used frequently, but not all the time. I'm not sure how often named inner classes are used though. I should have Enigma working with at least anonymous classes in a day or two. I actually made a little progress last night. I found out how to get Procyon to decompile inner classes correctly, so now I just have to do a little tweaking to get everything to look nice.
On 1.7.10 there are 223 inner classes in total (not counting anonymous ones).
Edit: And the amount of anonymous classes should be 232.
Lol, everyone starts brainstorming how to do it, then you discover that there's already something in the decompiler that can actually do it automatigically anyway
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.
Wow, that seems like a lot. My Heuristics found 20 or so inner classes and maybe a few times more than that in anonymous classes. Looks like I'm being far too strict. Want to send me a list? =)
Lol, it's not really a matter of finding which knobs and levers on Procyon get inner classes working. It's more of a matter of finding out just how much information the obfuscator threw away, and then doing inference to put it back in so Procyon has enough information to get the right answer.
Man, sounds like the obfuscator really hacks the code up more than I thought... or is some of it the fault of compilation in general?
I believe in the Invisible Pink Unicorn, bless her Invisible Pinkness.