Permalänk
Medlem

Skydda från dekompilering C#

Tjenare.

Har byggt ett program som jag skulle vilja skydda från dekompileringar ("reverse engineering" - engelska).
Nu är ju problemet att jag har ingen aning hur jag utför detta eftersom jag inte riktigt lärt mig något om detta, för jag har inte behövt det förr.

Någon som har en idé?

Såvitt jag vet så finns det ju Crypto Obfuscator, men det är ju dock inte riktigt vad jag tänkt mig, hade hellre sett en freeware..

Visa signatur

Citera om du vill ha svar, hjälpte jag dig, gilla svaret!
Felkod40

Permalänk

Tjenare,
Kort svar så går det tyvärr inte. Obfuscator som du nämner gör det svårare att läsa den omvända koden genom att döpa om variabelnamn. T.ex. så byts:

public class Customer { public string Firstname {get;set;} public string Lastname {get;set;} }

till

public class S { public string SS {get;set;} public string SSS {get;set;} }

Detta gör att ett stort project väldigt svårläst. Nu var det ett tag sedan jag använda dom där produkterna och kanske finns det någon som är mer insatt än jag.
Vad är det för ett project? Är det möjligt att göra om det till en ASP.NET applikation istället för att slippa dom här problemen.

Permalänk
Medlem

Vissa obfuskatorer modifierar även byte code:n så att den innehåller features som inte finns C# (och kanske även VB.Net), t.ex. överlagrade funktioner där enbart returtypen skiljer sig, så visst skydd mot dekompilering går att få.

Visa signatur

Bra, snabbt, billigt; välj två.

Ljud
PC → ODAC/O2 → Sennheiser HD650/Ultrasone PRO 900/...
PC → S.M.S.L SA300 → Bowers & Wilkins 607

Permalänk
Medlem
Skrivet av freddyfresh:

Tjenare.

Har byggt ett program som jag skulle vilja skydda från dekompileringar ("reverse engineering" - engelska).
Nu är ju problemet att jag har ingen aning hur jag utför detta eftersom jag inte riktigt lärt mig något om detta, för jag har inte behövt det förr.

Någon som har en idé?

Såvitt jag vet så finns det ju Crypto Obfuscator, men det är ju dock inte riktigt vad jag tänkt mig, hade hellre sett en freeware..

Du kommer aldrig helt kunna skydda din .NET-applikation mot dekompilering, men obfuskering kan göras svårare för en människa att tolka den dekompilerade källkoden. Värt att notera är att processen inte innebär ett ökat skydd för lösenord eller liknande; det kan endast ses som en bromskloss för den som vill titta på programmets källkod.

Vilken du bör välja kan jag inte kommentera på, däremot avråder jag dig från att göra det i onödan.

Skickades från m.sweclockers.com

Visa signatur

Kom-pa-TI-bilitet

Permalänk
Medlem
Skrivet av shakeshar:

Tjenare,
Kort svar så går det tyvärr inte..

Skrivet av Phod:

Vissa obfuskatorer modifierar...

Skrivet av Teknocide:

Du kommer aldrig helt kunna skydda din .NET-applikation mot dekompilering, men obfuskering kan göras svårare för en människa att tolka den dekompilerade källkoden. Värt att notera är att processen inte innebär ett ökat skydd för lösenord eller liknande; det kan endast ses som en bromskloss för den som vill titta på programmets källkod.

Vilken du bör välja kan jag inte kommentera på, däremot avråder jag dig från att göra det i onödan.

Skickades från m.sweclockers.com

Projektet är ett program som kommer användas på mitt arbete. Chefen har begärt ett program som jag designat och kodat, den använder en databas för in-, utbyte av information. Informationen kommer bara skickas lokalt och man har egentligen ingen åtkomst till servern överhuvudtaget för bara jag och två till har full åtkomst till den. Säkerheten är alltså relativt hög.

Sen används ett särskilt konto på databasen så man kan inte ta bort någonting, bara jag kan (något orimlig lösning enligt mig).

