[algemeen] Uniek nummer in elke executable

[Farmerwood]

Momenteel ben ik bezig met een programmatje in c++ dat zich op een server moet aanmelden en identificeren. De gegevens van de gebruiker staan in een MySQLtabel. (belangrijkste: id, name en pass)
Nu is het de bedoeling om de identificatie hardcoded in het programma te zetten. (Dit is een eis en moet dus zo gebeuren). Nu ben ik dus op zoek naar een manier om wanneer een gebruiker die ingelogd is op de site en het programma wil downloaden meteen een uniek nummer (het userid) in het programma te verwerken. Want om nou van te voren voor ruim 1000 gebruikers het programma te gaan compilen zie ik niet zitten.

Ik heb alleen totaal geen idee hoe ik dat nou het beste aan kan pakken en een zoektocht op google leverde ook niet echt een antwoord op. Wie kan daar tips over geven?
Op de server draaien PHP en MySQL.

[Infinitive]

Wat dacht je van een globale static string:

volatile char id[] = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

Na compilatie zoek je op waar die xxx-jes staan en noteer je de positie. Voor het aanbieden ter download kopieër je het programma naar een tijdelijke locatie voor die klant en verander je de xxx-jes in de user-id.

[EfBe]

Infinitive schreef op zondag 05 december 2004 @ 17:23:
Wat dacht je van een globale static string:

volatile char id[] = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

Na compilatie zoek je op waar die xxx-jes staan en noteer je de positie. Voor het aanbieden ter download kopieër je het programma naar een tijdelijke locatie voor die klant en verander je de xxx-jes in de user-id.

Lijkt me compleet onbeheerbaar, stel dat je een fixed versie maakt? Kun je al je andere code ook patchen.

Het enige dat de TS kan doen is tezamen met de .exe een encrypted databestandje mee te leveren, dit bestandje wordt on the fly gemaakt op de server en bevat de code. (ook crypted). De .exe decrypt de datafile, laadt de code, stuurt deze (is ook encrypted) naar de server en daar wordt de code gedecrypt ter verificatie.

Als dit overigens is bedoeld ter copy-protection: forget it. Men hackt gewoon de hele routine eruit. Het is maar een hint, voordat je veel werk gaat doen.

[Farmerwood]

EfBe schreef op zondag 05 december 2004 @ 20:47:
Als dit overigens is bedoeld ter copy-protection: forget it. Men hackt gewoon de hele routine eruit. Het is maar een hint, voordat je veel werk gaat doen.

Het is niet bedoeld voor copy-protection, maar ter identificatie.
Een apart bestandje heb ik ook aan gedacht, maar dan zit het dus niet zoals mijn vraag was in de executable.

[Zoijar]

Je kan z'n netwerk MAC uitlezen, die is globaal uniek. Zo genereer je ook GUIDs in windows voor com objecten etc.

[Virgil]

Doe het zo;
De executable meldt de gebruiker aan, er gaat een algoritme lopen, de uitkomst daarvan wordt tesamen met login id en password id naar de server gestuurd. Als die drie codes niet samen overeenkomen, logt hij niet in.

Je stelt dus van te voren de unieke key in voor de gebruiker.

Wat je dan kan doen, om zelf niet voor elke gebruiker de unieke key te verzinnen. Is bijhouden hoevaak een gebruiker aanmeldt. Als het de eerste keer is dat de gebruiker zich aanmeldt wordt er dus gecheckt of de uitkomst van de algoritme niet al in gebruik is bij een andere gebruiker (in de database). Zodra de uitkomst van de algoritme bij een vrije key komt zegmaar, wordt deze key voor deze gebruiker vastgezet. Vanaf dan hoort deze key bij deze user.

Zodra dus de uitkomst van de algoritme overeenkomt met de user id + user pass stop je de algoritme, en start het werkelijke programma.

--edit
Anders verzin een algoritme die een gebruikers id zo versleuteld dat er maar 1 uitkomst mee mogelijk is. Deze algoritme wordt uitgevoerd als de gebruiker op login klikt. Dit wordt vergeleken met de gegevens in de database.

Als het de 1e keer is van aanmelden, wordt deze key in de database opgeslagen. En voortaan wordt het gechecked.
-/edit

