Invalidation of the supposed evidence of hd file tampering [ The malignant cult nxivm (K.Raniere) ]

1. Background information + summary:

Several people who were in nxivm, have tried in Oct. 2020 to invalidate evidence that was used to convict its leader Raniere (it's strange that it took far more than a year after the conclusion of the trial to finally sentence him, I don't know how this works and why this is done in the USA, but that is another matter). I had a look at the evidence in the report by an 'expert' ca. 26 Oct. 2020. I thought about options and the expert's analysis made sense except something was missing, the intermediate PC. The next day I wrote down my solution for the time differences in a text file. I didn't post yet, did other things and as I wanted to be sure that my analysis was correct I later installed XP in a VM in VirtualBox to do a test.

I found that some claims in that report about incorrect statements by the prosecution (i.e. the US government) were correct but not important, such as in the report about an external hard disk with nude photographs of an underage girl, the government's claim that it was hard to change EXIF information in image files is not true, and this is indeed not hard if you find an editor to specifically do that. In my view that the government stated this is hard, was for/about the average person who will need to install a specific program for it, and so this was not lying, just not true for experts.

The more interesting point is that the files on the external hard disk have time differences with corresponding files on the camera card of -1h, -2h, and 0h. The 'expert' comes to the conclusion that this indicates government tampering to convict Raniere, which would have needed many time zone changes within minutes or were caused by incorrectly setting file attributes for about 90 files (files 43-137). Both cases would mean that the files were altered and that likely the pictures were planted.
[ Note: When copying files by doing a recursive copy of directories, files generally do not get copied in order of file names, but usually in order of internal directory structure and the order there is affected by deleting and moving files. There may be other reasons, related to other aspects of the stored structure of the filing system on the disk. Such internal factors are why the order of creation of the intermediate copies of the images on the PC will not have been that of the camera's image card (from which individual images can be deleted on the camera or via the PC creating empty places in the directory that are later filled) and why on the external hard disk it is not he same as the order on the PC and thus also not of that on the camera's card (even if copied directly from camera to external hard disk), and thus the order of creation of files on the external HD is not the same as the creation date of the pictures. This different order of copyig is why when assuming no intermediate filing system, there would have been many time zone changes needed or altering of file attributes manually. ]
I thought about time diffferences that I experienced copying files in the past (e.g. between FreeBSD and win98/XP) and that time zone settings can affect this, and I started thinking about the causes here, and found it odd that the 'expert' didn't take intermediate copying into account as a possible factor. I show in my analysis below that when taking into account the intermediate PC with time zone aware filing system and 2 time zone changes, the time differences can be replicated, and I have a simple explanation as to why there were time zone changes: Manually changing the time zone to account for winter time, first incorrectly (+1h), then correctly (-1h) (note that there are reasons for changing to winter/summer time manually such as related to dual booting). This means that there is no indication for tampering from the file times, which then also means one cannot assume the single file that was altered in its 'last modified time', as being an indication for tampering by anyone else than Raniere himself.

Compared to the submitted comment, I made a few additions/clarifications, some are additional to clarify matters, and others I originally wanted to include but removed before submitting as I felt the comment would become too long, and these 2 types are both shown marked in this style of black on yellow: additional comment

2. Invalidation of the supposed evidence of hd file tampering and of Raniere's phone not being 'switched off':

I had a look at this report and this guy Kesheva Munegowda is a moron. There is no need to assume tampering.

a). About time changes: I will show that the following accounts for those changes:
a.1) Copying the files piecemeal to the PC, with a the PC running XP on NTFS
a.2) Time zone settings changed 2 times to change to winter time, first incorrect (+1h), then a day later this was corrected to the correct one (-1h),
a.3) copying all files from the NTFS filing system on the PC to the external hard disk in one go [ Addition: The files on the external HD have file creation times all close together so they must have been copied in a batch ] some time after all files have been on the PC.

I presume the PC used was running XP as the photos were from 2005, and possibly summer/winter time were not set automatically (it is optional...). As XP normally uses NTFS this means that in that case times/dates on its filing system are stored in UTC, not local time.

