เมื่อเราพูดถึงเรื่องการซุบซิบนินทา ผู้คนจะนึกถึงผู้ก่อการร้าย คนใคร่เด็ก สายลับ หรือที่ดีที่สุดคือพวกผู้นิยมอนาธิปไตยและนักวิทยาศาสตร์คนอื่นๆ และจริงๆแล้วใครอีกที่อาจต้องการ ซ่อน บางสิ่งบางอย่างจากดวงตาภายนอกเหรอ? สิ่งนี้จะเป็นประโยชน์ต่อบุคคลธรรมดาอย่างไร?
ปรากฎว่ามีอันหนึ่ง นั่นคือเหตุผลที่วันนี้เราจะบีบอัดข้อมูลโดยใช้วิธี Steganography และท้ายที่สุด ผู้อ่านจะสามารถใช้คลังภาพอันมีค่าของเขาในรูปแบบ JPEG เพื่อเพิ่มจำนวนกิกะไบต์ฟรีในระบบไฟล์ได้
อะไร
หากผู้อ่านจำได้ว่าการซุบซิบเป็นอัลกอริธึมแปลก ๆ ที่ทำให้สามารถซ่อนข้อมูลหนึ่งไว้ภายในอีกข้อมูลหนึ่งได้ ในภาษาที่ง่ายกว่า: รูปภาพ + ไฟล์ == รูปภาพเดียวกันโดยประมาณ แต่ไม่มาก (แทนที่จะเป็นรูปภาพอาจมีอะไรก็ได้ แต่โดยปกติแล้วทุกอย่างจะชัดเจนกว่าในนั้น) ไม่ควรมีวิธีที่ง่ายในการพิจารณาว่ามีอะไรอยู่ข้างในหรือไม่
แต่ถ้าใครแยกไม่ออกจะมีความแตกต่างไหม? จากมุมมองของผู้บริโภค ผู้ใช้ไม่สนใจเกี่ยวกับความแม่นยำทางคณิตศาสตร์ (สะท้อนโดยชุดบิตเฉพาะ) เฉพาะสิ่งที่เขารับรู้เท่านั้น
ตัวอย่างเช่น ลองดูภาพสุนัขน่ารักสามภาพ:
ระวัง JPEG!
แม้จะมีขนาดแตกต่างกันมาก แต่ก็มีเพียงไม่กี่คนที่เลือกรุ่นที่สาม ในทางกลับกัน ความแตกต่างระหว่างสองภาพแรกนั้นไม่ได้สังเกตเห็นได้ชัดเจนนัก และปริมาณข้อมูลในภาพถ่ายเหล่านั้น (จากมุมมองของฉัน) ก็อาจเท่ากันได้
หลักการนี้เก่าแล้วและถูกนำไปใช้อย่างแข็งขันโดยวิธีการบีบอัดข้อมูลที่สูญหายมานานหลายปี แต่การทำลายไม่ใช่การสร้าง เราสนใจในประเด็นที่ก้าวหน้ากว่า สามารถฝังข้อมูลขนาดเพิ่มเติมได้หรือไม่ N ลงในไฟล์เพื่อให้ขนาดเพิ่มขึ้น M < Nแต่ผู้ใช้ไม่สังเกตเห็นการเปลี่ยนแปลงใช่ไหม
แน่นอนคุณสามารถ. แต่มันก็คุ้มค่าที่จะทำการจองสองสามครั้งทันที:
- ประการแรก วิธีการต้องเป็นสากลและให้ผลลัพธ์ที่เป็นบวกกับข้อมูลอินพุตส่วนใหญ่ นั่นคือโดยเฉลี่ยแล้วสำหรับการป้อนข้อมูลแบบสุ่ม ปริมาณข้อมูลที่จัดเก็บควรลดลงตามจริง “โดยเฉลี่ย” หมายความว่าสิ่งที่ตรงกันข้ามอาจเกิดขึ้นได้ แต่ไม่ควรมีอำนาจเหนือกว่า
- ประการที่สอง ขนาดของคอนเทนเนอร์ที่บีบอัดก่อนการฝังข้อมูลจะต้องมีขนาดใหญ่กว่าการดัดแปลงที่บีบอัดในลักษณะเดียวกัน การฝังบิตจำนวนหนึ่งลงในอิมเมจ BMP โดยใช้วิธี LSB นั้นไม่ใช่การบีบอัดแบบ Steganographic เนื่องจากเมื่อผ่าน DEFLATE บางประเภท รูปภาพต้นฉบับจึงมีแนวโน้มว่าจะเล็กลงอย่างเห็นได้ชัด
- ประการที่สาม ต้องดำเนินการผลลัพธ์และเปรียบเทียบกับข้อมูลที่บีบอัดแล้วโดยวิธีดั้งเดิม วิธีนี้จะลบผลกระทบที่น่าจะเป็นของความแตกต่างในความซ้ำซ้อนและให้การบีบอัดที่มีประสิทธิภาพมากขึ้นในกรณีทั่วไป
ที่ไหน?
การใช้สุริยคติหมายความว่านอกเหนือจากข้อมูลที่บีบอัดแล้ว เรายังต้องมีคอนเทนเนอร์ที่จะฝังข้อมูลนั้นด้วย จำนวนข้อมูลที่ฝังสูงสุดส่วนใหญ่ขึ้นอยู่กับคุณสมบัติแต่ละรายการ แต่จะง่ายกว่ามากในการปรับขนาดตามจำนวน ดังนั้น รูปแบบคอนเทนเนอร์จะต้องเหมือนกันเพื่อให้ผู้ใช้มีรูปแบบเพียงพอที่จะได้รับประโยชน์จากกระบวนการ "บีบอัด"
ในบริบทนี้ ไฟล์กราฟิก เสียง และวิดีโอเป็นตัวเลือกที่ดี แต่เนื่องจากรูปแบบ ตัวแปลงสัญญาณ ฯลฯ ที่หลากหลาย ในทางปฏิบัติเราจึงมีตัวเลือกไม่มากนัก
เมื่อพิจารณาทั้งหมดนี้ ตัวเลือกของฉันจึงตกอยู่ที่ JPEG เกือบทุกคนมีมัน มันถูกใช้กันอย่างแพร่หลายเพื่อวัตถุประสงค์ส่วนตัวและทางธุรกิจ โดยเกือบจะเป็นรูปแบบจริงสำหรับรูปภาพส่วนใหญ่
มันขึ้นอยู่กับ?
ถัดไปคือไดอะแกรมและคำอธิบายที่ใกล้เคียงและทางเทคนิคโดยไม่มีคำอธิบายมากนัก ดังนั้นผู้ที่สนใจสามารถข้ามไปได้โดยเลื่อนไปที่ส่วน "เทคโนโลยีขั้นสูง"
คุณสมบัติทั่วไป
หากต้องการฝังข้อมูลไว้ที่ใดที่หนึ่ง คุณต้องระบุก่อนว่าอยู่ที่ไหน อาจมีรูปถ่ายที่แตกต่างกันจำนวนเท่าใดก็ได้ในระบบไฟล์ ซึ่งผู้ใช้อาจต้องการใช้เพียงไม่กี่รูปเท่านั้น เราจะเรียกชุดคอนเทนเนอร์ที่ต้องการว่าไลบรารี
มันถูกสร้างขึ้นในสองกรณี: ก่อนการบีบอัดและก่อนการบีบอัด ในกรณีแรก คุณสามารถใช้ชุดชื่อไฟล์ (หรือดีกว่านั้นคือนิพจน์ทั่วไปสำหรับชื่อเหล่านั้น) ของไฟล์ แต่ในกรณีที่สอง จำเป็นต้องมีสิ่งที่น่าเชื่อถือมากกว่า: ผู้ใช้สามารถคัดลอกและย้ายไฟล์เหล่านั้นภายในระบบไฟล์ จึงช่วยป้องกันไม่ให้มีการระบุอย่างถูกต้อง ดังนั้นจึงจำเป็นต้องจัดเก็บแฮช (md5 ก็เพียงพอแล้ว) หลังจากทำการแก้ไขทั้งหมดแล้ว
ในกรณีนี้ ไม่มีประโยชน์ในการดำเนินการค้นหาครั้งแรกโดยใช้นิพจน์ทั่วไปทั่วทั้งระบบไฟล์ เพียงระบุไดเร็กทอรีรากที่แน่นอนก็เพียงพอแล้ว ไฟล์เก็บถาวรพิเศษจะถูกบันทึกไว้ซึ่งจะมีแฮชเหล่านั้นพร้อมกับข้อมูลเมตาอื่น ๆ ที่จำเป็นสำหรับการกู้คืนข้อมูลที่ถูกบีบอัดในภายหลัง
ทั้งหมดนี้ใช้กับการใช้งานอัลกอริธึมการบีบอัดข้อมูลแบบ Steganographic อย่างเท่าเทียมกัน กระบวนการบีบอัดข้อมูลและการกู้คืนข้อมูลนั้นเรียกว่าการบรรจุและการแกะออก
F5
ตอนนี้เป็นที่ชัดเจนว่าเรากำลังทำอะไรอยู่และทำไม ยังคงต้องอธิบายอัลกอริทึมสำหรับการบรรลุเป้าหมาย จำกระบวนการเข้ารหัสไฟล์ JPEG กัน (ขอบคุณวิกิของหอสมุดแห่งชาติบาวแมน):
เมื่อพิจารณาดูแล้ว เป็นการดีกว่าที่จะแสดงความคิดเห็นทันที:
- ขนาดของไฟล์ JPEG ถือได้ว่าเหมาะสมที่สุดโดยไม่ต้องพยายามบีบอัดไฟล์ด้วย Winrar บางชนิดด้วยซ้ำ
- เฉพาะข้อมูลที่เก็บไว้ (ซึ่งส่งออกจากการแปลงโคไซน์แบบไม่ต่อเนื่องหรือ DCT) เท่านั้นที่สามารถแก้ไขได้เพื่อให้ได้ประสิทธิภาพที่ยอมรับได้เป็นอย่างน้อย
- เพื่อไม่ให้ข้อมูลสูญหายในระดับอุตสาหกรรมที่ผู้ใช้สังเกตเห็นได้ จำเป็นต้องทำการแก้ไขภาพแต่ละภาพขั้นต่ำ
อัลกอริธึมทั้งตระกูลสอดคล้องกับเงื่อนไขเหล่านี้ ซึ่งคุณสามารถทำความคุ้นเคยได้ . ขั้นสูงที่สุดคืออัลกอริธึม โดย Andreas Westfeld ทำงานร่วมกับค่าสัมประสิทธิ์ DCT ขององค์ประกอบความสว่าง (ดวงตาของมนุษย์มีความไวต่อการเปลี่ยนแปลงน้อยที่สุด) เค้าโครงทั่วไปเมื่อทำงานกับไฟล์ JPEG ที่มีอยู่จะแสดงดังนี้:
บล็อก F5 ใช้เทคนิคการฝังขั้นสูงตามการเข้ารหัสเมทริกซ์ ผู้อ่านสามารถเรียนรู้เพิ่มเติมเกี่ยวกับมันและอัลกอริทึมได้ที่ลิงค์ด้านบน แต่เราสนใจเป็นหลักในความจริงที่ว่าด้วยความช่วยเหลือนี้ คุณสามารถทำการเปลี่ยนแปลงน้อยลงเมื่อฝังข้อมูลในปริมาณเท่ากัน ยิ่งขนาดของคอนเทนเนอร์ที่ใช้มีขนาดใหญ่ขึ้น และสำหรับการดำเนินการ อัลกอริธึมจำเป็นต้องดำเนินการเข้ารหัส Huffman และ RLE (de) อย่างง่ายเท่านั้น
การเปลี่ยนแปลงเกิดขึ้นกับค่าสัมประสิทธิ์จำนวนเต็มและลดลงเหลือค่าสัมบูรณ์ลงหนึ่ง ซึ่งโดยทั่วไปแล้ว อนุญาตให้ใช้ F5 สำหรับการบีบอัดข้อมูล ประเด็นก็คือค่าสัมประสิทธิ์ที่ลดลงในค่าสัมบูรณ์มักจะใช้บิตน้อยลงหลังจากการเข้ารหัส Huffman เนื่องจากการกระจายค่าทางสถิติใน JPEG
ในกรณีของการก่อตัวของศูนย์ (ที่เรียกว่าการลดลง) จำนวนข้อมูลที่เก็บไว้จะลดลงตามขนาดของมัน เนื่องจากค่าสัมประสิทธิ์อิสระเดิมจะกลายเป็นส่วนหนึ่งของลำดับที่เข้ารหัส RLE ของศูนย์:
การปรับเปลี่ยน
การปกป้องและการบีบอัดข้อมูลเป็นปัญหามุมฉาก ดังนั้นการเปลี่ยนรหัสผ่านที่เป็นความลับจากอัลกอริธึมดั้งเดิมจึงสามารถละเลยได้ ยิ่งไปกว่านั้น เราจำเป็นต้องทราบวิธีการดึงข้อมูลอย่างชัดเจน ดังนั้นข้อมูลทั้งหมดที่จำเป็นสำหรับสิ่งนี้ (คอนเทนเนอร์ใดที่ใช้ ตามลำดับใด ฯลฯ) ควรบันทึกไว้ในไฟล์แยกต่างหาก และเปิดให้ผู้จัดเก็บอ่านได้ฟรี
อัลกอริธึมดั้งเดิมได้รับการออกแบบมาเพื่อส่งข้อความลับ ดังนั้นจึงใช้งานได้กับคอนเทนเนอร์เดียวเท่านั้นในแต่ละครั้ง โดยสมมติว่าผู้ใช้เองจะแยกมันออกเป็นส่วน ๆ หากจำเป็น (ถ้ามี) นอกจากนี้ เมื่อฝังแยกกันในแต่ละคอนเทนเนอร์ คุณจะต้องทราบล่วงหน้าว่าต้องใส่ข้อมูลจำนวนเท่าใดในแต่ละคอนเทนเนอร์ ดังนั้นค่าสัมประสิทธิ์ของแต่ละองค์ประกอบของไลบรารีควรนำมารวมกันเป็นนามธรรมขนาดใหญ่อันเดียวและทำงานร่วมกับมันตามอัลกอริทึมดั้งเดิม
เนื่องจาก F5 ดั้งเดิมอนุญาตให้มีขนาดคอนเทนเนอร์ได้มากถึง 12% การปรับเปลี่ยนนี้จะเพิ่มความจุสูงสุดด้วย: "สูงสุด 12%" ของขนาดของไลบรารีทั้งหมดมากกว่าหรือเท่ากับผลรวมของ "สูงสุด 12% "จากแต่ละองค์ประกอบ
โครงการทั่วไปที่ประมวลผลแล้วมีดังนี้:
อัลกอริธึมนั้นเอง
ตอนนี้ถึงเวลาอธิบายอัลกอริทึมตั้งแต่ต้นจนจบ เพื่อไม่ให้ผู้อ่านอยู่ในความมืด:
- ผู้ใช้กำหนดข้อมูลแบบบีบอัดไบนารี M และไลบรารี L โดยใช้นิพจน์ทั่วไปและไดเร็กทอรีรากการค้นหา
- ตามลำดับที่ปรากฏบน FS องค์ประกอบไลบรารีจะสร้าง MC:
- ชุดค่าสัมประสิทธิ์ C ถูกถอดรหัสจากข้อมูลไฟล์
- เอ็มซี <- เอ็มซี | ค;
- พารามิเตอร์ k ถูกกำหนดโดยอิงจากความไม่เท่าเทียมกันอย่างมาก:
|M| * 8 / (count_full(MC) + count_ones(MC) * k_rate(k)) < k / ((1 << k) - 1); - ถ่ายต่อไป
n = (1 << k) - 1บิตที่มีนัยสำคัญน้อยที่สุดขององค์ประกอบที่ไม่ใช่ศูนย์จาก MC และเขียนถึงa:- พิจารณาฟังก์ชันแฮชเวทย์มนตร์
fเป็นตัวแทนของคำ n บิตaถึง k-บิตs; - ถ้า
s == 0จากนั้นไม่จำเป็นต้องเปลี่ยนแปลงอะไรเลย และอัลกอริธึมจะย้ายไปยังค่าสัมประสิทธิ์ถัดไป - ลดค่าสัมประสิทธิ์สัมประสิทธิ์ที่รับผิดชอบ
s-เฮ้ กัดคำพูดa; - หากเป็นผลมาจากการลดลงการลดลงเกิดขึ้น (ค่าสัมประสิทธิ์กลายเป็น 0) ให้ทำซ้ำขั้นตอนตั้งแต่ต้น
- พิจารณาฟังก์ชันแฮชเวทย์มนตร์
- ค่าสัมประสิทธิ์ทั้งหมดถูกเข้ารหัสโดย RLE และ Huffman ซึ่งเขียนลงในไฟล์ต้นฉบับ
- พารามิเตอร์ k ถูกเขียนลงในไฟล์เก็บถาวร
- แฮช MD5 คำนวณจากแต่ละไฟล์ L ตามลำดับตำแหน่งดั้งเดิมและเขียนลงในไฟล์เก็บถาวร
เทคโนโลยีขั้นสูง
รูปแบบไร้เดียงสาของอัลกอริธึมและการนำไปใช้ในภาษาระดับสูงอื่น ๆ (โดยเฉพาะกับการรวบรวมขยะ) จะให้ประสิทธิภาพที่แย่มากดังนั้นฉันจึงใช้ความซับซ้อนเหล่านี้ทั้งหมดใน C ล้วนๆ และดำเนินการปรับแต่งหลายอย่างทั้งในแง่ของความเร็วในการดำเนินการและ หน่วยความจำ (คุณไม่รู้ว่ารูปภาพเหล่านี้มีน้ำหนักเท่าใดหากไม่มีการบีบอัดแม้กระทั่งก่อน DCT) แต่ถึงอย่างนั้น ในตอนแรกความเร็วของการดำเนินการยังเหลือความต้องการอีกมาก ดังนั้นฉันจะไม่อธิบายกระบวนการและวิธีการทั้งหมดที่ใช้
ข้ามแพลตฟอร์มได้โดยใช้การผสมผสานระหว่างไลบรารี libjpeg, pcre และ Tinydir ซึ่งเราขอขอบคุณพวกเขา โดยค่าเริ่มต้น ทุกอย่างจะถูกคอมไพล์ตามปกติ makeดังนั้นผู้ใช้ Windows จึงต้องการติดตั้ง Cygwin บางส่วนด้วยตนเอง หรือจัดการกับ Visual Studio และไลบรารี่ด้วยตนเอง
การใช้งานมีอยู่ในรูปแบบของยูทิลิตี้คอนโซลและไลบรารี ผู้ที่สนใจสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับการใช้อย่างหลังใน readme ในพื้นที่เก็บข้อมูลบน Github ซึ่งเป็นลิงก์ที่ฉันจะแนบท้ายโพสต์ และที่นี่เรามาดูคำอธิบายและการสาธิตงานกัน
วิธีการใช้งาน?
อย่างระมัดระวัง. รูปภาพที่ใช้สามารถย้าย เปลี่ยนชื่อ และคัดลอกได้ตามต้องการ อย่างไรก็ตาม คุณควรใช้ความระมัดระวังอย่างยิ่งและไม่เปลี่ยนแปลงเนื้อหาไม่ว่าในทางใด การเปลี่ยนบิตหนึ่งจะรบกวนแฮชและทำให้ไม่สามารถกู้คืนข้อมูลได้
สมมติว่าหลังจากการคอมไพล์เราได้รับไฟล์ปฏิบัติการ f5ar คุณสามารถวิเคราะห์ขนาดของไลบรารีเพื่อคำนวณความเป็นไปได้ในการใช้งานโดยใช้แฟล็ก -a: ./f5ar -a [папка поиска] [Perl-совместимое регулярное выражение]. ทีมงานจะแพ็คของให้ครับ ./f5ar -p [папка поиска] [Perl-совместимое регулярное выражение] [упаковываемый файл] [имя архива]และแกะกล่องโดยใช้ ./f5ar -u [файл архива] [имя восстановленного файла].
สาธิตการทำงาน
เพื่อแสดงประสิทธิภาพของวิธีการนี้ ฉันจึงอัปโหลดคอลเลกชันภาพถ่ายสุนัขฟรีจำนวน 225 ภาพจากบริการนี้ . แต่ละภาพมีคุณภาพที่สูงกว่าภาพถ่ายของผู้ใช้ทั่วไปเล็กน้อย แต่ยังคง แต่ละรายการได้รับการเข้ารหัสใหม่โดยใช้ libjpeg เพื่อลดผลกระทบของคุณสมบัติการเข้ารหัสของไลบรารีต่อขนาดโดยรวม เพื่อระบุตัวอย่างที่เลวร้ายที่สุดของข้อมูลที่บีบอัดได้ ไฟล์แบบสุ่มขนาด 36 เมตร (มากกว่า 5% ของขนาดทั้งหมดเล็กน้อย) ถูกสร้างขึ้นโดยใช้ dd
กระบวนการทดสอบค่อนข้างง่าย:
$ ls
binary_data dogs f5ar
$ du -sh dogs/
633M dogs/
$ du -h binary_data
36M binary_data
$ ./f5ar -p dogs/ .*jpg binary_data dogs.f5ar
Reading compressing file... ok
Initializing the archive... ok
Analysing library capacity... done in 16.8s
Detected somewhat guaranteed capacity of 48439359 bytes
Detected possible capacity of upto 102618787 bytes
Compressing... done in 32.6s
Saving the archive... ok
$ ./f5ar -u dogs/dogs.f5ar unpacked
Initializing the archive... ok
Reading the archive file... ok
Filling the archive with files... done in 1.2s
Decompressing... done in 17.5s
Writing extracted data... ok
$ sha1sum binary_data unpacked
ba7ade4bc77881ab463121e77bbd4d41ee181ae9 binary_data
ba7ade4bc77881ab463121e77bbd4d41ee181ae9 unpacked
$ du -sh dogs/
563M dogs/หรือแคปหน้าจอให้แฟนๆ
อย่างที่คุณเห็นจากข้อมูลเดิม 633 + 36 == 669 เมกะไบต์บนฮาร์ดไดรฟ์ เราได้ 563 ที่ดีกว่า ทำให้เรามีอัตราส่วนการบีบอัดที่ ~1,188 ความแตกต่างที่รุนแรงนี้อธิบายได้จากการสูญเสียเพียงเล็กน้อย คล้ายกับการสูญเสียที่ได้รับเมื่อปรับไฟล์ JPEG ให้เหมาะสมโดยใช้วิธีการดั้งเดิม (เช่น Tinyjpg) โดยปกติแล้วเมื่อใช้การบีบอัดข้อมูลแบบ Steganographic ข้อมูลจะไม่เพียงแค่ "สูญหาย" แต่ยังใช้ในการเข้ารหัสข้อมูลอื่น ๆ ยิ่งกว่านั้น จำนวนสัมประสิทธิ์ "ปรับให้เหมาะสม" เนื่องจากการใช้ F5 นั้นน้อยกว่าการเพิ่มประสิทธิภาพแบบเดิมมาก
ไม่ว่าจะมีการปรับเปลี่ยนอะไรก็ตาม พวกมันมองไม่เห็นด้วยตาเปล่าอย่างแน่นอน ภายใต้สปอยเลอร์ด้านล่างผู้อ่านสามารถประเมินความแตกต่างทั้งด้วยตาและโดยการลบค่าของส่วนประกอบที่เปลี่ยนแปลงไปจากต้นฉบับ (ยิ่งสีปิดเสียงมากเท่าใดความแตกต่างก็จะน้อยลงเท่านั้น):
ลิงก์ไปยังรูปภาพที่ไม่เหมาะกับการจัดเก็บข้อความ
ต้นฉบับ -
แก้ไข -
ความแตกต่าง -
แทนการสรุป
ฉันหวังว่าฉันจะสามารถโน้มน้าวผู้อ่านได้ว่าวิธีการดังกล่าวเป็นไปได้และมีสิทธิที่จะมีชีวิต อย่างไรก็ตาม การซื้อฮาร์ดไดรฟ์หรือช่องทางเพิ่มเติม (สำหรับการส่งสัญญาณผ่านเครือข่าย) อาจดูเหมือนเป็นตัวเลือกที่ง่ายกว่าการพยายามประหยัดเงินด้วยวิธีนี้ ประการหนึ่ง นี่เป็นเรื่องจริง การพัฒนาอย่างกว้างขวางมักจะง่ายกว่าและเชื่อถือได้มากกว่า แต่ในทางกลับกันเราก็ไม่ควรลืมเรื่องความเข้มข้น ท้ายที่สุดไม่มีการรับประกันว่าพรุ่งนี้คุณจะสามารถมาที่ร้านและซื้อฮาร์ดไดรฟ์อีกพันเทราไบต์ให้ตัวเองได้ แต่คุณสามารถใช้อันที่คุณมีอยู่ที่บ้านได้ตลอดเวลา
->
ที่มา: www.habr.com