hard drive - Raw reading USB mass storage or SCSI

Wife's USB HDD has a slight issue where a folder refuses to open (NTFS filesystem). I have been able to image the drive with Linux but for one sector (sectors are 4096 bytes). Reading that sector fails:

sudo dd if=/dev/sdb of=block skip=21647245 bs=4096 count=1
dd: error reading ‘/dev/sdb’: Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 22.9317 s, 0.0 kB/s

Replacing this sector with null bytes leads to the same symptom as in Windows, so the sector seems to be related to the problematic directory.

When accessing said sector dmesg output reads:

[20381.842495] sd 7:0:0:0: [sdb] Unhandled sense code
[20381.842506] sd 7:0:0:0: [sdb]  
[20381.842510] Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
[20381.842514] sd 7:0:0:0: [sdb]  
[20381.842517] Sense Key : Hardware Error [current] 
[20381.842531] sd 7:0:0:0: [sdb]  
[20381.842535] Add. Sense: No additional sense information

[20381.842539] sd 7:0:0:0: [sdb] CDB: 
[20381.842542] Read(10): 28 00 01 4a 4f 8d 00 00 01 00
[20381.842557] end_request: I/O error, dev sdb, sector 173177960
[20381.842572] Buffer I/O error on device sdb, logical block 21647245

Is there a way to read this sector, raw, without CRC checking or whatever to actually try to recover some of the corrupted data?

I opened the enclosure: the HDD is native USB, no USB to SATA conversion.

Edit:
Tried ddrescue, but has not been able to recover the bad sector either. Reading 2Gigs around the bad sector the let the heads stabilize after the seek:

sudo ddrescue -s 2Gi -o 0 -i 87593373696 /dev/sdb blkk
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued:     2147 MB,  errsize:    4096 B,  current rate:        0 B/s
   ipos:    88667 MB,   errors:       1,    average rate:    8488 kB/s
   opos:     1073 MB, run time:    4.21 m,  successful read:    1.06 m ago
Finished

Reading backwards (-R flag) failed too.

Edit 2: My planned second step was to use forensics to try to get the missing files. I first started looking at the MFT by hand, but this quickly gets very, very tedious. So I had the following tools on my list:

1. the Sleuthkit


2. ntfs-3g



3. scalpel


4. scrounge-ntfs

The Sleuthkit would not do anything useful, quitting very early complaining about errors in metadata structures.

With Ntfs-3g (now Tuxera) it is possible to mount the image with debug output:

sudo mount -o loop,ro,offset=258048,debug image2 ./mnt -t ntfs-3g

Trying to enter the faulty directory would trigger an error:

Index buffer (VCN 0x0) of directory inode 101874 has a size (24) differing from the directory specified size (4096).

Looking for that error in DuckduckGo lead me to the following post:
http://www.tuxera.com/forum/viewtopic.php?f=3&t=27054

It turns out that the people at Tuxera / ntfs-3g actually encourage the use of Microsoft's CHKDSK to recover NTFS errors

Running chkdsk on the disk was my third and last planned step, however it should be tried much earlier knowing that it CAN be run on a disk image, using for example OSFMount (http://www.osforensics.com/tools/mount-disk-images.html).

Most of the missing files and directories (if not all) have been recovered by chkdsk /f on the mounted disk image. More than a hundred errors (most of which being orphaned files) have been fixed.

Edit 3: I am accepting psusi's answer. Although not proved to be impossible, trying to read the bad sectors is certainly the most uncertain and difficult route for recovering data from a mildly damaged HDD.

Answer

No, it isn't possible. There is a SCSI command to do this, but you would still only be getting garbage, and it isn't supported on consumer level drives, especially not USB. Whatever was in that sector is gone.