[ 2020-11-2: Here is some additional background information that I originally wanted to include in the post but removed trying to make it shorter. But I think it will be useful to include here for a better understanding:
XP normally uses NTFS. NTFS stores times in UTC. UTC doesn't change with summer/winter time.
- current-local-time = UTC-time + current-tz-correction. So for example if current-local-time = 15:00 and UTC-time = 2:00, then current-tz-correction = 13:00
- NTFS-stored-time = UTC-time = current-local-time - current-tz-correction. In case of the example this is: 2:00 [ this method to calculate the internally stored time applies to NTFS-last-modified-time, NTFS-creation-time etc. ]
- to display this information or to copy the file (to a non-UTC filing system) the system uses as the file's time: NTFS-stored-time + current-tz-correction (= current-local-time).

As FAT16 on the camera card and FAT32 on the external hard disk do not have time zone data, when copying to/from them XP treats these filing systems as having local time (this means a time conversion takes place). Copying will without doubt not have been done directly from card to external disk but first to PC so onto that NTFS filing system, then at some point after the tz is changed the 2nd time, to the backup disk. This means photos are copied in several batches, per day, or whatever was convenient, to the PC's hard disk which was almost certainly formatted as NTFS. Copying means: FAT16 local time is translated to NTFS internal time, which is later translated to FAT32 local time on the external hard disk. When copying to external disk, local times are written as those actual local times, converting them from NTFS using the time zone of the PC, and that means using the time zone at the time of copying! (not the [ time zone at the ] time of copying onto the PC!) This means FAT-16 time - current-tz-correction = ntfs-internal-time, then later all the files are copied to the external hard disk, using the THEN current local time, i.e. with a possibly different 'current-tz-correction', if the tz was changed!: FAT32-time = ntfs-internal-time + current-tz-correction! So 'current-tz-correction' is variable, and is different for all 3 batches because of changing the time zone!

The following procedure explains the time differences:

1) The first batch of files from 43-126 are copied (not necessarily in one go, but likely piecemeal whenever interesting photos were made) to the PC [ ntfs-stored-time = fat-16-time - tz-correction1 ],
2) the tz is changed on 2005-10-29 on the PC, with clock going forward, which is a mistake,
3) more files are copied (127-137) to the PC which must have happened between the 2 changes of time zone [ ntfs-stored-time = fat-16-time - tz-correction2 ],
4) the same or next day (2005-10-29 or 2005-10-30) the time zone mistake is discovered and tz is changed with the clock/TZ going backward (i.e. -1h from the first batch, -2h from the 2nd batch),
5) more files are copied to the PC (not necessarily in one go, same as before) [ ntfs-stored-time = fat-16-time - tz-correction3 ].

All files listed are on the PC at some point in time after 2005-12-30 (last photo date of the files listed), and at a point after this date the whole batch of photos that were originally almost certainly copied to the PC piecemeal from the camera (which is normal, I do this too when copying photos from my camera), were later copied in one go to the external hard disk. When you check what happens with the converted times written on the external hard disk with the formulae I gave above, you then see that they now give exactly what the data shows (time differences of -1h, -2h, 0h respectively [ compared to the original (camera) disk that is FAT16 formatted ]).

[ 2020-11-5: I was thinking of adding an explicit calculation of the results but in the end to keep the original comment from not being too long, I didn't. But here it is, it may make things more clear:
So you can now calculate the FAT32 file times that the files will have when copying them to the external hard disk at a date after the lat file in the 2nd batch is copied to the PC, while still in the last used timezone, i.e. with tz-correction3 and note that ntfs-stored-time is different per batch in having a different current-tz-correction to determine the UTC-time=ntfs-time):
Note that: tz-correction2 = tz-correction1 +1, tz-correction3 = tz-correction1 -1:
batch 1: FAT32 time = ntfs-stored-time + tz-correction3 = (fat-16-time - tz-correction1) + tz-correction3 = fat-16-time -1
batch 2: FAT32 time = ntfs-stored-time + tz-correction3 = (fat-16-time - tz-correction2) + tz-correction3 = fat-16-time -2
batch 3: FAT32 time = ntfs-stored-time + tz-correction3 = (fat-16-time - tz-correction3) + tz-correction3 = fat-16-time +0
].

By the way, there are other possibilities that can mess up your times/dates of files, such as when dual booting operating systems (Long ago I used XP + FreeBSD, these days only FreeBSD), and so I switched off any time automatic time changes in windows. Such issues may be a reason to switch off clock changes in windows and to then change timezones manually. I don't know the exact reason why it was done on that PC, but my explanation of an incorrect time zone change to adjust for winter time then back to what it should be, is simple, logical and doesn't need any conspiracy theories.

Just to check that all the above is correct, I ran XP within a VM (using virtualbox) on my FreeBSD PC, as my old PC with XP/FreeBSD doesn't have a monitor at the moment.

