Bubble

Der Mittelpunkt ist halt der Mittelpunkt. Die Halbachsen sind die Große und die Kleine: Der jeweils größte bzw. kleinste Abstand eines auf der Ellipse liegenden Punktes vom Mittelpunkt. Beide stehen senkrecht aufeinader. Dies ist für die Ellipsengleichung bedeutsam. So, nun hast Du aber die Fragestellung grob verändert: Du willst also jetzt wissen, ob Punkte innerlab eines durch eine Koordinatenliste definierten geschlossenen Polygonzugs liegen?

Dann kann er aber noch immer nicht sagen, ob die Punkte eine, zwei oder noch mehr Kreise beschreiben, die z.B. nur zufällig den gleichen Mittelpunkt haben.

Wenn "sehr viele" oder geeignet liegende Punkte vorhanden sind: Mittelpunkt und Halbachsen bestimmen, dann testen ob alle Punkte (gegebenenfalls mit etwas Tolleranz) die Ellipsengleichung erfüllen. Wenn sich die Halbachsen nicht zuverlässig (innerhalb einer akzeptablen Tolleranz) direkt durch Suchen/Sortieren der Punktliste bestimmen lassen, sei es durch zu wenige oder schlecht liegende Punkte, dann musst Du untersuchen, ob sich Halbachsen finden lassen, mit denen alle Punkte die Ellipsengleichung erfüllen.

Bei Deinem bisherigen Ansatz ist es sogar völlig egal, ob das Passwort leicht entdeckt werden kann oder nicht (dass es vom Installer benötigt wird und so ausgelesen werden kann, ist natürlich eine weitere größere Schwachstelle), da Dein Programm geeignet ist, jedes andere Programm mit Admin-Rechten auszuführen. Mit anderen Worten: Du brauchst ein System, dass selbst nach Möglichkeit ohne Admin-Passwort auskommt, nur bereit ist authorisierte Dateien auszuführen und mit einfachen Benutzerrechten nicht ausgetauscht oder verändert werden kann.

Euch ist hoffentlich klar, dass durch ein festes Hinterlegen des Admin-Passworts in einem derartig einfach aufgebautem Programm, dass zum Starten beliebiger Prozesse mit Admin-Rechten verwendbar ist, eine riesige Sicherheitslücke erschaffen wird?

Dann frage ihn doch mal, wie er das umsetzen würde. Ich bin auf die Antwort gespannt Sind solche Sprüche üblich? Ist das eher lustig zu verstehen oder meint er es tatsächlich so? Wie viel Ahnung hat er in dem Bereich? Wie gesagt: Der Author des Setups sollte sich damit auseinandersetzen und dieses so gestallten, dass man es nach Gebrauch auch löschen darf. Ob man etwas aus dem Webbrowser herus gleich ausführt oder erst speichert, kann man IMO dem Anwender überlassen: Das Kontextmenü so einfach Webbrowserübergreifend zu ändern, geht sicherlich nicht. Eine Alternative wären vielleicht Downloadmanager, gegebenefalls Browserspezifische, aber die müssten auch erst mal installiert werden. Um andere möglichst sinnvolle Vorgehensweisen verschlagen zu können, müsste man die Details kennen.

Das dürfte vom Gerätemodell abhängen.

Nein. Ich halte es aber für seltsam, zu diesem Zweck überhaupt eine msi zu verwenden. Die exe-Datei würde es bestimmt auch ohne msi-Verpackung tun. Irgendwie frage mich, wer auf solche Ideen kommt, um ein vom Prinzip her ganz wo anders herkommendes Problem, derart "lösen" zu wollen. Am sinnvollsten wäre es sicherlich, das (ungewöhnliche) Verhalten des Programms zu verändern oder ansonsten zumindest das Setup entsprechend zu gestalten.

Dann müsste das erste Element der "Liste" bereits Teil vom Zyklus sein, das muss aber nicht so sein. Du sollst ja herausfinden, ob es sich tatsächlich um eine (einfach) verkettete Liste handelt, oder nicht versehentlich ein Zyklus eingebaut wurde. Das bedeutet anders ausgedrückt ungefähr: Du darfst Dir etwas merken, zu jedem Element der Liste gleich viel. Jetzt ist es ganz einfach auf Zyklen zu prüfen. Du kommst bestimmt drauf. Lies noch einmal den Hinweis ganz genau, die Lösung steht praktisch schon da. Probiere es mal auf einem Blatt Papier aus. Überlege es Dir noch einmal genau, welcher Knoten (d.h. welcher Speicher) tatsächlich entfernt werden muss, um zum gewünschten Ergebnis zu kommen.

Die eigentliche Frage nach dem warum hast Du leider nicht beantwortet. Immerhin sollte man von einem Verhalten, dass ein User erwarten darf, möglichst nicht abweichen. Im Zweifelsfall ein eigenes Button-Control schreiben. Allerdings ist das nicht unbedingt so einfach, wenn Barrierefreiheit vollständig unterstützt werden muss.

