Betriebsystem [Archiv]

PeGu

11.03.2007, 19:33

Ob das Archiv sich selbst entpackt, oder ob man ein Archivprogramm hat, ist wohl nicht sooooo furchtbar kompliziert für Newbies. Ich könnte mir vorstellen, dass es die Bibliotheken sind, die das Problem darstellen. Jetzt, wo du das ansprichst, könnte man das vielleicht so lösen wie Skype das macht? Eine rpm-Lösung für die Standard-Anwender mit geringen Kenntnissen, und tar.bz2 mit bzw. ohne eingelinkte Bibliotheken für die, die sich ihr System selbst pflegen möchten?
http://www.skype.com/intl/de/download/skype/linux/

Mr. S, wie wär das mit den beiden tar-Lösungen? Wäre das nicht einfacher für dich und genauso bequem für den User? Ich mein, ein rpm oder deb oder sonst ein Paket schnürt sich ja auch nicht von allein?

Mr. S

11.03.2007, 22:53

@PeGu
Das muss ich erst mal ausprobieren, wie das alles so funktioniert. Bisher habe ich nämlich noch nie meine Linux-Programme verpackt :p Die Linux-Programme die ich bisher geschrieben habe laufen nämlich als Cron-Jobs auf einem Server, die werden nicht weitergegeben. Aber wenn ich Fragen habe, weiss ich ja wen ich fragen kann, oder?

P.S.: Es werden CURL und eine GUI-Lib benötigt. Was ich für eine GUI nehme weiss ich noch nicht (KDE, wxWindows, QT oder GTK).

PeGu

11.03.2007, 23:13

Hm, da hab ich mich in was reinmanoevriert... :)
Ich habe auch noch nie ein Programm verpackt (bin auch alles andere als Programmierer). Ich browse aber für mein Leben gerne rpm-Archive, und gehe auf die Suche nach libs.
So wie ich deinen Post verstehe, läuft es wohl auf eine ELF-Datei raus mit dem Decoder und ein GUI-Script. Curl und Gui-Libs entweder dynamisch (da ist das Problem mit der Größe, ist aber einfach) oder statisch (klein, evtl. mit Problemen fürs configure-Skript) mit drin. Wenn du möchtest, packe ich gerne Testversionen in meine Sandbox und meckere über alles, was nicht klappt.

falcon_

30.03.2007, 22:34

Da würde noch die Auswahl 'Andere Linux Distribution' fehlen ;)

Momentan verwende ich den konsolen-original-decoder in nem kleinen bash-skript.

source ebuilds würden wohl von Anfang an ausscheiden, aber gegen Binaries hätte ich nichts - wobei der Aufwand für ein portage-overlay (portage ist gentoos paketverwaltung) sicher höher wäre als für einen kleinen tarball.

Andere Frage: Wäre das lizenztechnisch überhaupt sauber? Immerhin linkst du dein Programm gegen (L)GPL-Libs (libc?)?

Edit: Ach ja: Ganz vergessen: Ich verwende Gentoo Linux

Melavius

31.03.2007, 00:55

Um das ganze DistributionsUNabhaengig fuer Linux zu machen empfehle ich einfach /usr/local/.... (bin,lib,etc). Das sollte dann eigentlich mit so ziemlich allen Distris ohne PATH-Gefummel klappen.

KDE als Basis fuer die GUI wuerde ich nicht empfehlen, da meckern dann die GNOME, etc User. Mit GTK,wxW oder QT bist du da sicher besser bedient, das ist weniger spezifisch.

Alles unter der Annahme, das du es eben, wie selber geschrieben, moeglichst Anfaengerfreundlich machen willst. Ein tar.gz mit entsprechendem Installscript duerfte da imo gut klappen. Sobald du dich naemlich auf RPM, deb, pak.... einschiesst wird irgendwer wieder Probleme haben ;-) Es koennen dir ja theoretisch dann immernoch User dabei helfen, Distributionspakete daraus zu machen, die zusaetzlich angeboten werden...

Bezueglich des Libverlinkens hab ich auch nicht so die tiefgreifende Ahnung aber ich denke statisch muesste besser sein, weniger Libprobleme :)

Was die Lizenzsache angeht, gut da bin ich mir auch nicht so sicher aber gegen GPL Libs zu verlinken sollte kein Thema sein, da haetten es sonst viele Kommerzielle Linux-SW Anbieter Sorgen... Wenn du aber GPL Code in deiner Software einbaust, musst du natuerlich den Code freigeben...

Ich hoffe das klingt jetzt nicht zu Arrogant, ist mein erstes Post hier ;-)

undo

31.03.2007, 05:06

So, dann schreibe ich auch mal kurz mein Betriebssystem mit rein. Ich dekodiere ausschließlich unter FreeBSD. Der Linuxdekoder läßt sich bei mir zwar starten, hat dann aber Probleme beim Netzwerkzugriff, kommt also nicht an den Schlüssel und funktioniert folglich nicht. Auch mit Wine und den Windowsdekodern hatte ich irgendwie kein Glück.

Ich benutze einen selbstgeschriebenen Dekoder - keine 200 Zeilen C++ und äußerst zuverlässig. Anders als die meisten anderen Dekoder legt meiner die Zieldatei zuerst in voller größe an und wenn das schiefgeht (kein Platz / kein Schreibzugriff), dann wird erst gar nicht dekodiert. Wundert mich immer, daß andere Dekoder das nicht machen.

Wenn jetzt der neue Algorithmus kommt, werde ich bei FreeBSD bleiben und wohl einen neuen Dekoder schreiben, denn ich denke kaum, daß FreeBSD es in die Top 3 der ünterstützten Betriebssysteme schafft :).

Mr. S

31.03.2007, 15:02

Hey, es gibt erstaunlich viele FreeBSD-Anhänger, sag das nicht. Leider kann man nicht mehr als 10 Umfragepunkte einbauen.

Das Lizenzproblem ist eigentlich keins, da die libc von FreeBSD z. B. unter der BSD-Lizenz läuft, die den Einsatz in Closed-Source zuläßt. glibc steht unter LGPL, die auch begrenzt in Closed-Source eingesetzt werden kann. Das gleiche gilt auch für die verwendeten C++-Bibliotheken.

undo

31.03.2007, 15:46

Ich verwende an Bibliotheken nur CURL (macht der offizielle Dekoder ja auch) und OpenSSH (weil ich zu faul war, Blowfish selbst zu implementieren :). Beides ist von der Lizenz her kein Problem.

Ich würde meinen Quellcode gerne unter der BSD-Lizenz freigeben, weil ich das aus Prinzip für richtig halte. Aber ich verstehe auch, daß OTR gute Argumente braucht, falls mal wieder irgendwer gegen sie klagen will und will denen nicht in den Rücken fallen. Deswegen habe ich meinen Quellcode bisher für mich behalten und werde es auch weiter tun.

Mir fällt noch was zu dem neuen Dekoder ein: Wenn Du willst, können wir bei dem Frontend dafür zusammenarbeiten, so daß Du einen Linux- und ich einen FreeBSD-Dekoder machen kann, die dieselben Parameter aufweisen und von derselben GUI aus gesteuert werden. Die Kryptoroutinen schreibe ich gerne selber. Da habe ich dann Spaß am Reverse Engineering :).

Doofy

01.04.2007, 09:57

Hallo!

Ich möchte gerne mal wissen was für Betriebsysteme ihr so einsetzt. Mir geht es primär um das System, mit dem Otrkey-Dateien decodiert werden.
Tzz... keines meiner Systeme dabei. :'(

Windows Server 2003 Enterprise Edition
FreeBSD 6.1
FreeBSD 6.2

Mr. S

01.04.2007, 13:28

Mir fällt noch was zu dem neuen Dekoder ein: Wenn Du willst, können wir bei dem Frontend dafür zusammenarbeiten, so daß Du einen Linux- und ich einen FreeBSD-Dekoder machen kann, die dieselben Parameter aufweisen und von derselben GUI aus gesteuert werden. Die Kryptoroutinen schreibe ich gerne selber. Da habe ich dann Spaß am Reverse Engineering :).
Auf das Angebot komme ich zurück! Meine Freizeit ist etwas knapp bemessen und da würde reverse engeneering das Decoderupdate um Monate verzögern, vielleicht kriegst du das ja schneller hin ;). Für die Linux-GUI bin ich noch am überlegen welche Biliothek ich verwenden soll. Ich tendiere zu Qt, lasse mich aber auch gerne eines besseren belehren.

Mr. S

01.04.2007, 18:18

@ Mr. S: Ich weiß natürlich nicht, ob du dich bislang an die Standards gehalten hast, aber beim MSVS gehe ich erstmal davon aus, dass du MS-spezifischen Code hast. Wenn ich dir damit unrecht tue, dann tut mir das leid.
So verwunderlich das auch ist, da hält sich MS ausnahmsweise mal an Standarts.
Auf dein Hilfsangebot komme ich dann auch noch zurück.

emsa

02.04.2007, 16:36

Moin,

2. Will ich ja einen FreeBSD-Dekoder und bin dadurch motiviert, Zeit reinzustecken

das sollte mit einem ordentlich gebauten Linux-Decoder, der unter der Linux-ABI von FreeBSD läuft, kein Thema sein. Das erfüllen aber weder die alte, noch die aktuelle (OMR-)Version, wenn auch aus unterschiedlichen (aber leich fixbaren) Gründen.

Die alte Version ist schlicht statisch gelinkt und verwendet Funktionen, die unter FreeBSD in einer Lib stehen und nicht per se da sind. Das geht natürlich in die Hose, lässt sich aber leicht ändern.

Die aktuelle Version wurde gegen eine glibc mit --enable-kernel=... gelinkt, was natürlich in der Linux-ABI von FreeBSD in die Hose gehen kann (und mit guter Näherung auch tut).

Aber ich zum Beispiel will einen reinen Kommandozeilendekoder. Deswegen meinte ich ja vor allem ein gemeinsames Frontend - also identische Parameter, Fehlermeldungen, etc. So kann es mehrere Dekoder und mehrere GUIs (Qt 3, Qt4, GTK, TCL/Tk <- nutzt das noch wer?) geben und alle können mit allen :).

Ein CLI-Decoder für *ixe ist Pflicht, nicht jeder kann/will mit X oder sonstwas buntem rumbasteln.

Übrigens fängt ein Freund von mir bald mit seiner Diplomarbeit an und will sich dafür kräftig in Java einarbeiten. Wenn der Algorithmus bald ausgeknobelt wird, dann schreibt er sicher gerne eine Javaversion.

Gute Idee, aber auch hier gibt es zum einen Inkompatibilitäten und nicht zuletzt auch Bedenken wegen der nicht gerade resourcenschonenden JVM. Und natürlich ist Java mitunter relativ leicht reverse zu engineeren.

Ciao
emsa

mschafhuber

03.04.2007, 12:06

2x Windoof XP....
sonst nur Knoppix auf LiveCDs...

Doofy

04.04.2007, 04:43

das sollte mit einem ordentlich gebauten Linux-Decoder, der unter der Linux-ABI von FreeBSD läuft ...

Ich vermute, dass es, wenn undo oder meinereiner von der Partie sind, einen nativen FBSD-Client geben wird... also wozu das Linux-ABI? :>

Doofy

04.04.2007, 04:45

Ich persönlich bin ein großer Fan von Qt.

Fein. Du magst Qt, ich mag Qt und Mr. S denkt ebenfalls darüber nach... dann passt das ja eigentlich soweit schon, oder? :)

stna1981

04.04.2007, 14:15

Sooker

04.04.2007, 14:34

Das so viele Linux Distros in der Liste sind verfälscht das ganze..

Debian oder Ubuntu ist an sich schon mal egal, Ubuntu baut ja auf debian auf, die packages können ganz normal genutzt werden..

Ansonsten am besten das ganze über Python laufen zu lassen, dann können alle Distros damit umgehen..

Achja : Bei wem der Linux Decoder nicht geht : Python installieren.

Mr_Maniac

04.04.2007, 15:52

Ansonsten am besten das ganze über Python laufen zu lassen, dann können alle Distros damit umgehen..
Aber dann kann auch jeder in den Quell-Code reinschauen... Wenn der Key gut geschützt ist macht das ja nichts, aber so wie es momentan ist...

Achja : Bei wem der Linux Decoder nicht geht : Python installieren.
Kleine Anmerkung: Nur die grafische Oberfläche (das GTK+-UI) läuft mit Python (und natürlich pyGTK). Das decodieren selbst erledigt immer noch der CLI-Decoder...

Mr. S

04.04.2007, 16:29

Also ich denke ein Support für Vista sollte - früher oder später - schon eingebaut werden, denn die Zahl derer, die es einsetzen, wird zwangsläufig steigen, spätestens dann, wenn die ersten guten DirectX 10-Spiele kommen ;-)

Also Vista bekommt von mir ganz klar keinen Extra-Decoder! Entweder funktioniert der unter Vista oder die Leute haben Pech gehabt, ich will Vista nicht einmal geschenkt haben! Vorher steige ich lieber komplett auf Linux um.

Doofy

04.04.2007, 21:58

Also Vista bekommt von mir ganz klar keinen Extra-Decoder! Entweder funktioniert der unter Vista oder die Leute haben Pech gehabt, ich will Vista nicht einmal geschenkt haben! Vorher steige ich lieber komplett auf Linux um.

Wieso motzen eigentlich alle über Vista?
Tolle Grafik, keine Funktionen, verdammt hohe Hardwareanforderungen, präzise Maussteuerung und eine miserable Story -- bei Spielen wird bei einer solchen Beschreibung doch vom Mainstream immer gejubelt.

*edit* Muss man mal schauen... So ein unter XP compilierter Decoder sollte dann auch unter Vista laufen. Ich würde mich ja sogar darum kümmern... aber mein Compiler und Vista vertragen sich nicht. Weckt mich, wenn's ne neue MinGW-Version gibt. :))

emsa

04.04.2007, 23:42

Ich vermute, dass es, wenn undo oder meinereiner von der Partie sind, einen nativen FBSD-Client geben wird... also wozu das Linux-ABI? :>

Ich habe nichts gegen einen nativen BSD-Client, im Gegentum. Ich denke halt aber auch ökonomisch und wenn man es so einfacher (ökonomischer) abfackeln kann...

Und die Linux-ABI haben wohl die meisten (wohl oder übel) eh drauf und aktiv.

Ciao
emsa

Doofy

05.04.2007, 01:36

Ich habe nichts gegen einen nativen BSD-Client, im Gegentum. Ich denke halt aber auch ökonomisch und wenn man es so einfacher (ökonomischer) abfackeln kann...

Es gibt auch die Möglichkeit, gleich so zu programmieren, dass der Code plattformunabhängig ist. :)

Dann ist ein nativer BSD-Client nur ein weiterer Compile.

undo

05.04.2007, 02:58

Also ich habe morgen noch einen Arbeitstag und dann vier Tage frei. Ich hoffe, BR-Alpha wird bald umgestellt, damit ich mit dem neuen Dekoder experimentieren kann und versuchen, Verschlüsselungsverfahren sowie Schlüsselabfrage auzuknobeln.

Natürlich stimme ich den Vorrednern darin zu, daß ein ordentlich geschriebener CLI-Dekoder sich so gut wie unter jedem Betriebssystem kompilieren lassen sollte. Ich aber zum Beispiel kompilere alles aus Prinzip selbst und wäre nicht wirklich sehr froh über einen von irgendwem gebauten FreeBSD-Dekoder. Den will ich schon selber schreiben und genau wissen, was er so treibt :).

Doofy

05.04.2007, 06:50

... und genau wissen, was er so treibt :).

Nix böses. Das
chown root /usr/bin/otrdecode
chmod 4755 /usr/bin/otrdecode
ist reeeeeein kometischer Natur. :o)

dh42

06.04.2007, 18:36

Die aktuelle Version wurde gegen eine glibc mit --enable-kernel=... gelinkt, was natürlich in der Linux-ABI von FreeBSD in die Hose gehen kann (und mit guter Näherung auch tut).

Der OMR-Decoder -317 läuft bei mir auch nicht (Kernel too old), und ich verwende Linux mit Kernel 2.4.33.2.

Ein CLI-Decoder für *ixe ist Pflicht, nicht jeder kann/will mit X oder sonstwas buntem rumbasteln.

ACK. CLI ist Pflicht, GUI ist die Kür. Ob wie z.B. beim OTR-Decoder mit pyGlade/pyGTK, mit perl/Tk, tcl/Tk oder sonst wie ist egal.

Bis denn,
dh

kopfgeldjaeger

06.04.2007, 18:43

Ich benutz Ubuntu. Debian und Ubuntu kann man bei den Paketen ja zusammenfassen, wegen dem .deb. Das geht normalerweise ja auf beiden - wenn man's nen bissl anpasst. Viele Debian/unstable Pakete laufen zB unter Edgy Eft...

luffer

08.04.2007, 19:28

Macht bitte einen Dekoder für Windows 98!!!!
Bitte!! Sonst bin ich verloren!!!
Siehe hier: http://otrforum.com/showthread.php?p=70227

luffer

F_A

12.04.2007, 13:23

