Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Rar -niewłaściwe hasło.

fazi8 11 Lis 2005 00:33 17796 18
  • #1 11 Lis 2005 00:33
    fazi8
    Poziom 11  

    Witam szanownych kolegów. Mam mały, a raczej duży problem . Kiedyś spakowałem pliki Rar-em z hasłem.Odbyło się to jeszcze na moim starym komputerze/ na XP / i dysku formatowanym w FAT 32.I wszystko grało jak należy.Od niedawna mam nowy komputer system XP ale dysk formatowany w NTFS.Otóż wgrywam pliki ,chcę rozpakować,oczywiście program żąda hasła,ja je podaję i dostaję komunikat,że niewłaściwe hasło. Co może być przyczyną ? Hasło jest na sto procent właściwe, bo mam w zwyczaju notować hasła.Starego komputera już nie posiadam.Za wszelkie podpowiedzi z góry bardzo dziękuję.


    Wszyskim kolegom bardzo dziękuję za pomoc, bo pomogło!

    Niniejszym temat uważam za zamknięty.

  • Pomocny post
    #2 11 Lis 2005 01:36
    Jezior2000
    Poziom 17  

    Ja nie mam pojęcia co może być przyczyną tego ale mogę pomóc w inny sposób.Więc kiedyś ściągnąłem z netu plik w zipie i był zabezpieczony.Nie znałem hasła ale mi zależało więc poszukałem taki program Ultimate Zip Cracker w skrócie UZC hasło było 6 literowe a programik demo do 4znaków obsługiwał.Więc ściągnąłem sobie crack do tego crackera.Hasło znalazł w sekundę.Polecam programy pod win.Widziałem na tej stronie też crackery do rara.Pewnie nazywa się podobnie np.rarcracker.Powodzenia.Co do tego ntfs to nie wiem wydaje mi się że plik po znalezieniu hasła powinien być dobry.

  • Pomocny post
    #3 11 Lis 2005 01:45
    grzechura
    Poziom 17  

    mam ten sam problem. Haslo na 100 procent jest poprawne ale wyskakuje mi ze haslo jest niepoprawne. Jednak sytem plikow i operacyjny u mnie sie nie zmienil.

  • Pomocny post
    #4 11 Lis 2005 19:57
    Tommy82
    Poziom 39  

    Do rara jest

    Advanced RAR Password Recovery

    A le to dzial metoda brut-force przy dlugim hasle moze zycia braknac jesli mieliscie krotkie to polecam programik poradzi sobie (jesli wiecie czy to byly same litery male lub duze to tez przyspieszy zabawe)
    Ale podkreslam to dziala brut-force sprawdza po kolei wszystkie hasla i sprawdza pewnie crc przy blednym hasle bedzie blad crc ktory program wylapuje i sprawdza nastepne haslo

  • Pomocny post
    #5 11 Lis 2005 22:34
    oleq_30
    Poziom 30  

    jesli dobrze kojarze to win rar koduje haslo w kluczu 128 bitowym wykorzystujac numer seryjny Hdd . kombinuj wiec jak radza wyzej

  • Pomocny post
    #6 11 Lis 2005 23:33
    Tommy82
    Poziom 39  

    Cytat:
    numer seryjny Hdd

    Mozesz podac wiecej szczegolow ??
    WYdaje mi sie ze wtedy dekompresja na innym dysku byla by niemozliwa ale moge sie mylic

  • Pomocny post
    #7 12 Lis 2005 00:48
    Jezior2000
    Poziom 17  

    Myśle że tommy82 ma rację ale przecież o to właśnie chodzi że dekompresja na innym dysku nie jest możliwa.To musi być coś wspólnego z systemem ntfs.Pewnie hasło jest zapisywane inną metodą niż przy pomocy ntfs czy fat tak żeby sobie nie wyśledzić monitorem hdd pod którym klastrem jest to zapisane.Gdyby było to takie proste to program łamacz nie robiłby to metodą klepać-patrzeć.
    Coś mi się zdaje że polega to raczej na tym że twórcy rara nie przewidzieli tego że może kiedyś wejść taki system plików który będzie wymuszał ten i tylko ten system i/o albo twórcy systemu ntfs nie wzięli pod uwagę rara.Ale mogę się mylić :\ .
    Jeśli byłoby tak jak myślę to wystarczyłoby wziąć sobie taki monitorek i sprawdzić teraz gdzie on to zapisuje skoro wymuszony jest tylko system ntfs.Może być problem tego typu że zostało to już przez tych twórców przewidziane bo ten kto pisał jakikolwiek program wie że trzeba sobie najpierw otworzyć strumień a kiedy nie da rady to flaga jest fail.No i teraz co ten program robi to nie wiadomo czy losuje sobie to hasło a może jednak czyta sobie jakieś bzdury z pamięci ram albo z hdd.Najlepiej jest sprawdzić programeem łamaczem czy hasło jest podobne do tego co się je wpisało oraz czy nie jest czasami przy zresetowaniu kompa inne za każdym razem.

  • Pomocny post
    #8 12 Lis 2005 10:13
    Tommy82
    Poziom 39  

    Wg mnie to haslo w rar nie jest zapisane nigdzie.
    wydaje mi sie ze podane przez uzytkownia haslo jest uwzgledniane jako jakis parametr w algorytmie kompresujacym z tad blad crc przy blednym hasle jesli haslo bylo by gdzies zapisane to na bank bylo by to juz rozwalone (zipa tez lamie sie metoda brut-force).
    Kumpel napisal kiedys takiego lamacza dla rara jeszcze dosowego (chodzilo o zaklad).
    Program byl odpalany w ramdrive i plik .rar tez byl w ramdriwie (to byla 486/66 z dyskiem 100 mb wiec z dysku (tak wolnego ) trwalo by to tysiace lat)
    Program dzialal w nastepujacy sposob :
    program odpalal rara a parametrem byla nazwa pliku rar i haslo. Jesli rar mial zle haslo to pojawial sie komunikat rara crc failed (czyli bledne haslo poniewaz nie zgadza sie suma kontrolna) program to wylapywal i odpalal znowy rara z nastepnym haslem i tak do czasu az nie bylo komunikatu crc.
    Wydaje mi sie zr rar sam z siebie nawet spakowany z haslem musi byc rozpakowywalny wszedzie poniewaz bylo by to bez sesu (rar powstal miedzyinnymi po to zeby ulatwic przenoszenie plikow miedzy koputerami) dlatego przyczyny szukal bym gdzie indziej
    Moze to byc wina klawiatury lub strony kodowej
    NIe mamy nigdy pewnosci jakie jest haslo bo widzimy gwiazdki.
    Zawsze mozna sprobowac rozpakowac to z cdromu (nagrac redo rara na rw i sprobowac rozpakowac z cd na tym samym kompie jesli niepomoze to na innym , jesli dalej nie bedzie biegac to ja bym sie raczej od tego ntfs odczepil bo przy kopiowaniu na cd raczej wszystkie inf z partycji ntfs powinny zostac utracone)

  • #9 13 Lis 2005 00:02
    grzechura
    Poziom 17  

    U mnie bylo tak ze tylko przeinstalowalem system (wczesniej zrobile formata) i pozniej archiwum juz nie moglem otworzyc. Nie jest mozliwe zeby on gdzies haslo na dysku zapisywal, bo mam wiele spakowanych archiwow z haslem i otwieram je bez problemu na roznych kompach pod roznymi systemami (XP i ME). Wiec to chyba odpada. Kombinowanie z systemem plikow tez raczej odpada, bo jak wspomnialem wczesniej u mnie system plikow po formacie na 100% sie nie zmienil a jedenka nie moge otworzyc tego archiwum. Wiec w czym lezy problem?? sam nie wiem.

    Jesli chodzi o Advanced RAR Password Recovery to jest masakra. Plik maialem okolo 400MB haslo 8 literowe, w tym duze i male. rzeczywiscie zycia braknie...

  • #10 13 Lis 2005 01:35
    Jezior2000
    Poziom 17  

    Jakby tak na rozum to hasło musi być tylko raz zczytane z hdd i załadowane do ramu w postaci zaszyfrowanej tylko i wyłącznie w jednej paczce dopiero odpowiedni do tego algo ma je rozszyfrować tzw. token.Istota tkwi nie w samym haśle tylko w haśle i w kluczu.Ale żeby jakoś się do tego dobrać to trzeba najpierw wiedzieć gdzie to hasło na twardym dysku jest.Dlaczego w jednej paczce?Bo choćby z tego powodu że jeśli mamy takie pliki spakowane jak np. film to zajmuje taki plik 700MB i nie może być zapakowany do Ramdrive w jednej paczce.Jeśli by ten plik dekompresować metodą "siekaną" to gdyby znaki hasła były wpięte gdzieś pomiędzy bity tego pliku to spowodowałoby nielada nieporządek.Może się mylę :/.Dopiero później można podziwić się na temat jak to hasło jest zakodowane?.I myślę że też jest to problem nie do końca zamknięty.Bo algorytmy także można łamać.Nie wiem jakim programem ale wiem że każdy łańcuch operacji można złożyć z czterech podstawowych czyli +,-,*,/.Czyli każdy algorytm można złamać.
    Trochę z innej beczki.Mój program UZC rozpracował hasło 6 znakowe dopiero później okazało się że literowe(małe litery) w 1sek.Wiem że liczba operacji obliczeniowych wzrasta exponencjalnie w przybliżeniu 2 do n-tej gdzie n to liczba bitów hasła.Ale przecież 6 a 8 bitów to nie taka duża różnica jakby się mogło wydawać na pewno życia nie zbrakłoby.Z dużym przybliżeniem to jakieś 2 do 24h.
    Jeśli nie jest to hasło związane z ntfs lub z numerem seryjnym hdd to może ono być związane nawet z takim banałem jak nazwa grupy roboczej komputera.Ale fakt jest faktem że jest ono z czymś zmiennym związane.Chyba że się mylę.
    Prosta sprawa tommy82 napisał że program łamacz bazuje na sumie kontrolnej pliku.Moim zdaniem to prawda dlatego ja uważam że program winrar przewidział zmianę systemu operacyjnego :(.

  • #11 13 Lis 2005 11:38
    Tommy82
    Poziom 39  

    Zrobilem kilka prostych doswaidczen i moje wnioski to:
    1) dlugosc hasa nie wplywa w zaden sposob na wielkosc pliku wynikowego (nawet przy znacznych roznicach dlugosci hasel plik wynikowy ma rozna dlugosc co do bajtu)
    --->haslo raczej nie jest zpisywane w pliku rar
    2) Jest roznica dlugosci miedzy plikiem wynikowym spakowanym bez hasla i z haslem
    ---> Najprwadopodobniej jest to tylko informacja ze tam jest haslo (w moich testach bylo tego troszke ponad 20 bajtow, to mniej niz hasla ktore stosowalem do testow)
    3) Dlugosc zastosowanego hasla ma wplyw na dlugosc trwania kompresji
    ---> z tego wynika ze haslo jest jakos uwzgledniane podczas kompresji.

    Moje konkluzje:
    z 1 wynika ze haslo nie jest zapisywane w pliku (ze wzgledu na fakt ze archiwa rar sa generalnie przenoszalne na inne napedy i inne komputery wiec nie jest to inne miejsce na dysku, w sumie nigdy nie spotkalem sie z czyms takim zeby archiwum nie chcialo sie rozpakowac)
    Z faktu ze dlugosc hasla wplywa na czas kompresji wnioskuje ze haslo podane jest uwzgladniane w algorytnie kompresujacym w jaks prosty sposob (ale "trudny" obliczeniowo w druga strone). WYglada to pewnie tak ze algorytm pakujacy w ktoryms momecie wykonuje jakies przesuniecie bitowe albo cos na ta nute wykozystujac do tego haslo) Nastepnie przy dekompresji jest to odwaracane jesli podane zostalo dobre haslo jesli zle wystepuje bad CRC (nalezy zwrucic uwage ze ten sam plik ma zawsze takisam rozmar niezaleznie od dlugosci hasla). Dlatego wlasne jest ono lamane brut force bo nie ma innej mozliwosci
    CO jest jednym z lepszych zabezpieczen, W przeciwnym przypadku takie chaslo zostalo by juz dawno rozpracowanae i program typu pass recowery poprostu by zwracal haslo

  • #12 13 Lis 2005 16:23
    grzechura
    Poziom 17  

    Tommy82 napisał:
    Zrobilem kilka prostych doswaidczen i moje wnioski to:
    1) dlugosc hasa nie wplywa w zaden sposob na wielkosc pliku wynikowego (nawet przy znacznych roznicach dlugosci hasel plik wynikowy ma rozna dlugosc co do bajtu)
    --->haslo raczej nie jest zpisywane w pliku rar
    2) Jest roznica dlugosci miedzy plikiem wynikowym spakowanym bez hasla i z haslem
    ---> Najprwadopodobniej jest to tylko informacja ze tam jest haslo (w moich testach bylo tego troszke ponad 20 bajtow, to mniej niz hasla ktore stosowalem do testow)
    3) Dlugosc zastosowanego hasla ma wplyw na dlugosc trwania kompresji
    ---> z tego wynika ze haslo jest jakos uwzgledniane podczas kompresji.

    Moje konkluzje: z Twoich prob.
    Jesli jest roznica w wielkosci pliku wynikowego z haslem a bez hasla to musi byc tam zapisywane haslo. Sprobuj spakowac plik z haslem i otworzyj je na innym kompie. Gwarantuje ze na 100% otworzysz. Wiec to haslo musi byc w archiwym.To ze dlugosc hasla ne ma wplywu na wielkosc pliku moze swiadczyc o tym ponizyszy przyklad:
    np w programowaniu np w w pascalu definiuje sobie zmienna lancuch:string[255]. I niezaleznie czy bede w niej przechowywal jeden, czy 255 znakow to i tak ta zmienna bedzie zajmowala takie samo miejsce.

  • #13 13 Lis 2005 17:22
    Tommy82
    Poziom 39  

    Tak ale roznica byla mniej niz 30 bajtow a haslo bylo znacznie dluzsze (by wychwycic roznice w czasie kompresji zalezne od dlugosci hasla )
    A pozatym nie musi byc zapisanego hasla gdziekolwiek
    Bo rar go nie sprawdza (jesli haslo bylo by zapisane gdzies to rar by od razu powiedzial ze bledne haslo a on rozpakowywuje plik bez zastanowienia z podanym haslem) dopiero na koncu sprawdza sume kontrlna rozpakowanego pliku.
    I jesli sie nie zgadza to znaczy ze bylo bledne haslo a w pliku mamy kaszanke a nie dane (cos zupelnie innego niz to co spakowalismy) wiec wnioskuje ze podane przy dekompresji haslo jest jakims parametrem algorytmu dekompresujacego bo ze zlym haslem wywala smieci a poprawnosc hasla jest sprawdzana na koncu i to nie wprost tylko posrednio wiec hasla nie ma w pliku, Jak by bylo to juz dawno by je ktos rozszarpal.
    Na koniec dodam

    Code:
     
    
    !   E:\xxx\xxx.rar: Błąd CRC w zaszyfrowanym pliku xxxx.tes (niewłaściwe hasło?)


    Zwrocie uwage ze rar sam nie jest pewien czy blad crc jest spowodowany blednym haslem to tylko jego przypuszczenie jesli znal by haslo bylby tego pewny a tak tylko przypuszcza bo rownie dobrze moze to byc spowodowane jakims przeklamaniem w samym pliku rar

    Natomiast jesli w pliku niespakowanym zmienimy jakis bajt otrzymamy komunikat
    Code:

    !   E:\txxxsxi\xxxx.rar: Błąd CRC w xxxx.tes . Plik jest uszkodzony

    Tez nie zgadza sie suma kontrolna ale tu nie ma juz watpliwosci ze jest blad w archiwum BO nie ma mozliwosci zaistnienia bledu w hasle.
    NA dowod tego niech posluzy fakt ze jesli wezmie sie plik spakowany na haslo i zmieni sie 1 bajt to rar i tak bedzie sugerowal bledne haslo (mimo ze jest ono podane prawidlowo a blad crc wynika z ingerecji w rara)

    Code:
    !   C:\xxxx\kkk.rar: Błąd CRC w zaszyfrowanym pliku Nowy kkkkk.txt (niewłaściwe hasło?)
    


    Reasumujac w pliku *.rar nie ma hasla bo jak by bylo to by sie takie cuda nie dzialy, Pozatym bylo by to glupie bo to haslo (lub cos co bardzo pomoglo by je rozwalic ) dalo by sie wyssac w debugerze podczas jego weryfikacji. Dlatego wlasnie haslo nie jest zapisywane nigdzie
    Inny,mi slowy nasz kolega blednie wprowadza haslo z jakis powodow


    Moim zdaniem algorytm haslowania rara dziala na takiej zasadzie (max uproszczenie i brak jakichkolwiek szczegolow):
    jesli mamy do zakodowania ciag
    Code:
    aaaaaaaaaa


    Powiedzmy teraz ze nasze haslo to klawisze (ALT+1),(ALT+2),(ALT+3)
    czyli wpisalismy znaki o kodach 1, 2, 3, (bez w nikania w szczegoly co to)

    A teraz algotytm uwzglednia nasze haslo w ten sposob ze dodaje do kodu znaku wartosc kodu znaku hasla
    Wiec po zaszyfrowaniu otrzymamy ciag
    Code:
    bcdbcdbcdb


    I mamy plik zaszyfrowany
    w ktorym nie ma nigdzie hasla
    jesli go chcemy rozpakowac i podamy haslo
    (ALT+1),(ALT+1)
    Po odjeciu wartosci hasla od zakodowanego ciagu otrzymamy plik
    Code:
    abcabcabca

    Z ty ze nie bedzie nam sie zgadzac suma kontrolna i otrzymamy blad crc
    natomiast jeszli podamy haslo prawidlowe
    rozpakuje nam sie archiwum dobrze a suma kontrolna bedzie sie zgadzac
    I tak wlasnie lamacze lamia haslo az trafia na haslo przy ktorym zgadza sie suma kontrolna
    JAk widac nie ma potrzeby aby haslo gdziekolwiek zapisywac
    JEsli ktos znajdzie jakies niescislosci w moim toku rozumowania prosze o zwrocenie uwagi.

  • #14 13 Lis 2005 18:45
    grzechura
    Poziom 17  

    No to co napisales to w sumie ma rece i nogi. Jenak tak czy owak, haslo jest przechowywane w archiwum bo suma kontrolan musi byc tam przechowywwana - chyab ze sie myle. Mysle ze nie ma to znaczenia czy jest w postaci jawnej czy niejwanej, ale jednak jest w archiwum. Inaczej danego pliku nie mozna by otworzyc na innym kompie.

    Czy mzliwe jest ze algorytm rozkodowania zmienil sie w najnowszej wersji rara i dlatego wywala blad? Bo jedyne co mi przychodzi teraz do glowy to po formacie moglem zainstalowac nowsza wersje rara, niz ta ktora pakowalem archiwum. ale nie jestem pewien czy tak bylo.

  • #15 13 Lis 2005 19:26
    Tommy82
    Poziom 39  

    Wlasnie caly knif polega na to ze haslo jest mu do niczego nie potrzebne bo uzywa je przy pakowaniu
    a potem przy dekompresji (jesli haslo jest dobre to dekompresuje i zgada sie suma kontrolna jesli jest zle to tez dekompresuje ale pojawia sie blad crc jesli to haslo bylo by gdzies w srodku to zostalo by rozwalone juz dawno temu niezaleznie w jakiej formie by bylo), Jedyne co jest potrzebne to suma kontrolna, Rar nie sprawdza nigdzie poprawnosci hasla poprostu uzywa podanego w processie dekompresji i tyle albo bylo dobre albo zle,
    Takie zabezpieczenie to jedno z najlepszych jakie moze byc bez hasla (ktore jest kluczem do dekompresji rozpakujemy smieci)

    A co do kwestji zainstalowania innej wersji rara to maja one to do siebie ze sa z soba w dol w pelni kompatybilne (z doswaidczenia wiem ze winrar najnowszy radzi sobie bez zadnych problemow z rozpakowaniem archiwow z haslem ktore tworzylem jeszcze pod rarem 2.0 pod dosa wiec to raczej odpada)
    Ja bym sie raczej moze przyczepil strony kodowej/ukladu klawiatury moze masz inna/inny i jakis znak w hasle wskakuje nie taki

  • #16 13 Lis 2005 19:34
    grzechura
    Poziom 17  

    nie nie, klawiatura ta sama, sprzet ten sam, tylko format...i potem nowy system (ten sam)

  • #17 13 Lis 2005 19:42
    Tommy82
    Poziom 39  

    chodzi mi o ustawienia ukladu klawiatury i strony kodowej w systemie
    JEszcze jedno pytanko czy to archiwum bylo wczesniej rozpakowywane ??
    Czy jest mozliwosc uszkodzienia samego archiwom (jak napisalem wyzej zmiana wartosci jednego bajtu w archiwum z haslem powoduje wyswietlemnnie komunikatu crc bledne haslo??)
    masz moze kopie tego archiwum ?? moze z kopi
    Sproboj tak
    wiesz pewnie co masz w tym archiwum (nie wnikam )
    wez je rozpakuj z twoim haslem
    i podgladnij poczatek pliku (hodzi o naglowek)
    i porownaj go z naglowkiem pliku tego samego formatu (jesli bedzie podobny to znaczy ze blad sumy kontrolnej prawie na pewno wynika z przeklamania w samym archiwom, jesli bedzie totalnie inny to z prawdopodobienstwem graniczacym z pewnoscia mozna stwierdzic ze wpisujesz zle haslo) w pierwszym przypadku nic sie nie da zrobic

  • #18 13 Lis 2005 20:21
    grzechura
    Poziom 17  

    Jezior2000 napisał:

    Wiem że liczba operacji obliczeniowych wzrasta exponencjalnie w przybliżeniu 2 do n-tej gdzie n to liczba bitów hasła.Ale przecież 6 a 8 bitów to nie taka duża różnica jakby się mogło wydawać na pewno życia nie zbrakłoby.Z dużym przybliżeniem to jakieś 2 do 24h.


    Otoz male sprostowanie. Mowa tu oczywiscie o wariacji z powtorzeniami. obliczamy to ze wzoru n^k gdzie w naszym przypadku n- liczba znakow ktore tworza haslo, k - ilosc liter w hasle. Tak wiec jesli mamy haslo zlozone z maluch i duzych liter (tak jest najczesciej) pomijajac znaki typu -,/,[,{ itd mamy n=48 przy k=6 lub k=8. Kto wezmie kalkulator i to policzy zobaczy ze to OGROMANA roznica...
    48^6=1,2*10^10
    48^8=2,8*10^13
    W przypadku Jezior2000, gdzie haslo 6 - literowe ropakowywyje w kilka sekund (zakladam np 2 sekundy, bo niewiem dokladnie), to roznica wyniesie (przy hasle 8 literowym) okolo 2300 sekund. W moim przypadku gdzie 400MB rozpakowywuje ie w okolo 3minuty to az boje sie liczyc, jak duza to roznica....

  • #19 13 Lis 2005 22:36
    Jezior2000
    Poziom 17  

    Myślę że cała ta akcja miałaby sens jeśli okazałoby się że jest jakaś zmienna przyczyna do której możnaby się przyczepić.Założenie było takie że istnieje taki plik który nie można rozpakować na tym samym systemie ale na innym dysku.Swoją drogą jakby to było fajnie jakby można było zwykłym programem bez wpisywania czy to mają być małe duże cyfry czy znaki nawet na słabym komputerze rozpracować hasło takie 128 bitowe w przeciągu ułamka sekundy myśle że nie muszę mówić że nie metodą brut-force (Co brutalne to nieeleganckie) :) .

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME