Na oficjalnym forum raspberrypi.org „Dom” - moderator napisał:
Sfałszowałem swoją tablicę, żeby mieć twój numer seryjny
Jak edytować numer seryjny Raspberry Pi?
/proc/cpuinfo
? Nie wiem, czy to pomoże z bąble dekoderów though ..
Na oficjalnym forum raspberrypi.org „Dom” - moderator napisał:
Sfałszowałem swoją tablicę, żeby mieć twój numer seryjny
Jak edytować numer seryjny Raspberry Pi?
/proc/cpuinfo
? Nie wiem, czy to pomoże z bąble dekoderów though ..
Odpowiedzi:
Kopiuję to z tego wątku na forum .
Dom ma dostęp do całego kodu źródłowego, debugera Videocore i wielu zamkniętych narzędzi specyficznych dla VC. Wydanie jakichkolwiek informacji umożliwiających zmianę numeru seryjnego złamałoby mechanizm licencjonowania kodeków, więc nigdy się nie wydarzy.
Dodatkowo jak opublikowano w wątku. Jedynym powodem zmiany numeru seryjnego byłoby skopiowanie czyjejś licencji MP4 i korzystanie z niej. Takie jest bezpieczeństwo związane z licencjonowaniem. Twój unikalny numer seryjny jest powiązany z licencją MP4, więc nawet jeśli ktoś dostanie twój klucz licencyjny, nie będzie w stanie nic z tym zrobić (chyba że mógłby zmienić numer seryjny Raspberry Pi).
AKTUALIZACJA: Aby odpowiedzieć na aktualne pytanie. Powiedziałbym, że ponieważ Dom ma źródło faktycznego niskiego poziomu oprogramowania układowego. Wyobrażam sobie, że tak naprawdę po prostu zmienia kod źródłowy, który odczytuje serial i zmusza go do zwrócenia innej wartości. Szczerze wątpię, czy to rzeczywiście zostało zmienione (mam na myśli procesor), bardziej tak, jakby zmienił część kodu oprogramowania, aby zwrócić inny numer seryjny. Przepraszam również pytającego, zamiast odpowiedzieć na pytanie, po prostu daliśmy ci „Dlaczego? To nie jest miłe. Twoja kradzież”. Mój błąd.
Jeśli chodzi o programy przestrzeni użytkownika, łatwo jest ich oszukać i sfałszować zawartość dowolnego pliku. Załóżmy na przykład, że program C używa /proc/cpuinfo
pliku do weryfikacji numeru seryjnego. Program jest chroniony przed kopiowaniem i powiązany z szeregowym, a ja nie mam kodu źródłowego. Nadal jednak mogę biegać strace program 2>&1 | grep cpuinfo
, co ujawni coś takiego:
open("/proc/cpuinfo", O_RDONLY) = 3
W tym momencie mogę utworzyć małą bibliotekę cpuinfo.so
z następującą funkcją:
int open(const char *file, int flags) {
static int (*real_open)(const char *file, int flags);
if(!real_open) real_open = dlsym(RTLD_NEXT, "open");
if(!strcmp(file, "/proc/cpuinfo")) file = "/tmp/cpuinfo";
return real_open(file, flags);
}
Jak widać, sprawdzam, czy użytkownik biblioteki próbuje otworzyć /proc/cpuinfo
, w którym to przypadku otwieram /tmp/cpuinfo
.
Następnie uruchomię oryginalny program zabezpieczony przed kopiowaniem jako LD_PRELOAD=/path/to/cpuinfo.so program
i z przyjemnością odczyta mój fałszywy plik, myśląc, że to /proc/cpuinfo
działa, jednocześnie pracując poprawnie z resztą plików.
Zauważ, że jeśli oprogramowanie chronione przed kopiowaniem zawiera obiekty jądra, będzie o wiele trudniej oszukać, ponieważ może uzyskać bezpośredni dostęp do sprzętu. Jednak takie oprogramowanie będzie również działać tylko z jądrem, dla którego zostało zbudowane, co sprawia, że jego dystrybucja jest niepraktyczna.