Windows er en kombinasjon mellom et helt eget kapittel i denne saken, og ikke så veldig ulikt alikevel - når man først kommer ned i materien.
Utfordringen med Windows er den store mangelen på dokumentasjon fra Microsoft når det kommer til Native API i sine operativsystemer. Ikke bland dette med Win32 API, som er det interfacet de fleste applikasjoner til Windows benytter.

Grunnen til den manglende dokumentasjonen er selvsagt veldig åpenbar. Microsoft vil stå fritt til å kunne gjøre endringer i sin Native API, og vil ikke at noen andre enn dem selv skal benytte denne når de kommuniserer med kernelen. Dokumenterer de denne sier de samtidig at de vil supportere den, ha bakoverkompabilitet osv, slik status er for Win32 API.
Et godt eksempel som underbygger dette, er forskjellene i Native API mellom Windows NT4, Windows 2000, Windows XP og Windows 2003 iforhold til Win32 API på de samme versjonene.

(kommer ikke til å ta for meg Vista her, fordi Vista er for nytt for meg)

Gary Nebbett (en av verdens få gjenværende old school hackere) har derimot gjort mye av jobben for oss her, og har gjennom sine mange programmer og bøker vist veien. Han er heldigvis dyktig til å både dokumentere, dele kode og oppdatere verden når endringene kommer, så trenger man info om dypere funksjoner i Windows - så er det bare å lese hans kode og dokumentasjon.

Men for å summere fort, så kan man si at pga denne mangelen på dokumentasjon av funksjonalitet fra Microsoft, den helt absurde mengden funksjoner Microsoft har implementert (langt over 1000!!) og det faktum at store grupper av denne funksjonaliteten er deler av dynamiske biblioteker brukt i "user mode" - så refererer vi til "windows systemkall" for alle funksjoner i alle dynamiske biblioteker som er tilgjengelige for "user mode" prosesser.

Den største forskjellen i implementasjonen på Linux og Windows er at på Linux (og alle andre UNIX implementasjoner) benytter vi en INTEGER for å identifisere hvilke systemkall vi kan kalle, men på Windows finnes ikke dette (ihvertfall ikke som vi har tilgang til). Så proxyen under vil gi funksjonalitet nok til å kalle de funksjoner som er i prosessen man har utnyttet sitt minneområde.

Og allerede nå er det sikkert noen av dere, med litt mer erfaring med Windows enn normalt dødelige, som tenker "men vent nå litt".
For jo - initielt kan man kun kalle de funksjoner som er del av den DLL som allerede er lastet av prosessen...men, det er jo to spesielle funksjoner som ligger der; LoadLibrary og GetProcAddress!

Plutselig har man full tilgang gitt...og veldig rart ikke flere trojanere bruker denne metoden, for det fungerer. Det fungerer utrolig bra faktisk!

Dette blir da pseudokoden for en Windows Systemkallserver:



#1. #2. Adressene til LoadLibrary og GetProcAddress i serveren adresseområde blir sent tilbake til systemkall klienten du må lage, og klienten kan dermed bruke den generiske "kall alle mulige adresser" mekanismen implementert til å kalle disse funksjonene og laste hvilke som helst DLL'r fra din maskin inn i minnet til den hackede maskinen!
#3. Klienten sender den eksakte adressen til funksjonen den vil kalle i henvendelsen. Stacken er allerede forberedt på dette.

På denne måten kan altså en lignende server lages for Windows. Det å lage systemkall servere er altså ikke så veldig vanskelig, og makten du får er absurd - hvis du får inn disse som payload i et angrep. Men man har et par store utfordringer.
For det første må du ha mulighet til å kommunisere med målet, du må lage klienter som inneholder alle systemkall osv.

På Windows har man, som du kanskje begynner å forstå, den største utfordrigen. Basert på det ekstreme antallet systemkall man har må man lage en generisk klient som kan sende over alle mulige former for kall...være seg integers, pointers, structures, pointers til pointers til structures med pointers osv....

Så i starten vil jeg anbefale å benytte Metasploit sin Meterpreter.
Søk her for å finne info om denne:

Metasploit Payload List

Det finnes også en del grupper som jobber med utvikling rundt både klienter og servere i systemkall proxy settinger, og operativsystemer som QNX har det implementert som funksjonalitet i sine OS - så man har mange kilder og mye kode på nettet hvis man vil leke litt selv også.

Det er ihvertfall ingen tvil om at dette er en av de absolutt kraftigste payloadene man kan uploade gjennom et exploit, og klarer man å lage en stabil implementasjon har man så mye makt som er mulig å få over et operativsystem. Mer enn både root og administrator...

Lykke til!

Må innrømme at jeg ikke skrev artikkelen for at det skulle være lett å lage klipp og lim spøker med kompiser, fordi det å faktisk implementere denne formen for angrep - og da spesielt klientene, er ekstremt komplekst.
Skrev det derfor mest for å spre budskapet om at denne metoden er utrolig kraftig, at den er kanskje det ypperste innenfor angrepsmetodikk for de som behersker den - og for å forklare litt hva som faktisk er mulig.

Løsningen for deg er derfor å benytte Metasploit, hvis du ikke selv er en erfaren koder - og begynner å forstå metodene som ligger til grunn her. Da kan du selvsagt more deg

For disse metodene er absolutt i bruk...og en hacker som kan benytte denne metoden, kan bevege seg gjennom et system uten å etterlate spor andre steder enn et par logglinjer i brannmurer, ids systemer o.l. Sjelden så mye som en linje i en OS logg om hva vedkommende faktisk har gjort.

Forstår at denne metoden kanskje er litt vel drøy for å bare kødde med kompisene mine, men det kunne jo ha vært gøy å prøve å skrive en form for implimentasjon av dette. Selv om jeg merker assembly-skillsa mine er litt for fraværende til å i det hele tatt forstå mesteparten av "les henvendelse - prosessering - skriv resultat"-eksempelet du viser i del 1.

Synes bare det virket så mye enklere enn det det faktisk viste seg å være etter å ha lest del 1. Skal lese litt mer og se om ikke dette faktisk kan være mulig for meg, selv om jeg tror nok nå at dette er noen hundre meter over min league. Bra artikler uansett *KP*
(Skal lese litt på artiklene du linker til jeg tror jeg, og se om jeg kanskje forstår no av RPC.)