Ich habe Win98se und kann und will nicht nur wegen des Decoders ein anderes OS zuzüglich der dazu nötigen Hardware kaufen und mich darin einarbeiten. Mit einem Decoder für Win98 wäre mir also sehr geholfen und ich bitte flehentlich darum. Wenn den 5 Leuten mit den Äpfeln geholfen werden kann, könnte man dann nicht den 9 Leuten mit altmodischem Windows helfen?
Meinetwegen auch irgendwas, was nur mit GTK läuft oder nach Installation einer zusätzlichen Programmiersprache oder so. Es darf gern umständlich sein, Hauptsache es läuft (und ich finde ne Anleitung dazu). Ich hab eh fast nur Linuxsoftware hier laufen :)

Koko

12.04.2007, 13:43

Mit einem Decoder für Win98 wäre mir also sehr geholfen und ich bitte flehentlich darum.

Bitte die Foren Suche benutzen. Dazu gibt es schon etliche Threads und das ist auch zugesagt worden. :)

NGC-Ollie

12.04.2007, 13:45

wenn du linux laufen hast, kannst bestimmt auch den linux decoder benutzen ode?

F_A

12.04.2007, 14:06

Die Threads, die ich gefunden habe, verwiesen alle direkt oder indirekt auf diesen hier.
Dann muß ich wohl noch weiter suchen ...

Mr. S

17.04.2007, 14:27

Deswegen würde mich interessieren, ob du evtl. schon eine gewisse Vorstellung hast, wann dein Decoder für Linux fertig sein wird?
In meinem LinOTR fehlt eigentlich hauptsächlich nur noch der Cutlist und Decoder-Teil, deswegen würde mich interessieren, wie lange ich warten müsste :)
Das kann noch eine Weile dauern, da ich keine Lust habe in drei Wochen wieder einen neuen Decoder zu bauen werde ich jetzt erst mal warten. Es gibt da zur Zeit noch Überarbeitungsbedarf an den Verfahren.

Qt/X11 ist auch unter QPL verfügbar und die wiederum läßt sich etwa mit BSD kombinieren, wenn ich das richtig in Erinnerung habe. Im allgemeinen wird man aber wohl bei Qt nicht drum rumkommen, alles, was mit Qt linkt, auch im Quellcode offenzulegen.

Das ist kein Problem solange der Dekoder ein eigenständiges Programm ist. Ein weiterer Grund dafür, einen Kommandozeilendekoder zu schreiben und dann eine davon unabhängige GUI drüberzustülpen. So kann man den Quellcode der GUI freigeben und den Dekoder geheim halten.
BSD heißt man kann verwenden wie ich möchte. Das tut aber nichts zur Sache, da es wahrscheinlich auf eine Programmkombi Komandozeilendecoder + GUI rausläuft.

undo

17.04.2007, 14:40

BSD heißt man kann verwenden wie ich möchte.

Das wird zwar jetzt off-topic, aber ich wollte es nur kurz anmerken: Ich glaube mich erinnern zu können, daß man Qt unter QPL mit Code unter BSD-Lizenz linken darf. Die QPL fordert aber auch, daß man den Quellcode weitergibt - was dann wieder mit BSD nicht kompatibel wäre. Weiß also nicht mehr genau, wie die Lizenzlage aussieht.

falcon_

17.04.2007, 14:44

Qt/X11 ist auch unter QPL verfügbar und die wiederum läßt sich etwa mit BSD kombinieren, wenn ich das richtig in Erinnerung habe. Im allgemeinen wird man aber wohl bei Qt nicht drum rumkommen, alles, was mit Qt linkt, auch im Quellcode offenzulegen.
Aber nur mit der BSD-3-clause Lizenz, die 4-clause-Variante ist mit der GPL technisch gesehen inkompatibel.

Für Qt gibt es afaik auch kommerzielle lizenzen, aber damit habe ich mich nie wirklich beschäftigt

undo

17.04.2007, 14:48

[...] die 4-clause-Variante [...]

Die Variante ist zum Glück so gut wie tot. Unter BSD versteht man heutzutage eigentlich immer die 3-clause.

Für Qt gibt es afaik auch kommerzielle lizenzen

Ja, gibt es. Aber schau Dir mal die Preise an :).

Doofy

18.04.2007, 04:05

Das ist kein Problem solange der Dekoder ein eigenständiges Programm ist. Ein weiterer Grund dafür, einen Kommandozeilendekoder zu schreiben und dann eine davon unabhängige GUI drüberzustülpen. So kann man den Quellcode der GUI freigeben und den Dekoder geheim halten.

Ich halte es nach wie vor für bescheuert, das GUI unbedingt auf einem Kommandozeilendings aufsetzen zu wollen. Da gibt es eine Closed-Source Decoder-DLL, die dann direkt von den Decoderinterfaces genutzt wird. Viel schöner, als da groß mit Kommandozeilenkrams rumfuchteln zu müssen.

undo

18.04.2007, 04:18

Ich halte es nach wie vor für bescheuert, das GUI unbedingt auf einem Kommandozeilendings aufsetzen zu wollen. Da gibt es eine Closed-Source Decoder-DLL, die dann direkt von den Decoderinterfaces genutzt wird.

Ich denke, Deine Einstellung dazu liegt an einem Mißverständnis. Die eigentliche Arbeit wird von einem Dekoderkern erledigt, der womöglich closed source ist und darüber sitzt eine GUI - soweit stimmen wir überein.

Ob der Dekoderkern nun ein Kommandozeilenprogramm oder eine DLL (shared library unter *NIX) ist, ist eher ein technisches Detail. Für die meisten Benutzer macht es *keinen* Unterschied, denn sie sehen nur die GUI und die Schnittstelle zwischen GUI und Dekoder ist für sie völlig uninteressant.

Daß ein Kommandozeilenprogramm besser ist, hat eine Vielzahl von Gründen. Dazu zählt etwa, daß man ihn halt von der Kommandozeile nutzen kann, wenn man will - mehr Flexibilität für Poweruser also. Auch hat man so einen Prozeßtrennung, was die Speicherbereiche von GUI und Dekoder voneinander abgrenzt. Weiter entspricht so eine Aufteilung auch der *NIX Philosophie und macht etwa Debugging einfacher. Und schließlich vermeidet man auch Lizenzprobleme, weil GUI und Dekoder nicht miteinander gelinkt werden.