So I have XP running from an NTFS formatted filing system (C:), then a FAT16 disk (E:), and a FAT32 disk (F:). Timezone was GMT+1.
1. With Notepad I made 6 files om the FAT16 disk called test1.txt - test6.txt, with time stamps all being 5:25.
2. I copied the files test1.txt and test2.txt to the NTFS drive.
3. I changed the timezone to +1h from original: GMT+2
4. I rebooted.
5. I copied the files test3.txt and test4.txt to the NTFS drive.
6. I changed the timezone to -1h from original: GMT
7. I rebooted.
8. I copied the files test5.txt and test6.txt to the NTFS drive.
9. I looked at the timestamps for the files:
test1.txt: 4:25
test2.txt: 4:25
test3.txt: 3:25
test4.txt: 3:25
test5.txt: 5:25
test6.txt: 5:25

Copying the files to the external HD [ formatted as FAT32, here emulated with drive F: ] of course changes nothing of these times, just that they are stored directly as times without TZ information, and so will show these times whenever accessed in any time zone.

[ Note that the creation times/dates when copying files are usually not shown when listing files, and those times/dates are the dates/times of creation of the copies onto the new filing system, not the original creation date. So the creation times/dates on the FAT32 files only show when the files are copied, not when they were originally made on the original filing system. The last-modified time/date is copied from 1 filing system to the next when copying files and that is what I'm talking about above. ]

So you see exactly the situation as with the disk in question (-1h, -2h, 0h time differences), achieved with just 2 time zone changes on the PC, first to an incorrect one, then a day later to the correct one. People make mistakes, and when they realise it, correct it. That is almost certainly what happened.

[ Final note: The time on the camera may have been altered a few times to account for summer/winter time, but this would not affect this analysis, as that would only mean that the times written on the FAT16 card would be different than if that were not done. That is irrelevant to the essence of the issue here, which is the difference between times of the files on the FAT16 card and on the FAT32 external disk. ]

b) As to the modified file 175 (EXIF on external disk includes photoshop elements line, but not on the camera card): The edited file has the original time/date instead of from the time of alteration. This does look like it is caused by editing of the file attributes, but perhaps it could have been caused by when editing (on the NTFS filing system) that then a power failure happened before the file-write was completed, so before the file attributes are written (does that happen after writing the file data in XP's NTFS? Or because of the disk cache? I don't know, but it would be rather coincidental, i.e. unlikely).

Assuming it was done on purpose:
The report by Kesheva Munegowda assumes a government conspiracy. His explanation for the time differences is a part of that, however, I've given a logical and simple explanation for those, thus making it clear that there is another option which means that it was not proven, not even made to seem likely, that tampering took place, and thus that one cannot assume that there was a government conspiracy.

Of course a conspiracy is very unlikely because there is plenty of evidence that Raniere is a pedophile from the video evidence as shown in "The vow" and "Seduced" where he talks about sex with children, so everything fits, and the pictures are almost certainly real. Of course the testimony by the woman (then girl) in question at the sentencing corroborated this.

So that leaves any conspiracy theory about modified file times as nothing more than wishful thinking by the defense. But what about that modified picture?

There are other options than tampering: The absence of the original (pre-photoshop) file tells you the person doing the editing wasn't interested in keeping the original, and that makes me think he could have wanted to keep the last-modified-time of the edited photo to be that of the original photo, e.g. for 'neatness' when listing files in time/date order, and possibly in his mind to have a 'correct' date.

The person who edited the photo and then modified the file attributes was likely Raniere, as these files contain the offending photos of the underage girl, right? So then these are his files, he wouldn't let others access them. That Raniere would change the time/date wouldn't surprise me at all because he wants reality conform to (and thus change to) his ideals, instead of adjusting himself to reality. That is actually what he's been doing in nxivm on a grand scale, trying to alter the world as he thinks it should be... So, why not also on his PC? There were simple programs that could be found on the web at that time to do that, and he could have programmed something himself too, it's not complicated.

Why would anyone assume that someone else than Raniere did any modification of the file attributes? That is clearly coming from the earlier incorrect conclusion that there is no reasonable explanation other than government tampering of the file dates...

Nothing shown in the report indicates anything besides what Raniere likely did himself, the 'expert' didn't even realise the obvious explanation for the time changes!

c) Oh, and another thing. The idiots from nxivm5 claimed that a screenshot of a whatsapp or telegram post proves Raniere was using his phone in Mexico and was not hiding: That proves nothing. He could have switched off the phone's phone transmission service (that is almost certainly what the authorities meant in that he switched off his phone), and then only used WiFi, possibly with a VPN to further hide himself, for 'just in case'... And then he could have, as someone else said he did "Use burner phones" for actual voice conversations (not sure why, phone conversations could have been done with telegram [ It seems with Telegram the phone call feature was added in April 2017. With Whatsapp calling via WiFi was introduced in 2015 already. ] and a VPN, though perhaps a free VPN (a free one to leave no trail) makes that less reliable/less usable).

Last modified: 2020-11-2