LINUX.ORG.RU
ФорумTalks

[ржунимагу] «крутое» шифрование у рисиверов gs-8300m


0

0

Сегодня я открыл (только сегодня, т.к. телевизор смотрю от силы 2-3 раза в месяц), что у упомянутого ресивера есть, оказывается, кардридер.

С горем пополам засунул туда SD-флешку (она ни в какую не хотела лезть в кардридер, а потом ее пришлось выковыривать острым предметом). Поставил на запись кусок телепередачи, чтобы проверить, как оно будет отображаться на компьютере.

Примонтировал флешку. Во-первых, оказалось, что дурной рисивер разбил мою 4Гб флешку на два раздела. Один - размером 2.8Гб, на который и писалось кино. Второй раздел остался не отформатированным... Во-вторых, оказалось, что видео записано в каком-то странном формате ".rec", который mplayer'ом не распознался.

Гугление на предмет преобразования этого дурацкого формата подсказало уйму вантузячих программ, но ни одной под линукс. И вдруг, о чудо! Я натыкаюсь на форум, где какой-то хороший человек объяснил, как эти файлы смотреть.

Оказывается, пишется видео в обычном mpeg2, 720x576, 15000кб/с;звук - стерео, mp3, 192кб/с. А посмотреть нельзя его было «просто так» потому, что видео «закодировано». А весь ржач в том, что кодирование это - XOR 0xAA! :)

В общем, делюсь «декодером»:

#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main(int argc, char **argv){
	int in = open(argv[1], O_RDONLY);
	int out = open(argv[2], O_RDWR|O_CREAT|O_TRUNC, 0666);
	int rb, i;
	unsigned char *buf = (char*) malloc(1024 * sizeof(char));
	unsigned char *ptr;
	while(rb = read(in, buf, 1024)){
		ptr = buf;
		for(i = 0; i < rb; i++)
			*ptr++ ^= 0xaa;
		write(out, buf, rb);
	}
	close(in);
	close(out);
	free(buf);
}

☆☆☆☆☆

Хацкор!
За тобой выехали.

tzukko
()

помоему баян, было что-то подобное уже давно, человек тоже под линукс искал программу, про кодирование он написал, а программу уже запилили добрые люди ему.

Novell-ch ★★★★★
()
Ответ на: комментарий от Novell-ch

Ну, боян это или не боян, не знаю: гугл мне на ЛОР ссылок не давал.

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Pavval

Да проще файл нормальный сделать. Большие файлы этот плеер, вроде бы, режет на кусочки. Можно будет обработчиком эти куски «декодировать» и собрать в один выходной файл.

Хотя, конечно, все это можно и в mplayer добавить. Но мне в горе исходников ковыряться невмоготу.

Eddy_Em ☆☆☆☆☆
() автор топика

Радуйся что шифрование нестойкое. Думаешь они дураки и не знают что это легко дешифруется? Всё гораздо сложнее, на вендоров копирасты давят чтобы они добавляли drm. У айпода типа тоже есть «защита» чтобы музыку нельзя было обратно сливать, требование RIAA.

А так ничего не стоит шифрануть через openssl, делается это одной коммандой.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Идиотизм же. Зачем вставлять палки в колеса? Если я захочу - вполне могу купить себе dvb-карту и писать фильмы сразу на компьютер.

Eddy_Em ☆☆☆☆☆
() автор топика

Где ты взял этот ресивер? Его производили всего несколько месяцев и сняли с продажи из-за сплошных косяков

stave ★★★★★
()
Ответ на: комментарий от stave

Тесть подключал спутниковое ТВ. Подключальщик сказал, что это - самый свежий рисивер. Что, пидманул?

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

Не, это правда был самый свежий ресивер. В этом и проблема. Повезло, если работает до сих пор.

stave ★★★★★
()
Ответ на: комментарий от Eddy_Em

Идиотизм же

Угу, копирасты хреновы. Но это лучше чем стойкое шифрование и проприетарные форматы.

true_admin ★★★★★
()

>for(i = 0; i < rb; i++)

*ptr++ ^= 0xaa;


Реквестирую в тред оптимизаторов. //let the srach' begin!

unsigned char *buf = (char*) malloc(1024 * sizeof(char));


А зачем вы таки преобразуете к (char*) ?

И да, зачем вы пишите константы циферками?

Dimanc ★★
()
Ответ на: комментарий от Dimanc

*ptr++ ^= 0xaa;

Реквестирую в тред оптимизаторов.

А что, можно как-то оптимизировать этот кусок?

А зачем вы таки преобразуете к (char*) ?

