[Цитат]

Идеята е проста и донякъде позната - върху някакъв достатъчно голям файл, съдържащ съдържание, за което няма да е фатално да понесе известен data loss, се "imprint"-ва текстова информация, така че от една страна обратната операция (да извадиш текста) да е възможна, а от друга страна това трябва да се направи сложно за злите елементи, които искат да я извадят. Има такива занимавки с jpeg файлове доколкото съм чувал. Моята идея е проста - при положение че имаш мп3-ка и текстов файл (който е скритото послание и "ключа", благодарение на който правим автентикацията), да може текста да се "вгражда", съответно "изважда". За да се затруднят злите хахори, въвеждам и целочислена стойност, която ако не се знае от страна на декодиращият, изваждането на текста е невъзможно. Вместо да обяснявам нашироко, по-добре да пейстна кода, защото е кратък:

това е "вграждащата" програмка:

Цитат

#include <unistd.h> #include <stdio.h> #include <sys/types.h> #include <stdlib.h> #include <string.h> #include <sys/stat.h> #include <fcntl.h> #define BUFSIZE 256*256*16*4 //large enough int seed; char *inmp3, *outmp3, *secret; // boring void printusage(char **arg0) {     printf("\nUsage:\n\n%s <input.mp3> <secret.txt> <random_seed> <output.mp3>\n\n",arg0);     printf("Where <input.mp3> is the name of input mp3 file\n");     printf("<secret.txt> should be replaced with a 'secret' text file\n");     printf("<random_seed> is an integer you use to seed the random func (e.g. 5051)\n");     printf("<output.mp3> is the name of output mp3 file\n\n"); } // entrypoint int main(int argc, char **argv[]) { // fds     int im, om;     FILE *sm; // text file streamed // cntrs     int a,b,c;     unsigned short d; // bufs     char *buf=malloc(BUFSIZE);     char *bufs=malloc(BUFSIZE); // bufpointers     unsigned int bp,sp; // code     if (argc != 5)     {    printusage(argv[0]);    exit(1);     } // gotcha         inmp3=argv[1];     secret=argv[2];     seed=strtod(argv[3],NULL);     outmp3=argv[4]; // debug     printf("inmp3: %s , secret: %s , seed: %d, outmp3: %s\n",inmp3,secret,seed,outmp3); // init io     im=open(inmp3,O_RDONLY);     sm=fopen(secret,"r");     om=creat(outmp3,S_IWRITE | S_IREAD |S_IRGRP | S_IWGRP|S_IWOTH|S_IROTH); // misc init     srand(seed);     sp=bp=0;     memset(buf,0,BUFSIZE); // eq bzero // Fetch first BUFSIZE buffers     read(im,buf,BUFSIZE);     // Fetch 'secret'         while (feof(sm)==0)     {         b=fgetc(sm);         if (b!=EOF) memset((bufs+sp),b,1);    sp++;     }     fclose(sm);     printf("sp=%d\n",sp); // 'Embody' secret data in buffer     d=seed;     memcpy(buf+d,&sp,sizeof(sp));     for (a=0;a<=sp;a++)     {    d=rand();//printf("%d\n",d*16*4);    memcpy((buf+d*16*4),(bufs+a),1);     } // Flush buffer in outfile     write(om,buf,BUFSIZE); // Copy rest of..     a=read(im,buf,BUFSIZE);     while ( a!=0) {write(om,buf,a);a=read(im,buf,BUFSIZE);}     close(om);close(im); // free buffers     free(buf);     free(bufs);     printf("Done!\n"); }

Това е "декодиращата" програмка:

Цитат

#include <unistd.h> #include <stdio.h> #include <sys/types.h> #include <stdlib.h> #include <string.h> #include <sys/stat.h> #include <fcntl.h> #define BUFSIZE 256*256*16*4 int seed; char *inmp3, *outmp3, *secret; // boring void printusage(char **arg0) {     printf("\nUsage:\n\n%s <input.mp3> <random_seed> \n\n",arg0);     printf("Where <input.mp3> is the name of input mp3 file\n");     printf("<random_seed> is an integer you use to seed the random func (e.g. 5051)\n"); } // entrypoint int main(int argc, char **argv[]) { // fds     int im; // cntrs     int a,b,c;     unsigned short d; // bufs     char *buf=malloc(BUFSIZE);     char *bufs=malloc(BUFSIZE);     int  *spp=malloc(2); // bufpointers     unsigned int sp; // code     if (argc != 3)     {    printusage(argv[0]);    exit(1);     } // gotcha         inmp3=argv[1];     seed=strtod(argv[2],NULL); // init io     im=open(inmp3,O_RDONLY); // misc init     srand(seed);     sp=0;     memset(bufs,0,BUFSIZE); // eq bzero // Fetch first BUFSIZE buffers     read(im,buf,BUFSIZE);         d=seed;     memcpy(spp,buf+d,2);     sp=*(spp); // 'Decode' secret data from buffer     for (a=1;a<=sp;a++)     {    d=rand();    strncat(bufs,(buf+d*16*4),1);     }     printf("%s",bufs); // free buffers     free(buf);     free(bufs); }