[ Voor 17% gewijzigd door Virgil op 05-12-2004 21:17 ]

[Soultaker]

Kan iemand toelichten wat er nu precies mis is met Infinitive's suggestie? Het lijkt mij een afdoende oplossing voor het probleem; verreweg de beste suggestie die ik tot nu toe gelezen heb.

[Verwijderd]

het MAC-adres van een netwerkkaart in een pc is altijd uniek, routine voor het opzoeken v/h mac-adres kun je zo vinden (google).

eenvoudig + oplossing voor het pobleem (?)

[Tux]

Verwijderd schreef op zondag 05 december 2004 @ 22:53:
het MAC-adres van een netwerkkaart in een pc is altijd uniek, routine voor het opzoeken v/h mac-adres kun je zo vinden (google).

eenvoudig + oplossing voor het pobleem (?)

Een MAC-adres is op best veel netwerkkaarten te veranderen

[Infinitive]

Soultaker schreef op zondag 05 december 2004 @ 21:33:
Kan iemand toelichten wat er nu precies mis is met Infinitive's suggestie? Het lijkt mij een afdoende oplossing voor het probleem; verreweg de beste suggestie die ik tot nu toe gelezen heb.

Het groote probleem van mijn oplossing is een versie probleem. Zodra je een nieuwe versie van je applicatie bakt, moet je overnieuw de invoeg-positie van het identificatie-nummer zoeken.

Nu kan het ook makkelijker: aan de achterkant van een windows executable kan je willekeurige text dumpen, dus daar zou je die code ook achter kunnen plakken. Je kan er alleen niet zo makkelijk vanuit je programma zelf bij. Op zich niet zo'n heel nette aanpak, maar wel eenvoudig door een downloadscript oid te realiseren.

Een nettere manier is misschien door de code in een resource-file te plaatsen. Ik weet alleen niet of er een tool beschikbaar is om aan een executable een text-resource toe te voegen nadat je applicatie al in elkaar gelinkt is.

[ Voor 3% gewijzigd door Infinitive op 05-12-2004 23:05 ]

[MSalters]

Infinitive's suggestie kan natuurlijk ook in een IDENTITY.DLL file. Hoef je niet op je server 1000 versies van de hele app te hebben, alleen van die DLL en die is <1K.

[Tomatoman]

Het is me niet duidelijk waarom de identificatie in de executable moet staan en niet in een apart bestand. Zodra je de executable gaat veranderen heb je daar een tweede executable voor nodig, want een geopend bestand (en dat is een werkende executable) kan niet gewijzigd worden. Gevolg: de executable kan zichzelf nooit op de harddisk wijzigen. Je hebt dus altijd een extern programma nodig dat de unieke code erin stopt.

Voor het genereren van een unieke code heb je een zeer eenvoudige oplossing ter beschikking: creëer een nieuwe GUID. Die is gegarandeerd uniek en altijd 128 bits lang. Wil je dat ding persé in de executable opslaan, doe dat dan in een resource, bijvoorbeeld als een string table of een (user-defined) resource van het type RCDATA. Dat is het eenvoudigst en ook het netst. Als je in andere gebieden van de executable gaat zitten frutten zullen sommige virusscanners dat (terecht) verdacht vinden.

[Verwijderd]

Je kunt gewoon je unieke code achter de executable plakken. Stel je neemt een code van 16 bits, dan zijn de laatste 16 bits van je programma die code. Dit kan zelfs in dos met een doodnormale copy opdracht al gedaan worden.

Dus.. iemand wil het programma downloaden. Je maakt op dat moment een unieke code aan en plakt die achter aan je executable. Dit verstoort de werking van de executable niet. In de executable zelf maak je een routine dat hij het eigen bestand opent, en de laatste 16 bits inleest. Eventueel kun je hier nog iets met MD5 mee uithalen, zodanig dat niet elke willekeurige combinatie van 16 bits gepakt wordt.

Als kopieerbeveiliging relatief naadje, dan zou alleen wel iemand al de moeite moeten nemen het te hacken.

[RobIII]

