Re: [opensuse] Partition Recovery? Is it even missing to begin with or just shifted?
On 08/10/2012 07:44 PM, Felix Miata wrote:
On 2012/08/10 19:02 (GMT-0500) David C. Rankin composed: [...]
The sfdisk -l information seems to point to the problem: start: (c,h,s) expected (1023,254,63) found (1023,1,1). How to repair that?
Part of what you get by buying a DFSee license is problem analysis by its author that commonly results in the return of a repair script that will fix problems found. It includes an analysis script that generates logs and such you email to support to enable such analysis. It's the only way I ever partition any HD for over a decade. It includes functionally equivalent executables for 5 different operating systems, so you can run it when necessary from a DOS CD or a live Linux CD or DVD, in addition to BartPE and Hirens. www.dfsee.com
Thanks Felix, At this point I'm really curious to learn what happened and try and fix it in the process. Worse case scenario, I nuke the drive and put another one it and go through the pain of reinstall. What I think happened, is some corrupting information got written to the first part of sda1 that is causing the partition table to see it as a separate partition. As such, it has renumbered the primary partition present sda1->sda2. Since sda1 starts on sector 29 and ends on sector 29, it looks like the answer will be along the lines of deleting sda1 and making sure sda2 ends up back as sda1. I have mounted sda2 to test and make sure the original xp partition is in tact. It appears to be: 16:13 killerz:/home/david # mount -t ntfs-3g /dev/sda2 /windows/c -o gid=users,fmask=133,dmask=022,locale=en_US.UTF-8The disk contains an unclean file system (0, 0). The file system wasn't safely closed on Windows. Fixing. 16:14 killerz:/home/david # l /windows/c total 4192197 drwxr-xr-x 1 root users 8192 Aug 7 14:21 . drwxr-xr-x 3 root root 4096 Mar 1 2011 .. drwxr-xr-x 1 root users 16384 Mar 5 2011 4629192f8fdea65e703a5362c88fd1 drwxr-xr-x 1 root users 4096 Oct 20 2011 Documents and Settings drwxr-xr-x 1 root users 4096 Jun 15 14:40 Fraps drwxr-xr-x 1 root users 4096 Nov 22 2011 glassfish3 drwxr-xr-x 1 root users 4096 Oct 20 2011 HammerAutosave drwxr-xr-x 1 root users 4096 Mar 1 2011 Inetpub drwxr-xr-x 1 root users 0 Mar 1 2011 Intel drwxr-xr-x 1 root users 0 Mar 26 2011 .jagex_cache_32 drwxr-xr-x 1 root users 0 Mar 1 2011 MSOCache drwxr-xr-x 1 root users 0 Mar 1 2011 NVIDIA drwxr-xr-x 1 root users 16384 Jul 24 20:04 Program Files drwxr-xr-x 1 root users 0 Mar 1 2011 RECYCLER drwxr-xr-x 1 root users 4096 Mar 1 2011 System Volume Information drwxr-xr-x 1 root users 155648 Aug 6 10:10 WINDOWS -rw-r--r-- 1 root users 0 Mar 1 2011 AUTOEXEC.BAT -rw-r--r-- 1 root users 211 Aug 3 08:15 boot.ini -rw-r--r-- 1 root users 0 Mar 1 2011 CONFIG.SYS -rw-r--r-- 1 root users 2146816000 Aug 6 10:10 hiberfil.sys -rw-r--r-- 1 root users 0 Mar 1 2011 IO.SYS -rw-r--r-- 1 root users 0 Mar 1 2011 MSDOS.SYS -rw-r--r-- 1 root users 47564 Mar 1 2011 NTDETECT.COM -rw-r--r-- 1 root users 250048 Mar 1 2011 ntldr -rw-r--r-- 1 root users 2145386496 Aug 6 10:10 pagefile.sys -rw-r--r-- 2 root users 77346 Aug 2 13:48 TDSSKiller.2.7.48.0_02.08.2012_13.48.30_log.txt Slowly I'm learning a bit more about repair, but that nagging 'uncertainty' of "do I really want to try X" certainly hangs heavy over my head. That's why I'm hoping some smart person on the list has done this before and can point me in the right direction :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, First of all: _PLEASE_ check any commands _diligently_ for correctness, I'm quite tired now. On Fri, 10 Aug 2012, David C. Rankin wrote:
On 2012/08/10 19:02 (GMT-0500) David C. Rankin composed: [...]
The sfdisk -l information seems to point to the problem: start: (c,h,s) expected (1023,254,63) found (1023,1,1). How to repair that? [..]
On 08/10/2012 07:44 PM, Felix Miata wrote: the process. Worse case scenario, I nuke the drive and put another one it and go through the pain of reinstall.
Do you have space on another drive for an image?
What I think happened, is some corrupting information got written to the first part of sda1
Actually, your drive was repartitionend and "dummy" entries in the MBR added. As the first one points to a sector between the MBR (and apparently after GRUB's stage 1.5), sda1 is still intact but as sda2.
that is causing the partition table to see it as a separate partition. As such, it has renumbered the primary partition present sda1->sda2. Since sda1 starts on sector 29 and ends on sector 29, it looks like the answer will be along the lines of deleting sda1 and making sure sda2 ends up back as sda1.
I'd be interested to see the actual content of the MBR and the first EPBR: dd if=/dev/sda of=dcr-sda-0.img bs=512 count=66 dd if=/dev/sda3 of=dcr-sda3-315291690.img bs=512 count=66 tar czf dcr-sda-imgs.tar.gz dcr-sda-0.img dcr-sda3-315291690.img if you have time, the other EPBRs might be helpful (but the seeking is _SLOW_: dd if=/dev/sda of=dcr-sda-319195485.img bs=512 count=66 skip=319195485 dd if=/dev/sda of=dcr-sda-368017020.img bs=512 count=66 skip=368017020 and mail the .gz as PM (the gzipping is more for a simple "integrity" check than for anything else ;) Those latter 2 EPBRs are the sectors linking the "chain" of extended partitions (logical parts), as listed as Type "X" in the output of testdisk in your first mail. Compare: $ echo '19869*255*63; 22908*255*63'|bc 319195485 368017020 each logical partition starts the "head" i.e. 63 sectors after the EPBR: 6 L Linux 19869 1 1 22907 254 63 X extended 22908 0 1 30514 254 63 Bad thing is: you can't access the EPBR directly as you can the first "extended" partition (the "primary one" in the MBR, in your case now sda3). If you have no qualms of maybe mailing me actual data, you could try seeking (skipping) and reading by whole cylinders, which should be much faster: dd if=/dev/sda of=dcr-sda-319195485-cyl.img bs=8225280 count=1 skip=19869 dd if=/dev/sda of=dcr-sda-368017020-cyl.img bs=8225280 count=1 skip=22908 8225280 is 255*63*512. You could then dd out the first sectors of each image and just mail that: dd if=dcr-sda-319195485-cyl.img of=dcr-sda-319195485.img bs=512 count=66 dd if=dcr-sda-368017020-cyl.img of=dcr-sda-368017020.img bs=512 count=66 The "count=66" is for me to get the first 3 sectors of the following FS, i.e. the ext[234]/NTFS bootsector and in your case also the complete "weird" zero-size partitions. [..]
Slowly I'm learning a bit more about repair, but that nagging 'uncertainty' of "do I really want to try X" certainly hangs heavy over my head. That's why I'm hoping some smart person on the list has done this before and can point me in the right direction :)
BTDT for myself but also for others via the -de-ML ;) But I'd like to be more awake for that. -dnh -- "Windows NT has detected the following system change: Mouse has moved. Click 'OK' to reboot." -- Mike Andrews -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/10/2012 10:33 PM, David Haller wrote:
BTDT for myself but also for others via the -de-ML ;) But I'd like to be more awake for that.
Will work through them all tomorrow morning and see just what injected itself into the drive. My son swears that he was not installing anything when it occurred. Just playing Steam Counter-Strike Source (which he has played for years). However, the steam code is loosely controlled java with contributors similar to an open-source project. Since the package runs on Win.., it may prove a tempting target for evil-doers... As mentioned in the last post. The original windows partition looks fine. I suspect it will boot fine once I get the mbr put back in shape. I can't remember off-hand how the boot sector is laid out as far as bits and bytes and backup copies of the bootloader code. Grub is 100% OK on the drive. I'll zip the stuff up so we can have a look, but my biggest questions is just "What in the heck to do with the stuff that is in sectors 1-62 that is currently junked. We will have to work that out as well. I suspect to get windows going again, we will need to boot with the install cd and restore the boot sector, then boot into linux and reinstall grub. Or something along those lines.... after much more sleep... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012/08/11 01:06 (GMT-0500) David C. Rankin composed:
my biggest questions is just "What in the heck to do with the stuff that is in sectors 1-62 that is currently junked. We will have to work that out as well.
The first 63 sectors comprise the boot track on traditionally partitioned HDs larger than about 4GB. The last 62 of those usually contain nothing, but on occasion OnTrack Disk Mangler or EZDive or other mismanagement software might be found there on drives larger than the BIOS supported at installation time, or some forms of RAID info, or OS/2 LVM and Boot Manager info, or on Windows systems, malware. IOW, most likely anything remaining there is either unimportant or junk. If you want to preserve it for later examination, just save it to a file with dd. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sat, 11 Aug 2012, Felix Miata wrote:
On 2012/08/11 01:06 (GMT-0500) David C. Rankin composed:
my biggest questions is just "What in the heck to do with the stuff that is in sectors 1-62 that is currently junked. We will have to work that out as well.
The first 63 sectors comprise the boot track on traditionally partitioned HDs larger than about 4GB. The last 62 of those usually contain nothing, but on occasion OnTrack Disk Mangler or EZDive or other mismanagement software might be found there on drives larger than the BIOS supported at installation time, or some forms of RAID info, or OS/2 LVM and Boot Manager info,
Actually, if you install Grub(1) into the MBR, it also uses that space for its stage1.5 with the FS driver, in dcr's case MBR + sectors 1-19 inclusive.
or on Windows systems, malware.
As it turned out in this case. -dnh -- Zu schön um nicht gesiggt zu werden ;-) [Rainer Behrendt in dag°] -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012/08/13 03:24 (GMT+0200) David Haller composed:
On Sat, 11 Aug 2012, Felix Miata wrote:
The first 63 sectors comprise the boot track on traditionally partitioned HDs larger than about 4GB. The last 62 of those usually contain nothing, but on occasion OnTrack Disk Mangler or EZDive or other mismanagement software might be found there on drives larger than the BIOS supported at installation time, or some forms of RAID info, or OS/2 LVM and Boot Manager info,
Actually, if you install Grub(1) into the MBR, it also uses that space for its stage1.5 with the FS driver, in dcr's case MBR + sectors 1-19 inclusive.
As _I_ never allow anything but PC/MS-DOS legacy or compatible code in any of my <2TiB HD MBRs, Grub didn't come to mind as I was making that list. :-(
or on Windows systems, malware.
As it turned out in this case. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Sat, 11 Aug 2012, David Haller wrote:
On Fri, 10 Aug 2012, David C. Rankin wrote: [..]
What I think happened, is some corrupting information got written to the first part of sda1
Actually, your drive was repartitionend and "dummy" entries in the MBR added. As the first one points to a sector between the MBR (and apparently after GRUB's stage 1.5), sda1 is still intact but as sda2.
Actually, it turns out that that "fishy" sector actually does contain the first part of the Boot.Pihar Trojan/Backdoor, and I think some more stuff is between each EPBR and the actual partition/filesystem. https://www.virustotal.com/file/1cf12d246e9a2fbe1995034366f74aa5c892fc78a21d... I think one could "fix" the partitioning itself by just deleting the extra entry in the MBR-Partitiontable and move the real entries (now sda2/3) to sda1/2 again. The partitions and filesystems seem ok. As it is a virus/trojan/backdoor infection, I recommended dcr do best zero the disk and reinstall. -dnh -- Es kursiert ja immer noch die Behauptung, dass sendmail geschrieben wurde, weil sich jemand sein root-Passwort nicht merken konnte. -- A. Schreiber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/12/2012 08:21 PM, David Haller wrote:
Actually, it turns out that that "fishy" sector actually does contain the first part of the Boot.Pihar Trojan/Backdoor, and I think some more stuff is between each EPBR and the actual partition/filesystem.
https://www.virustotal.com/file/1cf12d246e9a2fbe1995034366f74aa5c892fc78a21d...
I think one could "fix" the partitioning itself by just deleting the extra entry in the MBR-Partitiontable and move the real entries (now sda2/3) to sda1/2 again. The partitions and filesystems seem ok.
As it is a virus/trojan/backdoor infection, I recommended dcr do best zero the disk and reinstall.
dnh, You are the wizard. I appreciate the education that this has been for me regarding how to look at the code within the various bytes of the boot sector. I still cannot begin to fully understand precisely what happened, but I think I have gotten the big picture. There is one part of this puzzle I do not understand though. What did this malware do to cause an extra partition to be created? I think I get part of that. The first 63 sector were originally occupied by grub stage1.5 in sectors 1-19. Sectors 20-63 were originally empty. The boot tract was not considered by the system to be a partition in and of itself. The original sda1 began on sector 63 and ended on sector 315291689. Whatever was inserted into the boot tract after sector 19 caused sector 29 to appear as a complete partition to the system. Even though it was of 0 length. Sector 29 had some byte within it that caused it to be identified as a partition (a new sda1) and the original sda1 became sda2. Right? However, what I don't get is what the malware hoped to accomplish with a 1 sector entry. It gets inserted at sector 29 and the boot flag points to it. Then on boot, that code is read, and presumable triggers other code resident on what is now sda2. The reason for the quandary is I can't see enough code being inserted into a single sector (sector 29) to do much at all by itself other than scramble the disk/delete files/etc... or address code somewhere else on the disk. Meaning that I can't see enough code fitting into 1 sector to be intelligent enough by itself to conduct network activities or (phone home) for lack of better words. (I admit I could be completely wrong here, but I will take that, 512 bytes isn't much room to work with) So, I won't do it, but what your are saying is I could zero sectors 20-63 on the drive, reboot, and essentially have the original disk back with the correct partition numbering and a virus somewhere in the restored sda1 waiting to strike again -- right? Thank you again for another great bit of learning. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2012-08-13 05:50, David C. Rankin wrote:
So, I won't do it, but what your are saying is I could zero sectors 20-63 on the drive, reboot, and essentially have the original disk back with the correct partition numbering and a virus somewhere in the restored sda1 waiting to strike again -- right?
Yes and no, because sda2 would still be sda2, the numbers do not shift down. The partition table is in fact a table (with four lines and fixed size and position), which task is simply to point to the start and end of space in the disk assigned to each partition. Erasing sectors 1..63 erase the contents of the partition, but not the partition itself. For that you need to use partitioning software to reassign, ie, to rewrite the table. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAlAplpEACgkQja8UbcUWM1xKLgEAkb532r6qfUaZ4HOe6H3ogGPM zZa9nhU+O/QbZk622s0A/iG2HK7KcZVLf/aTSabwmmurL2MAxBmM+la65UIGYLo2 =cURY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, Nomenclature: I'll use 'sda*' designations for the original, real partitions and "bogus" for the zero-length-one in sector 29, MBR for the boot-code in the MBR (sector 0 of the disk), MBR-PT for the partition-table in the MBR and EPBR(-PT) for the chain of BRs and partitiontables of the extended and logical partitions. See http://en.wikipedia.org/wiki/Extended_partition and esp. http://en.wikipedia.org/wiki/Extended_partition#Examples for a quick rehash of the DOS partitioning scheme. On Sun, 12 Aug 2012, David C. Rankin wrote:
On 08/12/2012 08:21 PM, David Haller wrote:
Actually, it turns out that that "fishy" sector actually does contain the first part of the Boot.Pihar Trojan/Backdoor, and I think some more stuff is between each EPBR and the actual partition/filesystem.
https://www.virustotal.com/file/1cf12d246e9a2fbe1995034366f74aa5c892fc78a21d...
I think one could "fix" the partitioning itself by just deleting the extra entry in the MBR-Partitiontable and move the real entries (now sda2/3) to sda1/2 again. The partitions and filesystems seem ok.
As it is a virus/trojan/backdoor infection, I recommended dcr do best zero the disk and reinstall.
You are the wizard. I appreciate the education that this has been for me regarding how to look at the code within the various bytes of the boot sector. I still cannot begin to fully understand precisely what happened, but I think I have gotten the big picture. There is one part of this puzzle I do not understand though. What did this malware do to cause an extra partition to be created?
It just created that "bogus" partition entry in the MBR-Partitiontable pointing to sector 29. And it probably moved the existing entries for sda1 and sda2 back by one entry (so they show up as 2/3 in Linux).
I think I get part of that. The first 63 sector were originally occupied by grub stage1.5 in sectors 1-19. Sectors 20-63 were originally empty.
Correct.
The boot tract was not considered by the system to be a partition in and of itself.
What do you mean here by "boot tract"?
The original sda1 began on sector 63 and ended on sector 315291689.
Correct.
Whatever was inserted into the boot tract after sector 19 caused sector 29 to appear as a complete partition to the system. Even though it was of 0 length. Sector 29 had some byte within it that caused it to be identified as a partition (a new sda1) and the original sda1 became sda2. Right?
No, but not far off. There is no code between Grub's last sector (19) and sector 29, just zeroes (as it should be). The virus (to keep it short and not name it too often here) just wrote 240 bytes of code to the start of sector 29 and the "Boot/partition" marker 0x55 0xAA in the last two bytes. Of course, the partition entry is "invalid", and some BRs might even check for that, but probably the DOS/Win BR doesn't and just starts the active partition (as long as it has the boot sector signature). Sector 29 looks like this in 'od -tx1z -Ax ./dcr-sda-0.img': 003a00 31 c0 8e d0 bc 00 7c 8e c0 8e d8 fc fb 60 b9 dd >1À.Ð~.|.À.Øüû`¹Ý< 003a10 00 bd 1a 7c d2 4e 00 45 e2 fa 11 61 a8 f5 07 2e >.~.|ÒN.Eâú.a~õ..< 003a20 89 01 02 1a 98 10 83 e0 03 e8 6d c7 3e 18 ef 7c >.......à.èmÇ>.ï|< 003a30 0f 00 cc 13 06 99 47 [..] [..] 003af0 e1 1b 8c 27 89 d8 [..] [..] 003bf0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa >..............Uª< ^^^^^ boot-sector-signature At offset 0x7e00 (byte 32256 of the image/disk), i.e. the start of sector 63, there's your regular NTFS stuff. Now, why did I show so much in the first block? ...
However, what I don't get is what the malware hoped to accomplish with a 1 sector entry. It gets inserted at sector 29 and the boot flag points to it. Then on boot, that code is read, and presumable triggers other code resident on what is now sda2.
... Because of the last 4 bytes shown. They probably are a address/offset (inserted while the virus installed this code) to, *tada* a place in the "free" space between the sda6-EPBR and the actual logical partition/filesystem sda6 that starts 63 sectors after it. Again, od (and bc) helps: [fdisk -l]: /dev/sda5 315291753 319195484 1951866 82 Linux swap / Solaris /dev/sda6 319195548 368017019 24410736 83 Linux 0x13069947 = 319199559 (weirdly that would be big endian here, normally, little endian would be expected). Now, where's that sector? Ah, should be in dcr-sda-319195485.img. Now, looking at that image, we find the usual EPBR: Zeroes and a EPBR-PT with 2 entries (the actual partition/filesystem entry and the pointer entry to the next logical partition in the chain): $ od -tx1z -Ax dcr-sda-319195485.img | less 000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< * 0001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 >................< 0001c0 c1 ff 83 fe ff ff 3f 00 00 00 e0 f4 e8 02 00 00 >Áÿ.þÿÿ?...àôè...< 0001d0 c1 ff 05 fe ff ff 52 86 24 03 f7 b8 48 07 00 00 >Áÿ.þÿÿR.$.÷~H...< 0001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< 0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa >..............Uª< ^^ type of partition "column" ^^^^^ boot-sig 0xAA55 0x83 = linux, 0x05 = extended -> pointer to the next logical partition But what is that? In the next sectors, there's tons of "crap": 000200 f4 62 7a 68 52 22 32 aa aa de 1e 34 ff 13 13 f9 >ôbzhR"2ªªÞ.4ÿ..ù< [..] Ok, what's the offset from the start of the image to the sector that I suspected being pointed to from the sector-29-code? $ echo 'ibase=10;obase=16; (319199559-319195485)*512;'|bc 1FD400 Ok, nope, that doesn't work out, that's inside the filesystem. Must be something/-where else then. $ od -tx1z -Ax dcr-sda-319195485.img | less [..] 008200 a0 48 17 00 9c 1e 5d 00 ee a7 04 00 58 77 0d 00 > H....].î§..Xw..< 008210 37 bc 11 00 00 00 00 00 02 00 00 00 02 00 00 00 >7~..............< 008220 00 80 00 00 00 80 00 00 e0 1f 00 00 7e 0e 25 50 >........à...~.%P< 008230 77 0e 25 50 09 00 19 00 53 ef 01 00 01 00 00 00 >w.%P....Sï......< ^^^^^ ext2/3/4 signature 008240 2f b0 7c 4f 00 4e ed 00 00 00 00 00 01 00 00 00 >/°|O.Ní.........< 008250 00 00 00 00 0b 00 00 00 00 01 00 00 3c 00 00 00 >............<...< 008260 06 00 00 00 03 00 00 00 1e 98 c6 50 9c 74 47 1c >..........ÆP.tG.< 008270 99 81 d4 29 55 2e 39 bf 72 6f 6f 74 00 00 00 00 >..Ô)U.9¿root....< ^^^^LABEL So, the target for a jmp from the sector-29 code is some other.
The reason for the quandary is I can't see enough code being inserted into a single sector (sector 29) to do much at all by itself other than scramble the disk/delete files/etc... or address code somewhere else on the disk.
Basically, that stuff in sector 29 is probably a minmal "chainloader" much like a DOS-MBR-bootcode, GRUB or rather lilo stripped down on install to just load a sector into memory and jump & execute that. This can be done in _very_ few bytes, it's just about 6 or maybe some more assembler instructions or so (4 mov's, int 13, a movl and a jmp? An untested ad-hoc version gives me 316 bytes with plain 'gas' and no optimization at all (and lots of 0x00 in the file) ;) And no, I know virtually no Assembler and even less machine-code. Just think about it: the normal DOS MBR-boot-code uses 446 Bytes and has quite a few strings and more to do to start the active partition (read partition table, find active partition, load the sector, start it, some sanity checks). Our perpetrator code just has to load a hard-coded sector, et voila. A bit like GRUB stage1 without any "fluff" like error handling which seems to take most of the stage1 "place". Just the strings for the messages take up a bit. See 'od -tx1z -Ax /boot/grub/stage1 | less' (and don't worry about the "used" partition-table in there).
Meaning that I can't see enough code fitting into 1 sector to be intelligent enough by itself to conduct network activities or (phone home) for lack of better words. (I admit I could be completely wrong here, but I will take that, 512 bytes isn't much room to work with)
See above: it uses at least 94kb (sector 29, and at least 3 times 31k between an EPBR and the actual filesystem). Probably some more in the free space after the last partition (there usually is some, up to almost 8 MB depending on geometry and alignments ;). That's probably plenty enough for that "boot" part of the virus. The actual payload (with the phone home stuff) is on the Win-partition and autostarted etc.).
So, I won't do it, but what your are saying is I could zero sectors 20-63 on the drive, reboot, and essentially have the original disk back with the correct partition numbering and a virus somewhere in the restored sda1 waiting to strike again -- right?
Just sector 29, but also the sectors between the EPBRs and actual filesystems and that after the last partition. You'd have to be very careful there ;) KIDS, DON'T DO THAT AT HOME OR ANYWHERE! ;) And move the partitions back to the right positions (fdisk -> x (expert mode) -> f (fix partition order) should do the trick). But again, I do not recommend it. I probably would do it (with vche[0] / dd / hdparm) and zero the Win-partition, but then again, I do have a lot of experience fiddling with partitions etc. and know it by heart (well, almost, it's been quite some years and the refresher now was nice ;) If you can read technical german: [1]
Thank you again for another great bit of learning.
You're welcome, -dnh [0] fsck! Yet another SW I should build and get into factory. It's a mc-alike hex-editor that can "open" devices like disks. Something where all GUI hex-editors I tested fail. [1] https://www.heise.de/artikel-archiv/ct/1997/5/188_Pfriemeln-mit-Diskedit-und... Yes it's old. But that's how I repaired a futzed EPBR with debug.com, pen & paper and a calculator for the dec<->hex stuff under Win95. And it stuck. I even could recall earlier in this mail year, issue _and_ pagenumber of that article. Doing such stuff by hand obviously makes it stick. Yes, I'd use testdisk or such now, but still check _everything_ and if in doubt use it's output to do it by hand. I should get myself a T-shirt with that stuff :) -- Real programmers use chmod +x /dev/random and cross their fingers -- Comment found in a vi/emacs flamewar on slashdot. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/12/2012 08:21 PM, David Haller wrote: <snip>
I think one could "fix" the partitioning itself by just deleting the extra entry in the MBR-Partitiontable and move the real entries (now sda2/3) to sda1/2 again. The partitions and filesystems seem ok.
As it is a virus/trojan/backdoor infection, I recommended dcr do best zero the disk and reinstall.
-dnh
dnh, I have another questions on this disk. Currently, I was going to wipe the windows partition and reinstall, leaving the linux partitions in tack as they are fine. My question is: What do I do with the stuff in the current sda1? Do I just delete sda1 and let the partitions fix themselves? Do I delete sda1 and then manually rename/number the remaining partitions? (doesn't seem logical) Do I wipe out the offending data in sda1 to remove the partition boundary and then reboot to correct the partition order? Something along the lines of: dd if=/dev/zero of=/dev/sda bs=512 skip=28 count=3 (just to catch either side of the sector 29 problem?) How is the correct way to handle this if I want to preserve the linux install? Or, is that just not worth it, so I should just fdisk -l /dev/sda and then d,d,d,d,d? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/13/2012 10:17 PM, David C. Rankin wrote:
Do I wipe out the offending data in sda1 to remove the partition boundary and then reboot to correct the partition order? Something along the lines of:
dd if=/dev/zero of=/dev/sda bs=512 skip=28 count=3
(just to catch either side of the sector 29 problem?)
How is the correct way to handle this if I want to preserve the linux install? Or, is that just not worth it, so I should just fdisk -l /dev/sda and then d,d,d,d,d?
Well, a follow-on question, I delete sda1 in fdisk and linux continues to boot fine, but the partitions are still: sda2 sda3 sda5 sda6 sda7 What is the best way to rename sda2->sda2, sda3->sda2? (or does it even matter to the windows reinstall?) still booting from the first primary, even though it is sda2?? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/13/2012 11:38 PM, David C. Rankin wrote:
What is the best way to rename sda2->sda2, sda3->sda2? (or does it even matter
Should say sda2->sda1 :) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/14/2012 12:30 AM, David C. Rankin wrote:
On 08/13/2012 11:38 PM, David C. Rankin wrote:
What is the best way to rename sda2->sda2, sda3->sda2? (or does it even matter
Should say sda2->sda1 :)
OK, I guess my explanation of what I want to do may be confusing. So basically after deleting the first primary partition in fdisk to get rid of the malware created partition, I'm left with an empty partition-table for partition 'Nr' 1 which causes the original primary partition to now appear as sda2 instead of sda1 -- even though there is nothing in partition number 1. The print partitions in (x) expert mode of fdisk shows this well: Nr AF Hd Sec Cyl Hd Sec Cyl Start Size ID 1 00 0 0 0 0 0 0 0 0 00 2 00 1 1 0 254 63 1023 63 315291627 07 3 00 0 1 1023 254 63 1023 315291690 174931785 0f 4 00 0 0 0 0 0 0 0 0 00 5 00 1 1 1023 254 63 1023 63 3903732 82 6 00 1 1 1023 254 63 1023 63 48821472 83 7 00 1 1 1023 254 63 1023 63 122206392 83 Is there any way I can get rid of the Nr 1 entry completely so that what is now Nr 2 becomes Nr1 (and that should cause sda2 to become sda1 again)?? I don't think you can do this in fdisk, but could you do this with parted by moving Nr 2 to the front of the disk? Or is this just asking for trouble? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012/08/13 23:38 (GMT-0500) David C. Rankin composed:
I delete sda1 in fdisk and linux continues to boot fine, but the partitions are still:
sda2 sda3 ... What is the best way to rename sda2->sda1, sda3->sda2?
The names are assigned according to the physical position of the entry in the partition table. "Best" is probably a matter of personal preference. Options: 1-use a sector editor and move the entries yourself 2-non-destructive delete, then recreate, at same sizes and positions as originally 3-use a partitioning utility that will rearrange the entries according to the logical disk layout or your personal preference. I have to do this with an eSATA HD that has EXT2 and NTFS partitions alternately used by STBs that only recognize one or the other of the two types, and only if it is the first entry in the partition table. The EXT2 is physically first, but I give it the second entry and the NTFS the first when necessary so that the brain dead STB can use the M$ format. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin wrote:
On 08/13/2012 10:17 PM, David C. Rankin wrote:
Do I wipe out the offending data in sda1 to remove the partition boundary and then reboot to correct the partition order? Something along the lines of:
dd if=/dev/zero of=/dev/sda bs=512 skip=28 count=3
(just to catch either side of the sector 29 problem?)
How is the correct way to handle this if I want to preserve the linux install? Or, is that just not worth it, so I should just fdisk -l /dev/sda and then d,d,d,d,d?
Well, a follow-on question,
I delete sda1 in fdisk and linux continues to boot fine, but the partitions are still:
sda2 sda3 sda5 sda6 sda7
What is the best way to rename sda2->sda2, sda3->sda2? (or does it even matter to the windows reinstall?) still booting from the first primary, even though it is sda2??
The partition # doesn't matter, it's really just an index to the partition table. I don't think WIndows cares either, but I'm not sure. -- Per Jessen, Zürich (19.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/14/2012 01:05 AM, Per Jessen wrote:
The partition # doesn't matter, it's really just an index to the partition table. I don't think WIndows cares either, but I'm not sure.
I'll report back after I get this sorted. I think you are correct, but I'm in the same boat, not 100% sure. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Mon, 13 Aug 2012, David C. Rankin wrote:
On 08/13/2012 10:17 PM, David C. Rankin wrote:
Do I wipe out the offending data in sda1 to remove the partition boundary and then reboot to correct the partition order? Something along the lines of:
dd if=/dev/zero of=/dev/sda bs=512 skip=28 count=3
Jep, that should do the trick. [..]
Well, a follow-on question,
I delete sda1 in fdisk and linux continues to boot fine, but the partitions are still:
sda2 sda3 sda5 sda6 sda7
What is the best way to rename sda2->sda2, sda3->sda2? (or does it even matter to the windows reinstall?) still booting from the first primary, even though it is sda2??
Try 'fdisk /dev/sda' -> 'f' (fix partition order). I do not know what other tools might be able to, I'd probably use vche to do it by hand ;) -dnh -- In the Beginning there was nothing, which exploded. -- Terry Pratchett, Lords and Ladies -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Sorry for the top post dnh, but I'm just attaching all the files :) I hope you see something that is useful there and I hope they all come through. If you some get stripped, let me know. You should get: -rw-r--r-- 1 david david 33792 Aug 10 20:21 dcr-sda-0.img -rw-r--r-- 1 david david 33792 Aug 10 20:24 dcr-sda-319195485.img -rw-r--r-- 1 david david 1024 Aug 10 20:21 dcr-sda3-315291690.img -rw-r--r-- 1 david david 33792 Aug 10 20:24 dcr-sda-368017020.img -rw-r--r-- 1 david david 8387 Aug 10 20:21 dcr-sda-imgs.tar.gz The last two are available here: http://www.3111skyline.com/dl/suse/bugs/part/test/dcr-sda-319195485-cyl.img http://www.3111skyline.com/dl/suse/bugs/part/test/dcr-sda-368017020-cyl.img [7.8M each] Thank you! Hello, First of all: _PLEASE_ check any commands _diligently_ for correctness, I'm quite tired now. On Fri, 10 Aug 2012, David C. Rankin wrote:
On 2012/08/10 19:02 (GMT-0500) David C. Rankin composed: [...]
The sfdisk -l information seems to point to the problem: start: (c,h,s) expected (1023,254,63) found (1023,1,1). How to repair that? [..]
On 08/10/2012 07:44 PM, Felix Miata wrote: the process. Worse case scenario, I nuke the drive and put another one it and go through the pain of reinstall.
Do you have space on another drive for an image?
What I think happened, is some corrupting information got written to the first part of sda1
Actually, your drive was repartitionend and "dummy" entries in the MBR added. As the first one points to a sector between the MBR (and apparently after GRUB's stage 1.5), sda1 is still intact but as sda2.
that is causing the partition table to see it as a separate partition. As such, it has renumbered the primary partition present sda1->sda2. Since sda1 starts on sector 29 and ends on sector 29, it looks like the answer will be along the lines of deleting sda1 and making sure sda2 ends up back as sda1.
I'd be interested to see the actual content of the MBR and the first EPBR: dd if=/dev/sda of=dcr-sda-0.img bs=512 count=66 dd if=/dev/sda3 of=dcr-sda3-315291690.img bs=512 count=66 tar czf dcr-sda-imgs.tar.gz dcr-sda-0.img dcr-sda3-315291690.img if you have time, the other EPBRs might be helpful (but the seeking is _SLOW_: dd if=/dev/sda of=dcr-sda-319195485.img bs=512 count=66 skip=319195485 dd if=/dev/sda of=dcr-sda-368017020.img bs=512 count=66 skip=368017020 and mail the .gz as PM (the gzipping is more for a simple "integrity" check than for anything else ;) Those latter 2 EPBRs are the sectors linking the "chain" of extended partitions (logical parts), as listed as Type "X" in the output of testdisk in your first mail. Compare: $ echo '19869*255*63; 22908*255*63'|bc 319195485 368017020 each logical partition starts the "head" i.e. 63 sectors after the EPBR: 6 L Linux 19869 1 1 22907 254 63 X extended 22908 0 1 30514 254 63 Bad thing is: you can't access the EPBR directly as you can the first "extended" partition (the "primary one" in the MBR, in your case now sda3). If you have no qualms of maybe mailing me actual data, you could try seeking (skipping) and reading by whole cylinders, which should be much faster: dd if=/dev/sda of=dcr-sda-319195485-cyl.img bs=8225280 count=1 skip=19869 dd if=/dev/sda of=dcr-sda-368017020-cyl.img bs=8225280 count=1 skip=22908 8225280 is 255*63*512. You could then dd out the first sectors of each image and just mail that: dd if=dcr-sda-319195485-cyl.img of=dcr-sda-319195485.img bs=512 count=66 dd if=dcr-sda-368017020-cyl.img of=dcr-sda-368017020.img bs=512 count=66 The "count=66" is for me to get the first 3 sectors of the following FS, i.e. the ext[234]/NTFS bootsector and in your case also the complete "weird" zero-size partitions. [..]
Slowly I'm learning a bit more about repair, but that nagging 'uncertainty' of "do I really want to try X" certainly hangs heavy over my head. That's why I'm hoping some smart person on the list has done this before and can point me in the right direction :)
BTDT for myself but also for others via the -de-ML ;) But I'd like to be more awake for that. -dnh -- "Windows NT has detected the following system change: Mouse has moved. Click 'OK' to reboot." -- Mike Andrews -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Carlos E. R. -
David C. Rankin -
David Haller -
Felix Miata -
Per Jessen