Cara mengirim SMS menggunakan netcat (melalui SMPP)

10 Agustus 2020 [Programming]

SMPP adalah protokol biner yang digunakan oleh perusahaan telepon untuk mengirim pesan teks, atau dikenal sebagai pesan SMS.

Ini bisa bekerja melalui TCP, jadi kita bisa menggunakan netcat di baris perintah untuk mengirim pesan.

Cara yang lebih baik untuk memahami protokol ini adalah dengan menggunakan dukungan protokol SMPP Wireshark tetapi untuk artikel ini, kami akan melakukannya dengan cara yang sulit.

Menyiapkan

[Note: the netcat I am using is Ncat 7.70 on Linux.]

Server yang menerima pesan disebut SMSC. Anda mungkin memilikinya sendiri, tetapi jika tidak, Anda dapat menggunakan CloudHopper seperti ini:

sudo apt install make maven  # (or similar on non-Debian-derived distros)
git clone 
cd cloudhopper-smpp

Jika Anda sedikit lambat, seperti saya, saya sarankan untuk menunggu lebih lama untuk permintaan pengikatan sebelum menyerah pada Anda. Untuk melakukannya, edit metode main() dari src/test/java/com/cloudhopper/smpp/demo/ServerMain.java untuk menambahkan baris seperti ini: konfigurasi.setBindTimeout(500000); di sekitar jalur 80, dekat jalur serupa lainnya. Ini akan membuat Anda menunggu 500 detik untuk mengirim BIND_TRANSCEIVER, bukannya menyerah setelah hanya 5 detik.

Setelah Anda melakukan perubahan itu, Anda dapat menjalankan:

make server

Sekarang Anda telah menjalankan SMSC!

Biarkan terbuka, dan masuk ke terminal lain, dan ketik:

mkfifo tmpfifo
nc 0.0.0.0 2776 < tmpfifo | xxd

Bagian mkfifp membuat “fifo” – pipa bernama yang akan digunakan untuk mengirimkan perintah SMPP.

Bagian nc memulai Ncat, menghubungkan ke SMSC yang kami mulai.

Bagian xxd akan mengambil data biner apa pun yang keluar dari Ncat dan menampilkannya dengan cara yang lebih mudah dibaca manusia.

Biarkan terbuka juga, dan di terminal ketiga ketik:

exec 3> tmpfifo

Ini membuat semua yang kami kirim ke deskriptor file 3 masuk ke fifo, dan karenanya ke Ncat.

Sekarang kami memiliki cara untuk mengirimkan data biner ke Ncat, yang akan mengirimkannya ke SMSC dan mencetak tanggapan apa pun.

Catatan: kami akan menggunakan SMPP versi 3.4 karena paling banyak digunakan, meskipun bukan yang terbaru.

Terminologi

“SMPP” adalah protokol yang kami gunakan, yang kami gunakan melalui TCP/IP.

SMSC adalah server (yang menerima pesan yang ditujukan untuk telepon dan mengirimkan kembali tanggapan dan tanda terima).

Kami akan bertindak sebagai ESME atau klien (yang mengirimkan pesan yang ditujukan ke telepon dan menerima tanggapan dan tanda terima).

Unit informasi yang diteruskan bolak-balik di SMPP disebut “PDU” (Protocol Data Units) – ini hanyalah bit data biner yang mengalir melalui koneksi TCP antara dua komputer.

Spesifikasi berbicara tentang “oktet” – ini berarti byte 8-bit.

ENQUIRE_LINK

Pertama, kita akan memeriksa apakah SMSC merespons, dengan mengirimkan ENQUIRE_LINK, yang digunakan untuk menanyakan SMSC apakah ada dan berfungsi.

Kembali ke terminal ketiga (tempat kita menjalankan exec) dan ketik ini:

LEN16='\x00\x00\x00\x10'
ENQUIRE_LINK='\x00\x00\x00\x15'
NULL='\x00\x00\x00\x00'
SEQ1='\x00\x00\x00\x01'

echo -n -e "${LEN16}${ENQUIRE_LINK}${NULL}${SEQ1}" >&3

Penjelasan: PDU ENQUIRE_LINK terdiri dari:

• 4 byte untuk menyatakan panjang seluruh PDU dalam byte. ENQUIRE_LINK PDU selalu berukuran 16 byte, “00000010” dalam hex. Saya menyebutnya LEN16.
• 4 byte untuk menyatakan jenis PDU apa ini. ENQUIRE_LINK adalah “00000015” dalam heksa. Saya menyebutnya ENQUIRE_LINK.
• 4 byte yang selalu nol di ENQUIRE_LINK. Saya menyebut ini NULL.
• 4 byte yang mengidentifikasi permintaan ini, disebut nomor urut. Respons dari server akan menyertakan ini sehingga kami dapat mencocokkan respons terhadap permintaan. Saya menyebutnya SEQ1.