Ten eerste vind ik de eis ronduit belachelijk. Geef me één goede reden waarom het in de .exe zou moeten zitten. Ten tweede gaan er waarschijnlijk een hoop virusscanners zeuren als je self-modifying code gaat schrijven. Dus dan moet de "wijziging" zowieso al serverside gebeuren alvoor je de .exe verstuurd naar iemand.

Waarom niet gewoon met een Login/Pass systeem ofzo? Geef een GUID ofzo terug bij de eerste keer aanmelden, knal die in het register, bestand of losse resource van je keuze et voila. Ik zie niet in waarom het in de .exe zou moeten.

Inderdaad, MAC adressen zijn easy te spoofen, en een losse resource is makkelijk aan te passen. Maar waarom het wiel opnieuw uitvinden als het al vaak genoeg (IMHO beter dan dit) gedaan is? Zorg gewoon voor een sluitende aanmeld/login functie en je bent even ver als nu, alleen dan beter.

Mocht je mijn (goed bedoelde) advies toch in de wind willen slaan, dan zou ik toch nog maar eens Infinitive's suggestie goed overwegen, want dat is dan nog de meest zinnige (maar helaas dus wel onbeheersbaar en programmeertechnisch ronduit ranzig )

Overigens is het, in tegenstelling wat hier beweerd wordt, niet geheel onmogelijk om "jezelf" aan te passen (dus de lopende .exe aan te passen). Alleen vrees ik dus een "groot alarm" van de meeste virii scanners.

[ Voor 10% gewijzigd door RobIII op 06-12-2004 01:09 ]

[Verwijderd]

Ik heb geen idee wat de voor/nadelen zijn, maar je zou toch de bestandsnaam als identificatie kunnenn gebruiken? Maak een md5 van userid + salt en bied het bestand ter download aan met de bestandsnaam md5+.exe.

[Verwijderd]

Je kan er alleen niet zo makkelijk vanuit je programma zelf bij.

Waarom niet? Gewoon executable read-only openen en lezen maar?!

Gezien de eis, lijkt dat mij de makkelijkste optie. Gewoon achteraan je .exe plakken. Zit je niet met versieconflicten, en is makkelijk uitvoerbaar voor een downloadscript.

[pjvandesande]

Je zit ook nog met een probleem, dat als er een anderen user wil onloggen op zijn account op de excecutable van een anderen user dat dit niet mogelijk is.

Ik zou de reactie van RobIII nog maar is goed lezen. Dit lijkt mij namelijk programmeer technisch de beste oplossing.

Verwijderd schreef op maandag 06 december 2004 @ 02:06:
Ik heb geen idee wat de voor/nadelen zijn, maar je zou toch de bestandsnaam als identificatie kunnenn gebruiken? Maak een md5 van userid + salt en bied het bestand ter download aan met de bestandsnaam md5+.exe.

Dat lijkt mij nou helemaal niets, bestandsnaam is namelijk zo aan te passen door de gebruiker. Ook vind ik GR3FRR42VFBGFR11E.exe niet echt netjes staan.

[MisterData]

Gewoon een resource van maken, die zijn toch redelijk makkelijk aan te passen achteraf? Eventueel kan die resource in een aparte DLL... Google bijvoorbeeld eens op ResHacker, dat is een programma waarmee resources van al gecompileerde .exe's aan te passen zijn Het kán dus wel!

[ Voor 35% gewijzigd door MisterData op 06-12-2004 10:39 ]

[Farmerwood]

De gebruikers van het systeem bestaan al in de database dus allerlei codes genereren lijkt me onnodig aangezien elke user in de database al een uniek ID heeft. Dit ID kan het programma dan ook kennen.

Ik ga de oplossingen van een aparte DLL en de code achter de executable plakken eens proberen. Die klinken me het meest zinnig.

Het probleem dat je krijgt wanneer elk programma nog maar 1 gebruiker aan zal kunnen melden heb ik al besproken met de opdrachtgever en die zou overwegen de eisen aan te passen zodat ik alsnog met een gewone login + pass kan werken.

[RobIII]

Farmerwood schreef op maandag 06 december 2004 @ 10:46:
Het probleem dat je krijgt wanneer elk programma nog maar 1 gebruiker aan zal kunnen melden heb ik al besproken met de opdrachtgever en die zou overwegen de eisen aan te passen zodat ik alsnog met een gewone login + pass kan werken.