Wenn Du ein Benutzer bist, der eine GUI will, ist der Unterschied zwischen DLL und Kommandozeilendekoder für Dich also egal. Für Poweruser und Programmierer ist ein Kommandozeilenprogramm besser. Damit sollte die Entscheidung einfach sein :).

Mr. S

18.04.2007, 10:30

So, um die Dieskussion zu einem Ende zu bringen: QT gibt es in zwei Ausführungen, nämlich OpenSource (GPL) und kommerziell (BSD). Da der Decodercode wahrscheinlich geheim bleibt wird es also einen Kommandozeilendecoder geben und eine seperate GUI! Für eine komplette Implementierung müsste man ein anderes Toolkit nehmen (z. B. wxWindows LGPL).

Doofy

20.04.2007, 03:54

Da der Decodercode wahrscheinlich geheim bleibt wird es also einen Kommandozeilendecoder geben und eine seperate GUI!

Seperates GUI - ok. Ich würde aber nach wie vor auch den Kommandozeilendecoder vom Decodercode trennen. :) *mich wiederhol* :D

undo

20.04.2007, 04:00

Ich würde aber nach wie vor auch den Kommandozeilendecoder vom Decodercode trennen.

Das ist dann letzten Endes eine Glaubensfrage und wird von denen entschieden, die einen Dekoder schreiben :). Es wird einen von OTR geben, Mr. S schreibt einen und auch ich werde wohl einen beisteuern. Da sollte dann wirklich für jeden etwas dabei sein, mit dem er zufrieden ist. Und falls nicht, kann jeder gerne seine eigene Version schreiben, wenn er sich die Mühe macht, das Kodierverfahren auszuknobeln.

Mr. S

20.04.2007, 14:32

Wer pauschal sagt Java sei langsam, der hat noch nicht richtig damit gearbeitet! ;)
Wer pauschal so einen Blödsinn erszählt, der hat keine Ahnung! ;)

Java verbraucht auf jeden Fall deutlich mehr Resourcen als C++. Das liegt aber schon an der Struktur, bei C++ läuft das Programm direkt im Betriebssystem als Maschinencode, bei Java ist da noch eine art virtuelle Maschine (JRE) dazwischen. Das ist das gleiche wie bei .NET (VB.NET, C#), alles was in einer Laufzeitumgebung läuft ist langsamer als direkter Code. Vor allem weil diese Systeme interpretierte Sprachen sind, d. h. die werden zur Laufzeit von einem Code in Maschinencode übertragen und ausgeführt. Bei C++ wird direkter Maschinencode erzeugt. Interpretieren kostet Zeit und Resourcen, daran kann man auch nichts ändern.

So, das spricht natürlich nicht dagegen eine Java-Version zu veröffentlichen, es muss nur sicher gestellt werden, dass man es nicht so leicht decompilieren kann.

Taube

20.04.2007, 14:38

So, das spricht natürlich nicht dagegen eine Java-Version zu veröffentlichen, es muss nur sicher gestellt werden, dass man es nicht so leicht decompilieren kann.
Das ist kein Problem - ich habe einen Obfuscator (ProGuard) so angepasst, dass der decompilierte Code weder lesbar ist, noch erneut kompiliert werden könnte. Wer sich dann noch so viel Mühe macht, der schafft es auch ein Binary zu patchen - siehe diverse Kopiergeschütze Computerspiele.

Doofy

25.04.2007, 13:38

Na da kannst du dir ja nu ein (Taubene|Ostere|E)i drauf braten. :P

SGE

26.04.2007, 15:30

Dafuer funktioniert der alte Windoof-Dekoder5 unter wine wunderbar, so dass ich er bisher verschmerzen konnte, dass es keinen Dekoder fuer FreeBSD gibt.
Der neue Dekoder dagegen scheint nicht zu funktionieren unter wine, daher bin ich in Zukunft wohl angeschissen und muss dann wohl auf OTR verzichten :-(

Also mit dem Wine aus Debian Etch (0.9.25) hab ich hier schon mal eine Datei testweise entschlüsselt. Ging erstaunlich problemfrei. Weche Version von wine läuft unter BSD?

undo

26.04.2007, 15:34

Kann ich irgendwas dazu beitragen, dass es vielleicht in Zukunft auch einen FreeBSD-Dekoder gibt?

Keine Angst. Ich benutze jetzt meinen eigenen Dekoder unter FreeBSD und werde auch einen neuen schreiben, sobald das Verfahren umgestellt worden ist. Im Gegensatz zu meinem aktuellen Dekoder veröffentliche ich den dann aber, so daß auch andere was davon haben :).

undo

26.04.2007, 15:35

Weche Version von wine läuft unter BSD?

Immer die aktuellste. Im Moment also 0.9.35.

Mr. S

26.04.2007, 20:13

Keine Angst. Ich benutze jetzt meinen eigenen Dekoder unter FreeBSD und werde auch einen neuen schreiben, sobald das Verfahren umgestellt worden ist. Im Gegensatz zu meinem aktuellen Dekoder veröffentliche ich den dann aber, so daß auch andere was davon haben :).
Es wird einen Linux-Decoder geben, allerdings wird das verfahren gerade noch ein bischen überarbeitet, so dass es noch ein Weile dauern wird, bis sich da überhaupt was ändert.

real-snake

26.04.2007, 20:39

Also mit dem Wine aus Debian Etch (0.9.25) hab ich hier schon mal eine Datei testweise entschlüsselt. Ging erstaunlich problemfrei. Weche Version von wine läuft unter BSD?

Ich habs mit wine Version 0.9.35 versucht.

real-snake

26.04.2007, 20:44

