Mailinglist Archive: opensuse (770 mails)

< Previous Next >
Re: [Summary/Solved] Re: [opensuse] Partition Recovery? Is it even missing to begin with or just shifted?


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 and esp.
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.

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.
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

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.


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


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ª<

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.
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

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....<

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

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 ;)


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,

[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.

Yes it's old. But that's how I repaired a futzed EPBR with, 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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >