2009-10-21 9 views
14

Korzystam z Visual Studio 2005 w 64-bitowym systemie Windows XP Pro dla projektów C i C++. Jedną z popularnych sztuczek, których używałem od czasu do czasu w debugerze, było zapamiętanie wartości liczbowej wskaźnika z poprzedniego przebiegu debugowania programu (na przykład 0x00000000FFAB8938), dodanie go do okna oglądania z odpowiednią typografią (na przykład ((MyObject *) 0x00000000FFAB8938)->data_field) a następnie obserwować pamięć zajmowaną przez obiekt podczas następnego przebiegu debugowania. W wielu przypadkach jest to dość wygodne i użyteczne, ponieważ dopóki kod pozostaje niezmieniony, można oczekiwać, że przydzielony układ pamięci pozostanie niezmieniony. Krótko mówiąc, działa.Stabilność wskaźnika w systemie Windows Vista

Jednak stosunkowo niedawno zacząłem używać tej samej wersji Visual Studio na laptopie z Windows Vista (Home Premium) 64-bitowym. O dziwo, znacznie trudniej jest użyć tej sztuczki w tej konfiguracji. Rzeczywisty adres pamięci wydaje się zmieniać raczej często od uruchomienia do uruchomienia bez wyraźnego powodu, tj. Nawet gdy kod programu nie został w ogóle zmieniony. Wygląda na to, że rzeczywisty adres nie zmienia się całkowicie losowo, po prostu wybiera jedną wartość ze stałego, bardziej lub mniej stabilnego zestawu wartości, ale w każdym przypadku znacznie utrudnia to oglądanie tego typu pamięci.

Czy ktoś zna przyczynę tego zachowania w systemie Windows Vista? Co powoduje zmianę układu pamięci? Czy jest to jakaś zewnętrzna ingerencja w przestrzeń adresową procesu z innych procesów [systemowych]? Czy jest to jakieś dziwactwo/funkcja API Heap API pod Vistą? Czy istnieje sposób, aby temu zapobiec?

+1

Pod Linuksem istnieje od dłuższego czasu randomizator sterty, który ma na celu uniknięcie ataków z przepełnieniem bufora. Może to zostało ostatecznie zaimplementowane również przez MS? – jdehaan

+0

Cóż, wiem o tym, ale AFAIK działa tylko wtedy, gdy * ponownie uruchamiasz * komputer. Dokładniej, usłyszałem, że MS zaimplementowało swoją wersję, aby losować rzeczy przy każdym rozruchu (nie wiem jak to działa na Linuksie). Tak więc zachowanie, które obserwuję w Vista nie wydaje się być powiązane. – AnT

+0

Chociaż może to być coś. Używam aplikacji VS 2005, która jest 32-bitową aplikacją, która może debugować aplikacje 64-bitowe. AFAIK, działa poprzez zdalny mechanizm debugowania MS. Czy to możliwe, że Vista zasadniczo "uruchamia" nowe środowisko 64-bitowe za każdym razem, gdy uruchamiam aplikację 64-bitową z VS 2005 (powodując w ten sposób losowe losowanie)? – AnT

Odpowiedz

30

Windows Vista implementuje address space layout randomization, heap randomization, and stack randomization. Jest to mechanizm bezpieczeństwa, który próbuje zapobiec atakom przepełnienia bufora, które opierają się na wiedzy o miejscu, w którym każdy fragment kodu i danych znajduje się w pamięci.

Istnieje możliwość wyłączenia usługi ASLR przez ustawienie wartości rejestru MoveImages. Nie mogłem znaleźć sposobu na wyłączenie randomizacji sterty, ale niektóre firmy Microsoft zalecają adresy obliczeniowe w stosunku do _crtheap. Nawet jeśli sterty przemieszczają się, względny adres może pozostać stabilny.

+0

Dzięki za cytat. :) Spekulować, ale miło zobaczyć dowody. – BobbyShaftoe