Hacking the Assembly Manifest

EltonStoneman — Wed, 11 Mar 2009 22:44:28 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

I was debugging a particularly nasty problem and found myself wanting to edit the manifest of a compiled .NET assembly, to change the version number of the assemblies it was referencing. Not necessarily best practice, but in this case it would enable me to confirm the exact issue without a two-hour build-and-deploy cycle. Turns out that nasty hacks like this are very straightforward:

Run ILDASM, open the assembly and choose File…Dump to extract the IL
Open the IL file in Visual Studio and edit the manifest – in this case, the version numbers of the referenced assemblies are easily found at the top of the file:

// Metadata version: v2.0.50727
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4..
.ver 2:0:0:0
}
.assembly extern x.y.z
{
.publickeytoken = (E4 21 0D 54 23 66 A2 B4 ) // . .D'f..
.ver 1:0:9:12
}
Save the IL and reassemble it with ILASM – if the assembly was signed, re-sign it using ilasm /DLL x.y.z.il /KEY=x.y.z.snk
Ensure the new assembly has the same name as the original, and it will operate as an exact replacement, only now its dependencies will be for the modified versions.

Simon McEnlly's article on CodeProject describes going further with the manifest to change the visibility of methods, and generally modifying and rebuilding assemblies where you don't have the source code. Note that if the assembly is signed and you don't have the strong name key to re-sign it, the modified assembly will warn about being tampered with and won't load.

Debugging SOAP messages with WireShark

EltonStoneman — Thu, 29 Jan 2009 14:37:44 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

If you're debugging Web service calls, you may want to capture incoming requests so you can see exactly what's reaching the service. If BizTalk's hosting the Web service, it's a simple process of adding a FILE send port filtered on the receive port name to copy all incoming messages. If this isn't an option, or if you want the full SOAP envelope together with metadata about the call, you can use a packet sniffer.

Packet sniffers monitor traffic over a machine NIC, and show you exactly what was sent or received over the wire. An excellent, free tool is WireShark (previously "Ethereal"), which has an rich suite of functionality, but has a bit of a learning curve. To use it exclusively for SOAP debugging is a matter of correctly configuring filters.

Run WireShark on the machine hosting your Web service. Open Capture…Options (screenshots below are from version 1.0.5). You'll be shown all the NICs on your machine, select one (it may be trial-and-error to pick the right NIC if you have multiple cards on a server) and configure it as shown:

The key options to set are:

Enable network name resolution (makes identifying traffic much easier)
Capture Filter = tcp port http (this captures TCP packets over default port 80).

Specifying a Capture Filter limits the amount of traffic logged, but isn't necessary if you're not using the default port, as you can also filter results. Click Start and send some calls in to your Web service. Note the capture only operates over the selected NIC, so calls to localhost won't be recorded – you'll need to make requests from a separate machine. You'll see the network traffic building up in the results pane:

Source and Destination will show the names of the communicating machines if WireShark has been able to resolve them, IP addresses if not. Enter a filter of xml and only packets representing XML exchanges over HTTP will be shown. It's simple to identify the service calls as they will be listed as POSTs to the service endpoint. Note that these are individual TCP packets. WireShark can reassemble all the packets in an exchange to show the full conversation – right click one packet and select "Follow TCP Stream".

The full stream will be shown, and can be converted between known formats or saved. The stream includes metadata information on the exchange and the full SOAP envelope:

POST /ESB.ItineraryServices.Response/ProcessItinerary.asmx HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3053)

Content-Type: text/xml; charset=utf-8

SOAPAction: "http://microsoft.practices.esb/Process/SubmitRequestResponse"

Host: itinerary-service

Content-Length: 1635

Expect: 100-continue

Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<soap:Header>

…

<soap:Body>

…

- in this case, a request to the itinerary service from Microsoft's ESB Guidance package, capturing the full itinerary in the header and the service payload in the body. Any response sent to the caller will also be shown.