Kopiowanie plików przez schowek w Windows? Administratorzy go nienawidzą!

Ostatnio w pracy miałem do przekopiowania kilka małych plików, ze względu na specyfikę środowiska, poza suchym połączeniem RDP nie dało się zbyt wiele – kopiowanie plików tylko fizycznie w serwerowni, do której nie mam dostępu. Zmapowanie zasobu sieciowego? Niestety, ruch wycięty. Kopiowanie plików przez kopiuj/wklej i RDP? Też mogłem zapomnieć – bo połączenie zdalne odbywało się poprzez rozwiązanie Citrixowe, a tutaj bezpieczeństwo najwyraźniej nie chciało kopiowania plików. Co zatem zrobić?

Czy trzeba prosić kogoś aby fizycznie wpiął się do serwera i wgrał nam pliki? To zależy 😉 Jeśli mamy do czynienia z dużymi plikami, to niestety tak. W tym przypadku dużym plikiem w moim mniemaniu jest już plik powyżej 20KB – polecam tutaj przetestować co jest dla Was akceptowalnym rozmiarem.

Zatem jeśli macie do skopiowania certyfikat/plik.dll, a może mały spakowany zip, spróbujcie użyć komendy:

certutil -encode plik.wejsciowy plik.wyjsciowy

Co nam to da? Dość dużo tekstu w pliku wyjściowym. Poniżej zrzut ekranu po przeprocesowaniu pliku .exe:

Tak, właśnie wygenerowaliśmy certyfikat „czegokolwiek”

W praktyce właśnie zakodowaliśmy plik do postaci tekstowej. Na czym polega trick? Skoro działa schowek, to damy radę przekopiować ten tekst. Teraz warto przypomnieć, jak duży plik kodowaliśmy – tutaj mamy ponad 500 linii tekstu po 65 znaków każda. Jeśli plik będzie zbyt duży, kopiowanie może się okazać bardzo czasochłonne, bo niekoniecznie cała zawartość może się zmieścić w schowku.

Plik po skopiowaniu odtwarzamy w analogiczny sposób:

certutil -decode plik.wejsciowy plik.wyjsiowy

Dekodowanie pliku trwa znacząco dłużej niż jego kodowanie.

Pomimo swoich ograniczeń, uważam ten sposób za świetny trick dla pewnych środowisk. Czy widzę inne zastosowania? Może ukrywanie „tajnych” informacji przed osobami nietechnicznymi… ale na to jest setki innych sposobów 🙂

Marcin Kuchczyński

Wielki fan automatyzowania wszystkiego, co trzeba wykonać więcej niż 2 razy. Cierpliwie rozwijający się w kierunku rozwiązań chmurowych i raczkujący w sferze sztucznej inteligencji. W IT od 2016 roku.

4 komentarze

  1. kapela86 pisze:

    No ale po co te kombinacje skoro po RDP możesz normalnie kopiować pliki przez Kopiuj/Wklej, a nawet możesz „zamapować” swój lokalny dysk.

    • gjon pisze:

      Myślę, że chodzi o ten fragment: „połączenie zdalne odbywało się poprzez rozwiązanie Citrixowe”, co sugeruje mi, że niekoniecznie musiało to wyglądac tak jak dzieje się do pod klientem MS.

  2. Krzysiek pisze:

    Czy Wy sobie na siłę utrudnianiacie życie? A kopiowanie pomiędzy RDC a zasobem lokalnym, nie mówię o mapowaniu zasobu po RDC, po prostu przez schowek i uwierzcie mi nie 20kB a 20GB tak pójdzie, chyba że jak macie łącze do d… to faktycznie, może nie pójść

    • Marcin Kuchczyński pisze:

      Cześć, dziękuje za komentarz. Tak jak pisałem, dotyczy to specyficznych warunków, gdzie o zmapowaniu zasobu możesz zapomnieć (bo ruch wycięty), a dostęp RDP masz nie przez czystego RDP, a na przykład Citrixa albo CyberArk – te rozwiązania mogą blokować transfer plików przez zwykłe kopiuj/wklej, a i schowek ma znacznie ograniczoną zawartość. Jeśli w środowisku wycięty jest też schowek – no to i moja rada nic nie da 🙂
      Fakt, zastosowałem dość mocny skrót myślowy z tym RDP i nie wspomniałem o tym we wpisie. Zrobię korektę

Leave a Reply