Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.
sfalc

sfalc

Medlem
  • Plats Uppsala
  • Registrerad 2005-01-03
  • Senast aktiv 2013-02-23
  • Antal inlägg 92

Foruminlägg

De senaste inläggen sfalc har skrivit i forumet.

  • Medlem
  • Uppsala
  • 2010-08-04 18:02

Den ska naturligtvis inte lagras i en fil av typen "nyckel.key", för då blir det ju hel klart trivialt att göra en kopia, utan inne i programkoden på något fiffigt sätt.

Alltså
0. En valideringssteg körs där programmet kollar att licenser finns och att den själv inte har blivit modifierad.
1. Programmet körs....
2. Användaren klickar på "Lägg till mer tid"
3. Programmet läser in filen...
4. Programmet dekrypterar filen och validerar den. Uppdaterar sin egen nyckel genom att patcha sina egna binärer, patchar även binärerna så att tiden som återstår lagras där samt i någon config-fil. Typ i header-bitar som inte syns dessutom.

Det går det inte att lagra någon data om hur länge programmet får köras på ett bra sätt. Så fort man skriver till hårddisken är man egentligen rökt. Det enda man kan göra är att dölja hur man lagrar informationen och hoppas på att användaren inte fixar att gå förbi det.
Olika varianter på steganografi behöver man nog använda.

  • Medlem
  • Uppsala
  • 2010-08-04 17:21

Nja alltså så fort man laddar in en ny nyckel förstörs den gamla och den kan inte dekryptera de förra filen utan enbart nästa

0. Nyckel nummer 0 dekrypterar fil 0, fil 0 innehåller Nyckel 1 samt tid för att köra programmet.
1. Nyckel 1 dekrypterar fil 1, fil 1 innehåller Nyckel 2 samt tid för att köra programmet.

ad infinitum

Viktigt är att inte skicka fel nycklar till fel kunder annars kommer supportsamtalen bli långa...

Den man i praktiken gör är att patchan sin egen programvara med nya nycklar. Nycklarna ligger ju i maskinkoden. Enda anledningen till att kryptera filerna är att se till bara en själv kan uppdatera nyckeln och räkneverket.

Ett problem kan vara att anti-virus program och NX skydd för minne kan triggas...

  • Medlem
  • Uppsala
  • 2010-08-04 17:18

Det finns en hel del kommersiella leverantörer av enklare säkerhetssystem för mjukvarulicensiering. Har inga i huvudet, men för dina syften borde det finnas något ute på marknaden som passar.
Vilken plattform talar vi om här? OSX? Linux? Windows? el en kombination?

  • Medlem
  • Uppsala
  • 2010-08-04 17:14

Sen för att göra det lite svårare för dem att fuska, kan ni ju alltid bygga in en funktion för att fråga systemet om vilken nyckel den använder, samt hur lång tid det är kvar.
Visar det sig att de använder en nyckel som redan har tagit slut eller att något annat skumt är i görningen, ja då får ni ringa BSA.

  • Medlem
  • Uppsala
  • 2010-08-04 17:10

Bygg in en krypteringsnyckel i programmet per kund. Varje x omgång av tid levereras som en krypterad fil el filer. Filen innehåller information om hur länge programmet får köras. Filen innehåller även en ny nyckel. Då kan man inte använda samma biljett två gånger.

  • Medlem
  • Uppsala
  • 2010-08-04 16:56

Tja mina synpunkter är inte enbart principiella, min fars företag byggde ett sådant kort. Tror att de tog typ 2000 000 kr för 100 st kort. Det var dock en liten FPGA.

  • Medlem
  • Uppsala
  • 2010-08-04 16:42

Det är ett fundamentalt svårt problem. Bruce Schneier har skrivit en del om det futila i att samtidigt ge och förneka tillgång till en resurs på en dator.
Min egen erfarenhet är att alla typer av donglar och mjukvarulösningar går att ta bort mha en patch.
De du kan göra är följande:
Designa ett PCI-kort med en FPGA på som i sin tur innehåller instruktioner och data som är essentiella för programmets funktionalitet. FPGA:n kan då innehålla de engångsnycklar som du beskriver och när en sådan matas in svarar PCI-kortet på de funktionsanrop som programmet kräver.
Så som (vissa) FPGA:er är utformade förstörs konfigurationen på dem om man försöker sig på invasivt hackande. Därmed är du säker så länge inte Intel el någon annan chiptillverkare försöker komma åt innehållet på kortet.

