IDiff/IDA/imgdiff.xml interpretation of variables like %30%, etc.

[Kevin Bulgrien]

Per message DUA interaction with EWF posted last July (with no responses):

http://groups.google.com/group/micr..._frm/thread/56e825c5b07c6abf/d42424bd4610aa63

A solution for using IDA on our embedded system is not known yet, so to
bridge the gap we have a small XSLT script that converts the idiffout.xml
into a DUA script, but we need to tune the script and IDIFF.IN file to
improve results for our system. When looking at idiffout.xml and IDIFF.IN,
many references to numeric environment variables like %30%, etc are found.

IDIFF and IDA seem to have some shared knowledge about these environment
variables as there is no apparent cross-reference I have found, so I have to
look at existing entries in IDIFF.IN and guess what to use.

Is there a reference for these variables that I have not stumbled across?

 

[Srikanth Kamath [MSFT]]

I have created several builds that have DUA and EWF. However, when I

run IDA using a Device Update Script, it always blows away any data
about my EWF volumes. After applying an update using IDA, any queries
of ewfmgr return an error saying there are no EWF volumes.

Are you using EWF in RAM mode or Disk mode ? In both these modes, EWF
configuration information (such as which volumes are protected etc) is stored
in a separate partition (with partition type = 0x45). This partition type is
most likely not recognized by IDA which is why it ignores it. If this
partition is missing ewfmgr will fail to obtain configuration info.

Did you try using EWF RAM REG ?

Thanks
Srikanth

 

[Kevin Bulgrien]

Are you using EWF in RAM mode or Disk mode ? In both these modes, EWF
configuration information (such as which volumes are protected etc) is stored
in a separate partition (with partition type = 0x45). This partition type is
most likely not recognized by IDA which is why it ignores it. If this
partition is missing ewfmgr will fail to obtain configuration info.

Did you try using EWF RAM REG ?

Srikanth,

We use EWF in disk mode, and no, we did not try using RAM REG. When the
system was designed, we wanted to be sure we were not using up RAM that
is needed by the application. Due to tight scheduling, I have not revisited
the
issue to understand what the implications are to the system design, but plan
to do so when I can find more information or have time to experiment myself.

I do not understand why the EWF partition would be missing unless IDA.EXE
itself corrupted it, or some registry entries dealing with it, which I guess
could be possible. Do you have more hints as to what I should look for?

IDA and IDIFF should not care about the EWF partition as we always have it
flush on every boot, so the C: drive should always contain the proper image
to analyze for differences. The only time we ever commit the overlay is
after an update succeeds, and updates only occur at boot time.

In any event, our XSLT cannot produce a working .dus without knowing how
to remap the %number% variables. As I had to create an update already
without these tools working for me, I wrote yet another custom script based
on MSYS diff -qr to produce a difference report of the two disks, and then
generate a DUA script based on that. I then merge the results with the
registry operations defined by the idiffout.xml file as produced by our XSLT.

I also made an error in my prior question. I meant "tune the IDIFF.XML"
file rather than what I wrote (IDIFF.IN).

 

[Sean Liming]

MSDN and the online help list the Predefined System Environment Variables:

http://msdn.microsoft.com/en-us/library/ms933062(WinEmbedded.5).aspx

--
Regards,

Sean Liming
www.sjjmicro.com / www.seanliming.com
Book Author - XP Embedded Advanced, XP Embedded Supplemental Toolkit