Periksa kembali di terminal kedua (tempat Anda menjalankan nc). Jika semuanya berfungsi, Anda akan melihat sesuatu seperti ini:

00000000: 0000 0010 8000 0015 0000 0000 0000 0001  ................

Mengabaikan bagian pertama dan terakhir (yang merupakan cara xxd memformat outputnya), respon yang kami terima adalah empat bagian 4-byte, sangat mirip dengan apa yang kami kirimkan:

• 4 byte untuk menyatakan panjang seluruh PDU dalam byte. Ini dia “00000010” hex, atau 16 desimal.
• 4 byte untuk menyatakan jenis PDU apa ini. Ini dia “80000015” dalam hex, yang merupakan kode untuk ENQUIRE_LINK_RESP.
• 4 byte untuk status keberhasilan ENQUIRE_LINK_RESP. Ini selalu “00000000”, yang berarti sukses dan disebut ESME_ROK dalam spesifikasinya.
• 4 byte yang sesuai dengan nomor urut yang kami kirimkan. Ini adalah “00000001”, seperti yang kami harapkan.

BIND_TRANSCEIVER

Sekarang kita dapat melihat bahwa SMSC berfungsi, mari kita “mengikat” ke dalamnya. Artinya seperti login: kita meyakinkan SMSC bahwa kita adalah klien yang sah, dan memberitahukannya jenis koneksi apa yang kita inginkan, dan, dengan asumsi SMSC setuju, SMSC akan menjaga koneksi tetap terbuka untuk kita selama yang kita perlukan.

Kita akan mengikatnya sebagai transceiver, yang berarti pemancar dan penerima, sehingga kita bisa mengirim pesan dan menerima tanggapan.

Kirim permintaan pengikatan seperti ini:

LEN32='\x00\x00\x00\x20'
BIND_TRANSCEIVER='\x00\x00\x00\x09'
NULL='\x00\x00\x00\x00'
SEQ2='\x00\x00\x00\x02'
SYSTEM_ID="sys\x00"
PASSWORD="pas\x00"
SYSTEM_TYPE='typ\x00'
INTERFACE_VERSION='\x34'
ADDR_TON='\x00'
ADDR_NPI='\x00'
ADDRESS_RANGE='\x00'

echo -n -e "${LEN32}${BIND_TRANSCEIVER}${NULL}${SEQ2}${SYSTEM_ID}${PASSWORD}${SYSTEM_TYPE}${INTERFACE_VERSION}${ADDR_TON}${ADDR_NPI}${ADDRESS_RANGE}" >&3

Penjelasan: PDU ini panjangnya 32 byte, jadi yang pertama kita kirimkan adalah hex “00000020”, yaitu 32.

Kemudian kita kirim “00000009” untuk tipe: BIND_TRANSCEIVER, 4 byte nol, dan nomor urut – kali ini saya menggunakan 2.

Itu adalah headernya. Sekarang badan PDU dimulai dengan id sistem (pada dasarnya nama pengguna), kata sandi, dan tipe sistem (info tambahan tentang siapa Anda). Ini semua adalah string yang diakhiri dengan null dengan panjang variabel, jadi saya mengakhiri masing-masing string dengan \x00.

Bagian selanjutnya adalah beberapa opsi tentang jenis nomor telepon asal dan tujuan pengiriman kami – Saya membuat semuanya “00” hex, yang artinya “kami tidak tahu”.

Jika berhasil, Anda akan melihat ini di keluaran nc:

00000000: 0000 0021 8000 0009 0000 0000 0000 0002  ...!............
00000010: 636c 6f75 6468 6f70 7065 7200 0210 0001  cloudhopper.....

Seperti sebelumnya, 4 byte pertama untuk berapa panjang PDU – 33 byte – dan 4 byte berikutnya untuk jenis PDU apa ini – “80000009” untuk BIND_TRANSCEIVER_RESP yang merupakan respons terhadap BIND_TRANSCEIVER.

4 byte berikutnya adalah untuk status – ini adalah angka nol yang menunjukkan keberhasilan (ESME_ROK) lagi. Setelah itu nomor urut kita (2).

15 byte berikutnya adalah karakter dari kata “cloudhopper” diikuti dengan nol – ini adalah id sistem SMSC.

Byte berikutnya (“01”) – yang terakhir kita lihat – adalah awal dari “TLV”, atau bagian opsional dari respons. Program xxd sebenarnya menunda byte terakhir dari keluaran, jadi kita belum bisa melihatnya, tapi itu adalah “34”. Bersama-sama, “0134” berarti “versi antarmuka yang kami dukung adalah SMPP 3.4”.

KIRIM_SM

Alasan mengapa kami di sini adalah untuk mengirim pesan. Untuk melakukan itu, kami menggunakan SUBMIT_SM:

LEN61='\x00\x00\x00\x3d'
SUBMIT_SM='\x00\x00\x00\x04'
SEQ3='\x00\x00\x00\x03'
SERVICE_TYPE='\x00'
SOURCE_ADDR_TON='\x00'
SOURCE_ADDR_NPI='\x00'
SOURCE_ADDR='447000123123\x00'
DEST_ADDR_TON='\x00'
DEST_ADDR_NPI='\x00'
DESTINATION_ADDR='447111222222\x00'
ESM_CLASS='\x00'
PROTOCOL_ID='\x01'
PRIORITY_FLAG='\x01'
SCHEDULE_DELIVERY_TIME='\x00'
VALIDITY_PERIOD='\x00'
REGISTERED_DELIVERY='\x01'
REPLACE_IF_PRESENT_FLAG='\x00'
DATA_CODING='\x03'
SM_DEFAULT_MSG_ID='\x00'
SM_LENGTH='\x04'
SHORT_MESSAGE='hihi'
echo -n -e "${LEN61}${SUBMIT_SM}${NULL}${SEQ3}${SERVICE_TYPE}${SOURCE_ADDR_TON}${SOURCE_ADDR_NPI}${SOURCE_ADDR}${DEST_ADDR_TON}${DEST_ADDR_NPI}${DESTINATION_ADDR}${ESM_CLASS}${PROTOCOL_ID}${PRIORITY_FLAG}${SCHEDULE_DELIVERY_TIME}${VALIDITY_PERIOD}${REGISTERED_DELIVERY}${REPLACE_IF_PRESENT_FLAG}${DATA_CODING}${SM_DEFAULT_MSG_ID}${SM_LENGTH}${SHORT_MESSAGE}" >&3

LEN61 adalah panjang PDU dalam byte, SUBMIT_SM adalah jenis PDU, dan SEQ3 adalah nomor urut, seperti sebelumnya.

SOURCE_ADDR adalah string karakter ASCII yang diakhiri dengan null (yaitu diakhiri dengan byte nol) yang menyatakan dari siapa pesan tersebut berasal. Ini bisa berupa nomor telepon, atau nama (tetapi peraturan tentang nama yang diperbolehkan rumit dan spesifik wilayah). SOURCE_ADDR_TON dan SOURCE_ADDR_NPI memberikan informasi tentang jenis alamat yang kami sediakan – kami menyetelnya ke nol yang berarti “kami tidak tahu”.

DESTINATION_ADDR, DEST_ADDR_TON dan DEST_ADDR_NPI menjelaskan nomor telepon tujuan pengiriman kami.

ESM_CLASS memberi tahu SMSC cara menangani pesan Anda – kami menggunakan mode “simpan dan teruskan”, yang berarti menyimpannya dan mengirimkannya bila Anda bisa.

PROTOCOL_ID berbeda tergantung jenis SMSC yang Anda gunakan. Kami mengasumsikan GSM di sini, dan memberikan nilai yang berfungsi untuk GSM.

PRIORITY_FLAG berarti seberapa penting pesan tersebut – kami menggunakan “interaktif”.

SCHEDULE_DELIVERY_TIME adalah waktu pengiriman – kami katakan “segera”.

VALIDITY_PERIOD berarti berapa lama pesan ini akan bertahan sebelum kita berhenti mencoba mengirimkannya (misalnya jika ponsel pengguna mati). Kami menggunakan “default” sehingga SMSC akan melakukan sesuatu yang masuk akal.

REGISTERED_DELIVERY memberikan informasi apakah kita menginginkan tanda terima yang menyatakan pesan sudah sampai di telepon. Kami mengatakan “ya, tolong”.

REPLACE_IF_PRESENT_FLAG memberitahukan apa yang harus dilakukan jika duplikat pesan ini dikirim ke SMSC sebelum pesan ini dikirimkan – nilai yang kami gunakan berarti “jangan ganti”.

DATA_CODING menyatakan pengkodean karakter apa yang Anda gunakan untuk mengirim teks pesan – kami menggunakan “Latin 1”, yang berarti ISO-8859-1.

SM_DEFAULT_MSG_ID memungkinkan kami menggunakan salah satu dari segelintir pesan standar yang dikodekan secara keras – kami mengatakan “tidak, gunakan pesan khusus”.

SM_LENGTH adalah panjang “pesan singkat” dalam byte – teks sebenarnya yang akan dilihat pengguna di layar ponsel.

SHORT_MESSAGE adalah pesan singkat itu sendiri – pesan kita semuanya berupa karakter ASCII, namun kita dapat menggunakan byte apa pun dan byte tersebut akan ditafsirkan sebagai karakter dalam pengkodean ISO-8859-1.

Anda akan melihat respons di terminal lain seperti ini:

00000020: 3400 0000 1180 0000 0400 0000 0000 0000  4...............

Awal “34” adalah byte sisa dari pesan sebelumnya seperti yang disebutkan di atas. Setelah itu, kami memiliki:

“00000011” untuk panjang PDU ini (17 byte).

“80000004” untuk tipe – SUBMIT_SM_RESP yang memberitahu kita apakah pesan telah diterima (tetapi tidak apakah pesan telah diterima).

“00000000” untuk status – nol berarti “OK”.

Dua byte terakhir dipotong lagi, tetapi yang sebenarnya kami dapatkan kembali adalah:

“00000003”, yang merupakan nomor urut, dan kemudian:

“00” yang merupakan ID pesan ASCII yang diakhiri dengan null: dalam hal ini SMSC mengatakan bahwa ID yang diberikan pesan ini adalah “”, yang mungkin tidak terlalu membantu! Jika ID ini tidak kosong, akan membantu kita nantinya jika kita menerima resi pengiriman, atau jika kita ingin bertanya tentang pesan tersebut, atau mengubah atau membatalkannya.

PENGIRIMAN_SM

Jika Anda menghentikan proses SMSC (yang kita mulai dengan make server) dengan menekan Ctrl-C, dan memulai proses lain dengan make server-echo, lalu ulangi perintah lainnya (perhatikan bahwa Anda harus cepat karena Anda hanya punya waktu 5 detik untuk mengikat sebelum menyerah pada Anda – buat perubahan serupa seperti yang kami lakukan di ServerMain ke ServerEchoMain jika ini menyebabkan masalah), Anda akan menerima tanda terima pengiriman dari server, yang terlihat seperti ini:

“0000003d” untuk panjang PDU ini (59 byte).

“00000005” untuk jenis (DELIVER_SM).

“00000000” untuk status perintah yang tidak digunakan.

“00000001” sebagai nomor urut. Catatan, ini tidak berhubungan dengan nomor urut pesan asli: untuk mencocokkan dengan pesan asli, kita harus menggunakan ID pesan yang disediakan di SUBMIT_SM_RESP.

“0000003400” artinya kita menggunakan SMPP 3.4. (Ini adalah string byte yang diakhiri dengan null.)

“00” dan “00” untuk TON dan NPI alamat sumber, diikuti dengan alamat sumber itu sendiri, yang merupakan string ASCII yang diakhiri dengan null: “34343731313132323232323200”. Ini diterjemahkan menjadi “447111222222”, yang merupakan alamat tujuan pesan asli kami. Catatan: beberapa SMSC mengganti alamat sumber dan tujuan seperti ini di resi pengirimannya, dan ada pula yang tidak, sehingga membuat hidup menjadi menarik.

“00” dan “00” untuk TON dan NPI alamat tujuan, diikuti dengan “34343730303031323331323300” untuk alamat itu sendiri, yang diterjemahkan menjadi “447000123123”, seperti yang diharapkan.

PDU DELIVER_SM melanjutkan dengan banyak informasi yang diulang dari pesan asli, dan SMSC diperbolehkan untuk memberikan pesan singkat sebagai bagian dari tanda terima – dalam contoh kita, SMSC cloudhopper mengulangi pesan asli. Beberapa SMSC menggunakan pesan singkat untuk memberikan informasi seperti ID pesan dan waktu pengiriman, namun tidak ada standar formal tentang cara memberikannya. SMSC lain menggunakan TLV untuk memberikan ID pesan.

Di suatu tempat di DELIVER_SM Anda akan menemukan indikasi apakah pesan benar-benar terkirim ke telepon. Seringkali berada dalam TLV yang disebut “status pesan”, tetapi bisa juga di badan pesan. Anehnya, keadaan “4” adalah kode normal untuk “berhasil terkirim”.

Untuk menyelesaikan percakapan, Anda harus memberikan DELIVER_SM_RESP, dan kemudian UNBIND, tapi mudah-mudahan berdasarkan apa yang telah kami lakukan dan standar SMPP 3.4, Anda seharusnya bisa mengetahuinya.

Anda berhasil

SMPP adalah protokol biner yang berlapis langsung di atas TCP, yang membuatnya sedikit lebih sulit untuk dikerjakan secara manual dibandingkan dengan protokol HTTP yang banyak dari kita lebih familiar, tapi saya harap saya dapat meyakinkan Anda bahwa Anda dapat memahami apa yang terjadi tanpa menggunakan semacam alat atau pustaka debugging kelas berat.

Selamat mengirim pesan!