Sesama programmer menggunakan praktik pemrograman terburuk


37

Saya tahu itu aneh untuk dikatakan, tetapi sesama programmer di tempat kerja sengaja menggunakan beberapa praktik pemrograman yang buruk dengan sengaja! Saya akan jelaskan. Pertama, izinkan saya mengatakan bahwa ia adalah orang yang cerdas dan sebagian besar ia menulis kode yang dapat dipahami.

Dia diminta untuk menerapkan lisensi pada proyek aplikasi web yang ditulis di Jawa. Karena itu adalah Java, jika seseorang benar-benar menginginkannya, seseorang mungkin bisa meretas guci terbuka dan membaca nama-nama kelas dan metode yang tertulis di dalamnya. Solusi untuk masalah ini adalah secara harfiah memanggil variabel dan metode dengan canggung nama yang kurang jelas dan menanamnya di dalam kelas yang sudah padat daripada menghasilkan kelas baru.

Pembenarannya adalah bahwa jika seorang hacker ingin mengganti kelas-kelas tertentu untuk mem-bypass perizinan lisensi (dan karenanya mendapatkan salinan produk secara gratis), ia akan memiliki waktu yang jauh lebih sulit jika tidak jelas metode mana yang melakukan tugas-tugas khusus ini. Hanya setelah dia melakukannya saya menghadapi dia tentang hal itu, menyarankan bahwa kita mungkin bisa membeli semacam perpustakaan obfuscator untuk melakukannya untuk kita, sambil mempertahankan praktik pemrograman yang baik. Dia mengaku tidak punya waktu atau sumber daya untuk mencari solusi semacam itu.

..Yang membuatku dilema. Apakah saya mencari perpustakaan obfuscator di Jawa dan memperbaiki kode lamanya (yang mungkin sedikit sensitif tentang mengubah kode), atau apakah saya membiarkannya, sebanyak yang mengganggu saya tanpa henti?


4
Jika pertanyaan Anda adalah tentang bagaimana menangani politik situasi ini, maka banyak jawaban di sini menunjuk ke arah yang benar, tetapi jika seperti komentar Anda, Anda benar-benar ingin alternatif yang lebih baik untuk diajukan, Anda mungkin ingin memeriksa keluar jawaban untuk pertanyaan ini: stackoverflow.com/questions/6018215/…
Mark Booth

8
Jika seorang peretas dengan akses ke kode sumber bersih Anda dapat meretas otentikasi Anda maka itu dapat diretas, titik. Tidak ada jumlah kebingungan yang akan membantu. Jika Anda mencari solusi yang menghentikan beberapa peretas, maka di atas kebingungan Anda mungkin juga ingin menggunakan beberapa praktik penyesatannya (menyembunyikan hal-hal di kelas yang tidak mungkin yang tidak dapat dengan mudah diganti). Pembaruan yang sering mengubah praktik otentikasi Anda juga membantu. Banyak pengguna bosan mengandalkan peretas dan hanya membelinya.
Bill K

2
Apakah dia mengganti nama penduduk setempat? Jika demikian, ia membuang-buang waktu - mereka tidak ada sebagai variabel bernama dalam kode yang dikompilasi.
Nick Johnson

1
Ini disebut "kebingungan" dan meskipun sedang lebih sering digunakan hari ini, itu tidak penuh-bukti! .. Meskipun akan menunda seseorang dari memecahkan kode, itu dapat dipecahkan! .. apa yang ingin saya lihat adalah kompiler yang dapat mengenkripsi kode objek dan hanya dapat dieksekusi dengan kunci yang benar, sehingga bahkan seseorang dengan disk editor, disassembler atau alat cracking lainnya tidak akan pernah dapat membuat kepala atau ekor keluar dari itu!
Frank R.

6
"Solusi untuk masalah ini adalah secara harfiah memanggil variabel dan metode dengan canggung nama-nama yang kurang jelas dan menanamnya di dalam kelas yang sudah padat daripada menghasilkan kelas baru." dan "Pertama, izinkan saya mengatakan bahwa dia adalah pria yang cerdas" tidak berjalan dengan baik dalam paragraf yang sama!
melahap elysium

Jawaban:


94