Med en tillräckligt stor FPGA kan man få in rätt mycket av programmet i kortet.

Problemet med denna approach är naturligtvis att det är mycket dyrt då du måste konverter din källkod till typ verilog etc plus att någon måste designa kort o dyl.
Det är dock billigare än en ASIC.

Grejen är dock denna om dina kunder inte är hackers av den högre skolan är en enkel mjukvarulösning med engångskoder fullt tillräckligt. Så länge det inte är uppenbart enkelt gjort så borde det räcka.

  • Medlem
  • Uppsala
  • 2009-03-24 19:41

Om du vill två dina händer ytterligare kan du alltid ladda ner ClamXav. Ett gratis antivirusprogram som är baserat på ClamAV och sedan få bekräftat, svart på vitt, att din USB-sticka är virusfri.

Sedan står det dig fritt att tvåla till IT-avdelningen

  • Medlem
  • Uppsala
  • 2008-11-24 23:29
Ursprungligen av SkrotNisse:

Det måste fantamej vara dagens mest puckade inlägg!! Slår t.o.m. "panter"s inlägg i pre-Mac OS X tråden...

Äru kommunist eller ?!?

Det är väl snarare Chicagoekonomer av Milton Friedman-typ som förespråkar avskaffade patent och upphovsrättslagar då de innebär konstlade monopol skapade av den förhatliga staten:)

Medans vänsterpartier värnar "kulturarbetare" och deras möjligheter att försörja sig.

  • Medlem
  • Uppsala
  • 2008-11-04 21:51

Får ni ut föreläsningen i ett format som kan omvandlas till PDF i förväg?
Själv antecknar jag med ett program som heter Skim, vilket lagrar ett "anteckningslager" ovanpå en pdf-fil.
Det har en del nackdelar bl.a avsaknad av ordentliga ritmöjligheter, enklare figurer går, men annars är det jättebra.

  • Medlem
  • Uppsala
  • 2008-10-28 21:56

Principen är att man har sin offentliga nyckel i en authorized_keys fil i ssh-mappen på de sitt användarkonto i den eller de maskiner som man vill komma åt med ssh.
Det spelar ingen roll var du skapar nyckelparet.
Det som är viktigt är att den publika nyckeln placeras i authorized_keys filen på de datorer du vill komma åt och den privata nyckeln har du på den eller de datorer som du vill logga in från.

  • Medlem
  • Uppsala
  • 2008-10-27 22:55

Hittade just en tänkbar förklaring varför det inte fungera. Det portnummer som du fått, 666, uppfattade jag som den port som du kan tunnla en filöverföringstjänsts på. Dock kan det var så att 666 är det port som du ska ansluta till med ssh.

Då blir kommandot "ssh anvä[email protected] -p 666"

För det kan vara så att, beroend på hur infrastrukturen ser ut hos den du skall anslut till,det finns ett antal ssh-servrar som döljer sig bakom samma IP-adress.

Det man då gör, är att man avänder icke-standardiserade portnummer. 22 är den ordinarie porten för ssh, men bakom en port ryms det bara en server. Så om den du försöker ansluta till har flera ssh servrar misslyckas du p.g att du ansluter till fel server.

Så prova med att lägga till -p 666 på kommandoraden

  • Medlem
  • Uppsala
  • 2008-10-27 22:46

Hum, mysteriet tätnar.

Skulle du vilja vara vänlig att skriva, alternativt ta ett screenshot av, vad exakt du gör när du försöker logga in. Ju fler detaljer desto bättre.

  • Medlem
  • Uppsala
  • 2008-10-27 22:22

Ja, tyvärr, annars såg det rätt ut.
När du lyckas lösa lösenordsbiten är du en god bit på väg.

  • Medlem
  • Uppsala
  • 2008-10-27 22:15

Du måste helt enkelt ha ett lösenord.
Alternativet är att du har en privat nyckel, men även i det fallet brukar man kryptera den privata nyckeln med ett lösenord.

Den som du har kontot hos måste väl ha låtit dig välja ett lösenord?
Ett alternativt är att du har ett tomt lösenord, prova det, tryck bara på enter när servern begär ett lösenord.