Компилират се лесно (cc program.c -o program). "Разбъркването" на текста в мп3-ката се постига чрез pseudorandom функция, която генерира *уникални* редици от числа спрямо зададен seed. Тези числа от редицата са дефакто  позициите в мп3 файла на всеки символ от файла.

Недостатъци: по този начин направено има много. Този алгоритъм по този начин няма да сработи с мп3-ки по-малки от 4МБ. Форматът на мп3-ката не се "уважава", като резултат се пише и в хедърчетата, не само във audio frames, което малко или много влошава качеството (чат-пат се чува изпукване). За да станат нещата по-зле, разпределението на числата в pseudorandom редиците не е *равномерно*, повечето стойности са по-ниски, при което с голяма вероятност, в началото на мп3-ката може да се чуят  изпуквания. И накрая: това няма да сработи с прекалено големи текстови файлове, защото никой не гарантира че няма да има повтарящи се числа в редицата в един момент. За всички тези проблеми обаче има разрешение, при това не е безкрайно сложно '>

И накрая: примерна (рудиментарна) уеб-автентикация базирана на това: качваш една мп3-ка и ако "secret-a" й съвпадне с този в /tmp/secret, то потребителя бива *автентициран*:

грозен html код

Цитат

<html><body> <h2> <center>mp3 auth PoC</center> <form enctype="multipart/form-data" action="upload.php" method="POST"> <input type="hidden" name="MAX_FILE_SIZE" value="18000000" /> Choose a mp3 to upload: <input name="uploadedfile" type="file" /><br /> <input type="submit" value="Upload Mp3" /> </body></html>

И грозен upload.php:

Цитат

<?php $target_path = "/tmp/"; $target_path = $target_path . basename( $_FILES['uploadedfile']['name']); if(move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target_path)) {     echo "The file ".  basename( $_FILES['uploadedfile']['name']). " has been uploaded, pending checks...<br>"; } else {     echo "There was an error uploading the file, please go back and try again!";     die(); } system("/tmp/decode ".$target_path." 100 > /tmp/secret1.txt"); exec("cmp /tmp/secret.txt /tmp/secret1.txt",$a); echo "$a[0]"; if ((strlen($a[0])<4) && (filesize("/tmp/secret1.txt")>4)) {     echo "<h1><font color=red>Bravo, bravo, bravo, uspehte da se avtenticirate s mp3-ka!"; } else {     echo "<h1><font color=red>Sorry, kachili ste greshnata mp3-ka '> Probvaite otnovo '>"; } system ("rm /tmp/secret1.txt");

Цялата тази работа не е особено практически полезна, по-скоро ми щукна в главата и реших да видя какво ще излезе. Иначе, забавно е това с което се автентицираш да си го държиш на мп3 плейъра...а сийд-а да го знаеш наум. Злите лоши хахори например бая биха си блъскали главата, докато разгадаят някаква такава малоумна схема също така '>

Напоследък покрай моите домашни занимания често ми се налагаше да пускам tcpdump на интерфейса към етернет сегмента на моят LAN доставчик.

С изненада установих че нерядко летят разни bootp пакети. Което ме навежда на мисълта че тук-там има разни машинки, чиито БИОС-и са конфигурирани да пробват да буут-ват първо от мрежата, през PXE. В момента в който се рестартират поради някаква причина или се пуснат, правят опит да си заредят операционна система отнякъде в мрежата.

Дали няма да е забавно да пуснем по един bootp сървър, който да слухти на външния интерфейс и да раздава някакъв linux image на който си поиска? Не е сложно, трябва ти само dhcpd и  някакъв tftp сървър. Естествено, много трябва да се внимава да не става конфликт с IP адреси или с друг DHCP сървър на доставчика. В този случай, тази операция няма да е никак законна и може да си отнесем някой проблем.

Просто не се сещам за причина, поради която това е нелегално обаче, стига да се направи като хората. Естествено, при положение че не disrupt-ваме услугите на доставчика.

Дали няма да е забавно за някой уиндоус потребител, който рестартира машината си и отива до хладилника да си вземе нещо за ядене, да завари линукс на машината си? Голяма забава ще настане '>