Keamanan melalui kebingungan tidak pernah merupakan keamanan yang baik. Pasti ada cara yang lebih baik untuk melindungi kekayaan intelektual Anda. Dan itu yang harus Anda dan kolega Anda sampaikan sebagai keprihatinan bersama dengan manajer Anda. Jika manajemen kemudian memutuskan bahwa mereka tidak ingin menghabiskan waktu atau uang untuk meningkatkan keamanan, maka Anda berdua harus hidup dengan keputusan itu (itu bukan produk Anda, itu adalah produk perusahaan) dan lebih baik tidak menghabiskan (limbah?) lagi waktu pada subjek.


31
Kebingungan +1 BUKAN keamanan, hanya selimut kenyamanan.
u

7
Jika Anda dapat menemukan solusi yang lebih baik daripada kebingungan, maka saya akan menandai jawaban Anda sebagai yang benar. Bagaimana Anda dapat menjamin bahwa seseorang yang memiliki akses ke file perang tidak dapat mengubah fungsinya untuk setidaknya apa yang menyangkut lisensi?
Neil

5
Anda tidak dapat menjamin sama sekali ketika seseorang memiliki akses ke file. Tetapi kenyataannya adalah: Mekanisme paling sederhana mencegah 99,99% pengguna melakukan kerusakan pada perangkat lunak Anda. Peretas yang berdedikasi dan terampil AKAN SELALU menemukan cara untuk memintas keamanan aplikasi. Namun, Anda dapat beralih ke verifikasi jarak jauh, sehingga program Anda hanya akan berjalan ketika dikonfirmasi terhadap layanan Anda. Agar itu aman, Anda harus mengenkripsi seluruh program Anda dan memiliki semacam bootloader. TETAPI: jika seseorang telah mendapatkan kunci yang valid, dia dapat merekayasa balik perangkat lunak itu lagi.
Falcon

7
@Neil: Menerapkan logika bisnis inti dalam mikrokontroler yang terpasang sebagai dongle USB. Anda tidak mengatakan itu harus murah atau mudah diimplementasikan;)
SF.

8
@ SF: Sentuh. Saya pikir itu harus memerlukan tiga satelit untuk terhubung secara bersamaan juga, hanya untuk itu. ;)
Neil

84

Asli: Apa kata bos Anda? Cari tahu - lakukan itu.


Saya diminta untuk menjelaskan hal-hal di atas:

Pertama-tama, saya pikir Anda memiliki lebih dari satu dilema:

  • Haruskah Anda "memperbaiki" kode orang lain?
  • Apakah implementasi (dari A) dari orang lain cukup buruk sehingga harus diganti dengan yang lain?
  • Akankah obfuscator (selanjutnya dari B) lebih baik untuk "lisensi embed dalam aplikasi kita"?

Pertama-tama, dilihat dari kasus bisnis masalah IS dipecahkan. A ada di tempat dan - kemungkinan besar - solusi "cukup baik" untuk masalah tersebut. Perusahaan Anda mungkin senang dengan itu pada dasarnya hanya cukup terlindungi sehingga upaya yang disengaja diperlukan untuk melanggarnya.

Ini berarti bahwa bahkan jika Anda tidak menyukainya (dan, percayalah, Anda akan melihat jauh lebih buruk melalui karier Anda ) itu melakukan apa yang dibutuhkan. Oleh karena itu, ketika masalah IS dipecahkan, Anda tidak harus "hanya melakukannya" tetapi lebih meyakinkan orang yang bertugas menugaskan pekerjaan Anda bahwa jangka panjangharga implementasi ini akan cukup tinggi untuk menjamin kemunduran dan memilih obfuscator saham. Ini akan memerlukan sedikit persiapan dari Anda, dan juga perhatikan bahwa obfuscator memiliki kelemahan juga yang perlu Anda ketahui (jawaban lain mencakup ini dengan baik). Misalnya jejak tumpukan tidak segera dapat digunakan, dll. Itu semua tergantung pada seberapa penting untuk menghindari pembajakan. Perhatikan bahwa yang paling sulit untuk dihancurkan adalah yang membutuhkan dongle perangkat keras untuk dijalankan dan kemungkinan besar lebih mahal daripada yang diinginkan pelanggan Anda.

