Re: Strange memory addresses

Kevin O'Connor wrote:
> On Sat, Apr 19, 2008 at 01:13:10AM +0100, Oliver Ford wrote:
> Wow, that is a pain.
Yes, that's exactly what I thought, but with some annoyed anger thrown in.

> It seems odd that they would do that. I wonder
> if they're actively trying to obscure what's occuring.
>
Well, if they are, they'll need to try harder next time...

To help me with all of this I've made another addition to haret. I'm not
sure how useful it'll be to other people but the patch is here:
http://www.oliford.co.uk/hpipaq214/haretChanges/0001-Initial-MMU-level-1-table-merging.patch

It makes a copy of a specified region of the MMU table when WIRQ starts
and basically watches it. Because watching every time an entry is
unmapped and remapped again would produce too much output, and adding
them to the trace buffer takes too much IRQ time, it just records when
any non-zero value appears in the table and increases the change count.
It ignores any 0s being written.

If windows is just mapping and unmapping to the same place, the change
count ends stays as 1, so you end up with a list of all the entries
windows keeps hiding. Any entry that it uses to map different things
to, you just get the last entry, and a change count > 1.

It still takes a while for it to scan the specified region of the table,
so you can only do it in about 512 entries at a time (on my system),
otherwise it crashes.

The output looks like this:

*** for things it just hides: ****

Finished restoring windows exception handlers.
MMU Merge table:
Index ( vAddr ) = Last entry x Change count
  160 (0a000000) = c3266001 x 1
  161 (0a100000) = c3266401 x 1
  162 (0a200000) = c3266801 x 1
  163 (0a300000) = c3266c01 x 1
  164 (0a400000) = c30d8001 x 1
...
**** for more dynamic entries: ****

MMU Merge table:
Index ( vAddr ) = Last entry x Change count
 5620 (5f400000) = 0c16f260 x 14
 5621 (5f500000) = 85e97f40 x 13
 5622 (5f600000) = 8034d350 x 12
 5623 (5f700000) = 8000934c x 4
...
*******************************

I can now find where it plays with registers by...

a) Search the whole of phys mem for what looks like an L2 entry pointing
at the register (eg. 0x40b00ff2)
b) Look for that L2 table in the merged L1 table.
c) Work out what the MVA will be that points at the register.
d) Use the PXA trace to watch that MVA, which gives me the (hidden) MVA
for the code.
e) Look up the code MVA in the merged table and find the phys address.
f) WinCE has a second set of entries, which are permanent and in the
same order as the hidden ones. Find this and use this vaddr to dump the
program's working space to disk.
g) Dissassemble
h) cry

It's a little tedious, I'll think of a way of automating some of it if I
can.

>> Unfortunately the pxa tracing output seems to crash haretconsole. I had a
>> quick look at the code but I'm not at all fluent in python so I've pasted
>> the crash below as well its log file.
>
> Sorry, looks like a bug in haretconsole. It happens only when objdump
> is not found. Should be fixed in latest CVS.
Excellent, thanks. Makes life a lot easier.
(I had actually seen that and applied it before I got this e-mail)

Thanks for your help,

Oliver
Received on Sat Apr 19 2008 - 13:48:58 EDT