Keine Angst. Ich benutze jetzt meinen eigenen Dekoder unter FreeBSD und werde auch einen neuen schreiben, sobald das Verfahren umgestellt worden ist. Im Gegensatz zu meinem aktuellen Dekoder veröffentliche ich den dann aber, so daß auch andere was davon haben :).

Na das klingt ja schon mal sehr gut :)
Wirds ein Port werden ?

Oder soll ich es zum Port machen, wenn mal ne Download Page feststeht ?
Oder soll ich den Download-Server stellen (hab ne Kiste in FFM fuer sowas) ?
Wenn ich irgendwie helfen kann, bitte Bescheid geben.

undo

26.04.2007, 20:47

Wirds ein Port werden ?

Schwer zu sagen. Auf Grund des so streng gehüteten Verschlüsselungsverfahrens will OTR ja keinen open source Dekoder. Wenn das Ding aber closed source sein soll, dann müßte ich es für viele verschiedene Versionen (5.x, 6.x, 7.x) und zig Architekturen bauen - oder den Port auf das beschränken, was ich selber nutze (i386, 6-STABLE). Mal schauen.

real-snake

26.04.2007, 20:55

Schwer zu sagen. Auf Grund des so streng gehüteten Verschlüsselungsverfahrens will OTR ja keinen open source Dekoder. Wenn das Ding aber closed source sein soll, dann müßte ich es für viele verschiedene Versionen (5.x, 6.x, 7.x) und zig Architekturen bauen - oder den Port auf das beschränken, was ich selber nutze (i386, 6-STABLE). Mal schauen.

Naja, ich denke man koennte es auf 6.x beschraenken. 5 nimmt doch eh kaum einer her, nachdem
es nicht grade der Hit war. Und 7.x hat bestimmt ein COMPAT_FREEBSD6 oder so (hab 7 noch nicht
angeschaut).
Bis auf ia64 und powerpc koennte ich auch nen Account anbieten zum compilieren auf anderen FreeBSD-
archs als x86 (also amd64, sparc64 und alpha).
Wobei auch mit x86 only und binary Port/Package schon viel geholfen waere, denke ich mal.

emsa

26.04.2007, 21:04

Naja, ich denke man koennte es auf 6.x beschraenken. 5 nimmt doch eh kaum einer her, nachdem
es nicht grade der Hit war. Und 7.x hat bestimmt ein COMPAT_FREEBSD6 oder so (hab 7 noch nicht
angeschaut).
Bis auf ia64 und powerpc koennte ich auch nen Account anbieten zum compilieren auf anderen FreeBSD-
archs als x86 (also amd64, sparc64 und alpha).
Wobei auch mit x86 only und binary Port/Package schon viel geholfen waere, denke ich mal.

Du glaubst nicht, wie viele 5.x ich durchaus (noch? ;) ) im Betrieb sehe. (Und sogar noch etliche 4.x)

Es sollte aber kein Thema sein, das Teil so zu bauen, dass es unter 4.x+ läuft. Oder ganz simpel die Linux-Version so zu bauen, dass sie in der Linux-ABI von BSD läuft.

Aber ich wiederhole mich... *soifz*

Ciao
emsa

undo

26.04.2007, 21:12

Es sollte aber kein Thema sein, das Teil so zu bauen, dass es unter 4.x+ läuft.

