Jump to content











Photo
- - - - -

HideAndProtect (NTFS)

ntfs

  • Please log in to reply
21 replies to this topic

#1 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 26 May 2013 - 11:26 PM

Posted Image

File Name: HideAndProtect (NTFS)
File Submitter: joakim
File Submitted: 27 May 2013
File Updated: 27 May 2013
File Category: Security

This program will turn a regular file into an NTFS system file, by changing it's MFT reference number to one between 12 and 15, which are reserved by the filesystem. By doing this, the file becomes invisible and protected from modification. By invisible it means, no tool explorer or the dir command will see it. However the filesystem regard it as a systemfile, and will thus prevent writing any file to that location with that name. It is like when you try to create a file named $MFT in the root of the volume, which the filesystem will prevent you from doing. The only way to modify this file is by a hex editor writing to physical disk. Alternatively you could extract the file from volume (datarecovery), modify the extracted file, and then lastly use the tool to inject it back into the same MFT reference number as it was.

What can be hidden with this tool?
Basically any file or folder. However a few restrictions apply:
  • Target can not have $ATTRIBUTE_LIST in its MFT record (content span across several MFT records).
  • Content in subdirectories, except root dir.
  • New MFT reference must be between 12 and 15.

That means the file or folder must be located at the root level of the volume.

Example that works:
HideAndProtect.exe C:\file.ext 12
HideAndProtect.exe C:\folder 15








Example that does not work:

HideAndProtect.exe C:\folder\file.ext 14
HideAndProtect.exe C:\file.ext 20

Example using path to source file and target IndexNumber 12:
HideAndProtect C:\bootmgr 12

Example using IndexNumber of source file (33) on volume C: and target IndexNumber 13:
HideAndProtect C:33 13

Example to wipe the record of MFT reference number 14 on volume C:
HideAndProtect C:W 14


What can it be used for?
  • Hide a few files, and protect them from modification. Try it on your boot loader, like bootmgr.
  • Reserve certain filenames in the root of the volume. For instance autorun.inf on flash sticks.

I have tried this on bootmgr, and Windows booted fine. The point is that when the bootsector is executed there is no NTFS driver or anything present that understand the concept of a file vs folder. It is basically X number of sector loaded into memory, based on a few conditions. Later on in the boot process, Windows will differentiate on it and turn the system file invisible.

Technical details:
We take a copy of the original MFT record and write it to the location of where the record of the new MFT reference number is located. We wipe the original record. Then we modify the backup, change MFT ref and sequence number. Then let chkdsk do the rest of the job to make Windows happy about the new NTFS systemfile (it will correct timestamps in $FILE_NAME attribute, update flags in both $STANDARD_INFORMATION and $FILE_NAME ATTRIBUTE, correct the index in $I30 in the root directory (MFT ref 5), and a few more. These last steps are tricky if done manual, so using chkdsk for it is fine.

Warning:
Due to the very hacky nature of this application, you must understand that this may corrupt your filesystem, and that I take no responsibility for what this application may cause. Use at own risk! Important to close any open files on the target volume before trying this.


The tool has been tested with success on XP SP2 32-bit and Windows 7 SP1 64-bit. Please be aware of limitations when running on nt6.x

Limitation
At nt6.x new security measures have been implemented, preventing you from writing directly to sectors inside filesystem. Before doing anything like this, we obtain a lock on the target volume. However, this is not possible to in a few situations (systemdrive, volume where pagefile is on, volume where HideAndProtect is run from, and maybe a ew more). These restrictions do not apply for nt5.x (anything before Vista). In any case there is an absolute restriction of a maximum of 4 files per volume that you can hide.

Credits:
User DeltaRocked at autoit forums who made me aware of this trick.

Click here to download this file

#2 Centaur

Centaur

    Newbie

  • Members
  • 23 posts
  •  
    United States

Posted 27 May 2013 - 12:14 AM

some probably silly quetions,

 

1) is there a file size limit? (ie. could you do this with a ISO or VHD file 700megs to 3-4gigs)

 

