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