По привычке.

И да, зачем вы пишите константы циферками?

Ну, сделайте так:

#define BUF_SIZ 1024
...
malloc(BUF_SIZ * sizeof(char))
...
read(in, buf, BUF_SIZ)

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

А что, можно как-то оптимизировать этот кусок?

По идее xor'ить пачками в виде uint32_t и uint64_t будет быстрее (на 32- и 64-разрядных системах соответственно).

Deleted
()
Ответ на: комментарий от Deleted

По идее xor'ить пачками в виде uint32_t и uint64_t будет быстрее

Неа. С char:

time recdecode 0th48431.rec 0th48431.001 a.avi
2.57user 11.78system 1:52.69elapsed 12%CPU (0avgtext+0avgdata 0maxresident)k
5698976inputs+5695224outputs (3major+392minor)pagefaults 0swaps
С uint_32:
time recdecode 0th48431.rec 0th48431.001 b.avi
1.12user 11.46system 2:10.15elapsed 9%CPU (0avgtext+0avgdata 0maxresident)k
5718224inputs+5695392outputs (0major+395minor)pagefaults 0swaps
~18 секунд разницы (по сравнению с двумя минутами), все-таки, на статистическую погрешность не спихнешь...

Код для char был такой:

#define _FILE_OFFSET_BITS	64
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>

#define BUF_SIZ 1048576L

int main(int argc, char **argv){
	int in, out, i, j, l;
	off_t rb;
	unsigned char *ptr, *buf;
	if(argc < 3){
		printf("\nUsage:\t%s <file.rec> <file.001> ... <file.avi>\n\t\t\"декодирует\" rec-файл в выходной avi-файл\n", argv[0]);
		exit(-1);
	}
	out = open(argv[argc - 1], O_RDWR|O_CREAT|O_TRUNC, 0666);
	buf = malloc(BUF_SIZ * sizeof(char));
	l = argc - 1;
	for(j = 1; j < l; j++){
		in = open(argv[j], O_RDONLY);
		while(rb = read(in, buf, BUF_SIZ)){
			ptr = buf;
			for(i = 0; i < rb; i++)
				*ptr++ ^= 0xaa;
			write(out, buf, rb);
		}
		close(in);
	}
	close(out);
	free(buf);
}
Код для uint_32:
#define _FILE_OFFSET_BITS	64
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdint.h>

#define BUF_SIZ 1048576L

int main(int argc, char **argv){
	int in, out, i, j, l, ps, s, rb;
	uint32_t mask = 0xaaaaaaaa, *ptr;
	unsigned char *buf;
	if(argc < 3){
		printf("\nUsage:\t%s <file.rec> <file.001> ... <file.avi>\n\t\t\"декодирует\" rec-файл в выходной avi-файл\n", argv[0]);
		exit(-1);
	}
	out = open(argv[argc - 1], O_RDWR|O_CREAT|O_TRUNC, 0666);
	buf = malloc(BUF_SIZ * sizeof(char));
	l = argc - 1;
	for(j = 1; j < l; j++){
		in = open(argv[j], O_RDONLY);
		while(rb = read(in, buf, BUF_SIZ)){
			ptr = (uint32_t*)buf;
			s = (rb+3)/4;
			for(i = 0; i < s; i++)
				*ptr++ ^= mask;
			write(out, buf, rb);
		}
		close(in);
	}
	close(out);
	free(buf);
}

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

Ну да , конечно ... но быстрым . кто тут без SSE поднимите руки

Loki13 ★★★★★
()
Ответ на: комментарий от true_admin

>А так ничего не стоит шифрануть через openssl, делается это одной коммандой.

А процессор ресивера осилит?

AptGet ★★★
()
Ответ на: комментарий от Eddy_Em

Странно. У меня результат получился другой. Тестовый файл:

$ ls -lh /dev/shm/test.in 
-rw-rw-r--. 1 ivan ivan 642M Янв 30 04:08 /dev/shm/test.in
Твой вариант с char:
$ time ./char /dev/shm/test.in /dev/shm/test.out 

real	0m1.696s
user	0m0.554s
sys	0m1.120s
Твой вариант с uint32_t:
$ time ./uint_old /dev/shm/test.in /dev/shm/test.out 

real	0m1.282s
user	0m0.145s
sys	0m1.129s
Мой вариант с uint_fast32_t:
$ time ./uint /dev/shm/test.in /dev/shm/test.out 
Error while writing to output file.

real	0m1.196s
user	0m0.097s
sys	0m1.092s
Вот исходник:
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

