Mit JNI finale Variablen überschreiben

[Tomate_Salat]

Hi, ich habe gerade etwas nettes entdeckt:

public class SoundLib
{
	private final String[] tracks;
	
	static 
	{
		System.loadLibrary("sounds");		
	}
	
	public native void play(int track);	
	public native void loadTracks();
	
	public SoundLib()
	{
		tracks	= null;
	}
	
	public String[] getTrackList()
	{
		return tracks;
	}
	
	public int getTrackCount()
	{		
		return tracks == null ? -1 : tracks.length;
	}
}

und die loadMethode in c++:

JNIEXPORT void JNICALL Java_jni_SoundLib_loadTracks(JNIEnv *env, jobject obj)
{			
	jstring track1	= env->NewStringUTF("TrackA");
	jstring track2	= env->NewStringUTF("TrackB");

	jobjectArray a	= env->NewObjectArray(2,env->FindClass("java/lang/String"),env->NewStringUTF(""));

	env->SetObjectArrayElement(a,0,track1);
	env->SetObjectArrayElement(a,1,track2);

	jclass clazz	= env->GetObjectClass(obj);
	jfieldID fid	= env->GetFieldID(clazz,"tracks", "[Ljava/lang/String;");
	env->SetObjectField(obj,fid,a);
}

Ist euch schonmal aufgefallen, dass man mit JNI finale Variablen überschreiben kann. Ich nehme mal, das funktioniert, weil er einfach auf den Speicherplatz zugreift.

MFG

Tomate_Salat

 

[The_S]

Du kannst auch problemlos auf private Attribute und Methoden zugreifen .

 

[Tomate_Salat]

auf Methoden (java) habe ich jetzt noch nicht zugegriffen, aber das mit den privaten Attributen wusste ich. Habe es mal abgehandelt, weil die dll aus der Klasse ja auch aufgerufen wird

 

[Marco13]

Jo, mit JNI geht so einiges. Bei finalen Variablen muss man aber trotzdem vorsichtig sein, weil es sein kann, dass der Compiler jedes Auftreten dieser Variablen durch ihren Wert ersetzt, sinngemäß

class A { final int value = 123; }

class B
{
    private A a = new A();

    void print()
    {
         System.out.println(a.value);
    }
}


// Main:
B b = new B();
b.print(); // Gibt 123 aus
ändereVariableMitJNI();
b.print(); // KÖNNTE immernoch 123 ausgeben...

 

[Tomate_Salat]

Nun ja, ich habe zwar erst wenig mit jni gemacht, aber bisher hielt ich es immer so: Variablen die von der DLL aus verändert werden sollen, werden in Java nur lesend angesprochen. Aber ich glaube zu wissen was du meinst. Aktuell ist mir eh nicht ganz klar wie ich z.B. von B aus die variable in der Referenz a verändern sollte, von daher bin ich auch erstmal außer Gefahr ^^

 

[Guest2]

Moin,

das geht leider nicht nur per JNI sondern auch schon mit Java Bordmitteln:

public class Foo {

    private final int bar;

    public Foo(){

        bar = 7;

    }

    @Override
    public String toString(){

        return Integer.toString(bar);

    }

}


public class Test {


    public static void main(final String[] args) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException {

        final Foo foo = new Foo();

        final Field field = Foo.class.getDeclaredField("bar");
        field.setAccessible(true);
        field.setInt(foo, 42);

        System.out.println(foo);

    }

}

(wenn jemand zufällig weis, wie man sowas verhindern kann, wäre das schnuckelig!
(würde gerne C-Pointer unter Java als long zwischenspeichern, aber ohne das jemand mit reinem Java den C-Pointer verbiegen kann))

Gruß,
Fancy

 

[Tomate_Salat]

Oo ich mein: ich wusste das man finale nicht als konstanten bezeichnen kann....jz ist auch definitiv klar wieso -.-. Vllt könnte man das mit dem SecurityManager unterbinden (es wirft ja eine securityexception)

Edit habs mal getestet: wird die das ganze als private definiert, findet er das Feld nicht und eine [c]NoSuchFieldException[/c]:

public class Main
{
	private final int test = 5;
	
	public static void main(String[] args)
	{
		Main main	= new Main();
		try
		{
			java.lang.reflect.Field field	= Main.class.getField("test");
			field.setAccessible(true);
			field.setInt(main, 6);
			
			System.out.println(main.test);
		}
		catch(Exception e)
		{
			e.printStackTrace();
		}
	}	
}

 

[Guest2]

Leider nicht ganz.

private final int test = 5;

...führt dazu das der Compiler das Wegoptimiert (das ist der Punkt den Marco schon ansprach).

java.lang.reflect.Field field   = Main.class.getField("test");

...getDeclaredField("test").

Und so gehts dann leider wieder:

public class Main
{
    private final int test = Integer.parseInt("5");