Ik zou nog maar eens om tafel gaan zitten, want in essentie gebruik je gewoon al een login + pass (alleen dan hardcoded). Dat is natuurlijk, zoals al vaker aangegeven hier, klinkklare onzin. Maak er een instelling van, en onthoud desnoods de login gegevens als je je gebruikers niet steeds wil confronteren met een login schermpje. Maar stap alsjeblieft af van die onzin om je .exe te renamen naar UIGOUY78732jGOHGe72569GEJ.exe of om een externe resource dll aan te passen. Ook de code achter in de .exe plakken is natuurlijk gewoon ronduit ranzig.

Gebruik het register, een .dat bestand, een .ini of whatever om je instellingen op te slaan, en ga nou niet liggen klooien met .dll's die je daarvoor "misbruikt" of zelfs (erger!) je eigen .exe. Ik voorspel je nu alvast dat een boel virusscanners daar alarm op gaan slaan....

Overigens vraag ik me af waarom de klant zich op dit technisch niveau met jou bemoeit, en niet op functioneel niveau Wat is dat voor "klant from hell"?

[ Voor 16% gewijzigd door RobIII op 06-12-2004 10:59 ]

[Infinitive]

Waar je misschien eens naar kunt kijken is waarom die "eis" er is. Zoals je al aangeeft wordt die code ook ergens voor gebruikt, dus dat nummer moet er in om een speciale reden. Als die reden authenticatie is en de reden iets als "dan hoeft de gebruiker zijn wachtwoord niet elke keer in te vullen", dan kan je zeggen dat die eis niet goed is: zoals je vaak ziet denkt de opdrachtgever te ver in termen van technische oplossingen. Als je de eis vertaald naar:
"gebruiker moet zich authenticeren"
"gebruiker moet er zelf echter niets bij het programma voor hoeven doen"
Dan kan je andere, wellicht betere, oplossingen zoeken (windows authenticatie, oid).

[Edit] Arg, dit topic is al een dag oud, en ROBIII post hetzelfde als mij een paar minuten eerder Nou ja, laat dit een teken zijn om maar eens goed met je opdrachtgever te overleggen

[ Voor 26% gewijzigd door Infinitive op 06-12-2004 11:04 ]

[RwD]

RobIII schreef op maandag 06 december 2004 @ 01:07:
Overigens is het, in tegenstelling wat hier beweerd wordt, niet geheel onmogelijk om "jezelf" aan te passen (dus de lopende .exe aan te passen). Alleen vrees ik dus een "groot alarm" van de meeste virii scanners.

Ik heb zelf een aantal programmas gemaakt die iets deden met zichzelf, van aanpassen via zichzelf kopieren tot aan zichzelf onafsluitbaar/extra malen opstarten.
Al deze dingen werden door bijna alle virusscanners gezien als stout.

offtopic:
Maar mijn verborgen reden om te reageren is jouw gebruikvan het meervoud van virus. "viri" of "virii" is net als "euri" ((voor mij) ontzettend irritant en) onnozel taalgebruik. Het meervoud van euro is euros (al zul je dat niet snel gebruiken, meestal is het enkelvoud nodig). En het meervoud van virus is virussen.

[ Voor 10% gewijzigd door RwD op 06-12-2004 11:14 ]

[pjvandesande]

RwD schreef op maandag 06 december 2004 @ 11:04:
[...]

offtopic:
Maar mijn eigenlijke verborgen reden om te reageren is jouw gebruikvan het meervoud van virus. "viri" of "virii" is net als "euri" ((voor mij) ontzettend irritant en) onnozel taalgebruik. Het meervoud van euro is euros (al zul je dat niet snel gebruiken, meestal is het enkelvoud nodig). En het meervoud van virus is virussen.

Questa gokt op een typo, RobIII kennende.

[RwD]

een typfout van 4 letters

[Farmerwood]

RobIII schreef op maandag 06 december 2004 @ 10:57:
[...]Overigens vraag ik me af waarom de klant zich op dit technisch niveau met jou bemoeit, en niet op functioneel niveau Wat is dat voor "klant from hell"?

Omdat de 'klant' niet geheel onbekend is met programmeren, maar niet voldoende kennis heeft voor het programma dat nu gemaakt moet worden.

