[JDBC] Verbinding met exotische database

[Schapie]

Ik heb hier een exotsche door een extern bedrijf ooit ontwikkelde database die ik graag zou willen benaderen met een willekeurige management tool, echter heb ik wat problemen om de juiste driver class te achter halen.

De database is actief draaiende onder een Java omgeving, maar ik kan niet specifiek achter halen welke driver class ik nu nodig heb. Kan ik dit door middel van een debug optie achterhalen?
(De software welke communiceert met de database functioneert immers, en kan ik gebruiken.)
Ik weet wel zeker wat de driver locatie is, maar ik heb een kijkje in genomen in de .jar, en deze is toch wel erg groot om even wat te proberen.

Als ik hier een debug optie voor heb kan ik dan ook de JDBC url achterhalen? Ik heb wel gewoon username en password voor de database dat is het probleem niet, echter wel de manier om verbinding te maken...

Helaas schiet de bijgeleverde documentatie wat te kort, voor de andere databases die de applicatie gebruikt is wel van alles voor handen.

[Daos]

De jar kan je uitpakken met een unzipper. Probeer daarna eens een Java decompiler. Je kan daarmee de oorspronkelijke code bijna exact terug toveren.

[_Erikje_]

Misschien ken je het via de API achterhalen.

http://docs.oracle.com/ja...use/DatabaseMetaData.html Sysout deze informatie

[Johnsel]

Wireshark is ook nog een optie, naar de raw pakketjes kijken en zo ontcijferen wat het is/doet.

[_Erikje_]

und?

[gmblom]

Aangezien je de driver locatie weet, kun je waarschijnlijk ook wel achterhalen voor welk type database deze driver ontwikkeld is. Door de bijbehorende documentatie op te zoeken kun je kijken op welke manier je je connect string moet opbouwen. Meestal moet je hier een server naam en misschien nog een database naam meegeven, maar ook dat lijkt me geen rocket science om uit te vinden. Je geeft aan dat username en password al aanwezig zijn... dus, je hebt alles lijkt me zo.

[JJ93]

Daos schreef op zaterdag 02 mei 2015 @ 16:56:
De jar kan je uitpakken met een unzipper. Probeer daarna eens een Java decompiler. Je kan daarmee de oorspronkelijke code bijna exact terug toveren.

Hangt er van af hoe de .jar geproduceerd is, als ze er eerst nog een obfuscator over heen gegooid hebben gaat het wat lastiger.

Maar met JD-GUI kan je mooi op strings zoeken binnen de .jar classes
Een stap verder is FernFlower om de source code terug te toveren

[SPee]

Is het een officiele JDBC4 driver, dan staat de naam van de Driver in het bestand META-INF/services/java.sql.Driver

Verder kun je in die jar op zoek gaan naar classes die de java.sql.Driver interface implementeren. Voor een JDBC driver is dit nodig. Hierin staan methods gedefinieerd die worden gebruikt bij het verbinden en krijgt (als string) de connection url mee, die je later nodig hebt.
Anders is het een volledige eigengemaakte oplossing en zal dit niet lukken.
De java SDK heeft o.a. tools om een class (gedeeltelijk) te decompileren.

Andere tip: je kunt ook kijken naar de package namen (directory structuur) of ze niet toevallig van een standaard product gebruik maken en die gewoon meeleveren (b.v. JavaDB, postgres, derby). Dat zou het wat makkelijker maken.

Wat betreft een obfiscator; deze kan niet alles verbergen. Classes waar je geen controle over hebt (b.v. de JDK) blijven gewoon leesbaar met decompilen. Ik heb echter vrij weinig meegemaakt dat zo'n tool is gebruikt. Java classes zijn vrij leesbaar, zelfs met een decompiler. Wat ik echter wel heb gezien, is dat ze 'native' gaan en de daadwerkelijke implementatie inlezen als externe dll.
Je weet dan niet hoe hij de verbinding opzet. Hooguit de URL connectie die je moet gebruiken.