- Đây là một framework phá hoại không được lập tài liệu, được tạo ra vào năm 2005, được thiết kế để vá mã trong bộ nhớ của phần mềm tính toán được chọn nhằm bóp méo kết quả số
svcmgmt.exe bề ngoài giống một service wrapper, nhưng bên trong chứa máy ảo Lua 5.0, bytecode mã hóa, DLL phụ trợ và driver fast16.sys, cho phép tách riêng và thực thi payload theo từng tác vụfast16.sys là driver hệ thống tệp khởi động cùng hệ thống, được nạp ở giai đoạn rất sớm, sau đó chọn các tệp .EXE được build bằng Intel C/C++ compiler để thực hiện vá bộ nhớ ở cấp kernel- Công cụ vá hoạt động theo 101 quy tắc, đặc biệt để lại dấu vết nhắm vào các công cụ tính toán chuyên biệt như kỹ thuật dân dụng, vật lý và mô phỏng quy trình bằng cách dùng các khối lệnh FPU để thay đổi tỉ lệ giá trị mảng nội bộ
- Khi kết hợp với dấu hiệu
fast16 từ vụ rò rỉ ShadowBrokers, có thể thấy rằng hoạt động phá hoại công nghiệp chính xác cao từ thời kỳ trước Stuxnet đã tồn tại dưới dạng kết hợp scripting nhúng, nhắm mục tiêu hẹp và vá kernel
Tổng quan và dấu hiệu nhận diện
fast16 là một framework phá hoại mạng không được lập tài liệu với thành phần lõi từ năm 2005; fast16.sys nhắm chọn lọc vào phần mềm tính toán độ chính xác cao, vá mã trong bộ nhớ và làm sai lệch kết quả tính toánsvcmgmt.exe bề ngoài trông như một service wrapper phổ biến thời Windows 2000/XP, nhưng bên trong chứa máy ảo Lua 5.0 và container bytecode mã hóa được giải nén bởi entry point của service- Trong quá trình truy tìm mã độc dựa trên Lua, các magic byte bytecode
1B 4C 75 61, byte phiên bản, LUA_PATH và API C đặc trưng đã trở thành manh mối, qua đó svcmgmt.exe được nhận diện
- Chuỗi
C:\buildy\driver\fd\i386\fast16.pdb bên trong svcmgmt.exe trở thành manh mối pháp chứng nối file thực thi dịch vụ với dự án driver kernel
- Trong
drv_list.txt của vụ rò rỉ ShadowBrokers năm 2017 cũng xuất hiện fast16 cùng tên, gắn chuỗi PDB của svcmgmt.exe với driver dùng cho phá hoại chính xác trong cùng một mạch liên hệ
- Chữ ký né tránh từ phía ShadowBrokers có chứa câu
fast16 *** Nothing to see here – carry on***
Cấu trúc carrier và cách thực thi
svcmgmt.exe được thiết kế như một carrier thích ứng, thay đổi hành vi theo tham số dòng lệnh
- Không có tham số: chạy như dịch vụ Windows
-p: đặt InstallFlag = 1 và chạy như dịch vụ-i: đặt InstallFlag = 1 và thực thi mã Lua-r: thực thi mã Lua mà không đặt cờ cài đặt- Ngoài ra
<filename>: hoạt động ở chế độ Wrapper/Proxy, tạo hai tiến trình con gồm lệnh gốc và lệnh gắn thêm tham số -r
- Kho lưu trữ nội bộ chứa đồng thời bytecode Lua mã hóa, DLL phụ trợ và driver
fast16.sys
- Môi trường Lua được mở rộng vượt trạng thái mặc định, cung cấp module
wstring, hàm mã hóa đối xứng tích hợp b, cùng các module binding tới API Windows NT về hệ thống tệp, registry, điều khiển dịch vụ và mạng
- Binary carrier bên ngoài được giữ tương đối ổn định, trong khi payload theo từng tác vụ được tách riêng dưới dạng mã hóa để có thể tái sử dụng theo môi trường và mục tiêu chiến dịch
- Các giá trị nhận diện của
svcmgmt.exe như sau
- Tên tệp
svcmgmt.exe
- Kích thước
315,392 bytes
- MD5
dbe51eabebf9d4ef9581ef99844a2944
- SHA1
de584703c78a60a56028f9834086facd1401b355
- SHA256
9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525
- Loại
PE32 executable for MS Windows 4.00 (console), Intel i386
- Thời gian liên kết
2005-08-30 18:15:06 UTC
Cấu trúc lây lan wormlet và né tránh
svcmgmt.exe hoạt động như một carrier kiểu đạn chùm có thể mang nhiều wormlet, nhưng trong mẫu đã xác nhận chỉ có một SCM wormlet- Luồng thực thi bao gồm chuẩn bị cấu hình, chuyển đổi chuỗi wide, leo thang đặc quyền, cài đặt và khởi động dịch vụ
SvcMgmt, triển khai có điều kiện fast16.sys, phát tán wormlet, trì hoãn ban đầu và lặp lại cho tới khi đạt ngưỡng lỗi hoặc gặp điều kiện kết thúc từ bên ngoài
- SCM wormlet nhắm vào môi trường Windows 2000/XP, tìm máy chủ trong mạng bằng các file share có mật khẩu quản trị yếu hoặc mặc định, sao chép payload rồi khởi động dịch vụ từ xa
- Việc lây lan không dựa vào giao thức mạng tùy biến mà dựa vào các chức năng quản trị chuẩn của Windows như service control API và file sharing API
- Trước khi cài đặt,
ok_to_install() gọi ok_to_propagate() để kiểm tra môi trường, và nếu không có ép buộc thủ công thì quyết định khả năng lây lan dựa trên sự hiện diện của khóa registry của một số sản phẩm bảo mật nhất định
- Nếu có bất kỳ khóa registry nào dưới đây thì quá trình cài đặt sẽ dừng lại để tránh triển khai vào môi trường giám sát
HKLM\SOFTWARE\Symantec\InstalledAppsHKLM\SOFTWARE\Sygate Technologies, Inc.\Sygate Personal FirewallHKLM\SOFTWARE\TrendMicro\PFWHKLM\SOFTWARE\Zone Labs\TrueVectorHKLM\SOFTWARE\F-SecureHKLM\SOFTWARE\Network Ice\BlackIceHKLM\SOFTWARE\McAfee.com\Personal FirewallHKLM\SOFTWARE\ComputerAssociates\eTrust EZ ArmorHKLM\SOFTWARE\RedCannon\FireballHKLM\SOFTWARE\Kerio\Personal Firewall 4HKLM\SOFTWARE\KasperskyLab\InstalledProducts\Kaspersky Anti-HackerHKLM\SOFTWARE\Tiny Software\Tiny FirewallHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Look n Stop 2.05p2HKCU\SOFTWARE\Soft4EverHKLM\SOFTWARE\Norman Data Defense SystemsHKLM\SOFTWARE\Agnitum\Outpost FirewallHKLM\SOFTWARE\Panda Software\FirewallHKLM\SOFTWARE\InfoTeCS\TermiNET
connotify.dll đảm nhiệm vai trò kênh báo cáo tối thiểu
- Được đăng ký bằng Windows
AddConnectNotify() API, nên sẽ được gọi mỗi khi xuất hiện kết nối mạng mới dựa trên RAS
- Giải mã chuỗi làm rối để lấy named pipe
\\.\pipe\p577, kết nối tới pipe cục bộ, ghi lại tên kết nối từ xa và cục bộ rồi thoát
- Không phải module thực thi độc lập và cần được tiến trình host đăng ký
- Tên tệp
svcmgmt.dll
- Kích thước
45056 bytes
- MD5
410eddfc19de44249897986ecc8ac449
- SHA1
675cb83cec5f25ebbe8d9f90dea3d836fcb1c234
- SHA256
8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9
- Thời gian liên kết
2005-06-06 18:42:45 UTC
- Loại
PE32 DLL (i386, 4 sections)
Cấu trúc driver và cách vá bộ nhớ
fast16.sys là thành phần mạnh nhất trong framework, được cấu hình là boot-start filesystem driver nên được nạp ở giai đoạn rất sớm cùng với driver đĩa- Cấu hình là
Start=0, Type=2, nhóm lớp SCSI, và tự chèn mình lên trên NTFS, FAT, MRxSMB
- Khi vào ban đầu, nó đặt giá trị
EnablePrefetcher dưới Session Manager\PrefetchParameters thành 0 để các yêu cầu trang mã sau đó phải đi qua toàn bộ stack filesystem
- Nó động phân giải kernel API bằng mã hóa chuỗi XOR đơn giản và quét
ntoskrnl.exe, đồng thời phơi bày \Device\fast16, \??\fast16 và DeviceType tùy chỉnh 0xA57C
- Bằng
IoRegisterFsRegistrationChange, nó gắn worker device object lên trên các thiết bị filesystem đang hoạt động và mới tạo, rồi chặn các đường IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_CLOSE, IRP_MJ_QUERY_INFORMATION, IRP_MJ_FILE_SYSTEM_CONTROL cùng các đường Fast I/O liên quan
- Dù được nạp từ thời điểm khởi động, engine tiêm mã cấp kernel thực tế chỉ được kích hoạt sau khi
explorer.exe được mở
- Mục tiêu để vá phải đồng thời thỏa mãn hai điều kiện
- Tên tệp kết thúc bằng
.EXE
- Ngay sau PE section header cuối cùng có chuỗi ASCII có thể in được bắt đầu bằng
Intel
- Điều kiện này nhắm tới các tệp thực thi được build bằng Intel C/C++ compiler, cho thấy kẻ tấn công biết toolchain của phần mềm mục tiêu
- Với các tệp phù hợp điều kiện, PE header trong bộ nhớ sẽ bị sửa đổi, chèn mới hai section
.xdata, .pdata, rồi lấp đầy byte của section mã gốc để giữ lại một bản sao mã sạch
- Các giá trị nhận diện của
fast16.sys như sau
- Tên tệp
fast16.sys
- Kích thước
44,580 bytes
- MD5
0ff6abe0252d4f37a196a1231fae5f26
- SHA1
92e9dcaf7249110047ef121b7586c81d4b8cb4e5
- SHA256
07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529
- Loại
PE32 executable for MS Windows 5.00 (native), Intel i386, 5 sections
- Thời gian liên kết
2005-07-19 15:15:41 UTC
Engine vá dựa trên quy tắc và đặc tính mục tiêu
- Engine vá là một scanner tối giản dựa trên trạng thái gồm 101 quy tắc, âm thầm thay đổi mã thực thi trong bộ nhớ bằng logic so khớp mẫu và thay thế khi tệp được đọc từ đĩa
- Để duy trì hiệu năng, nó dùng dispatch array 256 byte để lọc nhanh một số byte đầu, cho phép wildcard bên trong mẫu, và một số quy tắc thiết lập/kiểm tra state flag để thực hiện các chuỗi sửa đổi nhiều bước
- Phần lớn các mẫu vá tương ứng với các chuỗi lệnh phổ biến trong mã x86 dùng để chiếm quyền hoặc tác động tới luồng thực thi, nhưng có một mẫu gồm khối lệnh FPU lớn hơn nhiều
- Khối FPU này là mã chuyên dụng cho số học chính xác và scale giá trị trong mảng nội bộ, cho thấy bản chất khác với kiểu tiêm mã độc thông thường
- Nhóm nghiên cứu đã chuyển các quy tắc vá thành mẫu hex của YARA signature rồi áp dụng lên kho phần mềm cùng thời, và số tệp khớp từ hai mẫu trở lên là cực ít, dưới 10 tệp
- Các tệp trúng khớp có điểm chung là đều là công cụ tính toán chuyên biệt trong các lĩnh vực như kỹ thuật dân dụng, vật lý và mô phỏng quy trình vật lý
- Bản vá FPU scale các giá trị được truyền vào ba mảng nội bộ để tinh chỉnh phép tính, cho thấy mục tiêu không phải truy cập trái phép hay phát tán thông thường mà là can thiệp kết quả số liệu
- Do chưa xác định được đầy đủ cả binary mục tiêu lẫn workload, ý nghĩa của các mảng vẫn chưa thể chỉ ra hoàn toàn
- Nếu phép tính được kiểm chứng trên hệ thống riêng biệt thì kiểu phá hoại này có thể thất bại, nhưng nếu cùng một driver được triển khai lên nhiều hệ thống dùng chung mạng và môi trường bảo mật thì khả năng phát hiện sai khác qua đối chiếu độc lập cũng giảm đi
- Phần phụ lục có đính kèm nguyên văn một số mẫu được trích từ engine vá
48 89 84 24 9C 00 00 00 4B 0F 8F 79 FF FF FF 00D8 E1 D9 5D FC D9 04 0055 8B EC 83 EC 14 53 56 57 8B 3D ?? ?? ?? ?? 8B 0D 008D 1D ?? ?? ?? ?? 52 8D 05 ?? ?? ?? ?? 51 8D 15 ?? ?? ?? ?? 8D 0D ?? ?? ?? ?? 53 50 52 51 56 57 E8 ?? ?? ?? ?? 83 C4 38 EB 0E 83 EC 04 00B9 01 00 00 00 C1 E7 02 8B BF ?? ?? ?? ?? 8B D7 85 FF 8B 55 30 8B 45 30 D8 C9 8B 75 2C 00 9A 8B 00 00 00 1B 00 90 0F 94 C3 0B D8 33 D2 83 3D 00
Các ứng viên mục tiêu vá lỗi
- Đối tượng có kết quả khớp mẫu chồng lấp mạnh nhất là LS-DYNA 970, PKPM, và MOHID
- LS-DYNA 970 là phần mềm mô phỏng kỹ thuật dùng để phân tích hành vi của vật liệu và kết cấu trong các điều kiện cực hạn, xử lý các bài toán va chạm ô tô, nổ, xung kích, tạo hình kim loại và quy trình sản xuất, và được sử dụng trong ô tô, hàng không vũ trụ, nghiên cứu quốc phòng-quân sự, sản xuất và khoa học vật liệu
- Đã được phát triển từ năm 1976
- MD5
1d2f32c57ae2f2013f513d342925e972
- SHA1
2fa28ef1c6744bdc2021abd4048eefc777dccf22
- SHA256
5966513a12a5601b262c4ee4d3e32091feb05b666951d06431c30a8cece83010
- Kích thước tệp
5,225,591 bytes
- Thời gian liên kết
2003-10-24 16:34:57 UTC
- Loại tệp
PE32 executable for MS Windows 4.00 (console), Intel i386, 7 sections
- PKPM là bộ sản phẩm CAD kỹ thuật kết cấu được sử dụng rộng rãi ở Trung Quốc, gồm nhiều mô-đun thực thi bao phủ toàn bộ vòng đời thiết kế kết cấu công trình
- SATWE là động cơ lõi phụ trách phân tích kết cấu 3 chiều cho sàn, dầm, cột, tường và toàn bộ khung
- Giá trị nhận diện mô-đun thiết kế cắt bê tông
- MD5
af4461a149bfd2ba566f2abefe7dcde4
- SHA1
586edef41c3b3fba87bf0f0346c7e402f86fc11e
- SHA256
09ca719e06a526f70aadf34fb66b136ed20f923776e6b33a33a9059ef674da22
- Kích thước tệp
7716864 bytes
- Loại tệp
PE32 executable for MS Windows 4.00 (GUI), Intel i386, 6 sections
- Thời gian liên kết
2011-08-26 10:58:17 UTC
- Giá trị nhận diện mô-đun Building Structure CAD
- MD5
49a8934ccd34e2aaae6ea1e6a6313ffe
- SHA1
3ce5b358c2ddd116ac9582efbb38354809999cb5
- SHA256
8b018452fdd64c346af4d97da420681e2e0b55b8c9ce2b8de75e330993b759a0
- Kích thước
11849728 bytes
- Thời gian liên kết
2005-12-01 08:35:46 UTC
- MD5
e0c10106626711f287ff91c0d6314407
- SHA1
650fc6b3e4f62ecdc1ec5728f36bb46ba0f74d05
- SHA256
06361562cc53d759fb5a4c2b7aac348e4d23fe59be3b2871b14678365283ca47
- Kích thước
16355328 bytes
- Thời gian liên kết
2012-07-07 08:47:11 UTC
- Giá trị nhận diện động cơ phân tích kết cấu SATWE
- MD5
2717b58246237b35d44ef2e49712d3a2
- SHA1
d475ace24b9aedebf431efc68f9db32d5ae761bd
- SHA256
bd04715c5c43c862c38a4ad6c2167ad082a352881e04a35117af9bbfad8e5613
- Kích thước
9908224 bytes
- Thời gian liên kết
2011-01-12 06:37:39 UTC
- MD5
daea40562458fc7ae1adb812137d3d05
- SHA1
1ce1111702b765f5c4d09315ff1f0d914f7e5c70
- SHA256
da2b170994031477091be89c8835ff9db1a5304f3f2f25344654f44d0430ced1
- Kích thước
8454144 bytes
- Thời gian liên kết
2012-11-29 03:10:12 UTC
- MD5
2740a703859cbd8b43425d4a2cacb5ec
- SHA1
ca665b59bc590292f94c23e04fa458f90d7b20c9
- SHA256
aeaa389453f04a9e79ff6c8b7b66db7b65d4aaffc6cac0bd7957257a30468e33
- Kích thước
16568320 bytes
- Thời gian liên kết
2014-12-30 03:23:43 UTC
- MD5
ebff5b7d4c5becb8715009df596c5a91
- SHA1
829f8be65dfe159d2b0dc7ee7a61a017acb54b7b
- SHA256
37414d9ca87a132ec5081f3e7590d04498237746f9a7479c6b443accee17a062
- Kích thước
8089600 bytes
- Thời gian liên kết
2009-04-22 01:46:46 UTC
- MD5
cb66a4d52a30bfcd980fe50e7e3f73f0
- SHA1
e6018cd482c012de8b69c64dc3165337bc121b86
- SHA256
66fe485f29a6405265756aaf7f822b9ceb56e108afabd414ee222ee9657dd7e2
- Kích thước
9219072 bytes
- Thời gian liên kết
N/A
- Giá trị nhận diện tệp PKPM CAD bổ sung
- MD5
075b4aa105e728f2b659723e3f36c72c
- SHA1
145ef372c3e9c352eaaa53bb0893749163e49892
- SHA256
c11a210cb98095422d0d33cbd4e9ecc86b95024f956ede812e17c97e79591cfa
- Kích thước
6852608 bytes
- Thời gian liên kết
2012-06-18 10:01:54 UTC
- MD5
cf859f164870d113608a843e4a9600ab
- SHA1
952ed694b60c34ba12df9d392269eae3a4f11be4
- SHA256
7e00030a35504de5c0d16020aa40cbaf5d36561e0716feb8f73235579a7b0909
- Kích thước
8392704 bytes
- Thời gian liên kết
2012-11-29 03:10:12 UTC
- MOHID là hệ thống mô hình hóa thủy vực mã nguồn mở do MARETEC thuộc Instituto Superior Técnico ở Lisbon, Bồ Đào Nha phát triển, xử lý thủy động lực học biển và ven bờ, mô phỏng chất lượng nước, vận chuyển trầm tích, mô hình hóa tràn dầu và theo dõi hạt Lagrangian
- Họ cho biết đến thời điểm hiện tại vẫn chưa thể xác định một cách dứt khoát hiệu ứng tấn công đã được nhắm tới
- MD5
f4dbbb78979c1ee8a1523c77065e18a5
- SHA1
9e089a733fb2740c0e408b2a25d8f5a451584cf6
- SHA256
e775049d1ecf68dee870f1a5c36b2f3542d1182782eb497b8ccfd2309c400b3a
- Kích thước tệp
5443584 bytes
- Loại tệp
PE32 executable for MS Windows 4.00 (console), Intel i386, 3 sections
- Thời gian liên kết
2002-10-18 09:29:54 UTC
- LS-DYNA từng được trích dẫn cùng với nghiên cứu về mô hình hóa máy tính liên quan đến phát triển vũ khí hạt nhân trong các bản tin công khai về nghi vấn Iran vi phạm Mục T của JCPOA
Quy tắc phát hiện và chỉ dấu xâm nhập
-
Chỉ dấu xâm nhập
- Ba tệp đã được xác nhận là fast16.sys, connotify.dll và svcmgmt.exe
fast16.sys: MD5 0ff6abe0252d4f37a196a1231fae5f26, SHA1 92e9dcaf7249110047ef121b7586c81d4b8cb4e5, SHA256 07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529connotify.dll: MD5 410eddfc19de44249897986ecc8ac449, SHA1 675cb83cec5f25ebbe8d9f90dea3d836fcb1c234, SHA256 8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9svcmgmt.exe: MD5 dbe51eabebf9d4ef9581ef99844a2944, SHA1 de584703c78a60a56028f9834086facd1401b355, SHA256 9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525
-
apt_fast16_carrier
- Được thiết kế để bắt carrier, payload Lua và biến thể văn bản thuần, hash tham chiếu là
9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525
- Sử dụng magic bytecode Lua
1B 4C 75 61, cùng các chuỗi build_wormlet_table, unpropagate, scm_wormlet_install, install_implant, start_worm, ok_to_propagate
- Đưa nhiều khóa registry của sản phẩm bảo mật như
Symantec, Sygate Personal Firewall, Zone Labs\\TrueVector, Kaspersky Anti-Hacker vào điều kiện
- Cũng phát hiện mẫu byte chuỗi mã hóa, 2 hằng số mật mã, mã giải mã độ dài của container lưu trữ, và chữ ký bản ghi lưu trữ có chứa chuỗi
file
- Điều kiện được thỏa mãn khi tệp có header MZ và nhỏ hơn 10MB, đáp ứng 3 mục
$s*, 12 mục $rk*, bất kỳ mục $e*, vị trí gần nhau của 2 hằng số mật mã, cùng một trong $code1, $stor1, hoặc khi đáp ứng magic Lua và 7 mục $s*
-
apt_fast16_driver
- Được thiết kế để bắt driver hoặc các tệp dự án liên quan, hash tham chiếu là
07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529
- Sử dụng nhiều chuỗi nhận diện tệp nguồn như
@(#)foo.c :, @(#)par.h :, @(#)pae.h :, @(#)ree.c :
- Bao gồm các mẫu
\\Device\\fast16, \\??\\fast16, C:\\buildy\\, driver\\fd\\i386\\fast16.pdb, push 0A57Ch ; DeviceType
- Chữ ký cũng chứa các mẫu API đẩy ở dạng XOR cho
ExAllocatePool, ExAllocatePoolWithTag, ExFreePool, ExFreePoolWithTag
- Điều kiện được thỏa mãn trên tệp nhỏ hơn 10MB khi cùng có header MZ và 2 đường dẫn PDB,
C:\\buildy\\ và 1 định danh nguồn, #devtype == 3, pe.machine == pe.MACHINE_I386, pe.subsystem == pe.SUBSYSTEM_NATIVE, bất kỳ api*, một trong 2 mục dev*, hoặc khi đáp ứng 6 định danh nguồn
-
clean_fast16_patchtarget
- Phát hiện phần mềm là mục tiêu bị vá, được ghi là
most probably clean, hash tham chiếu là 8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9
- Sử dụng nhiều mẫu byte kéo dài từ
$el0 đến $el99
- Điều kiện là tệp nhỏ hơn 20MB, có header MZ, và khớp từ 2 chữ ký đã định nghĩa trở lên
-
apt_fast16_patch
- Phát hiện chính mã vá, có thể tồn tại trong tệp đã bị vá tĩnh hoặc trong memory dump
- Hash tham chiếu là
0ff6abe0252d4f37a196a1231fae5f26
- Định nghĩa 3 mẫu byte là
$p1, $p2, $p3
- Điều kiện là
any of them, tức chỉ cần khớp một trong ba mẫu là sẽ bị phát hiện
Phả hệ và hàm ý lịch sử
- Chuỗi
@(#)par.h $Revision: 1.3 $ bên trong binary là một manh mối giúp suy đoán phả hệ của framework này
- Tiền tố
@(#) chỉ tới tập quán quản lý mã nguồn kiểu SCCS/RCS của Unix trong thập niên 1970–1980, và dấu vết như vậy là hiếm thấy trong driver kernel Windows giữa những năm 2000
- Những artifact này dường như gần với dấu vết của một kỹ sư kỳ cựu quen thuộc với văn hóa và toolchain của các môi trường Unix bảo mật cao đời cũ hơn là một nhà phát triển thuần Windows điển hình
svcmgmt.exe đã được tải lên VirusTotal gần 10 năm trước, nhưng đến nay tỷ lệ phát hiện vẫn rất thấp, và chỉ một engine xếp nó vào nhóm malware phổ thông với mức độ tin cậy hạn chế- Khi kết hợp với chữ ký Territorial Dispute của ShadowBrokers,
fast16 buộc người ta phải nhìn lại thời điểm phát triển của một chiến dịch phá hoại mạng cấp quốc gia cực kỳ bí mật
fast16 cho thấy một cấu trúc nhất quán kết hợp công cụ script nhúng, nhắm mục tiêu hẹp dựa trên compiler và vá ở cấp kernel từ trước các họ được biết đến rộng rãi hơn- Trong thời gian dài, gần như không có phân tích công khai, chiến dịch được đặt tên, hay mối liên hệ với các sự cố tiêu biểu; ngay cả các dấu hiệu nội bộ có thể đọc được mà tác giả để lại cũng chỉ ở dạng tiết chế như
*** Nothing to see here – carry on***
- Nó được định vị như một mắt xích kết nối trong dòng tiến hóa APT dẫn tới các toolkit dựa trên Lua và LuaJIT về sau
1 bình luận
Ý kiến trên Hacker News
Đoạn này đặc biệt thú vị
Phép so sánh việc thấy ký pháp SCCS/RCS trong mã kernel Windows năm 2005 giống như nhìn thấy điện thoại quay số trong văn phòng ngày nay khá thuyết phục
Phòng thí nghiệm vật lý thiên văn nơi tôi làm việc năm 2006 vẫn còn dùng svn, và trong codebase có rất nhiều Fortran mang dấu vết của các hệ thống từ thập niên 70~80
Dù vậy nó vẫn chạy tốt nhờ các trình biên dịch tối ưu hóa hiện đại, và quá trình chuyển từ Vax sang Linux vào thập niên 90 cũng mượt đến đáng ngạc nhiên
Nó làm tôi nhớ đến bài nói chuyện do over or make due, với ý đại khái là viết lại toàn bộ một codebase lớn đang chạy ổn thường không đáng, nếu với công cụ hiện đại người ta vẫn có thể chắp vá để tiếp tục dùng được
Tên của nó là MKS, và quản lý một cây revision cụ thể dưới dạng "project file", trông như một bản cũ từ thập niên 90 chứ không phải ngay cả phiên bản làm lại bằng Java EE
Ở đầu file có các thẻ như
$Revision: 1.3 $và changelog, nhưng khá nhiều file mới thậm chí không có thẻ nên cũng chẳng được thay thế gì, tính nhất quán thì rất tệDòng thiết bị mục tiêu bắt đầu từ khoảng giữa thập niên 90, nhưng bản thân code ở thời điểm đó trên thực tế hầu như không có gì quá 5 năm tuổi
Dù chỉ có vài chục kỹ sư, xung đột commit vẫn xảy ra thường xuyên và toàn bộ cây mã hay bị hỏng
Tôi viết một script cho vui để đọc toàn bộ lịch sử và nhập vào git, nhưng chỉ cần lùi lại vài năm thôi là bản ghi đã hoàn toàn hỗn loạn
Tôi không biết vì sao họ vẫn dùng nó tới lúc đó, nhưng các công ty phần cứng đôi khi đến gần đây hơn người ta tưởng vẫn xem quản lý mã nguồn như kiểu "thư mục chia sẻ từ xa", nên có lẽ quản lý phiên bản phía phần mềm không phải ưu tiên
Trong thế giới tính toán số, dòng dõi đó vẫn còn giữ vai trò nền tảng
Cho đến thập niên 2000 vẫn thực sự có những nơi dùng RCS, và bản thân công cụ này ở vài điểm còn tốt hơn SVN hay CVS
Chẳng hạn tôi cũng hình dung được chuyện fast16 do người vốn viết phần mềm tính toán khoa học làm ra, còn Stunex thì do người từng làm ở Siemens viết
Nếu nguyên nhân ban đầu khiến code cần refactoring vẫn còn nguyên, thì cuối cùng nó cũng sẽ quay lại trạng thái cũ
Những nguyên nhân đó nhiều khi ăn rất sâu ở tầng tâm lý như thói quen, niềm tin, hay chấn thương nghề nghiệp của lập trình viên
Khi định luật Conway chồng lên nữa, đội ngũ rốt cuộc khó tránh khỏi việc tạo ra phần mềm phản chiếu cấu trúc tổ chức lớn hơn, và nếu tổ chức không đổi thì kết quả refactoring phần lớn cũng sẽ lặp lại
Ngoại lệ thường là lúc tiếp quản codebase của đội khác hoặc code của người tiền nhiệm rồi tổ chức lại cấu trúc
Nhưng nếu cùng một nhóm tuyên bố refactor chính code của họ, thì thường chỉ dễ thành việc làm thêm một cái bẫy chuột thuận tay hơn cho chính họ
Việc lặp đi lặp lại cải tiến sản phẩm của chính tư duy mình thì không sao, nhưng muốn bước xuống khỏi vòng quay đó thì phải viết ra nguyên nhân của kiến trúc tệ và tự soi xét mình một cách lạnh lùng
Câu mà nhiều lập trình viên muốn tin là "chỉ cần cẩn thận và chăm chỉ thì một thiết kế hơi tệ vẫn có thể được hiện thực hóa tốt" đa phần không đúng
Cuối cùng gốc rễ vẫn là thiết kế; hoặc chấp nhận cái cây mọc ra từ đó, hoặc chặt nó đi, chứ chỉ tỉa cành thì giới hạn rất lớn
Bài này tạo cảm giác khá rợn người
Chỉ riêng chuyện malware này đã nằm dưới lưới phát hiện suốt 20 năm cũng đã đủ đáng ngại rồi
Đây là link tải cho ai tò mò
https://bazaar.abuse.ch/sample/9a10e1faa86a5d39417cae44da5ad...
Chắc tôi sẽ dựng một Windows XP VM trước đã
Cái này trông chỉ như loader thôi
IEEE-754 chỉ bắt buộc làm tròn đúng với +-*/ và sqrt
Các hàm siêu việt như sin/cos/exp/log/pow được phép lệch vài ULP cuối, và glibc, musl, MSVC, Intel SVML thực tế cũng hoạt động như vậy
PID chủ yếu dùng các phép toán cơ bản nên ít bị ảnh hưởng bởi khác biệt của libm, nhưng điều khiển vector động cơ hay tuyến tính hóa cảm biến thì đụng tới các hàm này ở mỗi chu kỳ, nên sai khác nhỏ sẽ tích lũy
Vì vậy ngay cả khi diff mã nguồn hoàn toàn không có gì, hành vi thực địa vẫn có thể drift chỉ vì libm được liên kết đã thay đổi
Những khác biệt này thực sự lộ ra ở Payne-Hanek argument reduction hoặc ở biên của table-maker's dilemma trong trường hợp xấu nhất
Có lẽ vì vậy mà hướng dẫn cho các hệ thống an toàn tối quan trọng không chỉ viết chung chung là "tuân thủ IEEE-754" mà còn cố định cả bản build libm cụ thể
Đây thật sự là một phát hiện lớn
Tôi rất tò mò chính xác các quy tắc này nhắm vào đối tượng nào và đã thay đổi kết quả ra sao
Có khi nó được thiết kế để chỉ tạo ra khác biệt trong những điều kiện mô phỏng cực kỳ cụ thể, kiểu như lò phản ứng hạt nhân chẳng hạn
Chẳng hạn phương trình EOS_JWL trong tài liệu công khai [1] là công thức LS-DYNA triển khai, và khi dùng cùng các phương trình khác, có vẻ nó có thể được dùng để tính thời gian từ lúc ngòi nổ của đầu đạn tên lửa kích nổ thuốc chính đến khi tạo ra một sóng áp suất nhất định ở khoảng cách 20 m
Từ kết quả đó cũng có thể suy ngược ra thời điểm kích nổ cần thiết của ngòi
Các phương trình và tham số đưa vào LS-DYNA đến từ những nghiên cứu khoa học như [2], đây là nghiên cứu thí nghiệm về thuốc nổ mạnh của chính phủ Mỹ trong thập niên 1980
Trong đó còn có các thí nghiệm đo đặc tính ma sát khi thuốc nổ cọ xát với nhiều loại vật liệu bao quanh nó
Vì các phương trình mô hình hóa thuốc nổ đã có sẵn rồi, nên chỉ cần chỉnh nhẹ các công thức như thế để thêm nhiễu ±20% vào hệ số ma sát, nhà khoa học hay kỹ sư rất có thể sẽ nghi vấn chất lượng chế tạo thép trước khi nghĩ tới chuyện phần mềm bị thao túng
Một phép so sánh hiện đại là tưởng tượng một quốc gia thù địch nào đó đang dùng bản crack Ansys Autodyn 2026 R1 do nhóm cracking Trung Quốc đăng trên diễn đàn Trung Quốc, tải từ một số ít seeder phía sau ISP Nga
Rồi về sau khi số đo thực nghiệm và kết quả tính toán cứ liên tục lệch nhau, lúc đó mới nghi ngờ rằng bản crack có thể đã bị chỉnh sửa có chủ ý
Tuy vậy hiện giờ có lẽ quốc gia thù địch đó sẽ dễ lấy bản chính thức hơn bằng cách trích xuất từ mạng bị xâm nhập của một trường đại học ngẫu nhiên hay một công ty tư vấn hàng không vũ trụ/quốc phòng
Cũng có thể là ngây thơ nếu cho rằng quốc gia thù địch năm 2026 sẽ không thể tự làm phần mềm ngay từ đầu, và họ vẫn có thể đạt được kết quả mong muốn bằng tính toán thủ công hoặc thí nghiệm
Cuối cùng thì để xác minh chất lượng chế tạo, thiết bị và năng lực thí nghiệm vốn dĩ vẫn là thứ phải có
Phần mềm mô phỏng chủ yếu chỉ giúp giảm số lần làm mô hình và thí nghiệm vật lý để tiết kiệm chi phí và thời gian
Ví dụ như [3], chạy 1000 lần một kịch bản đạn pháo bắn trúng tấm giáp thì rẻ, nhưng lặp lại điều đó ngoài đời thực sẽ tốn kém và mất thời gian hơn nhiều
[1] https://ftp.lstc.com/anonymous/outgoing/jday/manuals/LS-DYNA...
[2] https://www.osti.gov/servlets/purl/6530310
[3] https://www.youtube.com/watch?v=_dv2PecKUBM
Khi thấy những thứ tôi công khai có kèm dữ liệu revision RCS, tôi muốn mọi người chí ít phải khựng lại một chút
Quyển sách tôi đọc gần đây là Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin's Most Dangerous Hackers, của Andy Greenberg
Nó khá hay, và vì thông tin mới vẫn đang tiếp tục xuất hiện nên tôi nghĩ có thể sẽ cần một loạt tiếp theo
Nhìn Guix và điện toán tái lập được đang dần port được cả sang PowerPC lẫn các máy legacy, tôi nghĩ chính phủ hay các tổ chức kiểu 1984, cùng một số nhóm ở Trung Đông, hẳn sẽ thực sự ghét điều đó
Môi trường càng dị chủng thì càng có lợi
Con số mấu chốt là worm
Kiểm tra bằng máy tính khác cũng không phát hiện được, vì ngay từ đầu đã không hề có chiếc máy thứ hai sạch sẽ nào cả
Đây là một phát hiện thú vị, nhưng bình luận liên quan tới quản lý mã nguồn có vẻ hơi lệch
Những thứ giống SCCS thời đó chắc vẫn còn tồn tại đâu đó, và tôi cũng thoáng bối rối không biết CVS có thuộc kiểu tương tự không
Nó gợi ý rằng các lập trình viên vốn dĩ cũng làm việc ở phía UNIX, vì SCCS/RCS là thứ rất phổ biến ở đó