Memory readability in .NET CF / datasets

  • Thread starter Thread starter wendelborg
  • Start date Start date
W

wendelborg

Reviewing application security on Windows Mobile I am wondering about
memory readability in .Net CF, especially when it comes to datasets.

Memory access is protected in some ways through .Net, but it is still
possible to use tools like Remote Heap Walker to browse through. Are
datasets encrypted in memory or directly readable? We have so far not
been able to find any remains of our test datasets, but plain strings
seem to exist in clear text.

A side question is if there are any other tools for dumping memory or
searching for certain strings.

All help will be appreciated.

Best Regards,
Tommy Wendelborg
 
CE isn't a secure system. The GCHeap is in shared memory and any process
has rights to read that space, so anything can search the upper address
space and read from it. It is definitely not encrypted. If you need your
datasets to be encrypted, then you must do it yourself.
 
Thanks a lot for the answer, which confirms our suspicions.

Would you say it is possible to reconstruct a dataset or extract the
data with normal tools?
 
No. I think 99% (or more) of developers, especially managed developers,
would have no idea how to even begin to scrape memory for data like that.
Of the few that would, how many would take the time? Maybe 1%? Now look a
the fact that a DataSet is likely held in a b-tree, so it's going to be lots
of leaves and pointers going all over the place, so unless you had a very
good understanding of how it works underneath (and that's not documented
anywhere) then you'd have to reverse engineer it. How many have the skill
to do that? Another 1%? And how many would have the desire and time to do
it? Again, maybe 1%? So you're at 1% of 1% of 1% of 1%. Unless you have
some severly sensitive data, I can't imagine it's a problem. If you do,
then you're likely running in an environment that has all sorts of other
security manadates, and I doubt this is an issue.

So the short answer is it's highly unlikely that anyone could or would get
the data, and the time spent to encrypt it and the perf hit for doing so is
probably not worth it.

If you really want to do it, the best route is to write a native file system
filter, and have it encrypt all writes to a specific folder, and put your
database there. Can't be done in managed code, but it will be the best
perf, the best security, and the simplest to implement without bugs.
 
Thanks again for a brilliant answer.

Using Rapi tools by Willem Jan Hengeveld and a hex editor we were able
to extract rows from the dataset, but related rows were nowhere near in
memory.

I guess it could be a good idea to separate information that should not
be easily related in separate tables. For instance separating names and
addresses, if the two fields together potentially should make a threat.



Tommy
 
Back
Top