2) when useing the --mem in g4d does the ISO, VHD keep or lose this attribute?

 

unless there is a size limit for a MFT i could see this working great for hidden ISO an loading with --mem, VHD's change so when in mem so not sure if it would work or how G4D would access the file(s) for copying.

 

Cenatur



#3 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 27 May 2013 - 12:02 PM

Seems very nice :thumbup:, but if I may, noone in his/her right mind would test that unless you also provide a "UNhideandUNprotect" tool that does the reverse.   :ph34r:

 

Also, if used without parameters or with /? it could display usage.

 

:cheers:

Wonko



#4 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 27 May 2013 - 12:49 PM

Hi Joakim,

 

Cannot download zip : appears to be corrupted.

Other zip on this forum are ok so I cannot blame my proxy right now.

 

Regards,

Erwan

 

edit : winrar seems ok with the file.



#5 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 27 May 2013 - 01:29 PM

tried the following

 

D:\>HideAndProtect.exe d:\xxx.exe 12
HideAndProtect v1.0.0.0
 
Target is a File
Record number: 12 found at disk offset: 87738880 -> 0x00000000053ACA00
Record number: 29 found at disk offset: 87756288 -> 0x00000000053B0E00
Finished
 
however, after this action, my file looks like before.
I can see it, rename it, etc.
 
?
 
/erwan


#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 27 May 2013 - 06:52 PM

however, after this action, my file looks like before.
I can see it, rename it, etc.
And what happens if you run CHKDSK on that volume? :unsure:
 
 

 

Then let chkdsk do the rest of the job to make Windows happy about the new NTFS systemfile (it will correct timestamps in $FILE_NAME attribute, update flags in both $STANDARD_INFORMATION and $FILE_NAME ATTRIBUTE, correct the index in $I30 in the root directory (MFT ref 5), and a few more. These last steps are tricky if done manual, so using chkdsk for it is fine.

 

:cheers:
Wonko
 


#7 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 27 May 2013 - 07:13 PM

Actually it is the last step of executing chkdsk that seems a bit buggy on xp (Erwan used XP perhaps?). My tests on Windows 7 x64 seems good. Will update with an improved version very soon. Testing in an XP vm now.



#8 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 27 May 2013 - 07:38 PM

Hi Joakim,

 

I used xp pro 32 bits.

I did not pay attention to chkdsk output :(

Will start over from scratch (shall I mention I use a virtual imdisk ntfs volume?).

 

Regards,

Erwan



#9 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 27 May 2013 - 07:44 PM

File is gone now :) or shall I say hidden :)

 

Below the output (sorry for the french part) :

 

 

HideAndProtect.exe e:\systems.xls 12
HideAndProtect v1.0.0.0
 
Target is a File
Record number: 12 found at disk offset: 22369280 -> 0x0000000001555400
Record number: 36 found at disk offset: 22393856 -> 0x000000000155B400
Error when locking e:
Trying to force dismount instead
Force dismounted e:
Warning: When target drive is re-mounted you must run this command: chkdsk e: /F
 
 
chkdsk e: /F
Le type du système de fichiers est NTFS.
 
CHKDSK est en train de vérifier les fichiers (étape 1 sur 3)...
 0 % effectués. (0 enregistrements de fichier sur 256 traités)
Correction des informations incorrectes dans le segment d'enregistrement de
fichier 12.
  256 enregistrements de fichier traités.
La vérification des fichiers est terminée.
  0 enregistrements de grand fichier traités.
  0 enregistrements de fichier incorrect traités.
  0 enregistrements EA traités.
  0 enregistrements d'analyse traités.