Oleh karena itu, keputusan ini bukan milik Anda, karena perusahaan Anda perlu menggunakan sumber daya tambahan untuk pergi ke B. Oleh karena itu Anda perlu membawa kekhawatiran Anda kepada orang yang bertanggung jawab, menjelaskan hal ini dan masalah jangka panjang lainnya dengan cukup baik baginya untuk memahami mengapa Anda menganggapnya lebih rendah dari saran Anda. Kemudian biarkan dia mengambil keputusan, dan terlepas dari apa hasilnya, hormati dan lakukan sesuai dengan cara profesional. Perhatikan bahwa penulis asli kemungkinan besar akan harus mempertahankannya saat ia menulisnya dan jika ia pergi atau tidak mau lagi, maka Anda dapat mengemukakan masalah itu lagi.

Dengan kata lain: Apa yang dikatakan bos Anda? Cari tahu - lakukan itu.

Perhatikan juga, bahwa ini akan berbeda jika Anda telah mengangkat masalah sebelumnya sehingga uang yang terbuang untuk waktu yang dihabiskan menerapkan A lebih kecil. Dengan kata lain, kapan pilihan antara A dan B harus dibuat.

Akhirnya, saya ingin mengomentari pertanyaan Anda tentang "hanya memperbaiki kode orang lain". Ini bukan perbaikan kecil untuk kode yang ada (yang saya temukan baik dan dianjurkan, terutama dengan tes di tempat). Ini adalah kemunduran yang mengganggu dan implementasi ulang, dan bahkan dalam tim dengan kepemilikan kode bersama ini tidak akan menjadi hal yang dapat diterima untuk dilakukan - setidaknya bagi saya - tanpa persetujuan sebelumnya.

Semoga ini memperjelas sudut pandang saya.


8
Bos saya bukan programmer dan saya mungkin kesulitan menjelaskan mengapa kita harus menginvestasikan waktu dan uang untuk melakukan sesuatu yang pada akhirnya tidak akan mengubah perilaku program dengan cara apa pun.
Neil

15
@ Neil: ... jadi mungkin sekarang saatnya untuk memperkenalkan bos Anda dengan konsep "biaya pemeliharaan"?
SF.

21
Apakah ini akan menjadi respons default untuk setiap pertanyaan tentang rekan kerja atau lingkungan kerja? Saya tahu bahwa beberapa nub harus pergi dan memberitahu Anda untuk memposting ini sebagai jawaban, tetapi ayolah, itu bukan jawaban. Ini sebenarnya adalah pertanyaan semi-layak (meskipun canggung-worded) tentang masalah keamanan melalui ketidakjelasan; "jawaban" ini menghina.
Aaronaught

8
@Aaronaught. Jawaban ini memotong ke tulang ketika "implementasi A buruk, saya sarankan kita melakukan implementasi B" karena pekerjaan tambahan (menyamakan uang) perlu dilakukan. Jika itu adalah pilihan antara menerapkan A atau B jawabannya akan berbeda. Saya sarankan Anda membuka pertanyaan tentang meta jika Anda ingin jawaban yang lebih jelas.

22
"Apakah ini akan menjadi respons default untuk setiap pertanyaan tentang rekan kerja atau lingkungan kerja?" Kenapa tidak? Jika ini disebut sebagai pertanyaan teknis. Misalnya "Mana yang lebih baik, kode tangan (= praktik buruk) dikaburkan" maka itu adalah pertanyaan yang sama sekali berbeda, dan menjamin diskusi teknis. Semua "Haruskah saya memperbaiki ini di belakang rekan kerja saya?" pertanyaan akhirnya bermuara pada "Tidak, bawalah ke perhatian tim / kekuatan yang lebih tinggi"
Binary Worrier

13

Apakah saya mencari perpustakaan obfuscator di Jawa dan memperbaiki kode lamanya (yang mungkin sedikit sensitif tentang mengubah kode), atau apakah saya membiarkannya, sebanyak yang mengganggu saya tanpa henti?

Tidak , mundur di belakang seseorang dan mengubah kode yang menjadi tanggung jawabnya akan lebih buruk daripada menulis kode yang dipertanyakan.

Anda telah membawanya ke programmer, langkah Anda selanjutnya adalah menjaga hidung Anda keluar dari itu atau membawanya dengan manajemen dan kemudian menjaga hidung Anda keluar dari itu.


Lalu ketika saya memancing melalui kelas-kelas ini di masa depan, saya hanya akan memegang hidung saya kurasa.
Neil