Вие как мислите? '>

Мисля че това е една много важна област, подлежаща на огромно развитие сега и в близките години. Мисля и че има немалко хора, занимаващи се с тези проблеми понастоящем. Защо не направите такава тема, мисля че ще има немалко интерес към това?

Наскоро имаше поредната порция дърпаници по този въпрос. За това как след края на 2007 нямало да се пишат ядра които да подържат модули с лиценз != ГПЛ. И т.н. В ЛКМЛ Линус се е изказал по въпроса много забавно '>

Преди да питам за вашето мнение, ще си позволя да изкажа моето. На работа администрирам бройка машини, в чието ядро в момента има proprietary модули. Вкъщи АТИ видеокартата ми доскоро работи с такъв "фирмен" драйвер (fglrx), защото малко или много работи по-добре от ОС версията на модула. Да, според мен в ограничени случаи това е приемливо. Идеята на софтуерната свобода е да можеш да избираш най-доброто за теб. Ако линукс разработчиците мислят да ми ограничават свободата да ползвам софтуер със затворен код, това ми е определено против разбиранията. Естествено, прекрасно е и когато съществува ОС версия и когато мога да избирам.

Според мен и двете крайности в това отношение са безумни. Теорията че не трябва да има драйвери със затворен код и хардуер със затворени спецификации е силно подържана от хората от лагера на ОБСД (#$^#$%#$%#$'>. Тези фанатици измислят даже песнички по този въпрос. Значи, силно не споделям такъв вид войнстващ възглед по въпроса.

Другата крайност е...хмм също лоша работа. Ако оставим само производителите на джаджи да ни пишат драйвери, това означава че първо излагаме огромна част от системите на риск (наскоро имаше ОГРОМЕН проблем с едни видеодрайвери на Нвидия да речем). Означава че утре дебилите от Майкрософт ще им бутнат пари да спрат подръжката за линукс и няма да може да се предложи алтернатива.

Според мен винаги ще има хора, които да желаят да разработват драйвери за джаджи, за които няма спецификации, да reverse-engineer-ват начина им на работа и т.н. Мисля че не бива нито напълно да отрязваме възможността да ползваме затворени драйвери, нито да позволим някой ден те да доминират. Ето това за мен е истинската свобода, свободата да избирам.

Какво мислите вие?

П.П. това е по случай предложение за пач за драйвер който да го накара просто да спре да обработва IRQ-тата си в един момент. Линус им е писал че няма да merge-ва такова нещо и че ако си мислят че чрез неговото ядро ще си налагат политическите възгледи по-добре да се откажат. И да го merge-нат първо в ядрата, които се ползват от РедХат, Сусе и т.н.

В контекста на това че още преди година и половина има публикувани проучвания свързани със hyperthreading-a и един доста специфичен проблем свързан със споделянето на кеша на процесора/ядрото, който на теория позволява "открадването" на crypto keys, използвани от процес, работещ "паралелно" (вярвам че не само ключове ами и други важни данни могат да бъдат "откраднати" по подобен метод)...и понеже не съм много запознат със спецификата на тази технология (HTT), имам въпрос към по-компетентните по отношение на  системните архитектури и ядрата:

* Доколко такава опасност е реална и риск ли е подръжката от страна на ядрото на тази технология?
* Доколкото разбирам същият риск в доста по-малка степен е валиден и за многоядрени процесори. Някаква елементарна математика по въпроса и ЗАЩО?
* Ако има дори и минимален риск за интел-ски двуядрени системи, то тогава съществува ли и за подобен и на АМД? Там архитектурата е НУМА, това отразява ли се на картинката?

Мерси предварително, темата понастоящем доста ме е заинтригувала.

В контекста на това че още преди година и половина има публикувани проучвания свързани със hyperthreading-a и един доста специфичен проблем свързан със споделянето на кеша на процесора/ядрото, който на теория позволява "открадването" на crypto keys, използвани от процес, работещ "паралелно" (вярвам че не само ключове ами и други важни данни могат да бъдат "откраднати" по подобен метод)...и понеже не съм много запознат със спецификата на тази технология (HTT), имам въпрос към по-компетентните по отношение на  системните архитектури и ядрата:

* Доколко такава опасност е реална и риск ли е подръжката от страна на ядрото на тази технология?
* Доколкото разбирам същият риск в доста по-малка степен е валиден и за многоядрени процесори. Някаква елементарна математика по въпроса и ЗАЩО?
* Ако има дори и минимален риск за интел-ски двуядрени системи, то тогава съществува ли и за подобен и на АМД? Там архитектурата е НУМА, това отразява ли се на картинката?

Мерси предварително, темата понастоящем доста ме е заинтригувала.

От известно време насам се чудя дали това е добра идея?

За какво точно говоря? Представете си следната програмка:

1) През равни интервали от време в продължение на известен брой цикли събира информация за работата на системата (loadavg, buffers/cache, swap/mem usage, sockets/fds, etc).

