Gar keine schlechte Idee.. Danke! So werd ich das machen.
Aber ich kann mir irgendwie nicht vorstellen, dass es dafür keine Option gibt.. Falls ich noch etwas finde lasse ich es euch wissen.

Danke für eure Antworten!

Sorry für die ungenaue Erklärung. Ich weiß wohl, dass ich sie einfach löschen kann. 😉 Darum geht es nicht.
Ich will verhindern, dass ein User eine App.config hinzufügen / ändern kann, da er ja z.B. das StrongNameBypass-Feature aktivieren könnte, was aber nicht im Sinne der Anwendung ist.
Selbst wenn ich die Datei vor dem Kompilieren lösche, kann der User einfach selbst eine erstellen und zur exe legen. Die wird dann ganz normal geladen. Und das würde ich gerne irgendwie verhindern (da die Anwendung ja sowieso keine App.config benötigt).

Ich könnte mir z.B. vorstellen, dass es dafür eine Möglichkeit in der csproj-Datei geben könnte. Konnte aber leider nichts dazu finden.

Hallo,

gibt es irgend eine Möglichkeit zu verhindern, dass Konfigurationen in der App.Config (vor Allem Binding-Redirects und StrongNamesBypass) vorgenommen werden können?

Danke im Voraus!

Danke für eure Antworten (und Sorry für die späte Rückmeldung)!

Im Prinzip hat Abt recht. Eigentlich sollte das nicht meine Sorge sein. Dennoch glaube ich nicht, dass es gegen einige konventionen verstößt, ein Interface zu implementieren, dass man nicht verwenden können soll.

Das mit den Codepermissions werd ich mal unter die Lupe nehmen, danke.

Hallo Gü!

Vielen Dank für deine Antwort!

Ich kenne den Unterschied zwischen Strong Names und Authenticode.
Der Grund, warum ich dieses Problem mit Strong Names lösen wollte, ist z.B. der, dass ich hier kein Zertifikat kaufen muss und dieses Zertifikat (und alle damit ausgestellten) nicht warten (erneuern) muss.

Hilfreiche Informationen konnte ich aus dem zweiten Link leider keine filtern. Ich habe mir den Artikel auf Codeproject durchgelesen auf den verwiesen wird aber konnte das lokal nicht wirklich reproduzieren.
Zwar habe ich es geschafft den Public Key von einem authorisierten auf ein "Fake-Plugin" zu übertragen, jedoch konnte dieses dann nicht einmal geladen werden, da sich schon das .NET Framework aufregte, dass die Signatur nicht verifiziert werden konnte.

Im ersten Artikel steht ja folgendes:

The purpose of a strong name is solely to ensure that when you load an assembly by name, you are loading exactly the assembly you think you are loading.

und wenn das tatsächlich so ist, ist mein Problem damit ja gelöst. Das Programm hätte ja Zugriff auf eine Datenbank mit allen authorisierten Public Keys. Wenn der benutze Key darin nicht vorkommt, wird es nicht geladen.
Und sollte eine authorisierte Person ein "böses" Plugin schreiben, kann es dieser Persoon im Nachhinein ohne Probleme zugeordnet werden.

Also sofern diese Aussage oben stimmt und es keine funktionierende Möglichkeit gibt, einen starken Namen von einem Plugin auf das nächste zu übertragen (ohne den privaten Key zu besitzen), sehe ich da kein Problem.
Oder was überseh ich da?

MFG Yo

Hallo,

Ich arbeite im Moment an einem großen Projekt, bei dem Sicherheit eine wichtige Rolle spielt. Wir wollen autorisierten Personen die Möglichkeit geben, selbst Plugins dafür zu entwickeln.

Zur Überprüfung dieser Autorisierung haben wir an starke Namen gedacht, die von uns in Form von PFX-Dateinen an berechtigte Personen verteilt werden. Jeder Schlüssel ist dem Entwickler eindeutig zuzuordnen und jedes Plugin wird beim Laden darauf geprüft.

Die Frage ist nun wie sicher diese Strategie tatsächlich ist. Ich werde aus den Informationen, die man dazu findet, nicht wirklich schlau. Teilweise liest man, dass ein potentieller "Schädling" mit HEX-Editor einfach die Signatur auf ein selbst erstelltes Plugin übertragen kann.
Stimmt das?

Danke im Voraus!

Danke für eure Antworten!
Das hatte ich schon befürchtet. Das XmlIgnoreAttribute hilft in diesem Fall leider auch nicht weiter, da der Entwickler dann ja auch erst beim bzw. sogar erst nach dem Serialisieren merken würde, dass das nicht funktioniert. Und sonst gibt es auch nichts hilfreiches.
Insofern ist mein Workaround wohl die beste Möglichkeit, obwohl es mir nicht gefällt, ein Interface zu implementieren, das schlussendlich überhaupt nicht genutzt wird / werden kann.

Es wäre schön wenn man irgendwie abfragen könnte, wie das Objekt gerade serialisiert wird oder es überhaupt einfach ein NotXmlSerializable-Attribut geben würde. Oder noch viel besser: Wenn man IXmlSerializable implementieren müsste um ein Objekt mit der XmlSerializer serialisieren zu können.

Klar gibt es andere Möglichkeiten das Objekt zu serialisieren. So soll es ja auch sein. Nur soll / kann es nicht mit XML dargestellt werden.

Hallo!

Kennt jemand eine Möglichkeit in einer Klasse die ISerializable implementiert zu erreichen, dass eine Exception (NotSupportedException) geworfen wird, sobald das Objekt an einen XmlSerializer übergeben wird?
Dummerweise ist ein Objekt, das ISerializable implementiert (und nicht IXmlSerializable) im Grunde auch mit einem XmlSerializer serialisierbar, solange es keine öffentlichen Eigenschaften ohne Setter aufweist.

Mein anfängliches (grausames) Workaround war, zusätzlich IXmlSerializable zu implementieren und beim Aufruf von ReadXml und WriteXml eine Exception zu werfen. Das ist aber natürlich nicht im Sinne des Erfinders..
Ich muss also von vornherein klarstellen, dass dieses Objekt nicht mit dem XmlSerializer serialisierbar ist.

Gibt es da eine Möglichkeit? Ich konnte leider trotz langer Suche keine Informationen dazu finden.

Vielen Dank im Voraus!

Hallo,

Es gibt schon unzählige Threads zum Thema obfuscation, wie sinnvoll es ist und welcher wohl der beste Obfuscator ist.. Aber hier mal was anderes:

Gibt es eine Möglichkeit Programme aufzuhalten, die sich ums Gegenteil kümmern?

Ich habe vor ein Paar Tagen den Confuser kennengelernt, der an sich ein sehr guter Obfuscator zu sein scheint. Heute musste ich leider feststellen, dass es da ja z.b. NETDeob gibt, wodurch das ja alles noch weniger Sinn hat.

Mir war klar, dass obfuscation kein wirklicher Schutz ist. Aber dass 1 Klick reicht ist ja wirklich nicht mehr lustig..

Kennt jenand eine Möglichkeit so einer automatisierten Umkehrung vorzubeugen?

Das Problem ist gelöst!

Ich musste einfach mit tlbimp.exe aus der mshtml.tlb eine Interop-DLL erstellen.