3
Ketika Anda memiliki tanggung jawab langsung untuk kode itu kemudian mengubahnya sesuai dengan keinginan Anda baik-baik saja, tetapi jika ada tanggung jawab bersama Anda akan membutuhkan seseorang untuk menengahi. Sangat mudah untuk menyakiti hubungan kerja dan membuang waktu pada situasi seperti ini, lebih baik untuk tidak membuat masalah jika memungkinkan. Jika masalah perlu dibuat maka keluarkanlah dari jalan secepatnya.
DKnight

6

Apakah ada ulasan kode resmi dalam bentuk apa pun - atau adakah konfrontasi yang Anda lakukan dengan "tinjauan kode" tidak resmi? Saya akan mengatakan bahwa karena ini adalah subjek yang rumit dan penting seperti keamanan dan perizinan, Anda perlu meningkatkannya. Anda telah melakukan bagian pertama - menghadapi programmer. Namun, sekarang dia tidak mendengarkan, Anda bisa / harus mengambilnya. Jika tidak, Anda mungkin menjadi bagian dari masalah.

Saya akan mengatakan kepadanya bahwa Anda akan melakukannya - MUNGKIN ini berubah pikiran. Jika tidak, tulis email yang sangat tepat secara politis, akurat, dan singkat tentang situasinya kepada atasan Anda, dan CC sang programmer. Dalam surel, minta pertemuan antara Anda bertiga dan / atau pihak lain yang berpartisipasi.

Selalu temui hal-hal ini secara langsung - namun dengan cara politik dan damai.


Tentunya pendekatan yang terpuji. Saya memperhatikan modifikasi kode sendiri, memperbarui kode saya dari SVN. Meskipun ada kemungkinan, jika dia tidak setuju, meyakinkan bos saya untuk mengambil tindakan pencegahan keamanan ini kemungkinan tidak akan menghasilkan perubahan apa pun karena programmer bisa berpendapat bahwa itu sudah 'berfungsi.'
Neil

2

Jika Anda dapat menemukan obfuscator yang dapat mengaburkan tanda tangan kelas (nama metode dll.), Maka usulkan untuk membeli dan menggunakannya.

Sampai saat itu, Anda mungkin harus hidup dengannya. Saya akui melakukan sesuatu yang serupa dalam proyek Grails baru - cek lisensi sengaja tertanam dalam metode login yang sudah besar, sehingga akan sangat sulit untuk mengganti metode untuk memotong cek.


1
Saya tidak bisa memberi tahu Anda betapa hal itu mengganggu saya, meskipun Anda mungkin benar bahwa saya harus hidup dengannya.
Neil

2

Bisakah dia menunjukkan bahwa peretasan seperti itu layak, atau hanya skenario hipotetis yang dia khawatirkan? Bisakah dia memberikan demo langsung dari pekerjaan ini? Dia harus mencoba. Serius. Jika berhasil, itu harus disampaikan kepada manajemen, dan kemudian menyarankan mendapatkan obfuscator.

Jika obfuscator tidak cukup aman, apakah Anda sudah mencari cara lain untuk mengamankan JAR, mungkin sesuatu seperti mengenkripsi, atau mengkompilasinya ke kode asli?

RE: pengerjaan ulang kodenya: Apakah itu hanya masalah penggantian nama? Banyak IDE memiliki alat refactoring yang dapat melakukan ini dengan mudah.


Dia menganggapku sedikit paranoid, meskipun aku bisa melihat alasannya. Jika produk diretas, itu mungkin berarti pekerjaannya. Saya tidak akan mengatakan itu mungkin, tapi saya cukup tahu untuk mengetahui bagaimana Anda dapat mencari nama metode dan jika ada metode yang jelas yang disebut "isLicenseValid", akan menjadi masalah menulis kelas yang memiliki metode ini dan selalu mengembalikan benar ke 'hack' itu. Saya pikir program ini cukup rumit tanpa menyulitkannya lebih lanjut, meskipun ia tampaknya ingin memastikannya. Saya pikir saya bisa memperbaiki kodenya dengan mudah dengan mengganti nama saja, ya.
Neil

