| Hacken der TOAD Freeware Version |
|
|
| Donnerstag, 15. Januar 2009 um 18:01 | ||
|
TOAD ist eigentlich ein ganz nettes Produkt, um mit ORACLE Datenbanken umzugehen. Es unterstützt (fast) alle Features, die ORACLE anbietet. Dafür kostet es allerdings auch Geld. Aber Quest Software ist so freundlich, eine Freeware-Version bereitzustellen, die zwar eingeschränkte Funktionalitäten bietet, dennoch eine Entscheidungshilfe für den Kauf des Produkts bietet. Das Problem: Nur maximal fünf Kollegen können sich mit der Freeware-Version in einer Datenbank anmelden, weitere Connections verweigert TOAD...normalerweise... Das folgende Vorgehen könnte verwendet werden, um diese Beschränkung zu umgehen. Das macht man natürlich nicht, weil man damit die Lizenzbedingungen von Quest verletzt, denen man vor dem Download der Freeware-Version zugestimmt hat! Ausserdem ist die hier vorgeschriebene Methode weiss Gott nicht optimal. Im Gegenteil, sie ist ein harter Eingriff in die Datenbank, den man einer Produktions-DB nicht zumuten sollte. Wir hacken also nicht TOAD (insofern verletzten wir ja eigentlich nicht die Lizenzbedingungen), sondern wir hacken die DB, so daß TOAD nicht mehr in der Lage ist, festzustellen, wieviel User gerade mit Hilfe von TOAD auf die DB zugreifen. Nochmal: Machen Sie das nicht mit einer Datenbank, auf die Sie Wert legen. Der Hack sorgt dafür, dass andere Produkte oder Features der DB eventuell nicht mehr ordnungsgemäß funktionieren. Wie stellt TOAD fest, wieviel User mit TOAD verbunden sindAnscheinend guckt TOAD in die View V$SESSION, und zwar in die Spalten PROGRAM und/oder MODULE, denn da steht zum einen das Programm drin, mit dem man mit ORACLE verbunden ist, zum anderen, dass es sich um die Freeware-Version handelt. Quick-and-very-very-very-dirty-HackMan verhindert, dass TOAD diese Informationen sieht, in dem man die Data-Dictionary-View verändert. V$SESSION ist lediglich ein Synonym auf SYS.V_$SESSION. Um diese Veränderung vorzunehmen, muß man sich als SYS connecten. Die Idee ist, den Inhalt der Spalten PROGRAM und MODULE komplett auszublenden. Mit einem Blick in die View DBA_VIEWS stellt man fest, wie V_$SESSION definiert ist, und ersetzt die View-Definition durch create or replace view v_$session as select Oben stehende View-Definition stammt aus einer 11G-Datenbank, u.U. sieht die View in 10g anders aus, also bitte prüfen. Das entscheidende ist, die Spalten Program und Module einfach durch NULL zu ersetzen, TOAD kann jetzt nicht mehr erkennen, welche Programme mit der DB verbunden sind. Nachteil: Der Admin auch nicht... Ausserdem ist der Eingriff derart schwerwiegend, dass niemand einer solchen Veränderung der DB zustimmen würde. Wir ändern hart an den ORACLE-Interna! Das ist nicht gut! Und der ORACLE-Support würde Ihnen garantiert sagen, dass Sie unter diesen Umständen jegliche Support-Leistungen verloren haben... Immernoch-Quick-und-weniger-dirty-HackDa durch oben beschriebene Maßnahme überhaupt gar keine Programme und Module mehr angezeigt werden, könnte es durchaus sein, dass andere Tools oder ORACLE-Werkzeuge streiken und die Arbeit niederlegen. Die nächste Idee ist, mit Hilfe von DECODE TOAD vorzugaukeln, es wäre SQLPLUS. Ich habe diese Variante nicht ausprobiert, aber sie sollte funktionieren. In obiger View-Definition ersetzt man null as "PROGRAM" durch decode ("PROGRAM",'TOAD.EXE','SQLPLUS.EXE',"PROGRAM") Dieses Vorgehen ist zwar immer noch extrem "invasiv", aber nicht mehr mit so vielen Nebeneffekten verbunden. Andere Applikationen, die auf V$SESSION zugreifen, sehen ein ordinäres SQLPLUS. Eine andere Idee wäre, in der Spalte MODULE den FREEWARE-String durch ein lizensiertes TOAD zu ersetzen. Ich freue mich, wenn jemand diese Herangehensweise testet und mich informiert. Auch-Quick-und-eigentlich-nicht-dirty-HackV$SESSION ist ja lediglich ein Synonym auf V_$SESSION. Wenn ein User ein lokales Objekt hat, das genauso heisst wie ein PUBLIC SYNONYM, hat dieses bei der Abfrage Vorrang gegenüber dem Public Synonym. Auch folgende Idee habe ich nicht ausprobiert, hier hängt es davon ab, wie TOAD programmiert ist. Der Versuch hat auf jeden Fall den Vorteil, dass ich die DB nicht komplett in Mitleidenschaft ziehe und der Versuch nur mein lokales Schema betrifft. Ausserdem kann ich den Versuch schnell reversibel machen, um den originären Zustand wieder herzustellen. Man legt einfach eine lokale View V$SESSION an und blendet dabei die Spalte PROGRAM und/oder MODULE aus: create or replace view v$session as select Vorteil: Wir müssen uns nicht als SYS connecten, wir ändern nichts an den DB-Interna, sondern legen lediglich eine View in unserem lokalen Schema an. Alle anderen bleiben unbeeinflusst. Nachteil: Nur unsere TOAD-Connection sieht keine anderen parallelen TOAD-Connections. User, die sich mit einem anderen Schema verbinden, unterliegen wieder der Beschränkung von maximal fünf Connections. Aber wenigstens können wir bei unserem Schema auf jedenfall eine Connection aufbauen, selbst wenn bereits fünf User connected sind. FazitMit dem ersten beschriebenen Hack funktioniert das Aushebeln der Connection-Beschränkung auf fünf User auf jeden Fall, aber wer darf sich schon als SYS connecten und möchte die Datenbank-Interna derart verbiegen. Die anderen beiden Varianten sind Ideen, die funktionieren könnten, ich freue mich, wenn mir jemand Feedback gibt. Bitte bedenken: Sie verletzten die Lizenzbedingungen für den Einsatz von TOAD, denen Sie beim Download der Freeware-Version zugestimmt haben! Daher ist das hier beschriebene Vorgehen lediglich eine Darstellung der Möglichkeiten. Machen tun wir das natürlich nicht.
|
||
| Aktualisiert ( Donnerstag, 15. Januar 2009 um 19:45 ) | ||

