Singing Mods / Fingerprint System

[LexManos]

I actually have a extensive background in actual security.

There is no 'exploit'. And the system does work. As evidenced by the few mods that do cross-checking already. {See the issues that raised with RailCraft and EE/RP mods}

The system is not designed as security and as such is not responsible for the situations you're referring to.

[Cuchaz]

There is no 'exploit'.

 

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:

This mod is hacked! And everyone knows!

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:

This mod is hacked! And you can't detect it!

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.

[endershadow]

couldn't you just put the key in a critical file for the mod? that way if they want to tamper with the key, they have to know the source code of the mod. and if they want to delete the file, then the mod either crashes or isn't loaded.

[hydroflame]

decompiling java bytecode is super easy. the "hackers"/people with bad intention could too easilysimply change that

[endershadow]

what if you put it on the internet so it checks if it's code is the same as the one on the internet? you could easily do that with dropbox

[hydroflame]

we could also redirect the dropbox folder to check because if wedecompile we have the source

[endershadow]

well, then it seems like there's no good way to protect against it if you can just edit it with java byte code.

[hydroflame]

well there can be, lex point is that its not forge responsability to do that.

i do agree with him but that doesnt change the fact that it is an issue irl (not a big but its worth discussing)

[endershadow]

I know, I just thought I'd try to give suggestions. I don't think it's forge's job either

[hydroflame]

we all agree that we shouldnt be downloading freeporn.exe from trolololtotallegitwarez.com. this removes 99% of the issue

[endershadow]

yes, lol. we all agree that we shouldn't download that.

[LexManos]

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:

This mod is hacked! And everyone knows!

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.

Yup that's how the system works, For doing it interally, but Violation events are fired globally. Which is where cross checking comes into play.

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:

This mod is hacked! And you can't detect it!

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.

This isn't a exploit. From Forge's point of view, this is two completely separate mods that happen to have the same id and name. We are not the naming authority. We do not police names. We don't care if there are two mods that exist with the same name. As long as they arn't installed at the same time.

 

This isn't a 'hack', you're not 'hacking' anything as there is NOTHING to hack.

 

Mod 'security' solely falls on the end user not installing compromised mods from source they do not trust.

[Cuchaz]

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.