Hanya karena Anda memiliki metode yang disebut "isLicenseValid" tidak berarti itu dapat diretas dengan hanya menulis kelas dengan metode yang sama. Jika Anda menandai kelas Anda sebagai "disegel" (itulah sintaks C #), maka pihak ke-3 tidak bisa mengelak dari pemeriksaan keamanan Anda dengan menulis subkelas dan mengganti metode Anda. Bagaimanapun, kecuali orang ini adalah petugas keamanan perusahaan, mengapa itu berarti pekerjaannya jika produk diretas?
Tundey

2
@Tundey, ini bukan masalah subkelas (bagaimana mereka dimuat?): Ini masalah menulis kelas yang sama dan meletakkan versi yang diretas sebelumnya dalam daftar pencarian classpath.
Peter Taylor

1
ha. Saya ingat sukacita pemuatan kelas di Jawa. Masih harus ada cara yang lebih baik untuk mengurangi itu. Sebenarnya, jika pemuat kelas Anda tidak terganggu, bagaimana mungkin seseorang menulis kelas yang sama dengan kelas Anda? Apalagi jika JAR Anda ditandatangani? Tidak akan menandatangani JAR Anda dan menyegel kelas Anda memecahkan masalah seseorang menulis kelas dengan nama yang sama dengan Anda?
Tundey

1
@Tundey the Sun JVM adalah (kebanyakan) open source, Anda dapat memodifikasinya.
Spudd86

2

Terlepas dari betapa berharganya IP Anda, hal yang cerdas bukanlah membuat kode Anda dengan harapan akan membingungkan peretas. Terlepas dari kenyataan bahwa itu akan menjadi mimpi buruk untuk terus maju, itu tidak benar-benar menyelesaikan masalah. Itu hanya membuatnya lebih sulit tetapi bukan tidak mungkin. Jadi itu bukan solusi dan efek sampingnya buruk. Ini seperti minum obat yang tidak berhasil dan memiliki efek samping yang buruk.

Masalah Anda adalah bagaimana cara mengamankan IP Anda. Temukan solusi untuk itu: obfuscators, server lisensi, dll.


Saya setuju dengan Anda 110%. Untuk masalah pengamanan IP, itu adalah perlindungan bagi klien kami untuk membuat, karena itu adalah mesin mereka yang menjalankan aplikasi web, bukan milik kami, meskipun Anda membuat poin yang valid. Saya lebih peduli dengan klien yang memiliki akses langsung ke produk kami di mesin mereka dan dapat memisahkannya. Server lisensi hanya sebagus keamanan sisi klien. Jika Anda dapat mem-bypass mengakses server lisensi, tidak ada trik dalam buku ini yang akan mencegah Anda menggunakan program bebas lisensi.
Neil

1

Saya mengalami masalah yang sama ketika pengembang lain menamai proses enkripsi / dekripsi kami str__copydan str__delete(perhatikan garis bawah kedua). Itu timpang dan bisa dilakukan lebih baik, jadi kami menunggu sampai ada cerita di mana memperbarui lisensi diperlukan. Manajemen tidak memiliki masalah dengan beberapa jam ekstra karena kami menggambarkannya sebagai "bersihkan sehingga saat berikutnya kami masuk ke perizinan, itu akan memakan waktu lebih sedikit dan itu akan lebih aman". Masalah terpecahkan, tidak ada perasaan sakit hati.


Yah tentu saja kita selalu bisa mengubahnya nanti, meskipun saya pikir perubahan harus di kepala lebih dari kode.
Neil

1
@ Neil Lalu aku sarankan kamu yang butuh perubahan di kepala. Jika kodenya berfungsi, memiliki pengujian yang memadai, dan berkomentar dengan baik bahwa rute tersebut bukan menggunakan dan obfuscator bukanlah pilihan terbaik, tetapi bukan akhir dari dunia juga. Perbaiki nanti jika itu masalah dan lanjutkan sebaliknya.
Christopher Bibbs

@Christopher_Bibbs: Tenangkan pikiran Anda. Saya hampir pasti dapat meyakinkan Anda bahwa itu pada akhirnya akan menghadirkan masalah.
Neil

1

Pikiran pertama saya adalah pemeliharaan kode itu. Jika kode sudah dikaburkan dan dia pindah, semoga berhasil untuk menangani kode itu. Anda kemudian akan menjadi peretas yang mencoba menguraikan kode.

Sebaliknya saya akan merekomendasikan membersihkan kode dan menggunakan obfuscator melakukan semua kerja keras. Jangka panjang Anda akan memiliki banyak kode yang dapat dikelola dan Anda meninggalkan semua kerumitan gila kepada siapa pun yang ingin meretas lisensi Anda.

Ingatlah bahwa tidak ada obfuscater yang sempurna, dan peretas yang sangat gigih dapat merekayasa balik apa pun, tetapi setidaknya hanya dia. Ditambah obfuscaters menambah kompleksitas lebih dari satu orang mungkin bisa.


0

Saya sangat setuju dengan jawaban bahwa Anda harus bertanya kepada bos Anda tentang masalah ini dan melakukan apa yang dia katakan.

Namun tambahan yang sangat penting untuk jawaban ini adalah Anda harus mendokumentasikan kekhawatiran Anda tentang keamanan dan pemeliharaan. Apakah Anda mengubah kode atau tidak, penting bahwa orang tahu apa yang Anda khawatirkan dan mengapa. Ini penting baik secara proaktif (atasan Anda tidak dapat membuat keputusan yang bahkan ia tidak tahu harus dibuat) dan membela diri (jika / ketika seorang peretas membuat lubang pada sistem perizinan yang diamankan dengan buruk, mereka tidak dapat menyalahkan Anda karena kesalahan mereka). kesalahan.)