CHKDSK est en train de vérifier les index (étape 2 sur 3)...
73 % effectués. (254 entrées d'index sur 274 traitées)
Suppression de l'entrée d'index systems.xls dans l'index $I30 du fichier 5.
  274 entrées d'index traitées.
La vérification des index est terminée.
CHKDSK analyse les fichiers non indexés pour les reconnecter à leur répertoire d
'origine.
  1 fichiers non indexés analysés.
Récupération du fichier orphelin systems.xls (12)  dans le fichier de répertoire
 5.
  0 fichiers non indéxés récupérés.
CHKDSK est en train de vérifier les descripteurs de sécurité (étape 3 sur 3)
  256 SD/SID de fichiers traités.
La vérification des descripteurs de sécurité est terminée.
  9 fichiers de données traités.
CHKDSK a découvert de l'espace libre marqué alloué dans la
bitmap de la table de fichiers maîtres (MFT).
CHKDSK a découvert de l'espace libre marqué alloué dans la bitmap du volume.
Windows a effectué des corrections sur le système de fichiers.
 
     65504 Ko d'espace disque au total.
      5184 Ko dans 5 fichiers.
         8 Ko dans 11 index.
         0 Ko dans des secteurs défectueux.
      2724 Ko utilisés par le système.
      2048 Ko occupés par le fichier journal.
     57588 Ko disponibles sur le disque.
 
      4096 octets dans chaque unité d'allocation.
     16376 unités d'allocation au total sur le disque.
     14397 unités d'allocation disponibles sur le disque.


#10 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 27 May 2013 - 07:46 PM

trying now my extents tool to recover this, I get access denied (5) :

 

 

invalid handle, 5
***************************
***************************
Done
 
Now that is a challenge :) I want to retrieve this "protected" file :)
 
edit : even when running as the system account, I still get access denied.


#11 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 27 May 2013 - 08:06 PM

trying now my extents tool to recover this, I get access denied (5) :

 

 

invalid handle, 5
***************************
***************************
Done
 
Now that is a challenge :) I want to retrieve this "protected" file :)
 
edit : even when running as the system account, I still get access denied.

That's expected bahaviour since we have implemented super protection :)

 

Edit: However, my earlier mentioning of shortcuts, is actually now becoming more visible.. You will not get this if you resolve the clusters from the datarun list yourself.



#12 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 27 May 2013 - 08:19 PM

I now understand what you mean by "shortcut".

 

Indeed the fsctl retrival_pointers use a system file driver whereas going thru the mft would eventually bypass the driver and its protections.

 

Erwan



#13 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 27 May 2013 - 09:06 PM

New version uploaded.

 

Added option to delete/undo previous hack. Added help/usage printed to console when no parameters are supplied. Added clear information about chkdsk at end, to prevent any misunderstanding. Actually the program attempted to launch chkdsk itself in first version, but it was not good. Therefore it is removed in the second version, and the user have to execute chkdsk himself/herself.

 

@Centaur

There is no size limit for the files you can hide. Regard g4d, I have not tested such a scenario. I don't know how g4d knows about files on NTFS. Maybe someone wants to test this..

 

Regarding bootmgr, I tested and verified that Windows will boot fine with a hidden bootmgr. It may be that a hidden BCD will work too, but then you need to move the BCD file to the root of the volume (\BCD), and patch bootmgr to point to that file instead of \Boot\BCD. This has not yet been tested, but I guess I can do so soon. Regarding other boot loaders, I would appreciate some help testing these scenarios, at least if that is of any interest.



#14 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 28 May 2013 - 04:33 AM

Some more information:


I tried with a patched bootmgr to use BCD store located at the root of volume, but did not work.


Then I tried grub4dos (0.4.6a-2013-05-21) which seem very happy with hidden files. My simpel test was to prepare an NTFS volume with the NT60 bootsector. Then I renamed grldr into bootmgr and put onto the volume. Then I copied menu.lst and a sample ISO for the test. Then I ran HideAndProtect on the 3 files, and they got MFT reference number 12, 13 and 14. Re-attached the virtual disk to a different VM and booted up just fine :) from an empty volume  Chainloading hidden files also went fine.



#15 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 28 May 2013 - 09:18 AM

