Jump to content

Cuchaz

Members
  • Posts

    27
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Cuchaz's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. Thanks for the suggestions. The limitations of core mods seems to be a philosophy decision from cpw. There's no technical reason why core mods can't do these things. That's disappointing, but there doesn't seem to be anything I can do about it. Your first suggestion is what I'll have to do. I'll just have to split my mod into two mods.
  2. cpw says core mods should never do these things. But he didn't give a reason why. =(
  3. I take it not many people write coremods around here... Is there any way to get a dev response on this? What's the usual procedure for lobbying for patches to the forge codebase?
  4. And while I'm thinking of it, the event dispatcher for core mods seems to swallow exceptions. That makes debugging slightly more difficult, but it's not a huge problem. ie, if my mod container has a method like this: @Subscribe public void construct( FMLConstruction event ) { throw new RuntimeException( "where does this go?" ); } The exception appears nowhere in the log. =( The easy workaround for now is to just remember to put a try/catch in all my event handlers.
  5. If for some reason it's not taboo to have core mods registering things like entities and guis, this small patch seems to resolve the issue: in cpw.mods.fml.common.FMLCommonHandler: public ModContainer findContainerFor(Object mod) { if( mod instanceof ModContainer ) { return (ModContainer)mod; } return Loader.instance().getReversedModObjectList().get(mod); }
  6. Hello, I'm writing a core mod now. For some reason, FMLCommonHandler.instance().findContainerFor(mod) doesn't work on core mods. It can't find the container and just returns null. After glancing at the source, it seems this is by design. InjectedModContainers goes to great lengths to "override" the isImmutable() method and disable inclusion of the mod in the usual lookup list that findContainerFor() uses. So my question is, how can my core mod use findContainerFor()? Or more importantly, how can my core mod use Forge functions that rely on findContainerFor() like entity registration, gui registration, etc? Are core mods not supposed to register these things for some reason? Am I required to split my mod into two mods? One FML mod and one core mod? It would be nice to keep everything in one mod. Thanks, Cuchaz
  7. I agree. It would be slow. That's why it's easier to develop in a deobfuscated environment. You could probably skip the slow MCP compile script by just passing Eclipse's bin folder to the MCP reobfs script. Incremental compiling will save you a lot of time. Your launch script could also pipe the log file to stdout (or redirect Minecraft's stdout) if you want to see it immediately. Or you could use a log file viewer.
  8. Yeah, that seems the most straightforward way to do it.
  9. Or just distribute Javassist with your library. Up to you.
  10. I'm deeply disturbed this isn't considered a flaw. Nevertheless, you've made your position clear and I won't trouble you about it anymore. However, I will ask if anyone else sees this as a problem and wants to do anything about it. I can probably write a mod to provide a real security layer for mod authors. If any concerned modders out there want to help, they are certainly welcome to contribute.
  11. If you want to dynamically change class files at runtime, I recommend using a tool called Javassist. It will make your life much easier. http://www.csg.ci.i.u-tokyo.ac.jp/~chiba/javassist/
  12. Here is a demonstration of the exploit. This link points to a zip file with three mods in it. https://bitbucket.org/cuchaz/power-tools/downloads/exploitDemo.zip The first mod, testMod.zip is the original mod. It's actually my Power Tools mod v1.2 on PMC. I compiled it from source and signed it in the usual way using a private key. It handles the FMLFingerprintViolationEvent event with the following code: @EventHandler public void onSignatureFail( FMLFingerprintViolationEvent event ) { // ignore the development environment if( event.isDirectory ) { return; } System.out.println( "\n\n" ); System.out.println( "===============================================" ); System.out.println( " Hack Report!" ); System.out.println( "===============================================" ); System.out.println( String.format( "Mod %s failed fingerprint check!", event.source.getAbsolutePath() ) ); System.out.println( String.format( "\tExpected fingerprint: %s", event.expectedFingerprint ) ); System.out.println( String.format( "\tObserved %d fingerprints:", event.fingerprints.size() ) ); for( String fingerprint : event.fingerprints ) { System.out.println( "\t\t" + fingerprint ); } System.out.println( "\n\n" ); } If an invalid signature is detected for this mod, you'll see a "Hack Report" in Forge's log file. However, since testMod.zip is completely benign, there won't be anything interesting in the log when you load it with Forge. The second mod, hackedMod.detectable.zip is a hacked version of testMod.zip. Instead of actually loading the original mod, this hacked version is merely programmed to spit out a message to the console: If you load it using Forge, the invalid signature event will be thrown and you'll see the "Hack Report" in the Forge log. In this case, everything is working as intended. At least, that's how I assume you want this system to work. The third mod, hackedMod.undetectable.zip is another hacked version of testMod.zip. Instead of actually loading the original mod, this hacked version is merely programmed to spit out a different message to the console: If you load it using Forge, the invalid signature event will NOT be thrown and you WON'T see the "Hack Report" in the Forge log. Crucially, all three mods identify as id="cuchaz.powerTools" name="Power Tools" so an end user could not tell the difference from the Forge mods screen. The two hacked mods were NOT compiled from the original source and they were NOT signed using the original key. I used tools to modify the class files of the testMod.zip to install the hack. You could send me any mod zip file and I could repeat the same hack. And your signature system can't detect it. Hopefully this demonstration is sufficient to convince that there is a flaw in Forge's signature system.
  13. You touted your signature system as a way for mod authors to tell if their mod has been tampered with. Whether or not you want to call it a "security" system is irrelevant. I asserted that it doesn't work and disclosed the exploit. You haven't yet convinced me that it actually does work. It's clear to me now that you have no interest in fixing the flaw in your tamper evident system. I'm pretty sure you don't even understand what's wrong with it. Statements like "we have to trust the mod" lead me to believe that I'll never be able to convince that something is actually very very wrong. That's fine. I'll spend my attention elsewhere.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.