On Mon, Nov 13, 2006 at 03:17:31PM -0600, Arrakistor wrote:
> Until an official doc is produced for helping users compile and
> understand the choice that were made, the answer to all your questions
> is here: http://www.torrify.com/forum/viewtopic.php?p=1800
I was also interested in the answer to these questions, so I tried out
Torpark under Virtual PC[1] and with Process Monitor[2] running to see
what really happened. In some cases it doesn't quite match your
documentation. This was a fairly cursory examination, and it certainly
isn't complete so please correct me if any of my points are incorrect.
In [3] Arrakistor wrote:
> It does not use the swap file on the host drive unless there is not
> enough physical memory, for which then windows resorts to swap.
This isn't quite how modern operating systems work. As the hard disk
is so slow compared to main memory, operating systems will
aggressively page unused data to swap, and use main memory for disk
cache.
To test this I ran Torpark with a fairly generous amount of RAM
(512MB). Although RAM never ran out, there was significant swap file
usage (even idle, it used 149MB swap). On reboot, the pagefile.sys
file contained 2367 mentions of "Torpark". These were mainly
filenames, but also contained user data. For example:
"E:\Torpark 1.5.0.7\App\tor\data\cached-status\7EA6EAD6FD83083C538F44038BBFA077587DD755"
"ushCircuit 1.1 - Flush the tor circuit on port 9051 (Torpark): Installing"
> That is a windows issue I cannot yet control, but I will definitely
> look into dealing with it.
This is indeed a tricky problem to deal with, but in the mean time,
perhaps you should clarify the <meta description> on the Torpark
homepage.
"[Torpark] leaves no track, is small, portable, and costs nothing."
Leaving traces behind may be unavoidable, but making users think that
it does not could lead to them facing problems. Some more examples are
continued later.
> Use NoScript to intercept Java, Javascript, and Flash.
In prefs.js, I noticed the following line:
user_pref("capability.policy.maonoscript.sites", "... mozillazine.org
noscript.net torpark.nfshost.com ...");
If I understand it correctly, this exempts your site from the
Javascript blocking. Is there any particular reason for this? I'm
certainly not suggesting any malicious intent, but DNS does get
spoofed, domain names do get hijacked, court orders do get passed and
XSS vulnerabilities do get found.
If there is no convincing reason for exempting certain sites from
Javascript blocking, prudent defence in depth principles would dictate
that they not be exempted. This also applies to the noscript and
Mozilla sites.
> It does not currently add any lines to the registry.
It creates at least 3 ones which are persistent after reboot, but
there might be more that I missed.
Process monitor shows Torpark, Flushcircuit and Firefox trying to
create a large number of entries in the registry, but many already
exist, created presumably by Internet Explorer or Windows itself. For
example:
RegSetValue
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{eba32d83-4625-11da-89de-806d6172696f}\BaseClass
RegSetValue
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ZoneMap\UNCAsIntranet
RegSetValue
HKCR\TypeLib\{1EA4DBF0-3C3B-11CF-810C-00AA00389B71}\1.1\0\win32\(Default)
Flushcircuit also creates several keys like this one, but they do not
survive a reboot:
RegSetValue HKLM\SYSTEM\ControlSet001\Control\Session
Manager\PendingFileRenameOperations
One registry key that Firefox creates that is new, and survives a reboot is:
RegSetValue
HKCU\Software\Microsoft\Windows\ShellNoRoam\MUICache\E:\Torpark
1.5.0.7\Data\torpark\profile\extensions\{65f3d609-18c1-4f62-bcef-1973b6abeab4}\flushcircuit.exe
There are similar ones for Firefox itself and Torpark.
> It only touches the drive where it is run from, and the RAM of the
machine it is running on
It creates a number of files, on the hard disk, which remain after
reboot.
Some temporary files from Nullsoft installer are left:
Documents and Settings/<username>/Local Settings/Temp/nst4.tmp
Documents and Settings/<username>/Local Settings/Temp/nszB.tmp
Also there are these files used by the Windows task scheduler to
optimise future application loading times[4]:
WINDOWS/Prefetch: FIREFOX.EXE-07686B34.pf
WINDOWS/Prefetch: FLUSHCIRCUIT.EXE-129F88FF.pf
WINDOWS/Prefetch: TORCIRCUITSTATUS.EXE-2E679AC0.pf
WINDOWS/Prefetch: TOR.EXE-29FB7B10.pf
WINDOWS/Prefetch: TORPARK.EXE-18DD2E51.pf
WINDOWS/Prefetch: TOR_RESOLVE.EXE-2BA063E1.pf
The Nullsoft installer also creates this file in the system directory:
WINDOWS/system32: gdiplus.dll
Although Torpark includes its own profile, Firefox still creates one
here:
Documents and Settings\<username>\Application Data\Mozilla\Firefox
This only contains pluginreg.dat.
A large number of files are also modified, but I haven't gone through
these to find out which are by Torpark and not parts of Windows.
This is only a start, but I hope this information will be of some help
towards producing a comprehensive and accurate analysis of Torpark and
its components.
Thanks,
Steven.
[1] http://www.microsoft.com/windows/virtualpc/default.mspx
[2] http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/processmonitor.mspx
[3] http://www.torrify.com/forum/viewtopic.php?p=1800
[4] http://msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/
--
w: http://www.cl.cam.ac.uk/users/sjm217/
Attachment:
pgppfBswg47np.pgp
Description: PGP signature