New version uploaded.
 
Added option to delete/undo previous hack. Added help/usage printed to console when no parameters are supplied. Added clear information about chkdsk at end, to prevent any misunderstanding. Actually the program attempted to launch chkdsk itself in first version, but it was not good. Therefore it is removed in the second version, and the user have to execute chkdsk himself/herself.

Very good :thumbup:
Then I tried grub4dos (0.4.6a-2013-05-21) which seem very happy with hidden files.
Yes, this was expected, grub4dos is not racist agains $MFT entries 12,13 and 14 (maybe only with the 15) ;).
For the record, also 7-zip lists the hidden file alright.

OT :ph34r: and @erwan.l
There are a few tools around that read the $MFT to find files FAST, maybe you can use/reuse their source code to avoid the shortcut? :unsure:
http://reboot.pro/to...lick-like-tool/
this one is open source:
http://sourceforge.n...ts/ntfs-search/
Also, maybe useful, maybe not:
http://www.codeproje...NTFS-Parser-Lib

:cheers:
Wonko

#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 May 2013 - 12:30 PM

Joakim, there is an issue :w00t: :ph34r:.

 

The chkdisk method is (besides being a PITA) giving different results on "Removable" vs. "Fixed" volumes (or *whatever*)

Example 1:

NTFS volume on HD image mounted through IMDISK (i.e. very "light" integration in the OS) NO "System Volume Information" created on the volume, the chkdsk /f works OK, fixes *whatever* in index $I30 of file 5:

 

 

 

Eliminazione della voce di indice fat12grldr.img nell'indice $I30 del file 5.
Eliminazione della voce di indice FAT12G~1.IMG nell'indice $I30 del file 5.
Verifica indici completata.
CHKDSK sta recuperando i file perduti.
Recupero del file orfano FAT12G~1.IMG (12) nel file di directory 5.
Recupero del file orfano fat12grldr.img (12) nel file di directory 5.

 

Example 2:

Same volume mounted through Kernsafe Total Mounter, i.e. fully integrated in the OS, the "System Volume Information" appears on the volume, chkdsk DOES NOT work as above:

 

 

 

Eliminazione del record attributi danneggiato (128, "")
dal segmento record file 29.
Verifica file completata.
Verifica degli indici in corso (fase 2 di 3)...
Verifica indici completata.
CHKDSK sta recuperando i file perduti.
Verifica dei descrittori di protezione in corso (fase 3 di 3)...
Verifica descrittori di protezione completata.
Inserimento degli attributi dei dati nel file 29.
Correzione degli errori nell'attributo BITMAP della Tabella file master (MFT).

A found.000 hidden, empty folder is created, the file (Win98.IMG) remains visible in ROOT BUT with 0 byte size, the actual entry in $MFT #12 is correct, BUT with NO filename!

 

:cheers:

Wonko



#17 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 May 2013 - 03:30 PM

Maybe it will make a difference if the original record was wiped instead. I'll take a look at it.



#18 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 May 2013 - 03:39 PM

Wonko, what OS was this behaviour observed on?



#19 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 29 May 2013 - 09:05 PM

@Wonko

 

I installed TotalMounter from kernsafe in a Windows 7 x64 vm, but it works just fine here. I have tried many variations like local disks, flash sticks and images mounted (Imdisk and TotalMounter tested), but am unable reproduce what you have reported. Do you have more information about the setup you used? OS, arch, type of image, version of TotalMounter, version of HideAndProtect, exact commandline, how volume on image was formatted, whatever else you find relevant.



#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 30 May 2013 - 09:32 AM

Wonko, what OS was this behaviour observed on?