Warum willst Du das normale Verhalten unbedingt verändern? Auf einen Tastendruck im übergeordneten Fenster zu reagieren wird nichts bringen, da dieses Event zuerst an den Button gehen dürfte.

Du kannst also nicht einmal sicherstellen, dass Du der alleinige Nutzer der Hardware (nicht der VM!) bist, da in inrgendeiner anderen von Dir nicht kontrollierten VM noch etwas anderes ablaufen kann? Falls ja, kannst Du unter diesen Voraussetzungen jeden sinnvollen, reproduzierbaren Performancetest ohnehin vergessen. Nein, hast Du nicht. Entscheidend ist die zugrundeliegende echte Hardware und nicht nur, wie die virtuelle aussieht. Zuerst müssten reproduzierbare Test-Cases her, darunter typische und gegebenfalls auch ein paar extreme Fälle. Wie man weiter vorgeht, hängt sehr von der Art des Programms ab, wie man es bedient, was es tut und was primär getestet werden soll. Gegebenenfalls muss das Programm für einige Tests auch um geeignete Hilfsfunktionen erweitert werden oder es müssen zusätzlich geeignete Testprogramme geschrieben werden.

Man kann doch auch nacheinander testen. Für ganz saubere Tests sollte die Testumgebung im Idealfall ohnehin neu aufgesetzt werden. Dann kann man dies mit in der Testumgebung berücksichtigen. Ich halte diese beiden Kriterien für nicht unbedingt interessant. Wichtig ist doch wie schnell das Programm bzw. die Oberfläche reagiert und wie lange ein Benutzer auf Berechnungen usw. warten muss (falls dies hier relevant ist). Und wenn das Programm das Gleiche ist (in Java geschrieben?) dann dürfte der Resourcenverbrauch ohnehin sehr ähnlich sein.

Performancemessungen macht man besser nicht in einer VM sondern mit echter Hardware. Wie man vorgeht hängt stark von der Art des zu testenden Programms und was man genau wissen will ab. Was für eine Aussage versprichst Du Dir von Mittelwerten für die CPU oder RAM-Auslastung?

Richtig. Ein Programm, dass Debugger abfangen möchte ist doch immer irgendwie verdächtig, oder findest Du das nicht? Viele der "Tricks" etwas zu verschleiern sind eher alt und wurden schon früher im Zusammenhang von Kopierschutzvorkehrungen genutzt. Beispielsweise wurde ausführbarer code gepackt (EXE-Packer), es wurde mit selbstmodifizierendem Code gearbeitet, um eine Analyse des Programms zu erschwerern, usw. Wenn man tatsächlich einen wirklich sicheren Schutz aufbauen will, dann braucht man im Grunde ein sicheres DRM für den Programmcode. Das könnte Hardware- und Betriebssystemunterstützung erfordern. Es müsste z.B. auch verhindert werden, dass der Code in einer VM ausgeführt werden kann - nur Debugger aussperren reicht dann auch nicht. Für noch mehr Schutz müsstest Du auch noch sicherstellen, dass auch die Hardware nicht modifiziert ist, usw. Was befürchtest Du denn könnte passieren, falls jemand fremdes das Programm tatsächlich einsieht? Es gibt immerhin haufenweise Programme, die ohne derartige Schutzvorkehrungen auskommen.

Das möchtest Du genau erreichen? Es sollte aber auch klar sein, dass bei einigen Vorgehensweisen möglicherweise das Risiko eines Support-Alptraums besteht, wenn die Vorgehensweise z.B. von Viren-Scannern irgendwann in der Zukunft als "verdächtig" eingestuft wird. Den Aufbau von ein paar Kommunikationsprotokollen (darum ging es Dir doch?) muss man meiner Meinung nach nicht wirklich verstecken.

Um eine Sprache zu lernen, muss man sie auch benutzen können.

Doch, da gibt es sogar mehrere, z.B. das Programm nur auf eigenen Computern ausführen (der beste Schutz) oder das Problem nicht per Software sondern per Hardware lösen, die so verpack ist, dass sie beim Versuch sie zu öffnen recht schnell kaputt geht (erhöht den Aufwand und die Kosten enorm, insbesondere wenn die Hardware pro Stück teuer verkauft wird). Das Verlagert das Problem auf native code, welcher insbesondere mangels aussagekräftiger Bezeichner oft schwieriger zu überblicken ist, löst es aber nicht an sich. Richtig. Bei den hier bisher genannten Programmen bezweifle ich, ob jemand die Zeit aufwenden wollen würde. Das Problem daran ist nur: Der Aufwand ist hoch und stellt trotzdem keinen völligen Schutz dar. Es kann für den Zweck reichen, aber man darf keine falschen Vorstellungen haben. Um aber mal einen neuen Vorschlag zu machen: Es gibt Anbieter von Lösungen für den Softwareschutz, auch mit Spezialhardware. Da sollte man sich mal erkundigen.