2) Прост алгоритъм който вади средно аритметично, средно отклонение, максимално отклонение, амплитуда (разликата между най-високата и най-ниската стойност в периода)

3) На база някакви критерии в зависимост от горните стойности променя различни kernel tunnables така че да се осигури по-добър responsiveness, по-рационално I/O спрямо наличната памет,  по-малко разхищение на памет (не ни трябват раздути буфери и структури когато не ги ползваме), ако щете донякъде защита от добре известни локални DoS (като например форкбомби, отваряне на голям брой сокети или файлове за малко време и т.н).

Що се отнася до тунинговането на производителността според мен има смисъл в зависимост от ситуацията човек динамично да променя неща като vfs_cache_pressure, swappiness, readahead буфери за блоковите устройства и т.н.

4) goto 1


Всъщност написах една кратка "първоначална" версия на програмка, която реализира нещо подобно. Естествено, доста далеч е от целта, най-малкото доста неща трябва да се допроверят и тестват, особено тези свързани с точка 3.

Мисълта ми е: според вас има ли смисъл от динамично тунинговане на тези параметри или ако човек работи през цялото време с дефолтните или някакви собствени, цялостната картинка ще е по-добра?

Знам че тестването на практическата файда от нещо такова е доста сложна занимавка от друга страна, иначе тестовете щях да си ги направя сам и нямаше да питам за чужди мнения '> От друга страна знам, че за да промениш някои параметри така че нещата да се наредят най-добре изисква да си баба Ванга и да знаеш какво ще се случи на машината известно време напред. Примерно хубаво е да имаш много dentry/inode кеш на машината принципно, но ако от това се възползва единствено updatedb едва ли ще го викаш през 5 минути  за да си индексираш файловите системи '>

П.П. за момента иначе съм донякъде горд с това дето го сътворих...когато изкуствено предизвикам ситуация в която се налага машината да суоп-ва, откривам някакъв смисъл от цялата работа. Иначе не се усеща никаква разлика '>

От известно време насам се чудя дали това е добра идея?

За какво точно говоря? Представете си следната програмка:

1) През равни интервали от време в продължение на известен брой цикли събира информация за работата на системата (loadavg, buffers/cache, swap/mem usage, sockets/fds, etc).

2) Прост алгоритъм който вади средно аритметично, средно отклонение, максимално отклонение, амплитуда (разликата между най-високата и най-ниската стойност в периода)

3) На база някакви критерии в зависимост от горните стойности променя различни kernel tunnables така че да се осигури по-добър responsiveness, по-рационално I/O спрямо наличната памет,  по-малко разхищение на памет (не ни трябват раздути буфери и структури когато не ги ползваме), ако щете донякъде защита от добре известни локални DoS (като например форкбомби, отваряне на голям брой сокети или файлове за малко време и т.н).

Що се отнася до тунинговането на производителността според мен има смисъл в зависимост от ситуацията човек динамично да променя неща като vfs_cache_pressure, swappiness, readahead буфери за блоковите устройства и т.н.

4) goto 1


Всъщност написах една кратка "първоначална" версия на програмка, която реализира нещо подобно. Естествено, доста далеч е от целта, най-малкото доста неща трябва да се допроверят и тестват, особено тези свързани с точка 3.

Мисълта ми е: според вас има ли смисъл от динамично тунинговане на тези параметри или ако човек работи през цялото време с дефолтните или някакви собствени, цялостната картинка ще е по-добра?

Знам че тестването на практическата файда от нещо такова е доста сложна занимавка от друга страна, иначе тестовете щях да си ги направя сам и нямаше да питам за чужди мнения '> От друга страна знам, че за да промениш някои параметри така че нещата да се наредят най-добре изисква да си баба Ванга и да знаеш какво ще се случи на машината известно време напред. Примерно хубаво е да имаш много dentry/inode кеш на машината принципно, но ако от това се възползва единствено updatedb едва ли ще го викаш през 5 минути  за да си индексираш файловите системи '>

П.П. за момента иначе съм донякъде горд с това дето го сътворих...когато изкуствено предизвикам ситуация в която се налага машината да суоп-ва, откривам някакъв смисъл от цялата работа. Иначе не се усеща никаква разлика '>

В-к Дневник...