#define BUF_SIZE (1024 * 1024)
#define MASK ((uint_fast32_t) 0xAAAAAAAAAAAAAAAA)

static char buf[BUF_SIZE];

int main(int argc, char **argv)
{
	FILE *fin, *fout;
	size_t readed;
	size_t elements;

	if(argc < 3) {
		fprintf(stderr, "Usage:\t%s <file.rec> <file.001> ... <file.avi>\n\t\t\"декодирует\" rec-файл в выходной avi-файл\n", argv[0]);
		return EXIT_FAILURE;
	}

	fout = fopen(argv[argc - 1], "wb");
	if (!fout) {
		fprintf(stderr, "Can't open output file \"%s\".\n", argv[argc - 1]);
		return EXIT_FAILURE;
	}

	--argc;
	while (++argv, --argc) {
		fin = fopen(*argv, "rb");
		if (!fin) {
			fprintf(stderr, "Can't open input file \"%s\".\n", *argv);
			return EXIT_FAILURE;
		}

		while (!feof(fin)) {
			uint_fast32_t *fast_buf = (uint_fast32_t *) buf;

			readed = fread(buf, 1, BUF_SIZE, fin);
			if ((readed < BUF_SIZE) && ferror(fin)) {
				fprintf(stderr, "Error while reading from input file \"%s\".\n", *argv);
				return EXIT_FAILURE;
			}

			elements = readed / sizeof(uint_fast32_t);
			if (readed % sizeof(uint_fast32_t))
				++elements;
			while (elements--)
				*fast_buf++ ^= MASK;

			if (fwrite(buf, readed, 1, fout) != 1) {
				fprintf(stderr, "Error while writing to output file.\n");
				return EXIT_FAILURE;
			}
		}

		if (fclose(fin)) {
			fprintf(stderr, "Error while closing input file \"%s\".\n", *argv);
			return EXIT_FAILURE;
		}
	}

	if (fclose(fout)) {
		fprintf(stderr, "Error while closing output file.\n");
		return EXIT_FAILURE;
	}

	return EXIT_SUCCESS;
}
Core 2 Duo T8300 2.40GHz, Fedora 14 amd64. Все три исходника компилировал с -O2.

Deleted
()
Ответ на: комментарий от Eddy_Em

А вообще

12%CPU

и

9%CPU

в результатах твоих измерений намекают на то, что производительность упёрлась в дисковый ввод-вывод.

Deleted
()
Ответ на: комментарий от AptGet

А процессор ресивера осилит?

как-то не подумал над этим :). От железа, конечно, зависит.

true_admin ★★★★★
()
Ответ на: комментарий от Deleted

uint32_t и uint64_t будет быстрее (на 32- и 64-разрядных системах соответственно).

а мне кажется будет одинаково работать вне зависимости от разрядности. Разрядность шины памяти напрямую к целочисленным операциям не относится. Замеряю как-нить когда влом не будет.

А ещё лучше какой-нить sse сюда впрячь.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

а мне кажется будет одинаково работать вне зависимости от разрядности. Разрядность шины памяти напрямую к целочисленным операциям не относится. Замеряю как-нить когда влом не будет.

У меня вышло быстрее =).

Deleted
()
Ответ на: комментарий от Deleted

производительность упёрлась в дисковый ввод-вывод.

Нет. Сделал многопоточную версию. Вот тест для 1000-байтного файла, забитого мусором из /dev/urandom (процессор у меня четырехъядерный):

03:54 /Data/scripts/C/decode_rec
gcc -DNBUF=2 recdecode.c -lpthread -o recdecode && time recdecode 111 222
1.25user 5.99system 0:50.04elapsed 14%CPU (0avgtext+0avgdata 0maxresident)k
2054496inputs+2050600outputs (1major+682minor)pagefaults 0swaps
03:55 /Data/scripts/C/decode_rec
gcc -DNBUF=4 recdecode.c -lpthread -o recdecode && time recdecode 111 222
0.82user 5.81system 0:40.52elapsed 16%CPU (0avgtext+0avgdata 0maxresident)k
2048592inputs+2050008outputs (2major+1196minor)pagefaults 0swaps
03:58 /Data/scripts/C/decode_rec
gcc -DNBUF=8 recdecode.c -lpthread -o recdecode && time recdecode 111 222
0.49user 5.16system 0:34.43elapsed 16%CPU (0avgtext+0avgdata 0maxresident)k
1965488inputs+2048000outputs (2major+2228minor)pagefaults 0swaps
03:59 /Data/scripts/C/decode_rec
gcc -DNBUF=12 recdecode.c -lpthread -o recdecode && time recdecode 111 222
0.74user 5.50system 0:44.04elapsed 14%CPU (0avgtext+0avgdata 0maxresident)k
1907520inputs+2048000outputs (2major+3260minor)pagefaults 0swaps
Меняю размер буфера:
04:01 /Data/scripts/C/decode_rec
gcc -DNBUF=8 -DBUF_SIZ=1000000L recdecode.c -lpthread -o recdecode && time recdecode 111 222
0.95user 5.62system 0:34.83elapsed 18%CPU (0avgtext+0avgdata 0maxresident)k
1902176inputs+2048024outputs (1major+2134minor)pagefaults 0swaps
04:02 /Data/scripts/C/decode_rec
gcc -DNBUF=8 -DBUF_SIZ=4000000L recdecode.c -lpthread -o recdecode && time recdecode 111 222
2.93user 7.06system 0:39.15elapsed 25%CPU (0avgtext+0avgdata 0maxresident)k
1893472inputs+2048568outputs (1major+7989minor)pagefaults 0swaps
Исходники

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Deleted