0

"Jangan menjadi profesional paling unggul untuk mengetahui masalah".

Dengan kata lain, beri tahu bos Anda dan pergi dari sana. Jika Anda tetap diam, dan Anda berada di puncak totum pada rahasia itu, ketika dorongan datang untuk mendorong Anda akan bertanggung jawab. Beri tahu atasan Anda secara sepintas dan biarkan dia memutuskan cara untuk mendekatinya. Dengan begitu Anda terbebas dari beban pilihan.

Jangan hanya memberi tahu atasan Anda, karena banyak manajer mungkin tidak teknis, tetapi lakukan apa yang selalu kami lakukan: berikan masalah dan kemungkinan solusi dengan kelebihan / kekurangan untuk masing-masing solusi tersebut. Kemudian biarkan mereka memutuskan dan membiarkannya berlalu. Itu sebabnya manajer / pemimpin dibayar banyak uang!


0

Kebenaran yang jelas adalah bahwa diberi cukup waktu dan sumber daya apa pun dapat dipecahkan. Ini adalah fungsi sederhana dari seberapa populer aplikasi Anda. Semakin populer, semakin menarik peretas yang terampil dan semakin banyak waktu yang dihabiskan untuk memecahkannya. Kebingungan kode menyediakan hanya itu - sarana untuk meningkatkan waktu yang diperlukan untuk memecahkannya, mirip dengan kriptografi. Jadi, jika kode Anda dikaburkan, itu membutuhkan penyerang untuk menjadi terampil dan mencurahkan waktu untuk itu jika tidak, ia akan putus asa dan menyerah. Anda harus bertanya pada diri sendiri apakah aplikasi Anda sepadan dengan masalah di kedua ujungnya.

Sungguh menakjubkan betapa sulitnya untuk memecahkan kode yang dikaburkan. Anda dapat dengan mudah mengubah program 10 garis C sederhana dalam perakitan 100 baris melalui kebingungan. Jika Anda mencoba men-debug-nya, Anda akan melompat-lompat tanpa makna dalam kode dan bisa sangat frustasi untuk melewatinya. Akhirnya akan pecah tetapi menjadi sangat sulit dan karena tidak ada yang benar-benar mustahil itulah intinya. Kebingungan kode mengurangi jumlah orang yang dapat memecahkannya.

Tentu ada cara yang lebih baik, seperti mencoba membingungkan debugger bukan cracker, tapi ini yang murah dan efisien. Namun penamaan hal-hal canggung tidak cukup memotongnya. Anda harus mengubah fungsi kontrol aliran panggilan yang tidak benar-benar melakukan apa pun untuk keseluruhan kode Anda tetapi menambah ukuran dan kompleksitasnya: memanggil fungsi dummy yang nilai baliknya tidak digunakan di mana pun, dari fungsi di dalam yang benar-benar melakukan sesuatu. Anda sudah bisa melihat bagaimana ini bisa sangat membingungkan.

Anda memiliki sesuatu yang tidak diserang si penyerang. Kode sumber asli. Temukan cara untuk mengaturnya dengan lebih baik untuk diri Anda sendiri.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.