Mögliche Varianten wären z.B.: Das Programm aus einer Shell/Command Prompt heraus starten. Am Programmende eine Funktion hinzufügen, die für die Testzwecke auf einen Tastendruck wartet und erst dann das Programm beendet. Die IDE so einstellen, dass sie das Fenster automatisch offen hält, bis z.B. eine Taste gedrückt wurde, oder eine IDE benutzen, die das kann.

Beim Erlernen von Sprachen macht das aber meistens nicht viel Sinn, insbesondere am Anfang. Gut, es gibt Lernprogramme. Aber (mehrere) verschiedene Stimmen, die Wörter auch mal leicht unterschiedlich aussprechen/betonen können, machen es leichter.

Aufgrund der reingesteckten Arbeit ist so eine Reaktion zwar verständlich: Aber selbst wenn der Source offen liegen würde, bedeutet das noch nicht, dass jemand das Programm unerlaubt benutzen oder vervielfältigen darf. Wenn sich jemand die Mühe machen will per Disassembler, Reflection oder in diesem Fall MSIL Decompiler mehr über das Programm zu erfahren, wäre mir das aber wohl auch eher egal bzw. ich würde es hinnehmen müssen. Zusätzlich gibt es noch Programme, die unter anderem Bezeichner umbenennen, wodurch das zurückübersetzte Ergebnis unübersichtlicher ist. Ich glaube Du hast etwas nicht verstanden: Damit ein Programm ausgeführt werden kann, muss eine Form des Codes bekannt sein - meistens ist diese Form CPU-spezifisch oder in dem Fall hier die Intermediate Language. Das wirst Du akzeptieren müssen oder das Programm, bzw. der relevante Teil von diesem, darf nur auf einem nur von Dir kontrollierten Computer ausgeführt werden. Ja, das ist meistens so. Allerdings kann das je nach Fall auch schon mal anders aussehen. Lege die Daten in einem Verzeichnis ab, auf das nur der jeweilige Benutzer zugreifen kann. Das wäre schon mal ein erster Schritt. Ich hoffe doch mal nicht, dass das Programm für jeden Programmbenutzer im gleichen Betriebssystem-Benutzer-Kontext ausgeführt wird? Höchstmögliche Sicherheit dürfte aber (für Dich) zu viel Aufwand bedeuten und könnte unter Umständen ein TPM im jeweiligen Rechner erfordern. Sobald etwas im Speicher steht, kann es vom Prinzip her abgegriffen werden.

Und wo ist das Problem, wenn jemand einen äquivalenten Source sieht, wenn er denn unbedingt will? Wenn man diesen in den 2 Minuten auch noch versteht, wird vermutlich eher nichts besonderes passieren. Ich will einschätzen können, ob es sich um das Schützen wollen wirklich cleverer Ideen handelt, oder eher das Gegenteil. Und was macht der E-Mail Client so besonderes, dass das Know-How der Implementierung bestmöglich geschützt sein muss? Hier liegt vielleicht eines der eigentlichen Probleme: Zeitaufwand für eine Implementierung ist für sich alleine nicht vergleichbar mit wirklich cleveren Alleinstellungsmerkmalen oder auch sonstigen in die Implementierung geflossenen Ideen, die vielleicht einen gewissen Vorsprung vor ähnlichen Programmen darstellen können. Ich glaube es gibt primär zwei Gründe, ein Programm möglichst gut schützen zu wollen: Wirklich clevere Ideen (vermutlich eher selten) und das genaue Gegenteil: Die Benutzer (Kunden) sollen nicht mitbekommen, wie furchtbar die Umsetzung ist. Erstmal ist es eine seht schlechte Idee vertrauliche Logindaten in ein Programm hineinzucompilieren, egal ob verschlüsselt oder nicht. Und dann stellt sich auch gleich eine weitere Design-Frage: Warum benötigt das Programm ein Passwort, dass der Benutzer nicht kennen darf? Das ist kompletter Unsinn. Sobald das Passwort entschlüsselt ist, kann es, wenn keine besonderen weiteren Schutzmaßnahmen vorhanden sind, im Klartext abgegriffen werden.

Na die Ausgangsfrage klingt etwas danach, als ob dem Fregesteller dies nicht so richtig gefällt. Das wird gelegentlich erwähnt, es sollte aber jedem klar sein, dass sich im Prinzip jede Software (auch ein "native" übersetztes Programm) mit genügend Aufwand nachvollziehen lässt. Wirklichen Schutz gibt es nur, wenn man das Programm erst gar nicht heraus gibt. Mich würde aber dennoch interessieren, um was für Programmteile es sich handelt, die möglichst niemand nachvollziehen können soll.

Das .NET Programme eine .NET Laufzeitumgebung benötigen ist gewollt. Wenn diese nicht vorhanden ist, kann sie, sofern für das verwendete OS verfügbar, installiert werden. Wo ist dabei das unüberwindbare Problem?

Was spricht prinzipiell dagegen? Diese Plugins sind aus Sicht von Visual Studio auch Source Control Provider, wie das Plugin für den TFS auch.