Пожалуйста. Два тестовых файла по 100Мб:

12:33 /dev/shm
gcc recdecode-mp.c -lpthread -DNBUF=1 -o recdecode && time ./recdecode 1 2 3
0.35user 0.94system 0:02.12elapsed 61%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+419minor)pagefaults 0swaps
12:33 /dev/shm
gcc recdecode-mp.c -lpthread -DNBUF=2 -o recdecode && time ./recdecode 1 2 3
0.06user 0.57system 0:00.82elapsed 78%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+676minor)pagefaults 0swaps
12:34 /dev/shm
gcc recdecode-mp.c -lpthread -DNBUF=4 -o recdecode && time ./recdecode 1 2 3
0.07user 0.67system 0:00.73elapsed 101%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1191minor)pagefaults 0swaps
12:34 /dev/shm
gcc recdecode-mp.c -lpthread -DNBUF=6 -o recdecode && time ./recdecode 1 2 3
0.01user 0.60system 0:00.56elapsed 110%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1708minor)pagefaults 0swaps
12:34 /dev/shm
gcc recdecode-mp.c -lpthread -DNBUF=8 -o recdecode && time ./recdecode 1 2 3
0.00user 0.53system 0:00.49elapsed 109%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2224minor)pagefaults 0swaps
12:34 /dev/shm
gcc recdecode-mp.c -lpthread -DNBUF=10 -o recdecode && time ./recdecode 1 2 3
0.00user 0.52system 0:00.48elapsed 108%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2740minor)pagefaults 0swaps
12:34 /dev/shm
gcc recdecode-mp.c -lpthread -DNBUF=12 -o recdecode && time ./recdecode 1 2 3
0.00user 0.52system 0:00.49elapsed 106%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3255minor)pagefaults 0swaps
12:34 /dev/shm
gcc recdecode-mp.c -lpthread -DNBUF=14 -o recdecode && time ./recdecode 1 2 3
0.00user 0.56system 0:00.50elapsed 112%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3772minor)pagefaults 0swaps
12:34 /dev/shm
gcc recdecode-mp.c -lpthread -DNBUF=16 -o recdecode && time ./recdecode 1 2 3
0.00user 0.52system 0:00.48elapsed 108%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+4288minor)pagefaults 0swaps
Налицо максимум в районе ~8-10 потоков.

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

Налицо максимум в районе ~8-10 потоков.

При чём тут потоки? Я же про IO говорил. Исключили дисковый IO - сильно возросла загрузка процессора и значительно уменьшилось время декодирования. Твои результаты подтверждают то, о чём говорю я.

Deleted
()
Ответ на: комментарий от Deleted

А я и не отрицаю, что в конечном итоге все упирается в дисковый ввод-вывод. Все-таки, быстрее ~20-25МБ/с на обычных саташных жестких дисках не получится.

Кстати, проверил на разных разделах разных жестких дисков. Зависимость от скорости IO довольно внушительная: чем ближе файл к краю диска и чем быстрее диск, тем больше выходит скорость.

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от Eddy_Em

Ан нет, несмотря на sync почему-то буферы не сбросились - скорость подскочила в конце теста до ~100МБ/с.

Eddy_Em ☆☆☆☆☆
() автор топика
Ответ на: комментарий от true_admin

Если у него 64-битная система, вполне возможно, что будет быстрее. Но, ИМХО, на современных домашних жестких дисках быстрее, чем моя последняя многопоточная версия, вряд ли что будет обсчитывать.

Eddy_Em ☆☆☆☆☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.