Skip to Content

Got Me

Posted under Other Technology at . Last updated 2022-07-24 02:52.
Tags:security, software, hardware, drive

got U

I’m trying to work out what happened to someone’s disk. This is one of a rotating pair of external drives used to backup an Ubuntu laptop. One of the pair, Backup 2, failed to mount the other day. I confirmed the problem and ran a backup to Backup 1. I now think that may have been a mistake, but we’ll see.

I tried fsck from the administrator account with no result, but noticed along the way that Backup 2 is seen as a single exFAT partition, which seems a little odd as I’d have expected ext3 or ext4.

Switching over to an OSX laptop where I have a better range of tools to hand, I can confirm that it reads as GUID/exFAT. But a look at it with a sector editor is puzzling. I see nothing in sector 0. Moving on to the sector 1 I have what looks like an EFI header so that should be fine. Sector 2 seems to be part of the same system. And I went back to 0 but this time scrolled down. That helps.

0x1c0  0100eefe ffff0100 0000ff67 6f740000   ........ ...got..
...
0x1f0  00000000 00000000 00000000 000055aa   ........ ......U.

Well, that don’t seem right. I haven’t had to do this sort of thing on anything other than APM drives since before GUID partitions came along, so I’m unfamiliar with some of the detail but I think the final U. (55 AA) is normal. But I’ve got bad feelings about got. So I’m starting this note.

Some checking online seems to confirm the point.   The 0x1c0 line should start in the middle of an EFI partition address (0100EE may be valid) [1], followed by FFFFFF indicating a larger disk than the CHS address system could deal with (which I think this is) [2], followed by 01000000 for the GPT partition header at LBA1, followed by the device size or FFFFFFFF again if too big. Clearly not what we have here.

Now I think — is this a virus rewriting the boot sector, and if so, did I do the same thing to Backup 1 earlier?

This is a system which doesn’t get operated with maximum security settings (no scripts) because the user can’t quite cope with it. So a website doing something isn’t impossible. Maybe Ubuntu is not immune?

Looking again at the EFI partition, it also has got written into lines 0x20 and 0x30, the AlternateLBA and LastUsableLBA sectors. Got U twice?

Funny thing is, OSX thinks this is a perfectly good but empty exFAT volume.

Also, discussing this with the system user, I’m told Backup 2 has not in fact been used previously, so it should be fairly empty save for ext4 formatting. And I see nothing on it anywhere.

Except, no — now I look, the last sector does have what I expect is a backup of the EFI sector. This is sector 1953458175. Which in hex is 0x746F67FF. Which I recognise . . . That’s the big-endian way of writing FF676F74, translated in my sector editor as .got.

I see. This is a slightly less-than 1TB drive. (My memory was faulty — the MBR limit is 0xFFFFFFFF sectors, usually meaning 2 (binary) terabytes.) In fact, it’s 931 (binary) gigabytes, a number with no obvious relationship to anything. [3] And it turns out Ubuntu doesn’t read exFAT by default, and this wasn’t even formatted for use.

Well done, Western Digital. You got me.


Comment or Question about this page?write


Notes

  1. Update: I’d have expected it to be 0200EE though?  
  2. Update: Well, FEFFFF is one byte (little-endian) less than 16 (binary) megasectors, typically an 8(binary)GB drive. But I thought it should indicate anything larger with FFFFFF? This is the original Western Digital formatting . . . it is of course likely that they know something I (and the references I’ve checked) don’t?  
  3. OK technically it’s the next binary gigabyte down from one decimal Terabyte, a few hundred megabytes short.  

Article text ©2022 Electropict Creative Commons Licence.
Click images for individual licences.


next post: Red Dock
older post: A Spotter’s Guide to HIPs and Strings

mastodon link