Raspberry beschermen tegen kopieren?

[ubremoved_2964]

Ik heb een stukje software gemaakt voor de raspberry, wat ik graag zou beschermen.

Het draait basically bovenop picoreplayer:

https://sites.google.com/site/picoreplayer/home

Ik heb recent de code van een concurrent (die eigenlijk geen echte concurrent is, gezien andere prijsklasse) opengegooid. Ik zou dus willen vermijden dat mensen met mijn code dit kunnen gaan doen. Wat ik bij concurrent gedaan heb, is hun recovery ISO gedownload, de tar file met root filesystem uitgepakt, om dan te concluderen dat hun player geschreven is in perl, en dan de effectieve decoders zoals de flac binary aanroept.

Hun code is beschermd met een perl module die modules encrypteert, maar de decryptiekey zit gewoon in een gecompileerde .so file en die heb ik met een hex editor eruit gevist na lang zoeken met o.a. objdump en elfdump. Conclusie: de BS code draait nu gewoon op mijn raspberry II en ik kan al hun perl lezen. Ik heb zelfs al hun API keys van externe stream providers kunnen uitlezen.

Ik ga hier niks mee doen, buiten dan de les om mijn eigen product te beschermen.

Dus waar ik aan dacht:

1. onze binary node locken op de serial van de raspberry, of zelfs de node locken aan de SD kaart via

/sys/block/mmcblk0/device/serial

2. de sd kaart vastlijmen op de raspberry, als ze die willen verwijderen dan moeten ze de SD kaart kapot krijgen
3. console access via hdmi dichtgooien, en eventuele rescue boot modes disablen
4. enkel SSH openzetten en default accounts veranderen in iets moeilijks
5. webinterface checken op exploits, zodat ze geen injections kunnen doen die zaken als root uitvoert om alsnog aan de code te kunnen

Voor wat een raspberry maar kost kan het mij weinig schelen als er ooit een flash kapot gaat, en ik er zelf niet meer aan kan.

[fryelectro]

encryptie?

[lacer]

Wat doet het meer als de picoreplayer, als ik vragen mag ?

[ubremoved_2964]

encryptie?

encryptie lost niks op gezien de decryptiekey op het device moet staan
dit is net het probleem wat ik ondervond met concurrent , hun perl scripts waren dan wel geëncrypteerd, maar de decryptiekey stond in een .so file

Wat doet het meer als de picoreplayer, als ik vragen mag ?

Wij hebben een DSP methode ontwikkeld die alle muziek gestemd in A=440 veel beter maakt. Daar is drie jaar onderzoek naar gedaan. Methode werkt zo goed als met elke linux based player en on the fly in realtime. Onze "main" server staat al bij 7 resellers in de Benelux, maar voor multiroom wil ik iets met de raspberry gaan doen.

[ITnetadmin]

Tja, ik vind het wel wat van slechte smaak getuigen om een proprietary stuk software te draaien op opensource software en het dan nog ns te willen dichttimmeren.
Als het uberhaupt al mag van de GPLv3.

Dat gezegd, is het aartsmoeilijk te beveiligen op een platform waar de end user baas van is (ie raspi).
Encryptie lost niks op, want encryptie beschermt enkel tegen een man-in-the-middle, nooit tegen een end user want die moet de key hebben.

[ Post made via mobile device ]

[Trojan]

Encryptie zou wel mogelijk zijn als je eigen chips zou kunnen plaatsen die het encryptieproces afhandelen. En dat is bij een rpi niet echt mogelijk.

Als je gebonden bent om enkel maar op software vlak encryptie te gebruiken ben je gedoemd om te falen.

[wimpie3]

Externe security hardware (usb key)? Epoxy over het bordje gieten (zie je wel eens bij oude arcadehardware)? Key via het internet ophalen?

[raf1]

Sluit dit topic maar, want wat ub4b wil doen, is compleet illegaal. picoreplayer is GPLv3 software en dus moet je alle uitbreidingen daarop open source aanbieden.
Als je bescherming wil op een uitvinding, vraag je een patent aan.

[ubremoved_2964]

Je mag op een open source distro eigen code draaien (bvb eigen C, C++ programma of eigen shell script of eigen perl code).
Anders zou geen enkele commerciële software onder linux kunnen draaien (bvb oracle op redhat).

Je mag dus bvb een wrapper script schrijven rond bestaande open source players (wat NAD gedaan heeft met hun Perl based player die gewoon zaken zoals flac aanroept) zonder dat de code van die wrapper onder de GPL valt. Als je echter GPL code gaat linken aan je eigen code, wordt het verhaal anders, dan wordt je eigen code ook GPL.

http://programmers.stackexchange.com/qu ... l-software

Ik kan even goed de code op raspbian laten draaien, maakt dus niks uit voor de license.
Wij doen dus niks illegaals.

[ubremoved_2964]

Encryptie zou wel mogelijk zijn als je eigen chips zou kunnen plaatsen die het encryptieproces afhandelen. En dat is bij een rpi niet echt mogelijk.

Als je gebonden bent om enkel maar op software vlak encryptie te gebruiken ben je gedoemd om te falen.

Klopt, ik heb zo de code van concurrent kunnen reversen. Dus encryptie is niet de oplossing.

Tja, ik vind het wel wat van slechte smaak getuigen om een proprietary stuk software te draaien op opensource software en het dan nog ns te willen dichttimmeren.

Iets waar we jaren op gezocht hebben willen we uiteraard beschermen tegen kapers.

Het pattent gaat op zich niet om de software, maar om de configuratie rond die software. Ons idee is namelijk toepasbaar op tal van players.
Configuratie valt niet onder GPL. Die config willen we uiteraard beschermen. Configratie kan je wrappen in scripts, die scripts zijn je eigen code vanaf 0, die kan je dus wel degelijk closed source maken. En zelfs als ze die scripts kunnen lezen (bvb door te reversen van een obfuscation layer zoals bvb NAD gebruikt) kan je daar als auteur copyright op claimen.

[ITnetadmin]

Als je niet aan de code zelf komt zit je qua gpl idd wel goed denk ik.

Je werk beschermen echter, op een open platform, is al bijna een onmogelijke taak. Kijk maar naar alle gefaalde DRM oplossingen die op gewone pc's werken. Het is niet voor niks dat de ongekraakte DRM zich bevindt op gesloten platformen, zoals consoles die de encryptie via hardware chips afhandelen.
Iemand die er *echt* in wil geraakt er ook in, bv de concurrentie. Vaak is het beter om in zo'n gevallen te concurreren op service en niet puur op code, anders wordt het een arms race die je nooit gaat winnen.

Moest ik potentiele klant zijn (maar da's persoonlijke smaak uiteraard) die een oplossing met raspi krijgt aangeboden, zou ik dat nooit aanvaarden als aan de geest van het project niet voldaan werd (maw customizability); locked down apparaatjes zie ik al genoeg passeren hier. Dat doet niks af van het feit dat je de code wil beschermen, het gaat om het "we lijmen alles vast" principe, waardoor zoveel toestellen moeten weggesmeten worden omdat je ze niet meer kan repareren.
We mogen nog van geluk spreken dat bv bhaalu nog zo vriendelijk was om de nodige info te leveren zodat hun boxjes niet nutteloos werden na het stopzetten van de service.

[ Post made via mobile device ]

[ubremoved_2964]

Moest ik potentiele klant zijn (maar da's persoonlijke smaak uiteraard) die een oplossing met raspi krijgt aangeboden, zou ik dat nooit aanvaarden als aan de geest van het project niet voldaan werd (maw customizability); locked down apparaatjes zie ik al genoeg passeren hier. Dat doet niks af van het feit dat je de code wil beschermen, het gaat om het "we lijmen alles vast" principe, waardoor zoveel toestellen moeten weggesmeten worden omdat je ze niet meer kan repareren.
We mogen nog van geluk spreken dat bv bhaalu nog zo vriendelijk was om de nodige info te leveren zodat hun boxjes niet nutteloos werden na het stopzetten van de service.

Klanten liggen totaal niet wakker van het feit dat het op een raspberry draait. Klanten lezen ook deze fora niet, zijn geen DIY mensen maar mensen met veel geld die een kant en klare oplossing willen die door een installer wordt geplaatst.

Maar we kunnen het ook omdraaien. We nemen een arm based board van de concurrent en we draaien er onze eigen code op ipv de Perl based player. De laatste versie van hun node heeft een raspberry achtige cpu, en de code van BS draait op een raspberry 2 en dus omgekeerd ook. Zij gebruiken gewoon busybox als linux.

Niemand kan mij verbieden om een device te kopen en daar andere software op te draaien? Ze kunnen hooguit verbieden dat wij hun logo gebruiken, of hun officiële foto's.

[ITnetadmin]

Klopt. Enfin, zolang je je aan alle licenses houdt kan je doen wat je wil.
Ik zeg dan ook alleen maar wat ik persoonlijk zou doen; ik kan me niet vinden in die "we sluiten de eigenaar uit zijn toestel uit" mentaliteit. Niet dat die oplossingen gebruikt worden, maar dat een (ind dit geval dan nog opensource) oplossing mee toegetimmerd wordt is waar ik het moeilijk mee heb.
Het is uiteraard de totale apathie van de klant die dit soort praktijken op gigantische schaal tolereert; denk maar aan smartphones, eigenlijk volwaardige computers waar je zelf geen admin maar enkel user van bent hoewel je ze gekocht hebt, of apparaten die je niet meer kan repareren als ze stukgaan omdat de nodige toegang vastgelijmd is, of met hars bedekt, of nog zo van die creatieve oplossingen om toch maar vooral de wegwerpmaatschappij te bevorderen en customizen onmogelijk te maken.


Enfin, we wijken af.
Beveiligen dus; dat wordt een schier onmogelijke opdracht. Je hebt de concurrentie ook ns gekraakt, en dat wil zeggen dat zij mogelijk hetzelfde doen met jouw materiaal. Industrial espionage op kleine schaal.
Puur praktisch dus zit je voor een moeilijke taak. Hardware access minimaliseren is de meest courante oplossing in deze gevallen.



[ Post made via mobile device ]