Re: lug-bg: Софтуер за следене на файлове
- Subject: Re: lug-bg: Софтуер за следене на файлове
- From: Aleksandar Valchev <hippo@xxxxxxxxxxxxxxxxxx>
- Date: Fri, 11 Mar 2005 13:24:40 +0200
- Organization: Efficient Software Systems
On Friday 11 March 2005 11:01, Dean Stoeff wrote:
> Aleksandar Valchev wrote:
> >Разгледах aide. Прави точно това, което се опитвам и аз да направя. Обаче
> >базата им данни е mysql или postrege и не е криптирана... plaintext...
> >В същата насока си мислех, че ако базата данни е изцяло криптирана, това
> >означава, че не трябва да се притесняваш за нея. Програма, която знае
> >паролата само тя може да има достъп до нея, а паролата идва от потребителя
> >(или по-други начини, но това не е съществено).
>
> Напротив много е съществено, не виждам причина потребителя и/или някой
> друг осен програмата и
> програмиста , да знае ключа с който е криптирана базата
това го написах, защото мисля, че при деасемблиране може да се намери
паролата, ако е хардкорната в самия изпълним файл. А имаше даже една програма
(strings), която отпечатва низовете, които се съдържат в дадед изпълним файл.
Затова ако паролата е <code> char *pass = "pass"; </code> то (предполагам)
тази програма ще си я отпечата без да се замисли.
Другото, което се сетих е паролата за базата с данни да се записва в файл,
които съответно е криптиран. Така се усигорява възможност за промяна на
паролата (не на базата с данни). Почти съм сигурен, че тази техника е
измислена и се прилага от много отдавна.
>
> >Притеснява изпълнимия файл.
> >
> >Как може да се гарантира, че това е точно този изпълним файл, който искаш
> > да работи с базата с данни. Един начин е както написа Веселин Колев: на
> > дискета md5 на изпълнимия файл и го стартираш след проверка, но това
> > означава, че не може да има така да се каже автоматизация на процеса,
> > която е важна.
>
> Друг начин е програмата да има 2 вградени алгоритъма - един за
> криптиране на изпълнимия код /чийто ключ отново се знае от програмата/ и
> да се декриптитра непосредствено преди изпълнение в ОП. А за да бъде още
> по паранойчно, макар че първия според мен е достатъен може да се добави
> и вътрешен алгоритъм за проверка на контролната сума /желателно твой
> собствен, а не стандарен/ и като продължаваме да разсъждаваме в тая
> посока - нищо ново под слънцето, не е лошо да издириш компютърни вируси
> от средата на 80-те на миналия век там е пълно с алгоритми които
> затрудняват анализирането на кода, така че всичко това приложено кам
> една такава програма може да се каже до голяма степен че е сигурна.
>
И това си го мислех, ама на малката ми глава й е трудно да понесе толкова
мислене.
Дали защитата не става, ако при самата компилация на изпълнимия файл да се
подава -Dнещо-си. Това "нещо-си" да е значимо за криптирания файл с паролата
или за самия изпълним файл. Това са много сурови идеи.
А дали съществува нещо като фускацията при Java-та. Там в jar-овете се
поставят запазени думи като if, else, while.
> ===========================================================================
>= A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
> http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara
> Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
> ===========================================================================
>=
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================
|