[vb]Strings in exe encrypten

[sopsop]

Om diverse redenen heb ik in mijn sourcecode wat hardcoded SQL-server scripts zitten, dat moet zo blijven (het is overigens VB6).

Nu is het probleem dat na het compilen (zowel P als Native code) de Strings gewoon zichtbaar zijn in de exe. Gewoon met een hexeditor, de strings staan dan netjes achter elkaar in uncode.

Dat wil ik niet. Op die manier is het mogelijk om de scripts te extracten of zelfs de exe te wijzigen. Aangezien consultants mijn progje moeten gaan gebruiken en die alle manieren aanpakken om de voorgeschreven werkwijze te verstieren wil ik dus die strings niet zichtbaar hebben.

De volgende opties heb ik zelf bedacht:

• Gewoon de ascii waardes van ieder karakter in de string bij elkaar optellen en die waarde vergelijken opnieuw met de waarde van de string in de exe bekijken.
  Voordeel: de exe kan niet worden gewijzigd. Als er een karakter wordt gewijzigd, signaleerd de exe dit zelf.
  Nadeel:
  1. Bij iedere wijziging aan de string in de code, moet dat getal opnieuw worden uitgerekend, wat nogal omslachtig is.
  2. De scripts kunnen nog steeds uit de exe worden gehaald.
• Het script encrypten en dan in code plakken.
  Voordeel: Script niet of nauwelijks in de exe te wijzigen en te extracten
  Nadeel: code niet meer leesbaar

Eigenlijk zoek ik gewoon een manier om de code encrypted te compilen, maar dat kan ik dus nergens vinden. Iemand een handig id?

[KinkyClown]

Waarom XOR je het niet met een vast getal? Dat is waarschijnlijk wel veilig genoeg.

[MissingDog]

Je zou alle strings in een encrypted resourcefile kunnen gooien, die file dus referencen zodra je een van je sql-scripts nodig hebt, laten decrypten, in je app gebruiken op de manier zoals jij dat wilt en klaar is boppert!

[Remco]

Anders gooi je ze naar Ascii code, en laat je je string tijdens het runnen van je prog hiermee vullen.

[whoami]

boppert schreef op 08 mei 2003 @ 10:56:
Om diverse redenen heb ik in mijn sourcecode wat hardcoded SQL-server scripts zitten, dat moet zo blijven (het is overigens VB6).

Waarom?
Het zou veel eenvoudiger zijn als je die SQL Server 'scripts' in Stored Procedures zet. (En beter ook).

[sopsop]

Remc0 schreef op 08 May 2003 @ 12:02:
Anders gooi je ze naar Ascii code, en laat je je string tijdens het runnen van je prog hiermee vullen.

Dan is de string niet meer zichtbaar in de source.

whoami schreef op 08 mei 2003 @ 12:05:
[...]

Waarom?
Het zou veel eenvoudiger zijn als je die SQL Server 'scripts' in Stored Procedures zet. (En beter ook).

Ik maak stored procedures aan met dat script. Het is om een de database structuur bij klanten aan te passen, fysiek kunnen wij niet 1,2,3 bij de SQL server van de klant komen. De consultants verdienen dus centjes door het land door te kachelen om een nieuwe versie van onze software neer te zetten. Als de database structuur daarvoor gewijzigd moet worden krijgen ze dus mijn progje mee, dat starten ze op, die maakt stored procedures op de sqlserver aan en voert die vervolgens uit, om ze daarna weer weg te gooien.

[Remco]

boppert schreef op 08 May 2003 @ 12:23:
[...]
Dan is de string niet meer zichtbaar in de source.

Dat maakt toch niet uit ?
Of zijn het er vele of zo ?
Waarvoor dient die string dan ?

[sopsop]

Remc0 schreef op 08 mei 2003 @ 12:25:
[...]

Dat maakt toch niet uit ?
Of zijn het er vele of zo ?
Waarvoor dient die string dan ?

String is een script die een stored procedure aanmaakt. En dat zijn er vele.
Het progje houdt aan de hand van een versie nummer in een tabel van de database bij tot waar een en ander is bijgewerkt. Volgens worden 1 voor een alle scripts uitgevoerd die de database vanaf versie X bijwerken tot de huidige versie.
Die scripts zijn vaak een paar A4tjes lang.
Om alles onderhoudbaar te houden en makkelijk te bewerken wordt alles in de exe gebakken, iets dat ik overigens niet beslist heb, maar dat terzijde.

Ik ben nu aan het uitzoeken of die encrypted resource files een goeie oplossing zijn.