标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,698)
- DB2 (22)
- MySQL (74)
- Oracle (1,559)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (68)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (571)
- Oracle安装升级 (93)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (81)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- Bug 21915719 Database hang or may fail to OPEN in 12c IBM AIX or HPUX Itanium – ORA-742, DEADLOCK or ORA-600 [kcrfrgv_nextlwn_scn] ORA-600 [krr_process_read_error_2]
- ORA-600 ktuPopDictI_1恢复
- impdp导入数据丢失sys授权问题分析
- impdp 创建index提示ORA-00942: table or view does not exist
- 数据泵导出 (expdp) 和导入 (impdp)工具性能降低分析参考
- 19c非归档数据库断电导致ORA-00742故障恢复
- Oracle 19c – 手动升级到 Non-CDB Oracle Database 19c 的完整核对清单
- sqlite数据库简单操作
- Oracle 暂定和恢复功能
- .pzpq扩展名勒索恢复
- Oracle read only用户—23ai新特性:只读用户
- 迁移awr快照数据到自定义表空间
- .hmallox加密mariadb/mysql数据库恢复
- 2025年首个故障恢复—ORA-600 kcbzib_kcrsds_1
- 第一例Oracle 21c恢复咨询
- ORA-15411: Failure groups in disk group DATA have different number of disks.
- 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理
- ORA-00227: corrupt block detected in control file
- 手工删除19c rac
- 解决oracle数据文件路径有回车故障
标签归档:oracle勒索
.makop病毒加密数据库恢复
最近接到客户几套oracle数据库所在的机器文件被加密,readme-warning.txt内容如下
::: Greetings ::: Little FAQ: .1. Q: Whats Happen? A: Your files have been encrypted and now have the "makop" extension. The file structure was not damaged, we did everything possible so that this could not happen. .2. Q: How to recover files? A: If you wish to decrypt your files you will need to pay in bitcoins. .3. Q: What about guarantees? A: Its just a business. We absolutely do not care about you and your deals, except getting benefits. If we do not do our work and liabilities - nobody will cooperate with us. Its not in our interests. To check the ability of returning files, you can send to us any 2 files with SIMPLE extensions(jpg,xls,doc, etc... not databases!) and low sizes(max 1 mb), we will decrypt them and send back to you. That is our guarantee. .4. Q: How to contact with you? A: You can write us to our mailbox: Evilminded@privatemail.com .5. Q: How will the decryption process proceed after payment? A: After payment we will send to you our scanner-decoder program and detailed instructions for use. With this program you will be able to decrypt all your encrypted files. .6. Q: If I don抰 want to pay bad people like you? A: If you will not cooperate with our service - for us, its does not matter. But you will lose your time and data, cause only we have the private key. In practice - time is much more valuable than money. :::BEWARE::: DON'T try to change encrypted files by yourself! If you will try to use any third party software for restoring your data or antivirus solutions - please make a backup for all encrypted files! Any changes in encrypted files may entail damage of the private key and, as result, the loss all data.
通过恢复工具进行处理,直接open数据库,并导入新库
如果此类的数据库文件(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
.CHAK1 比特币加密勒索恢复
最近有朋友遇到oracle数据库被加密后缀名为.CHAK1的比特币勒索
我们通过确认,这次的破坏和上次的(比特币加密勒索间隔加密)比较类似
通过分析,此类损坏结果为:
1)1280 block 间隔加密,
2)每个加密文件前10M数据可能丢失
对于这个客户,我们通过分析,业务数据可以比较完美的恢复
如果您的数据库被比特币加密勒索,需要恢复支持请联系我们
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
发表在 勒索恢复
标签为 .CHAK1, oracle勒索, oracle勒索病毒, YOUR FILES ARE ENCRYPTED, 勒索恢复, 比特币, 比特币 oracle, 比特币加密, 比特币勒索
评论关闭
比特币加密勒索间隔加密
最近我们在一个客户的oracle恢复case中发现比特币文件系统勒索加密比较特殊,和大家做一个分享
文件加密后缀名为:.$ILICONE
文件加密特点分析
DUL> dump datafile 5 block 1 Block Header: block type=0x0b (file header) block format=0xa2 (oracle 10) block rdba=0x01400001 (file#=5, block#=1) scn=0x0000.00000000, seq=1, tail=0x00000b01 block checksum value=0x6e7d=28285, flag=4 File Header: Db Id=0xe1891cca=3783859402, Db Name=XIFENFEI, Root Dba=0x0 Software vsn=0x0, Compatibility Vsn=0xa200300, File Size=0x3ffffe=4194302 Blocks File Type=0x3 (data file), File Number=5, Block Size=8192 Tablespace #7 - OA rel_fn:5 DUL> dump datafile 5 block 2 Block Header: block type=0x63 (unknown) block format=0x57 (unknown) block rdba=0xc6538298 (file#=793, block#=1278616) scn=0xe0ab.fdc4d8d0, seq=225, tail=0xa7b5cab5 block checksum value=0xfaa1=64161, flag=165 corrupted block. DUL> dump datafile 5 block 3 Block Header: block type=0x1e (LMT space map block) block format=0xa2 (oracle 10) block rdba=0x01400003 (file#=5, block#=3) scn=0x0000.00246fbe, seq=1, tail=0x6fbe1e01 block checksum value=0xe495=58517, flag=4 DUL> dump datafile 5 block 4 Block Header: block type=0x83 (unknown) block format=0xa3 (unknown) block rdba=0x17e4c9e4 (file#=95, block#=2410980) scn=0xe3b2.fc505eea, seq=101, tail=0x6e2f1004 block checksum value=0x7f2e=32558, flag=196 corrupted block. DUL> dump datafile 5 block 5 Block Header: block type=0x1e (LMT space map block) block format=0xa2 (oracle 10) block rdba=0x01400005 (file#=5, block#=5) scn=0x0000.00264875, seq=1, tail=0x48751e01 block checksum value=0xb25e=45662, flag=4 DUL> dump datafile 5 block 6 Block Header: block type=0x68 (unknown) block format=0x35 (unknown) block rdba=0x7011e0e3 (file#=448, block#=1171683) scn=0x47bf.9f2df54a, seq=207, tail=0x69ae0a91 block checksum value=0x49f8=18936, flag=174 corrupted block.
通过这里初步分析,确认加密是间隔方式加密,在数据库中表现明显的是每相隔8k进行加密,而且这里是偶数block被加密
确认加密文件结束位置
DUL> dump datafile 5 block 962818 header Block Header: block type=0x4d (unknown) block format=0xde (unknown) block rdba=0x0bab780d (file#=46, block#=2848781) scn=0x056b.2c695f6b, seq=223, tail=0x2399e0cb block checksum value=0x9706=38662, flag=212 corrupted block. DUL> dump datafile 5 block 962820 header Block Header: block type=0x00 (blank block) block format=0xa2 (oracle 10) block rdba=0x014eb104 (file#=5, block#=962820) scn=0x0000.00000000, seq=1, tail=0x00000001 block checksum value=0x174a=5962, flag=5
通过这里可以发现,对于一个32G的文件,一直被加密到block 962818,也就是7.34G(962818*8k),这里间隔加密,而且加密深度特别深,在以往的比特币文件系统加密中比较少见.
再次提醒
1. 不要把数据库暴露在外网
2. 相对linux而言,win更容易受到黑客的攻击
3. 数据库一定要做好备份,条件允许的情况下,配置数据实时同步到其他机器还是有必要的