Iaf, jag anser att det finns nödvändig information i det här programmets källkod jag hellre vill dölja.
Dock har jag lurkat runt lite och troligen hittat en utväg för att fixa det.

Testat en obfuskering men jag hade bara en prövotid på den. Vilket gör att jag måste snart omvalidera obfuskeringen, vilket jag vägrar göra i fortsättningen.

Programmet har ingen funktionalitet för att möjligtvis begära att hämta information manuellt, finns bara fördefinierade kommandon för att undvika att fel personer ser fel fakta (typ nån som leker runt med sql-injektioner). Grejen är att vi har många
IT-elever som börjat här eftersom det är till större del studenter som anställs för att erbjuda möjlighet till nytagna studenter och studerande. Grejen är den att min erfarenhet är att man gärna leker runt och tänker inte på konsekvenserna.

Jag vill inte använda en webbapplikation för att programmet ändå bara ska vara på plats och jag är utbildad i C#, HTML, SQL så jag föredrar helst program. Programmet är fortfarande tillgängligt genom virtualisering till en station på arbetsplatsen.

Visa signatur

Citera om du vill ha svar, hjälpte jag dig, gilla svaret!
Felkod40

Permalänk
Medlem

Handlar detta enbart om Connection Strings så finns det många bättre lösningar.

SPARA först och främst aldrig connection trings i koden, rejält dålig ide, sedan vist config filerna går bra men i så fall se till att kryptera dom.

Samt absolut bästa sätt är detta: http://msdn.microsoft.com/en-us/library/53tyfkaw%28VS.80%29.a...

Dock notera att detta stoppar inte någon kunnig heller, men det kvittar vad du gör, att spara data i klartext oavsett vad är inte så smart, varken om det är skrivit i C# eller C eller C++ o.s.v.

Och om informationen är så känslig så rekommenderar jag aldrig direkt åtkomst mot den, sätt upp en WCF Data Service mellan ditt program och SQL servern. Se till att de autentiserar till den och ge de rätt behörighet.

Visa signatur

Speldator: Ryzen 7800X3D, 64GB DDR5, RTX 3070
Server: i7-8700k, 32GB DDR4, RTX2080
Steam deck + de fiesta konsoller.

Permalänk
Avstängd

Jag skulle ha en App server, väldigt dålig practice att ha direkt access till SQL från clienten.

Visa signatur
Permalänk
Medlem
Skrivet av MugiMugi:

Handlar detta enbart om Connection Strings så finns det många bättre lösningar.

SPARA först och främst aldrig connection trings i koden, rejält dålig ide, sedan vist config filerna går bra men i så fall se till att kryptera dom.

Samt absolut bästa sätt är detta: http://msdn.microsoft.com/en-us/library/53tyfkaw%28VS.80%29.a...

Dock notera att detta stoppar inte någon kunnig heller, men det kvittar vad du gör, att spara data i klartext oavsett vad är inte så smart, varken om det är skrivit i C# eller C eller C++ o.s.v.

Och om informationen är så känslig så rekommenderar jag aldrig direkt åtkomst mot den, sätt upp en WCF Data Service mellan ditt program och SQL servern. Se till att de autentiserar till den och ge de rätt behörighet.

Har aldrig riktigt fått till det här med WCF, medveten om klartext och källkoden inte bör ha autentiseringsuppgifter öppna.
Låter ju dock som om en WCF är det bättre alternativet men kan inte riktigt med det. Förväntar mig inte att folk kommer vara väldigt kunniga
om detta, men jag vill helst ha så mycket skydd som möjligt så enkelt som möjligt.

Visa signatur

Citera om du vill ha svar, hjälpte jag dig, gilla svaret!
Felkod40

Permalänk
Medlem
Skrivet av freddyfresh:

Har aldrig riktigt fått till det här med WCF, medveten om klartext och källkoden inte bör ha autentiseringsuppgifter öppna.
Låter ju dock som om en WCF är det bättre alternativet men kan inte riktigt med det. Förväntar mig inte att folk kommer vara väldigt kunniga
om detta, men jag vill helst ha så mycket skydd som möjligt så enkelt som möjligt.