Zoals al aangegeven is het idd puur ter identificatie op de server. Iets wat ik zelf ook liever gewoon met een username + pass doe. De wens is echter om het hardcoded te doen en ik ben die optie eens aan het onderzoeken. Vandaar ook dit topic.
Maar als ik de reacties hier zo lees dan ga ik toch de optie voor de login met de optie deze encrypted op de pc te bewaren voor auto inloggen eens bespreken.

[.oisyn]

RobIII schreef op maandag 06 december 2004 @ 10:57:
Ik voorspel je nu alvast dat een boel virusscanners daar alarm op gaan slaan....

Resources kun je gewoon achteraf toevoegen, en aangezien je het doet vóór het bestand gedownload wordt (!!!) is er geen virusscanner die er naar zal kraaien, behalve die op de server PC dan maar dan moet je die virusscanner maar beter configureren

[RwD]

Raad hem anders een dongel/dongle aan?
Die zijn er ook in usb formaat.

@.oisyn:
Waarom zou daar de virusscanner gaan zeuren als je gewoon een bestand aanpast (niet zichzelf)? Dat is toch legale operatie, of niet soms

[ Voor 54% gewijzigd door RwD op 06-12-2004 13:52 ]

[alienfruit]

Maar een extern executable gebruiken om een unieke te injecten dat is toch helemaal niet leuk? Je moet gewoon in je programma iets verzinnen dat de code in programma stopt door het ophalen van een geheugen dump van het draaiend programma, vervolgens in je programma de unieke code ergs in stoppen en dan in het programma afsluiten Volgens mij kan dit wel, ik heb er ooit eens overgelezen. Volgens mij was hiervoor zelfs aparte WinaAPI voor...

Verder als je een encryptie gebruikt zou ik er wel een gebruiken dat gebruikt maakt van public en private keys, en dan de private key NIET in je programma verstoppen Zoals ze bij Turbopower ProActivate deden Kon je dus met wat moeite (niet al te veel ) nieuwe licensies aanmaken... Erg leuk...

[ Voor 28% gewijzigd door alienfruit op 06-12-2004 15:32 ]

[.oisyn]

RwD schreef op maandag 06 december 2004 @ 13:50:
@.oisyn:
Waarom zou daar de virusscanner gaan zeuren als je gewoon een bestand aanpast (niet zichzelf)? Dat is toch legale operatie, of niet soms

De virusscanner opmerking kwam niet van mij maar van RobIII, maar er zijn idd virusscanners die gaan zeuren als je een executable aanpast (zo heb ik op een suf vakantiewerk-kantoorbaan ooit eens de virusscanner moeten killen als ik iets wilde compilen, wat natuurlijk eigenlijk niet mocht, maar ja ).

Maar de virusscanner is geen issue, het aanpassen gebeurt op een eigen server waar je er dus controle over hebt.

[ Voor 10% gewijzigd door .oisyn op 06-12-2004 15:33 ]

[Tomatoman]

Het hele idee van beveiliging door ieder programma uniek te maken door een bestand aan te passen (in dit geval de executable) is verkeerd - het is security by obscurity.

Iemand die twee versies van het programma heeft, ziet met een hex editor onmiddellijk dat er ergens een paar bytes zijn omgegooid. Sterker nog, als hij de bestanden zipt, ziet hij het al aan de CRC-codes. Blijkbaar hebben die bits een betekenis, zodat hij ze er gewoon uit zal slopen. Daarmee maakt het totaal niet uit of ze nou in een resource in de executable zitten, achteraan de executable zijn geplakt of in een apart bestand zitten. Daarmee is meteen duidelijk dat het voor de beveiliging niet uitmaakt waar je de unieke code erin stopt.

Je kunt beter zorgen dat elk programma goed is beveiligd met een licentiecode die niet eenvoudig is te raden. Als de koper het programma vervolgens illegaal verspreidt, moet hij hoe dan ook zijn licentiecode erbij stoppen, waarmee hij meteen zichzelf heeft geïdentificeerd.

Het idee van het sneaky aanpassen van de executable is trouwens ook vrij dubieus, omdat je daarmee een mogelijkheid inbouwt om de koper te identificeren. Dat is alleen toegestaan als je het nadrukkelijk in de privacy statement van het product vermeldt! Nog een tweede consequentie: als de koper er niet mee akkoord gaat, moet hij zijn geld kunnen terugkrijgen, dat is wettelijk verplicht.