XP SP2 32 bit.
However I tried several more tests (changing also cluster size between 512/1024/2048/4096) and the behaviour is NOT easily/constantly reproducible (at least I haven't yet found a way to reproduce it "all the times I want" :w00t:).
 
The good news are that if it fails with the "damaged file (128,"")" error message in chkdsk, if you copy over again the file (overwriting the 0 byte one) and re-do the hideandprotect command, it seemingly works every time.
 
Another nice thing is that once you have succeeded in hiding the file, if you try to copy it again on the volume, you get an access error, like if the volume had become read only. (this could be a good way to make sure it worked from a batch, without needing to actually parse entry #12 in the $MFT)
 
Results of last round of tests (re-formatted every time):
 
 
 

Mounted in IMDISK (NO "System Volume Information")
Cluster size:
512 issue
1024 OK
2048 issue
4096 OK

Mounted in Total Mounter ("System Volume Information" automatically created)
Cluster size:
512 issue
1024 OK
2048 OK
4096 OK

BUT when I tried again the 512 and 4096 in Total Mounter I got opposite results:
 
 
 

512 OK
4096 issue

 
there must be some timing problem of some kind and/or having an Explorer window open on the drive or not (chkdsk prompts for invalidating all open handles to the volume or not). I am perplexed :dubbio:

I will do more "organized" tests and report.
 
 
:cheers:
Wonko

 

P.S.: Ok, some sort of "false alarm" (but not quite). 

The volume needs to be chkdsked IMMEDIATELY after having run hideandprotect.

 

If the files is accessed *something* changes (I presume last access date) and the chksdsk interprets the "corrupted data" differently and "fixes it" differently.

 

Another thing that changes is the indexing service, a volume mounted (and formatted) in IMDISK has it NOT set, a volume mounted (and formatted) in Total Mounter has it set, and from time to time during my tests a baloon popped out on my taskbar saying how the file was corrupted and how chkdsk had to be run.

 

 



#21 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 31 May 2013 - 01:52 PM

This may be of some use, chap.cmd :

 

 

 

@ECHO OFF
SETLOCAL ENABLEEXTENSIONS
IF "%1"=="" GOTO :usage
FOR /L %%A IN (12,1,15) DO IF %1==%%A SET FlagOK=1
IF NOT defined FlagOK PAUSE&GOTO :usage
IF "%2"=="" GOTO :usage
IF /I NOT "%2"=="%~d2" Set File=%~dpnx2&GOTO :no_copy
IF "%3"=="" GOTO :usage
IF NOT exist %3 ECHO No file to copy&PAUSE&GOTO :usage
COPY %3 %~d2

:no_copy
IF NOT exist %2%~pnx3 ECHO No file copied or already hidden&PAUSE&GOTO :usage
FOR /F "tokens=* delims=" %%A IN ('HideAndProtect.exe %2\%~pnx3 %1 ^| FIND "chkdsk"') DO %%A
IF exist %File% ECHO Something went wrong, try again &PAUSE&GOTO :EOF
IF exist %2%~pnx3 ECHO Something went wrong, try again &PAUSE&GOTO :EOF
echo Operation (hopefully) completed successfully.
GOTO :EOF

:usage
cls
echo.
echo chap.cmd small batch to manage HideandProtect.exe
echo.
echo Usage:
echo chap n [targetfile or targetdrive (if sourcefile is provided)] [sourcefile]
echo.
echo Where:
echo n is the $MFT entry that is wanted 12, 13, 14 or 15
echo targetfile is the file (full path) that you want to hide and protect
echo [sourcefile] is the optional file (full path) that you want to copy before
echo.
echo Examples:
echo chap 12 P:\somefile.txt ^<- hides and protects file P:\somefile.txt
echo (file P:\somefile.txt must already exist)
echo.
echo chap 12 P: D:\somefile.txt ^<- copies file D:\somefile.txt to P:
echo then hides and protects it (on P:)

 

:cheers:

Wonko



#22 joakim

joakim

    Silver Member

  • Team Reboot
  • 912 posts
  • Location:Bergen
  •  
    Norway

Posted 01 June 2013 - 05:50 AM

Thanks for the contribution Wonko.







Also tagged with one or more of these keywords: ntfs

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users