    public static void main(final String[] args)
    {
        final Main main   = new Main();
        try
        {
            final java.lang.reflect.Field field   = Main.class.getDeclaredField("test");
            field.setAccessible(true);
            field.setInt(main, 6);

            System.out.println(main.test);
        }
        catch(final Exception e)
        {
            e.printStackTrace();
        }
    }
}

Gruß,
Fancy

 

[Guest2]

So geht’s dann wieder nicht mehr:

public class Main {
    private final int test = Integer.parseInt("5");


    public static void main(final String[] args) {

        System.setSecurityManager(new RMISecurityManager());

        final Main main = new Main();
        try {
            final java.lang.reflect.Field field = Main.class.getDeclaredField("test");
            field.setAccessible(true);
            field.setInt(main, 6);

            System.out.println(main.test);
        } catch (final Exception e) {
            e.printStackTrace();
        }
    }
}

Also vielleicht lässt sich wirklich was mit dem SecurityManager drehen, aber ob das wirklich wasserdicht zu kriegen ist? Werd mich mal Einlesen.

Thanx für den Tip!

Gruß,
Fancy

 

[maki]

(wenn jemand zufällig weis, wie man sowas verhindern kann, wäre das schnuckelig!

Mit einem SecurityManager zB.

 

[Guest2]

Heißt das "zB." das Du evtl. noch einen weiteren Weg wüsstest?

Wie ich inzwischen gelernt habe, bezieht sich der SecurityManager wohl immer auf die gesamte VM. Wenn ich aber jetzt eine (open source) Library (nutzt intern JNI) als signiertes JAR veröffentlichen würde (für die, die kein eigenes code sign Zertifikat haben) und würde intern den SecurityManager setzen, hätte das Seiteneffekte auf die gesamte Anwendung (z.B. Inkompatibilität mit RMI).
Wenn ich jedoch keinen SecurityManager setze, könnte jemand per Reflection meine signierte Lib nutzen, um selbst ohne signiertes JAR auf einem fremden Rechner rum zu fuhrwerken (unter meinem Namen!).

Also eigentlich suche ich etwas um sicherzustellen, dass von genau meinem JAR mindestens keine final Variabeln verändert werden können.
(Oder noch besser auf nichts, das nicht public ist, zugegriffen werden kann.)

Gruß,
Fancy

(@Tomate Salat: Sorry, hab gerade ein wenig ein schlechtes Gewissen weil das Thema etwas von Deinem Ursprungspost abweicht (auch wenns immer noch ums nicht so ganz finale final und JNI geht ))

 

[maki]

JNI hat so einige tücken, da war auch mal etwas mit Vererbung dass dann nicht mehr funktioniert....

Den SecurityManager kannst du nur sinnvoll in der VM Konfig setzen (gibt eine eigene Datei für), wichtig bei Servern (Tomcat zB.) die mehrere WebApps ausführt.

Ein weiterer Weg?
Denke mit OSGi, dann würden die Nutzer niemals auf die Implemenetierung der Klasse zugreifen können, nur auf ein Interface .

 

[Guest2]

Ja, OSGi währe vielleicht eine Lösung. Aber die Nische, die ich mit meiner Lib füllen will, benötig vor allem das die Lib "schlank, schnell und einfach" ist. Da will ich den Nutzer nicht unbedingt zu einem OSGi Framework drängen.

Gruß,
Fancy

 

[Guest2]

Für "mein" Problem habe ich inzwischen eine Lösung gefunden:

Einfach den zu schützenden Code in ein JAR packen, in das Manifest "Trusted-Library: true" eintragen und das JAR normal signieren.

Das führt dann zu:

All trusted library jars are loaded into a separate dedicated class loader which is unique to the application or applet. The trusted library code components cannot be replaced and trusted library classes and resources are isolated from all untrusted components.

Quelle: Mixing Signed and Unsigned Code

Beim einem kurzen Versuch von einer nicht signierten Webstartanwendung, die meine signierte Lib nutzt, per Reflection auf die privaten Teile der Lib zuzugreifen, hat das auch hervorragend funktioniert.

Per JNI geht das vermutlich immer noch, aber da JNI Code nur von trusted Code aus geladen werden kann, ist das in "meinem" Fall ok.


Vielleicht hilft es ja dem einen oder anderen, dafür zu sorgen, dass seine JNI Lib nicht missbraucht werden kann.

Gruß,
Fancy

 

[Tomate_Salat]

@Tomate Salat: Sorry, hab gerade ein wenig ein schlechtes Gewissen weil das Thema etwas von Deinem Ursprungspost abweicht (auch wenns immer noch ums nicht so ganz finale final und JNI geht )

Sehe ich jz erst^^ war in dem Post lange nicht mehr. Aber ne, ich finde das ganze recht Interessant. Vor allem weil ich gerade auch damit wieder rumspiele (mit der NON-JNI-VERSION =] ). Insofern war dein kleines OT brauchbar für mich