[Zoijar]

RwD schreef op maandag 06 december 2004 @ 13:50:
Waarom zou daar de virusscanner gaan zeuren als je gewoon een bestand aanpast (niet zichzelf)? Dat is toch legale operatie, of niet soms

Een virus past toch ook 'gewoon een (executable) bestand aan'?

Bij de eerste keer draaien voer je een username/password in, dit encrypt je op de server's public key, en dat stukje data stuur je bij de volgende logins. Als je perse niet een keer wilt inloggen, dan doet de server het wel voor je, en stuur het mee als bestandje naast je .exe. Waarom mag het perse maar 1 bestand zijn?

[ Voor 36% gewijzigd door Zoijar op 06-12-2004 16:07 ]

[RobIII]

.oisyn schreef op maandag 06 december 2004 @ 12:27:
[...]


Resources kun je gewoon achteraf toevoegen, en aangezien je het doet vóór het bestand gedownload wordt (!!!) is er geen virusscanner die er naar zal kraaien, behalve die op de server PC dan maar dan moet je die virusscanner maar beter configureren

Dat zei ik toch?

RobIII schreef op maandag 06 december 2004 @ 01:07:
Ten tweede gaan er waarschijnlijk een hoop virusscanners zeuren als je self-modifying code gaat schrijven. Dus dan moet de "wijziging" sowieso al serverside gebeuren alvoor je de .exe verstuurd naar iemand.

En toen kwam:

tomatoman schreef op maandag 06 december 2004 @ 15:40:
...een heleboel waarheden...

Ik had 't niet mooier kunnen zeggen.

RwD schreef op maandag 06 december 2004 @ 11:04:
[...]

offtopic:
Maar mijn verborgen reden om te reageren is jouw gebruikvan het meervoud van virus. "viri" of "virii" is net als "euri" ((voor mij) ontzettend irritant en) onnozel taalgebruik. Het meervoud van euro is euros (al zul je dat niet snel gebruiken, meestal is het enkelvoud nodig). En het meervoud van virus is virussen.

Dan is het nog altijd euro's...

quote: http://en.wikipedia.org/wiki/Plural_of_virus

Debate about the correctness of the 'viri' and 'virii' forms
The correctness of the viri and virii forms in English language is somewhat controversial. The arguments of this debate are closely related to the positions of prescription and description in linguistics.

Some people think that the viri and virii forms are incorrect, since these forms violate the rules of constructing plurals in Latin and are not given as correct plurals by English language dictionaries, including specialized dictionaries. This represents a prescriptive view of linguistics. Others, who have a descriptive point of view, think that these forms are acceptable alternatives because they are used with some frequency. From this point of view, the fact that these forms conflict with earlier rules is not relevant.

Ik doe het dus niet omdat euro -> euri's ofzo, maar gewoon omdat ik (tot vanmorgen dus) altijd heb gedacht dat dit wél correct was. En ik zeg dus ook gewoon euro's i.p.v. euri. Sorry hoor...
Als je je daar al aan irriteert, dan zul je wel vaak chagrijnig zijn, niet? Mijn taalgebruik is over het algemeen vaak beter dan de gemiddelde GoT-ter hier, en ik steek veel tijd in mijn posts. Ik zie dan ook niet in waar die "flame" voor nodig was...

[ Voor 101% gewijzigd door RobIII op 06-12-2004 16:24 ]

[Verwijderd]

.oisyn schreef op maandag 06 december 2004 @ 15:32:
Maar de virusscanner is geen issue, het aanpassen gebeurt op een eigen server waar je er dus controle over hebt.

Kunnen we stoppen te praten over viruscanners?

[Soultaker]

off-topic:

RobIII schreef op maandag 06 december 2004 @ 16:02:
Als je je daar al aan irriteert

ergert!

Verwijderd schreef op maandag 06 december 2004 @ 16:15:
Kunnen we stoppen te praten over viruscanners?

virusscanners!

... maar ga vooral verder.

[Zoijar]

offtopic:
Om maar te zwijgen over interpunctie...