Wenn das neue Verschlüsselungsverfahren so ausfällt, daß ich den Dekoder als open source freigeben kann, dann wird es sicher möglich sein, ihn unter 4.x zu kompilieren. Andernfalls sehe ich mich außer Stande, Versionen vor 6.2 zu unterstützen. 4.x ist offiziell EOL, 5.x habe ich selber auch schon lange nicht mehr. So dumm ist das leider mit closed source :(.

emsa

26.04.2007, 21:17

Wenn das neue Verschlüsselungsverfahren so ausfällt, daß ich den Dekoder als open source freigeben kann, dann wird es sicher möglich sein, ihn unter 4.x zu kompilieren. Andernfalls sehe ich mich außer Stande, Versionen vor 6.2 zu unterstützen. 4.x ist offiziell EOL, 5.x habe ich selber auch schon lange nicht mehr. So dumm ist das leider mit closed source :(.

Was genau hindert Dich, Deinen Code entsprechend kompatibel zu gestalten? Mit Verlaub, aber das ist nun keine Hexerei ;) (Und auch nicht, entsprechende Binaries zu zaubern.)

Ciao
emsa

undo

26.04.2007, 21:20

Was genau hindert Dich, Deinen Code entsprechend kompatibel zu gestalten?

Nix. Ich denke durchaus, daß mein Code sich prima mit gcc 2.95 übersetzen läßt. Ich habe aber einfach keinen Rechner mit einer Version vor 6-STABLE mehr. Und extra VMs mit 4.x/5.x aufzusetzen ist schon Aufwand.

Taube

27.04.2007, 10:41

Cool - wieder was lang' gesuchtes gefunden und dazu gelernt! :)

Rava

27.04.2007, 11:30

Cool - wieder was lang' gesuchtes gefunden und dazu gelernt! :)Meinst Du damit mein Code-Snippet?

Den hatte ich nämlich leider lange verloren und mußte es mir wieder hart aneignen :p Backups waren zu viele oder genau der eine nicht gemacht :D
Leider weiß ich nicht wie man auf die Art ein xterm auslesen kann :confused: :confused: :confused:

LG
Rava

Taube

27.04.2007, 12:09

Ja, Snippet. Kann dir nur sagen, dass man über /dev/pts/* auf die Konsolen was ausgeben kann. Wenn Du eine Lösung findest: Du weisst, wo Du mich findest! :rolleyes:

fr3ddy

04.05.2007, 00:17

LINOTR fände ich ne feine Sache.

Die Trennung GUI <--> COMMAND Line is auch toll.

Das ganze als rpm UND! als deb Paket wäre cool, aber ich glaube nicht zweckmäßig. Da es dann für wirklich JEDE Distri ein extra Paket geben sollte.

Und wie schon angesprochen, würde ich darum bitten dass ganze (wenn notwendig zusätzlich) einfach nur als gepackte binaries anzubieten, wie der otrdecoder jetzt.

oder das ganze mit script in /usr/local zu installieren.

Leider habe ich zu wenig Ahnung von Dynamic und Static linked libs um einen qualifizierten hinweis abzugeben, vielleicht hilft mein Senf ja trotzdem irgendwie weiter.

Aufgrund verschiedener Distibutionen und Programmversionen kann es zu Problemen mit dyn link libs kommen.
Der OTR Decoder scheint ja auch dynamisch verlinkt zu sein (oder irre ich da?), aber scheint zumindest größtenteils zu funktionieren. Bis auf (unter anderem) BSD...

Aufgrund der LSB sollten vorschiedene Distris doch eigentlich kein Problem darstellen...

Darum würde ich vorschlagen den ganzen Spaß einmal dynamic und einmal statisch anzubieten.
Der erste Fall sollte beim Großteil funktionieren, und falls doch jemand ein Problem hat kann er auf die static Version zurückgreifen. Und wird, falls es so funktioniert, dann gerne die paar mehr resourcen in kauf nehmen.

Bei nativen Linux Spielen ist es schließlich auch üblich ist, die standard libs statisch einzubinden.

ciruZ

05.05.2007, 00:48

Hm, meine Linux Distribution ist nicht in der Liste drin und OpenBSD fehlt auch (Laptop).

Bis auf (unter anderem) BSD...
Geht bestens mittels compat_linux.

Warum denn noch ein Decoder? Der aktuelle Linux Decoder klappt doch gut. Und n GUI ist nur lästig. Beim CLI macht man sich einfach ein Script und braucht nur noch otr *.otrkey tippen. :)

PS: Warum fragen, welche Distribution? Source .tar.gz machen, dann können die Distributionen selber Pakete bauen. Und jeder kanns aufs Betriebssystem seiner Wahl portieren. Ne native OpenBSD Binary wär schon besser als das original Ding mittels compat_linux.

ciruZ

05.05.2007, 17:32

Das Verfahren heißt Blowfish und lässt sich überall nachlesen. Es werden lediglich ein paar Blöcke getauscht. Und den Key gibts vom OTR Server nach ner Anfrage via HTTP an ein PHP. So, jetzt hab ich gesagt, wies geht, jetzt is nix mehr mit Security by Obscurity, der Source kann raus ;). Security by Obscurity hat eben noch nie funktioniert. Erst recht, wenn die Binary überhaupt nicht gegen Disassemblen und Debuggen geschützt ist.

Der OTR Decoder läuft übrigens schon seit Jahren über compat_linux.

PS: Wo kann man deine BSD Version finden?

JennyMiller

05.05.2007, 17:40

Das Verfahren heißt Blowfish und lässt sich überall nachlesen. Es werden lediglich ein paar Blöcke getauscht. [...]

So weit nichts Neues, die Frage ist nur, wie die Blöcke verwürfelt werden ;-) Und die neue Key-Abfrage hab ich auch noch nicht kapiert. Beim alten Decoder wurde ja einfach der Dateiname übermittelt und es gab den Key zurück. Beim neuen sind das vermutlich irgendwelche Hashes. Den ganz neuen Decoder hab ich noch gar nicht ausprobiert :D

ciruZ

05.05.2007, 18:01

Dannn heißts halt den neuen Decoder abwarten und den durch nen Disassembler jagen und anschließend was als OpenSource schreiben. Gut, daß wir nicht in Amerika sind, da dürfte man sowas nicht :D.

undo

05.05.2007, 18:34

PS: Wo kann man deine BSD Version finden?

Nirgends :). Ich habe den auf die Schnelle gestrickt und solche Dinge wie Benutzername und Kennwort stehen fest im Code drin. Weil ja jetzt bald das neue Verfahren kommt, mache ich mir nicht mehr die Mühe, den alten Dekoder zu veröffentlichen.

Mr. S

06.05.2007, 12:15

Bitte einmal lesen:
http://www.otrforum.com/showpost.php?p=62440&postcount=2
http://www.otrforum.com/showthread.php?t=20057

@ciruZ
Ich weiss wie leicht es ist den OMR-Decoder zu hacken, man hat mir das einmal eindrucksvoll demonstriert! Nur beachte bitte einmal den Schaden den du verursachst, wenn du Leuten die Möglichkeit gibst, zu dekodieren ohne das Verfahren einhalten zu müssen! Dann wird OTR nämlich illegal. Daraus resultieren Klagen und Ermittlungen gegen die Betreiber und die Nutzer. Bei Tauschbörsen werden ja auch nicht nur die Betreiber sondern auch die Nutzer verklagt. Ich halte normalerweise auch nichts davon Closed-Source zu benutzen, aber in diesem Fall geht es erst einmal nicht anders!

ciruZ

06.05.2007, 14:24

Der Source ist doch eh nicht das Problem. Jeder, der nen Sniffer bedienen kann, merkt: Einmal die Antwort vom Server abfangen, nen eigenen HTTP Server aufsetzen der die selbe Antwort zurück gibt und in der /etc/hosts (die Hosts-Datei gibts auch unter Windows!) den Host von OTR auf 127.0.0.1 legen. Für den HTTP-Server reicht sogar schon netcat. Hab ich selber schon gemacht, als mein Rechner instabil lief, damit ich die Files auf jeden Fall dekodieren kann.

Man sieht, OpenSource würde nichts daran ändern, daß jemand, der will, einfach seinen eigenen OTR Server aufsetzt. Es könnte sogar jemand einen öffentlichen Server aufsetzen, auf dem alle Keys gesammelt werden. So ne Seite könnte sogar die Hosts-Datei anbieten und beschreiben, wie man sie installiert, sodaß es wirklich jeder hinkriegen würde.

Das Problem ist wie man sieht garnicht der Source, sondern vielmehr das Verfahren an sich. Man sollte sich da einfach ein besseres Verfahren überlegen. Z.B. so:

Jeder User kriegt einen Pubkey und einen privaten Key. Den privaten Key hat nur der User. Der Server hat alle Pubkeys. So, wenn der User jetzt eine Aufnahme macht, dann wird die ID des Pubkeys des Users in eine Liste getan. Anschließend wird das ganze mit nem symmetrischen Algorithmus (z.B. AES) verschlüsselt. Der Key vom symmetrischen Schlüssel wird anschließend mit RSA verschlüsselt - einmal für jeden User, der aufgenommen hat.

Auf diesem Wege kann ein User das File nur entschlüsseln, wenn er es wirklich aufgenommen hat und der AES Key mit RSA für seinen privaten Key verschüsselt wurde. Das ganze könnte man z.B. via GPG lösen. Das File kann man jetzt natürlich auch noch mehrmals entschlüsseln, allerdings wird es doch bedeutend weniger Leute geben, die tatsächlich ihren privaten Key weitergeben. Und die Login-Daten kann man auch jetzt weitergeben und so wen anders auch noch Dekodieren lassen (2x Dekodieren geht ja immer).

undo

07.05.2007, 00:08

Klingt gut, hast du mal n Link dazu?

Sorry, bin gerade vor ein paar Minuten aus dem Urlaub nach Hause gekommen und muß mich erstmal ums Auspacken und ein Abendessen kümmern :). Aber Google findet zu dem Thema einige sehr interessante Publikationen.

Wenn das wirklich so geht, dann könnte man das ganze eigentlich sogar OpenSource machen :).

Absolut. Das ist auch mein Ziel.

Taube

07.05.2007, 09:24

Die Mehrleistung wäre minimal. Es wird ja nur der AES key mit RSA für mehrere Keys verschlüsselt. D.h. es wären ein paar Byte, die für jeden User, der aufgenommen hat, einmal verschlüsselt würden. Das dürfte von der Zeit her garnicht auffallen, die dürfte dafür draufgehen, das eigentliche File mit AES zu verschlüsseln.

Und was ist mit der Wishlist?

Raus

07.05.2007, 09:29

Und was ist mit der Wishlist?

Ergänzend: Und mit den Mirrors wäre dann Schluß?

Oder verstehe ich hier grundsätzlich was falsch?

Taube

07.05.2007, 09:34

Ergänzend: Und mit den Mirrors wäre dann Schluß?

Wenn ich das richtig verstehe wird für jeden aufgenommenen Benutzer ein eigener kleiner Eintrag an die Datei angefügt aber dennoch eine gemeinsame Datei angeboten. Dann ist die Frage, wie sich das bei Top-Filmen mit vielen Aufnahmen auswirkt.

Raus

07.05.2007, 09:37

Danke für die Erläuterung.

Wie aber soll ein Mirror - der mich ja nicht kennt - an diese zusätzlich Datei kommen?

JennyMiller

07.05.2007, 11:58

Wenn ich das richtig verstehe wird für jeden aufgenommenen Benutzer ein eigener kleiner Eintrag an die Datei angefügt aber dennoch eine gemeinsame Datei angeboten. Dann ist die Frage, wie sich das bei Top-Filmen mit vielen Aufnahmen auswirkt.

Nein, nicht angefügt, sondern in den Verschlüsselungs-Schlüssel mit reingepackt. Es bleibt bei einer Datei für alle.

Ich halte das Ganze allerdings für nicht sinnvoll, da ja ohnehin die meisten die %%%-Wishlist haben. Und damit müsste man *alle* Keys reinpacken. Dann kann man auch gleich einen Key für alle verwenden.

ciruZ

07.05.2007, 20:37

Ich halte das Ganze allerdings für nicht sinnvoll, da ja ohnehin die meisten die %%%-Wishlist haben. Und damit müsste man *alle* Keys reinpacken. Dann kann man auch gleich einen Key für alle verwenden.

Auch die %%% Wishlist erlaubt net alles. Es wird nur das seit dem Hinzufügen zur Wishlist aufgenommen.
Das wäre aber kein Problem, da die Mehrlast pro User minimalst wäre.

Mr. S

08.05.2007, 15:07

Im Grunde ist das vorgeschlagene Verfahren relativ simpel, man verschlüsselt den Inhalt mit einem geheimen Schlüssel. Der geheime Schlüssel wiederum wird mit allen erlauben Userschlüsseln verschlüsselt und angehängt. Nun kann jeder User die Datei mit seinem ganz privaten Schlüssel decodieren, allerdings bringt das auch nichts, da man den geheimen Schlüssel ja nur einmal auslesen und weitergeben muss. Außerdem die Schlüssel für alle zugelassenen User abzurufen und zu verschlüsseln würde die Datenbank noch schneller in die Knie zwingen. Die läuft ja eh schon am Rande des Zusammenbruchs. Die Dateimenge würde sich in Grenzen halten:
100000 User * Schlüssel 16 Byte = 1,52587890625 MB

So, und jetzt bitte ich einmal darum beim Thema zu bleiben! Es geht hier um die verwendeten Betriebssysteme und nicht um Decoderstrategien!

ciruZ

08.05.2007, 17:20

Bei undos Methode soll das ja grade nicht sein. Daher bin ich ja so auf eine Beschreibung des Verfahrens gespannt.
100000 User sollten für eine Datenbank kein Problem sein - oder nutzt ihr MySQL? MySQL ist dafür bekannt, _SEHR_ schnell in die Knie zu gehen. Von den OpenSource Datenbanken hält glaub ich PostgreSQL am meisten aus, da sind Datenbanken mit 1 TB Größe bekannt, die sich immer noch recht flott nutzen lassen sollen.
Außerdem denke ich nicht, daß alle User eine %%% Wishlist haben.
Und im Übrigen denke ich, daß das sehr wohl mit dem Thema zu tun hat. Denn es geht um die Entwicklung eines OSS-Decoders.