Forum Debian Users Gang

Elizabeth napisał(-a):

Dobra, z tym ostatnim keyfilem to chyba masz racje,
udziału.

Chyba... xD

Elizabeth napisał(-a):

morfik napisał(-a):

Co do punktu A:
Obraz jest udostępniany ze smartfona, a dopiero na kompie cryptsetup odczytuje nagłówki LUKS i to na kompie wpisujesz hasło do odszyfrowania klucza głównego. W tych operacjach smartfon nie bierze żadnego udziału.

tutaj cała kontrola nad rozruchem jest w rękach tych którzy kontrolują tą aplikacje, można równie dobrze przeprowadzić zdalną wersje ataku złośliwej pokojówki

przecież to ze komp wykonuje ten kod nie ma nic do rzeczy wiec nie wiem po co to napisałeś - w najprostszym scenariuszu kod rozruchu może być np. tak zmieniony ze komp zapisze odszyfrowany master key na tej emulowanej partycji /boot, następnie zostanie ona zrzucona i wysłana po kryjomu do tego kto kontroluje aplikacje a przywrócona zostanie oryginalna wersja partycji /boot

O rany. xD Mój smartfon jest zawsze ze mną, w przeciwieństwie do mojego kompa, który może zostać sam na sam z tą pokojówką. Logiczne zatem jest, że nikt mi nic w tym smartfonie nie podmieni bez mojej wiedzy. Obraz jest udostępniany na moje życzenie (muszę odblokować fon i wejść w opcje aplikacji). Obraz do momentu udostępnienia jest przechowywany w formie szyfrowanej, później zaś jest on montowany w trybie tylko do odczytu i udostępniany poza telefon i nic w tym obrazie nie zmienisz nie mając kontroli nad systemem telefonu, której mieć nie będziesz. xD

idąc dalej, nawet jak uzyskasz kontrolę nad moim telefonem i wszelkie zabezpieczenia szlag trafi, to dalej nagłówki LUKS są zabezpieczone hasłem i w ten sposób i tak nie uzyskasz dostępu do klucza szyfrującego dane na kompie — musisz złamać hasło. Niemniej jednak, dalej jesteś w kropce, bo zwykle hasła się odzyskuje albo przez manipulację initramfs/initrd albo przez podmianę kodu bootloader'a na partycji boot albo w MBR. W tym przypadku taką podmianę możesz zrobić na dysku kompa bez mojej wiedzy i możesz tam zainstalować sobie dowolnego keyloggera ale to ci nic nie da, bo ja robię rozruch bezpośrednio z telefonu i omijam te skompromitowane obszary na dysku komputera. A jak mi telefon zabierzesz i zabezpieczenia zawiodą, to możesz próbować zmienić obraz partycji boot, który tam mam, tylko ja akurat mam procedurę odzyskiwania systemu w tego typu okolicznościach, i cały initramfs/initrd wraz z kernalami i bootloaderem jest czyszczony i tworzony od nowa (naturalnie nagłówki LUKS zostają). No i oczywiście factory reset w telefonie. Nie ważne co ty mi tam wgrasz na ten telefon w przypadku, gdy jestem świadom jego utraty, bo i tak postawię bezpieczny setup, który umożliwi mi się dostanie do systemu w kompie z pominięciem wszelkich szpiegów. xD Więc tę cześć pewnie mamy z głowy.

Co do gościa, który który "kontroluje aplikację". Co on ma kontrolować? Źródła masz otwarte, to nie jest zamknięta aplikacja, której trzeba ufać. Ona rozmawia z kernelem, tym samym, którego używasz na Debianie. Jakie masz przesłanki, że autor chce działać na twoją szkodę? A jakie masz przesłanki, że twórcy cryptsetup też czasem backdoor'a nie podrzucily? A devy kernela albo Debiana? Z jakiego bootloader'a korzystasz? Może oni współpracują z NSA, i już logują wszelkie twoje przyciśnięcia klawiszy i przesyłają pliki klucze wraz z nagłówkami zaszyfrowanych partycji? Skąd wiesz, że już cie nie hackneli? xD

Elizabeth napisał(-a):

No i oczywiście zapraszam na GH, gdzie masz źródła Mountr, bo widać, to że ten projekt jest również opensource, też ci umknęło. xD
https://github.com/Streetwalrus/android_usb_msd

Zaraz, zaraz, a czy to:

https://www.snip.today/post/4-million-iota-stolen-f … ed-generator/

tez nie było OpenSource i nie miało kodu pokazanego na githubie ?

To w takim razie jakim cudem im się udało ukraść 4 miliony dolarów ?

Wystarczy czytać co pisze w tekście: xD

The original website linked to a GitHub repository, complete with warnings to check the URL to avoid scammers and advising the user to use the website directly instead of downloading the code from GitHub, saying it is untested. When compared to the GitHub's files, the website loaded an extra JavaScript file containing malicious code. Generating a repeating series of numbers, this code caused the generated IOTA wallet seeds to always be the same.

Elizabeth napisał(-a):

prawda jest taka ze nikt nie ma czasu samodzielnie wszystkiego kompilować i analizować i po prostu trzeba oprzeć się na zaufaniu najlepiej do możliwie małej liczby organizacji

Aż dziw, że z Debiana korzystasz. xD

Elizabeth napisał(-a):

jeśli ta aplikacja ma otwartą możliwość aktualizacji czy wymieniania jakiś danych z internetem (a zapewne ma) to moim zdaniem dawanie jej kontroli nad głównymi kluczami szyfrującymi nie jest najlepszym pomysłem

No jak najbardziej ma, działa na prawach root, więc może wszystko. xD