commands/patchdata/patchdata.cif
author Tom Sutcliffe <thomas.sutcliffe@accenture.com>
Thu, 21 Oct 2010 22:32:59 +0100
changeset 73 dc41da2f70a4
parent 0 7f656887cf89
child 87 63fd51b1ff80
permissions -rw-r--r--
Added showdebug command. Also: * Added an exported constructor to RChildProcess so the iProcess handle was set to zero on construction. * Fixed bug in fshell_builddocs script that created HTML relative links with backslashes instead of forward slashes.

# patchdata.cif
# 
# Copyright (c) 2010 Accenture. All rights reserved.
# This component and the accompanying materials are made available
# under the terms of the "Eclipse Public License v1.0"
# which accompanies this distribution, and is available
# at the URL "http://www.eclipse.org/legal/epl-v10.html".
# 
# Initial Contributors:
# Accenture - Initial contribution
#

==name patchdata

==argument string dll-name optional

The DLL to examine for patchable data. If not specified, list some system-wide well-known patchable constants.

==argument int ordinal optional

The ordinal of the patchable constant to examine. This should be the number from the DEF file, ie it is one-based not zero-based. If not specified lists all the data exports in the DLL.

==argument uint value optional

Set a new value for the given ordinal. If not specified, just lists the current value.

==option bool v verbose

Display verbose information when scanning for exports.

==short-description

Examine the patchable data for a DLL.

==long-description

If no DLL is specified, print various common patchable constant data values. If a DLL is given but no ordinal number, all exports that look like patchable constants are listed. For DLLs in core (xip) ROM, you'll generally see more false positives than ROFS DLLs.

Patchdata can optionally modify the value of a given patchable constant, but there are certain caveats in doing this: Overall the technique used is slightly hairy, use at your own risk: it will not work for DLLs with sparse export tables (generally this means DLLs with lots of exports and/or ABSENT exports); it may appear to work but in some situations code will continue to use the unpatched values (patching EXEXPs used in startup, ECOM plugins that have already been cached, and anything else that hard-codes loading DLLs from a particular drive). Patching a DLL that is in core (xip) image will only persist until the next reboot, but on the plus side most of the other caveats don't apply.

==copyright

Copyright (c) 2008-2010 Accenture. All rights reserved.