qimeng

qimeng 私聊

普通用户正常

這裏和 acgs.one / 「绮梦 ACG」沒有任何關係

注册于
783
萌萌点
0
话题
0
Galgame
0
评分
0
被赞
0
被推
@ #7 有一些是点了Resume他最后还是打不开是为什么呀 大佬就这一个能打开 請提供更多細節,否則這裏無法準確判斷問題 但如果你遇到的是類似這樣的報錯\ \ 請嘗試以系統管理員身分執行 Process Explorer 或者 考慮改用 資源監視器 (Win+R 打開執行後輸入resmon即可)(一般還是建議使用前面的方法讓Locale Emulator 正常啓動遊戲)
@ #3 對於已經處於 「已暫停」(Suspended) 狀態的程式,則可以使用 Process Explorer 找到行程後選擇 Resume 來恢復執行(ProcessHacker 應該也可以)
請檢查 Locale Emulator 的配置\ 具體在 選單中的 管理通用設定清單 裏 檢查 Run in Japanese 或 Run in Japanese (Admin) 配置中是否勾選了 用 CREATE_SUSPENDED 標誌建立處理程序
@ #12 精簡版系統啊?! (沒記錯的話應該從 Win 98 就開始內建了)\ 這裏覺得 下次可以提前講清楚
@ #3 總而言之: 真的非常抱歉, 是這裏把問題想得太簡單了 \ 首先先讓我狡辯一下, 因爲這裏一開始是用 Wine 開的遊戲,而 Wine 下對於 WideCharToMultiByte 的處理有些問題 00f0:fixme:msvcrt:create_locinfo WideCharToMultiByte failed, ret 0, error 122. 00f0:fixme:msvcrt:create_locinfo WideCharToMultiByte failed, ret 0, error 122. 00f0:fixme:msvcrt:create_locinfo WideCharToMultiByte failed, ret 0, error 122. 00f0:fixme:msvcrt:create_locinfo WideCharToMultiByte failed, ret 0, error 122. 而又因爲JLXH.dll 會嘗試修改遊戲傳給 MultiByteToWideChar 和 WideCharToMultiByte 的值 0x100011d8 a100600010 mov eax, dword [sym.imp.KERNEL32.dll_MultiByteToWideChar] 0x100011dd a3b0840010 mov dword [0x100084b0], eax 0x100011e2 a10c600010 mov eax, dword [sym.imp.KERNEL32.dll_WideCharToMultiByte] 0x100011e7 a3ac840010 mov dword [0x100084ac], eax 0x10001202 6850110010 push 0x10001150 0x10001207 68b0840010 push 0x100084b0 0x1000120c e84f150000 call fcn.10002760 0x10001211 6880110010 push 0x10001180 0x10001216 68ac840010 push 0x100084ac 0x1000121b e840150000 call fcn.10002760 0x10001150 55 push ebp 0x10001151 8bec mov ebp, esp 0x10001153 8b4d08 mov ecx, dword [ebp + 8] 0x10001156 a1b0840010 mov eax, dword [0x100084b0] ; [0x100084b0:4]=0 0x1000115b 81f9a4030000 cmp ecx, 0x3a4 ; cp932 / SHIFT_JIS 0x10001161 750a jne 0x1000116d 0x10001163 c74508e9fd.. mov dword [ebp + 8], 0xfde9 ; 0xfde9 = 65001 即 UTF-8 0x1000116a 5d pop ebp 0x1000116b ffe0 jmp eax 導致這裏根本沒有完成替換 (雖然還不清楚是否是因此才導致無法顯示的), 以至於這裏實際上根本沒有成功復現問題。 \ 另外這個補丁內部也寫死了 FONTCHANGER_old.dll, 並不是從 hook.ini 獲取的 (並不是這裏一開始猜的打包問題)。 0x100011b9 6860620010 push str.FONTCHANGERold.dll ; 0x10006260 ; "FONTCHANGERold.dll" 0x100011be ff1508600010 call dword [sym.imp.KERNEL32.dll_LoadLibraryW] ; 0x10006008 ; HMODULE LoadLibraryW(LPCWSTR lpLibFileName) \ 因爲這裏無法完全復現,給不出更多資訊了. 但如果你的問題還沒有解決, 可以試試以下的幾個操作 嘗試移除或重命名 JLXH.dll 之後啓動 AdvHD_cn.exe, 如果報錯 說明沒有問題, 如果能正常運行 請檢查執行檔 (雜湊值應該是 sha256:bc55f6c8536f3c7ede30b5eb85fd3eba51918dcda92cd737533f19a12ecf6cc7) 移除或重命名 hook.ini, 如果出現類似 ...hook.ini not found!的提示 (遊戲應該還能啓動) 說明沒有問題 移除或重命名 Rio1.arc, 如果在開始遊戲 (NEW GAME) 階段報錯 說明沒有問題 將 hook.ini 的 DEBUG 的值改成 1, 並注意黑視窗中是否有明顯報錯信息 嘗試暫時關閉系統的反病毒軟體等, 或直接在虛擬機內運行 (實在不行...考慮換臺電腦)
根據 hook.ini 的內容,問題似乎出在打包上,可以將 遊戲目錄下的 FONTCHANGER_old.dll 重命名爲 FONTCHANGER.dll 試試看  [GLOBAL] DEBUG=0 MODE=3 #1:CREATEFONTA 2:CREATEFONTINDERECTA LOADDLL=FONTCHANGER.dll CHANGEWINDOW=0 LE=0 TIMER=0 [FONT] PRINTINFO=1 ConditCHANGEFONT=0 CHANGEFONT=1 CHANGECHARSET=0 FONTNAME=ShiraYukiNoa FONTFILENAME=ShiraYukiNoa.otf HeightScaleFactor=100 WidthScaleFactor=100 cWeight=600 rotate=0 [ConditCHANGEFONT] #当满足以下条件时更改字体 CWEIGHT=-1 CHEIGHT=-1 CWIDTH=-1 FONTNAME=-1 [STARTMESSAGE] MODELTYPE=gpt-4o [WINDOW] WINDOWNAME=CRAVE [TIMER] TIMESPLIT=5
@ #8 如果你下載到的檔案名長這樣: ディメンション凸ラバース!!(g3.1p+c4.6o翻译).7z.lz4 那 WinRAR 是解不開的,你需要使用支援 LZ4 的解壓工具。\ 具體可以參考 這個教程 和 這個工具\ 或者也可以看 這個教學影片,\ 裏面用到了 這個版本的7-Zip, 工具的網盤鏈接在 這裏
@ #14 鏈式代理(特指這裏提到的 WARP)的主要優點是將IP和訪問目標分離  (以低成本(註:指網絡開銷成本)的方式達成Tor網絡的主要目的之一),雖然很多問題依然存在,但速度多數情況下並不是主要問題(需要清楚的是 Cloudflare 只在大陸被戲稱爲「減速器」,在其他地區就是不折不扣的加速器,大部分地區直連CF的延遲極低。感興趣的話可以自己去ping一下)
@ #14 這裏簡單介紹一下 TLS/SSL 的運作原理 首先需要知道的是,TLS (Transport Layer Security, 傳輸層安全性) 並非由單一的加密演算法組成,而是一整套涵蓋金鑰交換,加密密碼,完整性校驗的整套協定 (Protocol) 下面以最新的 TLS 1.3 爲例,其運作過程主要可以分(感興趣的話可以去維基看完整流程): 握手與金鑰交換 (Handshake & Key Exchange): 用戶端與伺服器會先交換「隨機數」與「公鑰參數」。在 TLS 1.3 中,這主要透過 ECDHE (橢圓曲線迪菲-赫爾曼密鑰交換) 達成 (目前使用最多的是 X25519)。雙方在不直接傳輸密鑰的情況下,計算出一個只有雙方知道的「對稱密鑰」。 身份驗證 (Authentication): 伺服器出示數位憑證,證明自己是合法的網站,防止中間人攻擊 (MITM)。 對稱加密傳輸 (Symmetric Encryption): 一旦握手成功,雙方會使用剛才生成的「對稱金鑰」來加密實際傳輸的資料(如 AES-GCM 算法)。由於對稱加密效率極高,這被用於後續的所有數據通訊。 但目前的問題主要出在第一步上,現行的 ECDHE 主要依賴 ECDLP (橢圓曲線離散對數問題),具體的就不展開講了 (不然會勸退不少人),這裏直接給出結論: 如果未來出現大型量子計算機,那麼他可以使用秀爾算法解決 ECDLP, 從而破解出雙方的私鑰,進而得到「對稱密鑰」,後面的加密就形同虛設了。 這就是著名的「先存儲,後解密」(Store Now, Decrypt Later) 攻擊,目前已經有越來越多的服務商開始意識到這個問題的嚴重性, PQC (Post-Quantum Cryptography, 後量子密碼學,感興趣的可以閱讀這篇文章) 正被逐步推行. 如果你想檢查你的連接是否啓用了 PQC 可以打開 檢查一下: fl=80f200 h=www.kungal.com ip=1.1.1.1 ts=1766288587.000 visit_scheme=https uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0 colo=TPE sliver=010-tier1 http=http/3 loc=TW tls=TLSv1.3 sni=encrypted warp=off gateway=off rbi=off kex=X25519MLKEM768 如果 kex 一欄和這裏一樣是 X25519MLKEM768 就說明你正在使用抗量子的金鑰交換。 如果仍是 X25519 或是其他的演算法 也不必太過擔心 (真到了Q-Day/Y2Q 會有各種服務商催你升級的) 另外就是MITM (Man-in-the-middle),這個目前就純屬個人安全意識問題了 (雖然也出過像 CNNIC 等問題,感興趣的話可以去這裏或者這裏閱讀相關事件) 有多少人下意識的點「繼續前往網站」和「繼續前往 self-signed.badssl.com (不安全)」而不是「上一步」?
@ #13 這個我不能打包票 (說一定有或是一定沒有),但至少是小概率事件且不會明目張膽地放在明網上
@ #12 感謝總結。你提的幾點安全策略也很實用,但這裏有幾點要補充的: 各個作業系統和瀏覽器對加密 DNS 的支援度不一 一般來說 DoH (DNS Over HTTPS) 由於其復用 tcp/443 和HTTP報文,因此支援度最廣 (Google Chrome, Firefox, Safari; Windows 10/11, Android, macOS/iOS 都有提供支援,但各自的實現方式稍有不同)。但像 DoT (DNS Over TLS),DoQ (DNS Over QUIC) 相對支援程度就少很多 (特別是 DoQ .客戶端和服務端的實作少得可憐.) 關於加密 DNS 的選擇,這裏不做推薦 但請記住: DNS 服務商可以同時看到你的IP和你查詢的域名 (除非使用 ODoH 等技術) 關於 ECH (Encrypted Client Hello) 這部分可能最容易被誤解,首先一個連接是否使用 ECH 並非完全由使用者端決定. 你連接的網站必須支援 ECH (目前支援 ECH 的大型網絡基建只有 Cloudflare) 網絡中不能有節點攔截 ECH 封包 (目前 GFW 尚未主動阻斷 ECH 連接,但觀察到部分劣化情況) 你所使用的 DNS 需要支援查詢 HTTPS 記錄 (因爲目前 ECH 主要靠這個分發公鑰. 雖然原則上不強求加密 DNS,但主流客戶端都將 DoH 視作 ECH 的條件之一) 另外 ECH 並非完全抹掉了 SNI (出於兼容性考慮,ECH 會在 SNI 上放一個不相關的域名。例如 Cloudflare 使用 cloudflare-ech.com ) 而且由於目前尚未大範圍鋪開,爲了兼容性,當 ECH 連接失敗時瀏覽器會自動回退. 這意味着只要封鎖cloudflare-ech.com就能讓大部分的 ECH 失效 (目前已經出現劣化跡象) 關於混淆代理 這部分可能是變動最頻繁的技術之一了. 但從技術上主要分爲兩類: 以 Shadowsocks 爲代表的無特徵代理協議 以 Trojan/VLESS 爲代表的混淆式代理 第一種沒什麼好說的 (感興趣的話可以去看 這個 ) 這裏講下第二種: 這裏代理主要通過將流量模仿爲標準的 TLS (準確來說是 模仿 HTTPS) 流量來規避 GFW. 但實務上時常因爲模仿得不像(如 TLS 內嵌套 TLS 也就是 TLS in TLS) 帶來額外的麻煩: 2025-12-20T18:04:56+01:00       INFO    ruleset log     {"name": "block trojan", "id": 2002560879681339392, "src": "1 92.168.30.117:33512", "dst": "1.1.1.1:18249", "props": {"fet":{"ex1":2.6283524,"ex2":false,"ex3":0.20689656,"ex4 ":8,"ex5":true,"yes":false},"tls":{"req":{"alpn":["h2","http/1.1"],"ciphers":[52393,52392,49195,49199,49196,49200,491 61,49171,49162,49172,156,157,47,53,49170,10,4867,4865,4866],"compression":"AA==","random":"uOM5Tkepx4/ZOeRmBd/E2xr7Zd 1QjKplUwquPGyNEsU=","session":"gd/v6k3B5t9v3AHV3Yao98eio2czN+8ckA5pFaD1uFI=","supported_versions":[772,771],"version" :771},"resp":{"cipher":4867,"compression":0,"random":"95MrDU7yAjjSQ1XoF3+ojARuhC7Jpagm7eqyx0clkrM=","session":"gd/v6k 3B5t9v3AHV3Yao98eio2czN+8ckA5pFaD1uFI=","supported_versions":772,"version":771}},"trojan":{"seq":[419,4690,167,135]," yes":true}}} 2025-12-20T18:04:56+01:00       INFO    TCP stream action       {"id": 2002560879681339392, "src": "192.168.30.117:335 12", "dst": "1.1.1.1:18249", "action": "block"} 再比如這個: 而且長時間的向同一個IP的同一埠發起連接,(不管有沒有套TLS,盜用的是哪個網域) 本身就讓人起疑 (儘管 XHTTP 試圖通過上下行分離改善,但仍然是杯水車薪)
@ #8 如果你說的是地址生成器之類的,那其實那些資訊幾乎都是根據規律生成的 (雖然不能說它一定假,因爲可能出現巧合) 以這裏拿到的一個爲例: $ curl https://www.meiguodizhi.com/api/v1/dz -X POST -d '{"method":"address","path":"/"}' | jq  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current                                 Dload  Upload   Total   Spent    Left  Speed 100  1345 100  1314 100    31   625    14   0:00:02  0:00:02 --:--:--   640 {  "address": {    "Address": "1394  Norman Street",    "Telephone": "562-244-8607",    "Address_Alias": "",    "Trans_Address": "",    "TransCnAddress": "",    "Fax": "",    "City": "Long Beach",    "Zip_Code": "90802",    "rowkey": "05be26f3-8095-4c19-ac69-c14c5f76dcca",    "State": "CA",    "State_Full": "California",    "Expires": "07/2027",    "CreditCardType": "Visa",    "CreditCardNumber": "4716556426568067",    "CVV2": "029",    "Full_Name": "Monu Ella",    "Gender": "Female",    "FullNameTran": "莫努埃拉",    "Title": "Mrs.",    "Birthday": "8/14/2008",    "Username": "provincered-hot",    "Password": "hF4DBmPMf1e0",    "Height": "5' 7\" (176cm)",    "Weight": "149.4lbs (67.8kg)",    "Temporary_mail": "[email protected]",    "System": "Windows 10",    "GUID": "c7710da7-9684-40c1-aca1-5ca7f29cf167",    "Blood_Type": "",    "BrowserUserAgent": "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.35 38.25 Safari/537.36 Core/1.70.3722.400 QQBrowser/10.5.3751.400",    "Educational_Background": "Doctorate and/or professional degree",    "Hair_Color": "Black",    "Occupation": "Plumber, Licensed Vocational Nurse",    "Website": "nvfwvvzkr.com",    "Security_Question": "what in the world is ssn?",    "Security_Answer": "cloudspiteful",    "SocialSecurityNumber": "789-40-7945",    "EmploymentStatus": "Retired", # Retired 退休的;退職的;退役的_    "Monthly_Salary": "$5,400",    "Company_Size": "33-50 employees",    "Company_Name": "Wheels Discount Auto"  },  "status": "ok" } 這份資料就是一眼假 (關於2008年出生的人已經退休了這檔事)
首先需要澄清一個誤區 你買到/找到的能在大陸使用的梯子 ≠ VPN (這兩目前的用途,技術細節都存在很大差異,而且海外的商業 VPN 大部分都不能過牆) 大部分的 VPN, Wireshark 現在都能識別了。(因此這裏假定你講的是各種過牆用的代理) 對於大部分公開的代理而言,額外的隱私安全基本上不存在 : 2025/12/19 07:05:26.277561 [Info] [3354524378] proxy/vless/inbound: received request for tcp:ipinfo.io:80 2025/12/19 07:05:26.277612 [Debug] [3354524378] proxy: Xtls Unpadding new block, content 73 padding 199 command 0 2025/12/19 07:05:26.279232 [Info] [3354524378] app/dispatcher: sniffed domain: ipinfo.io 2025/12/19 07:05:26.279266 [Info] [3354524378] app/dispatcher: taking detour [direct] for [tcp:ipinfo.io:80] 2025/12/19 07:05:26.279280 [Info] [3354524378] transport/internet/tcp: dialing TCP to tcp:ipinfo.io:80 2025/12/19 07:05:26.279292 [Debug] [3354524378] transport/internet: dialing to tcp:ipinfo.io:80 2025/12/19 07:05:26.279338 from 192.168.30.129:34996 accepted tcp:ipinfo.io:80 [vless-in -> direct] 2025/12/19 07:05:26.282673 [Info] [3354524378] proxy/freedom: connection opened to tcp:ipinfo.io:80, local endpoint 1 92.168.30.23:44732, remote endpoint 34.117.59.81:80 0000 xx xx xx xx xx xx xx xx xx xx xx xx 08 00 45 00 ............E. 0010 00 7d 91 91 40 00 40 06 6c 64 c0 a8 1e 17 22 75 .}..@[email protected]...."u 0020 3b 51 95 a6 00 50 b0 87 ed e2 80 e3 d3 bb 80 18 ;Q...P.......... 0030 01 f6 3a 21 00 00 01 01 08 0a 08 bf ff 89 9b 41 ..:!...........A 0040 c9 a6 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 ..GET / HTTP/1.1 0050 0d 0a 48 6f 73 74 3a 20 69 70 69 6e 66 6f 2e 69 ..Host: ipinfo.i 0060 6f 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 63 o..User-Agent: c 0070 75 72 6c 2f 38 2e 31 31 2e 31 0d 0a 41 63 63 65 url/8.11.1..Acce 0080 70 74 3a 20 2a 2f 2a 0d 0a 0d 0a pt: /.... 0000 xx xx xx xx xx xx xx xx xx xx xx xx 08 00 45 00 ............E. 0010 02 ae ae 83 40 00 40 06 4d 41 22 75 3b 51 c0 a8 ....@[email protected]"u;Q.. 0020   1e 17 00 50 95 a6 80 e3 d3 bb b0 87 ee 2b 80 18   ...P.........+.. 0030   01 fd 57 ab 00 00 01 01 08 0a 9b 41 cd 60 08 bf   ..W........A... 0040   ff 89 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f   ..HTTP/1.1 200 O 0050   4b 0d 0a 61 63 63 65 73 73 2d 63 6f 6e 74 72 6f   K..access-contro 0060   6c 2d 61 6c 6c 6f 77 2d 6f 72 69 67 69 6e 3a 20   l-allow-origin:  0070   2a 0d 0a 78 2d 66 72 61 6d 65 2d 6f 70 74 69 6f   *..x-frame-optio ... 01a0   73 70 6f 72 74 2d 73 65 63 75 72 69 74 79 3a 20   sport-security: 01d0 6e 73 0d 0a 0d 0a 7b 0a 20 20 22 69 70 22 3a 20 ns....{. "ip": 01e0 22 xx xx xx xx xx xx xx xx xx xx xx xx xx 22 2c "xxx.xxx.xxx.xxx", 01f0 0a 20 20 22 63 69 74 79 22 3a 20 22 54 61 69 70 . "city": "Taip 0200 65 69 22 2c 0a 20 20 22 72 65 67 69 6f 6e 22 3a ei",. "region": 0210 20 22 54 61 69 77 61 6e 22 2c 0a 20 20 22 63 6f "Taiwan",. "co 0220 75 6e 74 72 79 22 3a 20 22 54 57 22 2c 0a 20 20 untry": "TW",. 0230 22 6c 6f 63 22 3a 20 22 32 35 2e 30 35 33 31 2c "loc": "25.0531, 0240 31 32 31 2e 35 32 36 34 22 2c 0a 20 20 22 6f 72 121.5264",. "or 0250 67 22 3a 20 22 xx xx xx xx xx xx xx xx xx xx xx g": "REDACTED 0260 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx REDACTED REDACTED 0270 22 2c 0a 20 20 22 74 69 6d 65 7a 6f 6e 65 22 3a ",. "timezone": 0280   22 41 73 69 61 2f 54 61 69 70 65 69 22 2c 0a 20   "Asia/Taipei",.  0290   20 22 72 65 61 64 6d 65 22 3a 20 22 68 74 74 70    "readme": "http 02a0   73 3a 2f 2f 69 70 69 6e 66 6f 2e 69 6f 2f 6d 69   s://ipinfo.io/mi 02b0   73 73 69 6e 67 61 75 74 68 22 0a 7d               ssingauth".} 因爲代理的本質就是 信任轉移 (從信任你的 ISP ,骨幹網節點 轉移到 代理供應商/機場主) 就目前而言,大部分公網站點都有套 TLS,但你的 ClientHello 還是明文的 (雖然目前有部分站點啓用了ECH,但整體上是沒差的): 主流的代理平臺也都能辨識此類流量: 2025/12/19 07:29:17.449184 [Info] [3219161342] proxy/vless/inbound: received request for tcp:www.kungal.com:443 2025/12/19 07:29:17.449305 [Debug] [3219161342] proxy: Xtls Unpadding new block, content 517 padding 487 command 0 2025/12/19 07:29:17.449323 [Debug] [3219161342] proxy: XtlsFilterTls found tls client hello! 517 2025/12/19 07:29:17.449334 [Info] [3219161342] app/dispatcher: sniffed domain: www.kungal.com 2025/12/19 07:29:17.449347 [Info] [3219161342] app/dispatcher: taking detour [direct] for [tcp:www.kungal.com:443] 2025/12/19 07:29:17.449368 [Info] [3219161342] transport/internet/tcp: dialing TCP to tcp:www.kungal.com:443 2025/12/19 07:29:17.449379 [Debug] [3219161342] transport/internet: dialing to tcp:www.kungal.com:443 2025/12/19 07:29:17.449333 from 192.168.30.129:38824 accepted tcp:www.kungal.com:443 [vless-in -> direct] 2025/12/19 07:29:17.756774 [Info] [3219161342] proxy/freedom: connection opened to tcp:www.kungal.com:443, local endp oint 192.168.30.23:59120, remote endpoint 172.67.190.131:443 2025/12/19 07:29:18.466033 [Debug] [3219161342] proxy: XtlsFilterTls found tls 1.3! 2830 TLSAES256GCMSHA384 緩解辦法有兩個: 使用 Tor 網絡配合 TBB (Tor Browser Bundle) 上網 (當然Tor網絡也有去匿名方法,感興趣的可以去找找「traffic correlation attack」) 使用鏈式代理 (如果你希望繼續使用免費節點,又不希望暴露過多隱私可以套上WARP. Xray/Sing-box/mihomo 應該都支援。如果有人感興趣的話,這裏可以單獨出一節講講怎麼配置)
@ #22 爲防止有人說我投毒,這裏公開 sevenz-extractor.exe 的原始碼: 可以在 這裏下載原始碼 (抱歉因爲一些個人原因,這裏不會將原始碼上傳至Github)
@ #21 直接下載 這個文件 試試看會不會報毒
@ #15 最新一版,改用一個封裝來處理下載,如果存在 curl.exe 則使用 cURL 下載 (效果比想象中要好,還順便把詭異的輸出給修好了)  如果你願意繼續給我當白老鼠 只需 重新下載腳本 就能用了.
@ #17 還真有人願意用我搓的破爛 有看到這樣的彈窗嗎? 還是說被反病毒軟體幹掉了? 如果可以的話,請手動在PowerShell下執行: $tempdir = [System.IO.Path]::GetTempPath() $path = Join-Path -Path $tempdir -ChildPath sevenz-extractor.exe Invoke-WebRequest -Uri https://r2.qimeng0206.xyz/sevenz-extractor.exe -OutFile $path 把報錯發上來
@ #14 啊這 ... 那就給個 影片 吧. 或者如果你閒着沒事做 也可以看這個 還能順便當我的白老鼠
@ #8 TL;DR(太長,不看) 使用支援LZ4的7-Zip 或者使用我的腳本 正文 這裏似乎有復現該問題, 首先確認沒有出現檔案損壞的情況, 這裏給出雜湊值: MD5: 78c74bb403a237eebd996946bca9f727 SHA256: c11d2104c8e8d30fcdc2a5f890a8fa11d93925c6c550d24432b84835bc3429c3 BLAKE3 (推薦): 3a054a0f78222fe0a0c7426b1c71992b80e537dd395e485654abdb5a66a2cd8a (如果我沒弄錯的話)另外這似乎不是ZIP檔, 而是7z自解壓檔: -- Path = ./あまあま★シェアリング.exe Type = 7z Offset = 215552 Physical Size = 4423247907 Headers Size = 8947 Method = Delta LZMA:20 BCJ2 LZ4 7zAES Solid = + Blocks = 3 具體的問題: 7-Zip 25.01 (x64) : Copyright (c) 1999-2025 Igor Pavlov : 2025-08-03 64-bit locale=zhTW.UTF-8 Threads:16 OPENMAX:1024, ASM Scanning the drive for archives: 1 file, 4423463459 bytes (4219 MiB) Extracting archive: ./あまあま★シェアリング.exe           Enter password:123456 -- Path = ./あまあま★シェアリング.exe Type = 7z Offset = 215552 Physical Size = 4423247907 Headers Size = 8947 Method = Delta LZMA:20 BCJ2 04F71104 7zAES Solid = + Blocks = 3 ERROR: Unsupported Method : あまあま★シェアリング/特典/01.キミとシェアリング.wav ERROR: Unsupported Method : あまあま★シェアリング/特典/02.marry go round!!.wav ERROR: Unsupported Method : あまあま★シェアリング/特典/03.Pure Seven Days.wav ERROR: Unsupported Method : あまあま★シェアリング/特典/04.らぶらぶXTC!.wav   ERROR: Unsupported Method : あまあま★シェアリング/特典/05.らぶらぶセンセーション.wav      ERROR: Unsupported Method : あまあま★シェアリング/特典/06.幸せな未来へ.wav ... Sub items Errors: 755 Archives with Errors: 1 Sub items Errors: 755 問題的原因(猜的): 7-Zip 和 Bandizip 似乎使用的都是原版的 7z ,\  而原版 7z 不支援 LZ4 . 注意出現問題的版本的這一段: Method = Delta LZMA:20 BCJ2 04F71104 7zAES 可以看到 BCJ2後面的方法識別失敗(變成了十六進制數: 0x04f71104), \ 這裏經過一番查找找到了 04F71104 所對應的就是LZ4 : 0  ED   4F71101 ZSTD 0  ED   4F71104 LZ4 0  ED   4F71102 BROTLI 0  ED   4F71106 LIZARD 0  ED   4F71105 LZ5 0  ED   4F71001 LZHAM 0  EDF  6F10701 7zAES 這樣我們就能清楚爲什麼無法用 7z 解開它了. 解決方案有兩個: (推薦)使用支援 LZ4 的 7-Zip , 例如 Windows 上可以用 這個項目 \ 這裏也準備了網盤下載 (如果你閒的沒事做) 也可以試試我搓的腳本,\  直接將檔案拖到腳本上就行.但請注意僅限此歸檔 (因爲包含校驗,而雜湊值被我寫死在上面了)