Om det ska enbart användas internt och om du tror folket där inte är kunniga nog eller har lust att förstöra så skulle jag säga att kryptera config filen räcker och lägga connection strängarna där, vist det är inte 100% säkert men för en icke kunnig så är det inte precis lätt att lösa heller.

Samt ifall VCF service är för jobbigt så går det att lösa på SQL nivå också beroende på vilken SQL server du kör. T.ex. du kan arbeta ENBART mot stored procedures för att spara samt för att läsa ENBART views, på det viset så kan du göra SQL servern säker men krävs en hel del configuration och jobb.

Visa signatur

Speldator: Ryzen 7800X3D, 64GB DDR5, RTX 3070
Server: i7-8700k, 32GB DDR4, RTX2080
Steam deck + de fiesta konsoller.

Permalänk
Medlem
Skrivet av MugiMugi:

Om det ska enbart användas internt och om du tror folket där inte är kunniga nog eller har lust att förstöra så skulle jag säga att kryptera config filen räcker och lägga connection strängarna där, vist det är inte 100% säkert men för en icke kunnig så är det inte precis lätt att lösa heller.

Samt ifall VCF service är för jobbigt så går det att lösa på SQL nivå också beroende på vilken SQL server du kör. T.ex. du kan arbeta ENBART mot stored procedures för att spara samt för att läsa ENBART views, på det viset så kan du göra SQL servern säker men krävs en hel del configuration och jobb.

Ska kika efter lite mer på det här. Återkommer, ge gärna bra förslag om ni kommer med några.
Förövrigt kör vi en postgresql databas.

Min configfil ser i dagsläget ut såhär:

<setting name="aFrGh9" serializeAs="String"> <value>K/+pfpxNtaFrGh9BFgckFg==</value> </setting> <setting name="iEJdK8" serializeAs="String"> <value>H+WcWiEJdK8=</value> </setting> <setting name="Q1etBy" serializeAs="String"> <value>hwQ1etByI6tkH4Yz67KfpA==</value> </setting> <setting name="v5ndBx" serializeAs="String"> <value>PwzQ6FZogFniqZv5ndBx7Q==</value> </setting> <setting name="tkH4Y6" serializeAs="String"> <value>hwQ1etByI6tkH4Yz67KfpA==</value> </setting> <setting name="JYelI" serializeAs="String"> <value>QRbmrDJYelI=</value> </setting>

Vet inte riktigt om man ska nöja sig med det, känns som om det blir lite väl mycket jobb om man ska gå in och försöka göra det idiotsäkert och jobba med detta istället livet ut.

Nu har jag fortfarande inte i klartext utan det ligger i config filen, det är krypterat så klartext blir det inte, det är dock avkrypteringen som borde vara lätt att göra eftersom man kan se metoden man använder, men det blev temporärt den här lösningen tillsvidare: F2039FIJE3.F2039(Properties.Settings.Default.aFrGh9).

Avkrypteringsmetodiken:

public static string F2039(string F2039String) { if (String.IsNullOrEmpty(F2039String)) { throw new ArgumentNullException ("The string which needs to be F2039 can not be null."); } DESCryptoServiceProvider cryptoProvider = new DESCryptoServiceProvider(); MemoryStream memoryStream = new MemoryStream (Convert.FromBase64String(F2039String)); CryptoStream cryptoStream = new CryptoStream(memoryStream, cryptoProvider.CreateDecryptor(bytes, bytes), CryptoStreamMode.Read); StreamReader reader = new StreamReader(cryptoStream); return reader.ReadToEnd(); }

Anledningen till namnen F2039FIJE3 och F2039 är för att det inte ska stå i klartext vad metoderna faktiskt gör.
Eftersom jag inte jobbat mycket med kryptering så blir det så att man känner sig om en idiot på det.

Visst borde det gå att använda en "File Merge" för att slippa att config filen ligger öppet också? Då får man väl lite mer kött på benen iaf.

Visa signatur

Citera om du vill ha svar, hjälpte jag dig, gilla svaret!
Felkod40