I think you'd be better off using an encoded memblock image. Like, if your fighter sprite is on a single sprite sheet, you could use a lower resolution version, coloured to highlight the different parts of the body. For example, the head might be red, weak parts of the body green, strong parts or defending parts blue. Then, once you have that collision point(s), you can check the enemy sprite frame on the memblock, check the colour of the pixel, and know exactly where the hit landed.
You don't have to use a memblock, you could use an array with a fixed resolution of say, 32x32 (should be accurate enough).
Doing it this way means you have total control - when the fighter is moving, jumping for example, you might want to make the collision data mostly green, to signify that the fighter is vulnerable, then when the fighter is defending, then the arms for example could be blue, so you can tell when the hit was on a defended part of the body. You could even use this for full collision, rather than using box2D polyline based collision, you could cross-reference the sprites to detect hits - with the number of checks needed for a 2D beat-em-up, and a 32x32 area on each sprite, it shouldn't be a big deal for performance.
One issue that I would worry about, is how effective box2D is at changing the sprite collision shape - the default just wouldn't have enough polylines to do a decent job, so you'd have to add your own polyline 'shield' for each frame. Personally, I'd go for the colour coded 32x32 sprites, I think it'd be easier in the long run and more accurate. You could even have key points on the collision that generate blood particles when hit - like the mouth and nose. With the level of control that this method would afford you, there's a lot of cool stuff you could do - have attacks that use any part of the body, knees, headbutts, both feet at once, because it can be controlled with the collision data to an exact degree.
I got a fever, and the only prescription, is more memes.
