Ở phố tốn kém đủ đường, tôi muốn về quê để con có một tuổi thơ trọn vẹn, nhưng lại chẳng biết kiếm việc gì để làm và mưu sinh?
"Tôi đang thuê trọ ở phố huyện Đức Hòa, tỉnh Long An.
Thú thật, sống ở đây, việc học hành của con tôi không tốt bằng ở quê. Cơ
sở vật chất của trường không thật sự tốt, giáo viên cũng không có đủ,
nên hiện tại chủ nhiệm lớp con tôi đang là một thầy giáo 64 tuổi (dạy
hợp đồng).
Trong khi đó, con tôi đang học chương
trình giáo dục đổi mới nên việc dạy và học càng gặp rất nhiều vấn đề.
Trái ngược, ở quê tôi, cả xã mỗi khối chỉ có hai lớp, mỗi lớp chỉ có sĩ
số khoảng 30 học sinh, nên giáo viên cũng đỡ mệt mỏi, căng thẳng hơn.
Về
đi lại, nếu ở quê, con tôi có thể tự đi xe đạp đến trường mỗi ngày do
đường ít xe cộ. Như vậy, con tôi vừa có điều kiện để vận động, vừa tự
lập được chuyện giờ giấc thay vì phụ thuộc vào bố mẹ, tốt cho con sau
này.
Còn ở nơi phố huyện đang trọ hiện nay, tôi
không dám để con tự ý chạy xe ra đường lớn, bởi quá nhiều xe cộ, đặc
biệt là container, vô cùng nguy hiểm. Vậy là, không còn cách nào khác,
tôi phải thuê xe đưa rước con mỗi ngày và cho con tiền ăn trưa gần
trường (do trường chưa có bán trú) để không phải đi lại, tốn kém cũng
gần hai triệu đồng một tháng.
Nhưng để con về quê
học tập thì con tôi cũng không chịu. Mà về quê, bản thân tôi cũng thực
sự không biết làm gì để kiếm sống? Tôi năm nay cũng 40 tuổi rồi, nếu giờ
nghỉ việc trên này thì về quê không có việc, còn nếu muốn quay lại
huyện cũng rất khó xin việc vì không nơi nào muốn tuyển nhân viên lớn
tuổi.
Thú thật, tôi thấy rất thương con khi tuổi thơ bị nhiều thiệt thòi:
không có sân chơi, không biết tập văn nghệ thiếu nhi dịp trung thu vui
cỡ nào, không biết lễ khai giảng ra sao (trường chỉ cho mỗi lớp 10 bạn
đại diện dự khai giảng)... Nhưng nếu tôi cùng con về quê bây giờ thì
không biết xoay sở cuộc sống thế nào? Thế nên, tôi cứ tự động viên mình
rằng 'ráng đi làm vài năm nữa, để dư được chút ít tiền bạc rồi cả nhà về
quê'".
Thú thật, tôi thấy rất thương con khi tuổi thơ bị nhiều thiệt thòi:
không có sân chơi, không biết tập văn nghệ thiếu nhi dịp trung thu vui
cỡ nào, không biết lễ khai giảng ra sao (trường chỉ cho mỗi lớp 10 bạn
đại diện dự khai giảng)... Nhưng nếu tôi cùng con về quê bây giờ thì
không biết xoay sở cuộc sống thế nào? Thế nên, tôi cứ tự động viên mình
rằng 'ráng đi làm vài năm nữa, để dư được chút ít tiền bạc rồi cả nhà về
quê'".
Chào các bạn, S155 mỗi tuần có thể farm trong Quốc Chiến 2 lần 85000 quân tư thông bảo,
Có thể đổi ra được 170 Quân Ấn Chi Thụ.
Do có members đặt hàng một số lượng không nhỏ và nhờ ad thu mua nên ai trong S155 có dư QACT thì bán lại ad nhé.
Ad thu mua 5000 VNĐ = 1 QACT.
Nghĩa là mỗi tuần mọi người có thể farm trực tiếp được 170 * 5000 = 850.000 VNĐ, quá ngon phải không nào!
Chưa
kể QACT còn có thể farm bằng nhiều hình thức khác nữa, cơ hội kiếm tiền
đã đến nếu có hàng hãy liên lạc với ad qua các kênh liên lạc từ máy chủ
nhé!
Qua file sample được Độ Mixi chia sẻ, chúng ta đã
có thể biết được mã độc này đã vượt mặt các cơ chế bảo mật của antivirus
như thế nào.
Mới đây, vụ việc streamer Độ Mixi (Phùng Thanh Độ) bị hack
kênh YouTube đã thu hút được sự quan tâm lớn của cộng đồng công nghệ và
game thủ trong nước. Sau 2 ngày tạm ngừng stream, vào ngày 3/4, kênh
YouTube của Mixigaming đã được phục hồi trở lại nguyên trạng, và
streamer này đã "on air" vào tối cùng ngày.
Trong buổi
stream mới nhất, Độ Mixi đã chia sẻ cách thức mà hacker đã liên lạc và
đánh lừa streamer này chạy mã độc trên máy tính cá nhân. Chúng tôi đã
thu thập được file sample và đã tiến hành phân tích sơ bộ về cách thức
mã độc này vượt mặt các trình diệt virus, cũng như danh sách những mã
độc mà PC của streamer này đã nhiễm.
Trước khi đọc tiếp, chúng tôi khuyến khích bạn đọc tham khảo bài viết "Mật khẩu mạnh, bật bảo mật 2 lớp, tại sao những YouTuber "top đầu" như Độ Mixi vẫn bị hack?". Dù
được hoàn thành trước thời điểm Độ Mixi xác nhận về cách thức tấn công,
tuy nhiên bài viết này đã dự đoán chính xác kịch bản được hacker tạo
ra, bao gồm giả dạng email chào mời hợp tác, gửi mã độc dưới dạng một
file nén, cũng như cách thức để vượt mặt các phần mềm diệt virus.
File mã độc được gửi tới Độ Mixi được giả dạng là một tựa game mang tên "Black Myth Wukong"
(hiện tại tựa game này vẫn chưa chính thức ra mắt, vì vậy tất cả các
đường link tải về đều là giả mạo). "Tựa game" này được chia sẻ qua dịch
vụ lưu trữ trực tuyến Google Drive và Dropbox.
Độ Mixi chia sẻ đoạn email "chào mời hợp tác" nhằm đánh lừa streamer này khởi chạy mã độc
Đầu tiên, hãy cùng đến với file được hacker gửi tới Độ Mixi. File này có tên "Black Myth Wukong.rar", là dạng file nén của WinRAR với dung lượng 886.5MB. File này không yêu cầu mật khẩu để giải nén.
"Black Myth Wukong.rar" bao gồm 2 file nhỏ bên trong: "Black Myth Wukong Demo.rar" và "ReadMe.txt".
Trong đó, Black Myth Wukong Demo.rar đã bị mã hóa (đặt mật khẩu), và
Readme.txt chứa mật khẩu để giải mã. Mật khẩu của file RAR cũng được
chia sẻ với Độ Mixi thông qua email trao đổi công việc.
Nội dung của file Black Myth Wukong.rar
Sau khi giải nén, chúng ta sẽ có được một loạt các folder và file được bố cục như một bộ cài game thật. Tuy
nhiên đây chỉ cách mà hacker đánh lừa thị giác của người dùng, bởi
những folder và file này hoàn toàn không liên quan đến bất kỳ tựa game
nào hay thậm chí là mã độc. Chúng chỉ có tác dụng "làm cảnh" một cách
đúng nghĩa.
File "Black Myth Wukong 64-bit.exe" với dung lượng 692.1MB
Thay
vào đó, mọi sự chú ý được đổ dồn vào file "Black Myth Wukong
64-bit.exe". Đây là một file .exe, có dung lượng 692.1MB và hash md5
05eb129bc331d556a3330bdb262cb132.
Như đã phân tích ở
bài viết trước, việc file .exe này có dung lượng lớn đến như vậy là cách
để mã độc vượt mặt các phần mềm diệt virus. "Sở dĩ làm điều này
là bởi theo thiết lập mặc định, một số phần mềm diệt virus sẽ không quét
các tệp tin dung lượng quá lớn để tránh làm ảnh hưởng tới hiệu năng của
PC. Một số dịch vụ quét virus trực tuyến như VirusTotal cũng chỉ cho
phép tải lên tệp tin với kích thước tối đa là 650MB, vậy nên mức
700-750MB có thể được coi là "con số lý tưởng" đối với những dạng tấn
công này.", trích dẫn từ bài viết.
Cách thức mà hacker tăng kích thước file cũng đã được đề cập trong bài viết trước. Bên cạnh một phần rất nhỏ những đoạn mã độc, hacker đã chèn thêm một loạt những đoạn mã dư thừa ở đoạn cuối của file exe.
Bên cạnh những đoạn mã độc, hacker đã chèn hàng loạt những đoạn mã trống nhằm tăng dung lượng file
Chúng tôi đã tiến hành chỉnh sửa lại file .exe gốc, xóa các đoạn mã dư thừa. Hậu "làm thon gọn", Black Myth Wukong 64-bit.exe đã giảm dung lượng từ 692.1MB còn 6.9MB.
Sau khi chỉnh sửa, file exe giảm dung lượng từ 692.1 MB xuống chỉ còn 6.9MB
Đến
đây, chúng tôi có thể dễ dàng upload file này lên công cụ VirusTotal để
xác thực. Trong số 72 phần mềm quét virus trên VirusTotal, có 29 phần
mềm nhận dạng là mã độc. Tiếc rằng, phần mềm diệt virus Bkav, được quảng
cáo tích hợp hàng loạt công nghệ AI tiên tiến, lại không thể nhận diện
được mã độc này. Xem báo cáo của VirusTotal với mẫu file chúng tôi đã chỉnh sửa tại đây.
File "Black Myth Wukong 64-bit.exe" sau chỉnh sửa đã được tải lên VirusTotal và nhận dạng bởi 29/72 trình diệt virus
Thế nhưng, câu chuyện chưa dừng lại ở đó. Tiếp tục sử dụng công vụ VirusTotal Graph, chúng ta sẽ có một cái nhìn chi tiết hơn về cách mà mã độc này hoạt động.
Có
thể coi VirusTotal Graph là một dạng "bản đồ tư duy" (mindmap) nhưng
dành cho mã độc. Khi người dùng tải một file lên công cụ này, VirusTotal
sẽ phân tích xem file đó sẽ làm gì trên hệ thống máy tính, ví dụ như
tạo ra những file nhỏ nào, kết nối với máy chủ ở đâu... Trên VirusTotal
Graph, những đối tượng bị có vòng tròn đỏ xung quanh được đánh giá là mã
độc.
Và, phân tích cho thấy một kết cục không mấy khả quan cho streamer Độ Mixi.
Phân tích mã độc thông qua công cụ VirusTotal Graph
Đầu tiên về kết nối Internet, khi được khởi chạy, mã độc này sẽ tạo kết nối tới một số máy chủ tại Mỹ.
Trong đó, có một số máy chủ đã nằm trong danh sách đen của các dịch vụ
an ninh mạng. Đương nhiên, việc những dữ liệu nào của Độ Mixi được gửi
tới các máy chủ đó sẽ cần thời gian phân tích sâu hơn.
Mã độc kết nối với hàng loạt địa chỉ IP nguy hiểm
Điều
mà chúng tôi muốn nhấn mạnh hơn là về những file đã được sản sinh ra
trong quá trình mã độc này được kích hoạt. Như đã nói ở trên, cách thức
hiển thị của VirusTotal Graph là những đối tượng bị có vòng tròn đỏ xung quanh được đánh giá là mã độc. Vànếu nhìn theo hình ảnh dưới đây, có thể thấy rằng không có một mã độc nào cả.
Các file được tạo ra trong quá trình mã độc được khởi chạy
Bởi
thực tế, toàn bộ các file bên trong đều là những thư viện .dll "chuẩn
chỉ" và được xác thực. Tuy nhiên, chúng tôi đã nhận ra sự xuất hiện của
bz2, một thư viện Python với nhiệm vụ giải nén file (tương tự như WinRAR
trên Windows).
Thư viện bz2 với nhiệm vụ giải nén
Và song song với đó, là một file zip mang tên "base_library.zip" với dung lượng 1.27MB.
File zip mang tên "base_library.zip" với dung lượng 1.27MB
Giải nén file zip, và đây là những gì chúng ta có được. Thật không thể tin nổi!
Hàng loạt mã độc được "ẩn náu" bên trong file zip này
Một trong số vô vàn mã độc đã tấn công PC của Độ Mixi
Như
vậy, nếu chỉ đếm "sơ sơ" bằng tay, Độ Mixi đã nhiễm ít nhất 20 loại mã
độc khác nhau. Sau đây là liệt kê các file và loại mã độc được nhận dạng
bởi các phần mềm antivirus khác nhau:
Đến
đây, mặc dù có thể "bung" từng file để phân tích sâu hơn, nhưng có thể
nói rằng số lượng mã độc đã quá lớn so với khuôn khổ bài viết. Và, có lẽ
đến đây cũng đã là đủ để khẳng định rằng streamer Độ Mixi thật sự đã
gặp rắc rối lớn. Do mỗi một mã độc được lập trình với một mục đích khác
nhau, rất khó để có thể liệt kê đầy đủ rằng hacker đã khai thác được
những gì từ máy tính của streamer này.
Sau khi bị hack
kênh YouTube, Độ Mixi đã làm việc với đại diện của Google để lấy lại
kênh. Đây là một điều không mấy ngạc nhiên, do Độ Mixi không phải trường
hợp YouTuber lớn đầu tiên bị hack kênh để livestream tiền ảo. Google đã
quá "quen" với các tình huống này và đều đã chuẩn bị sẵn các phương án
dự phòng nhằm phục hồi kênh và tài khoản.
Tuy nhiên, cũng
trong buổi stream hôm qua, đích thân Độ Mixi đã xác nhận hệ thống
camera giám sát của anh cũng đã bị hack. Sau đó, cũng ngay trên stream,
Độ Mixi mất thêm quyền kiểm soát tài khoản Steam với lượng game và kho
đồ được ước tính có trị giá cả tỷ đồng. Liệu với những tình huống này,
Độ Mixi có được hỗ trợ "tận tình" như YouTube?
Tính đến
thời điểm bài viết, tài khoản Steam của Độ Mixi vẫn chưa được phục hồi.
Và với lượng mã độc lớn như trên, rất có thể sẽ có thêm nhiều dữ liệu
của streamer này bị khai thác trong tương lai.
GoJek - Một đơn vị đang hoạt động trên lĩnh vực digital logistic & transport
mà các anh chị em hẳn không còn thấy lạ lẫm, hoặc thậm chí cũng đã sử
dụng tới dịch vụ của họ. Hôm nay nhân dịp mình đọc được bài viết của Go
Jek mô tả về hệ thống push notification của họ ở đây: How We Manage a Million Push Notifications an Hour, mình cũng thấy khá là thú vị. Và trên phương diện người làm liên quan tới công nghệ, cộng với mò mẫm
tìm hiểu trên internet, thêm 1 chút lý thuyết (lý thuyết nhé) mà mình
có trong quá trình học cloud, aws/google services... mình muốn chia sẻ
thêm một chút về mặt giải pháp công nghệ, phương án giải quyết vấn đề
trên quan điểm thu lượm và góp nhặt được.
Về
lý thuyết mình đã có, thì thông thường 1 hệ thống push notification cũ
(dễ sẽ được viết bằng python + mysql) có thể gặp nhiều vấn đề về
performance như:
Latency lớn gây chậm các service yêu cầu.
Service quá tải vào các thời gian cao điểm dẫn tới mất push.
Failed rate liên quan tới network với firebase lớn do tần suất call dày đặc.
Quản lý token không hiệu quả, xuất hiện duplicate token và nhiều token inactive gây chậm quá trình push.
Thiết kế DB dạng normalized không phù hợp dẫn tới việc tất cả các request push đều cần join 3 table.
Sử dụng nhiều tài nguyên CPU và RAM
Ngoài
ra hệ thống cũ này chưa track được tỷ lệ thành công của mỗi lần push,
cũng như truy vết hành động push từ các service nội bộ khác. Đơn giản
với mỗi request nhận được, Push API sẽ gọi list token của user từ Token store và gửi yêu cầu push lên Firebase API
Trên lý thuyết, mình cần giải quyết các nút thắt bởi DB (database) và API. Về cơ bản, database sẽ lưu 2 loại dữ liệu chính:
Push token (FCM token) của user: Update ít, đọc theo list nhiều, nhiều data bên lề như thông tin thiết bị, thông tin hệ điều hành cần lưu cùng.
Push log chứa log và kết quả push: Insert + update rất nhiều, đọc ít.
Phần Push API
sẽ chủ yếu nghe traffic request push từ các service nội bộ. Để quá
trình này diễn ra nhanh chóng và không bắt các service khác phải chờ thì
flow như sau:
Nhận yêu cầu push từ service nội bộ
Tạo job với unique job-id
Push job vào Job Queue
Trả lại job-id cho service để trace về sau
Bằng việc đơn giản hóa phần việc của Push API và thiết kế lại DB mình sẽ giải quyết được 3 vấn đề: latency của API, các vấn đề liên quan tới quản lý token và performance của việc tìm token cho từng request.
Thiết kế job worker
Các bạn đọc bài viết của Go Jek mình đề cập ở trên thì sẽ thấy phần thiết kế job worker của họ khá sơ sài khi chỉ nhắc tới việc xử lý mỗi yêu cầu push bằng 1 job. Với cách implement truyền thống 1 job dạng:
Insert Push log vào DB
Filter token của user từ DB
Build push request dựa vào list token
Call Firebase API
Update kết quả push vào DB
thì
1 job push sẽ mất trung bình 300~400ms để xử lý. Hệ thống sẽ cần scale
số lượng worker lên tương đối lớn để đạt hiệu suất sử lý song song lớn.
Tuy nhiên trong hệ thống này các bạn sẽ thấy 2 điểm bottleneck ảnh hưởng tới performance của hệ thống như sau:
Insert log và update kết quả làm tăng load database
Call API tới bên thứ 3 (ở đây là Firebase API) có giới hạn và độ trễ lớn do network
Để giải quyết được 2 vấn đề này, kỹ thuật batch processing nội bộ trong từng instance Job worker sẽ là tối ưu. Tức là gộp chung 1 loạt những request giống nhau vào 1 lần call DB, API thông qua batch.
Cũng
đơn giản thôi, những bài toán xử lý dữ liệu lớn, có sự đồng bộ nhất
định giữa các bản ghi... thì sử dụng batch luôn sẽ được nghĩ tới đâu
tiên. Thế nhưng có mạnh thì sẽ có yếu thôi. Batch processing là một kỹ thuật khó và xử lý được nó đòi hỏi các bạn phải tính toán thật cẩn thận về các vấn đề liên quan tới error, retry, report.
Batch là đồng bộ nên thay vì khi phát sinh sự cố trên mỗi push riêng
lẻ, thì phương án này sẽ có sự ảnh hưởng hàng loạt tới vài trăm tiến
trình khác trong cùng batch... nếu như việc retry không được xử lý cẩn
thận.
Firebase API cũng hỗ trợ batch request
lên tới 500 message/call thì việc tận dụng batch đã giảm đi rất nhiều
thời gian chờ API call (do giảm số lượng request) cũng như tài nguyên
của database (do giảm số query đơn lẻ). Điều này có thể đáp ứng trên 1000 push/s, tức là 3,6 triệu push / giờ chỉ với 1 worker và tiêu thụ lượng tài nguyên rất khiêm tốn.
