goglclassic.blogg.se

1. #Get ram from linux using accessdata ftk imager lite install#
2. #Get ram from linux using accessdata ftk imager lite update#

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\ Registry Keyīy default, DefaultEnvironment and KernelCommandLine were found to be the same for all three of the tested userlands but may be modified by a user or in later updates.

#Get ram from linux using accessdata ftk imager lite update#

However, after a Windows update and installing subsequent additional userlands, this key and its content have been moved one layer deeper, and they can now be found at: NTUSERDAT\SOFTWARE\Microsoft\Windows\CurrentVersion\Lxss

#Get ram from linux using accessdata ftk imager lite install#

The Beta install also created a notable Registry key at: If a user chooses the uninstall option either via the store or by right clicking in the start menu shortcut all user data is also removed. You may recall that one benefit of the beta method is that when a user uninstalled WSL then the /rootfs directory was deleted but /home was left intact and data which may be pertinent to a case was preserved, unfortunately for us this is no longer the case. What is notable is that while the beta install separates /, /home and /root into distinct locations which are individually mounted, the 'rootfs' directory is mounted as / and thereafter /home and /root exist within that structure. This location is also liable to change with future application and Windows updates. The current paths where the rootfs is located for each install is as follows:Ĭ:\Users\\AppData\Local\Packages\46932SUSE.openSUSELeap42.2_022rs5jcyhyac\LocalState\rootfsĬ:\Users\\AppData\Local\Packages\46932SUSE.SUSELinu圎nterpriseServer12SP2_022rs5jcyhyac\LocalState\rootfsĬ:\Users\\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs Installation of any of the currently available userlands via the Windows Store now creates the associated file system within the packages directory for that application. To summarise my previous posts, installs of ‘Bash for Ubuntu for Windows’ using the beta installation method cause notable files to be created within C:\Users\\AppData\Local\lxss, with specific subfolders for the home, root and rootfs which are then mounted when Bash is executed. Similarly, the location of the root file system for each is quite different from the location where the Beta version installs. This location is liable to change with future application and Windows updates. The core executable associated with each of the currently available userlands can be found at:Ĭ:\Program Files\WindowsApps\CanonicalGroupLimited.UbuntuonWindows_1604.2017.922.0_圆4_79rhkp1fndgsc\ubuntu.exeĬ:\Program Files\WindowsApps\46932SUSE.openSUSELeap42.2_1.1.0.0_圆4_022rs5jcyhyac\openSUSE-42.exeĬ:\Program Files\WindowsApps\46932SUSE.SUSELinu圎nterpriseServer12SP2_1.1.0.0_圆4_022rs5jcyhyac\SLES-12.exe The installation is still on a per user basis, so the points raised regarding activity attribution still stand. However, installation of any of the three currently available userlands via the store causes both the application files and the associated filesystem to be installed in different locations. In my prior testing I was limited to Ubuntu installed via the Beta installation method, however the other three installations are completed using the Windows Store.ĭetecting Windows Subsystem for Linux (installed via Windows Store) As per my previous posts, if you install WSL using the beta method the Bash executable will be found at: The eagle-eyed reader may have cottoned onto the fact that two instances of Ubuntu could be installed, one using each of the two installation methods. This begs the question, where are the corresponding files for these distinct Linux user land installs. Per the screenshot, I successfully installed four userlands side by side, Ubuntu (via Beta install method), Ubuntu (Via Windows Store), openSUSELeap (Via Windows Store) and SUSELinu圎nterpriseServer (Via Windows Store). Can an individual user install multiple userlands/ distributions side by side: The immediate question was quickly answered. Unfortunately for me, it opened a can of worms which necessitated this follow up post to expand upon, and in some instances correct, its predecessors. The update appeared to have resolved the issue, so I was keen to dive in and confirm the answer to that niggling question. Prior to this update my attempts to install openSUSE and SLES were failing repeatedly so I was unable to test whether multiple userlands could be installed side by side. No sooner had I pressed publish on the latter, than a new Windows Insider Program update was pushed to my PC.

This is a short follow up to my two recent posts, ' Windows Subsystem for Linux and Forensic Analysis' and ' Forensic Analysis of Systems that have Windows Subsystem for Linux Installed'.