Unix terminal, a simple cheatsheet
Unix terminal is a powerful tool.
I think that a lot of tasks (including my own forensics analysis workflows) can be accomplished more quickly on a “terminal only” environment.
Unix terminal is a powerful tool.
I think that a lot of tasks (including my own forensics analysis workflows) can be accomplished more quickly on a “terminal only” environment.
LiMEaide is a python application developed by Daryl Bennett that can remotely dump RAM of a Linux client.
It can also create a volatility profile for later analysis.
In order to use LiMEaide all you need to do is feed a remote Linux client IP address, sit back, and consume your favorite caffeinated beverage.
In order to use LiMEaide you need to resolve some dependencies.
sudo apt-get install python3-paramiko python3-termcolor
sudo apt-get install dwarfdump
LiMEaide/tools/
LiME
During a digital forensics analysis, a lot of different tools can be used, and it could be useful use a dedicated linux distribution with all tools already installed and configured.
Here a brief list of my choises.
CAINE offers a complete forensic environment that is organized to integrate existing software tools as software modules and to provide a friendly graphical interface: contains numerous tools that help investigators during their analysis, including forensic evidence collection
DEFT Linux distribution made for evidence collection that comes bundled with the Digital Advanced Response Toolkit (DART) for Windows.
A VMware-based appliance designed for small-to-medium sized digital investigation and acquisition and is built entirely from public domain software, like Autopsy, the Sleuth Kit, the Digital Forensics Framework, log2timeline, Xplico, and Wireshark.
The system maintenance is provided by Webmin.
NST is a Linux distribution that includes a vast collection of best-of-breed open source network security applications useful to the network security professional:
The main intent of developing this toolkit was to provide the security professional and network administrator with a comprehensive set of Open Source Network Security Tools.
A Linux distribution customized in order to perform various forenics tasks like password discovery , social media analysis, data carving, windows registry analysis, malware analysis, log analysis and more.
Security Onion is a special Linux distro aimed at network security monitoring featuring advanced analysis tools:
Security Onion is a Linux distro for intrusion detection, network security monitoring, and log management. It’s based on Ubuntu and contains Snort, Suricata, Bro, OSSEC, Sguil, Squert, ELSA, Xplico, NetworkMiner, and many other security tools.
The SIFT Workstation is a VMware appliance, preconfigured with the necessary tools to perform detailed digital forensic examination in a variety of settings.
The SIFT Workstation demonstrates that advanced incident response capabilities and deep dive digital forensic techniques to intrusions can be accomplished using cutting-edge open-source tools that are freely available and frequently updated
Some days ago i’ve written a post about the “Ultra-Geek” Linux Workstation developed by Joe Nelson.
Reading his post, I found many similarities with the current configuration of my laptop.
Finally, Debian 9 “Stretch” was released in the “stable” branch!
A lot of upgrades, especially in kernel, glibc and other base packages.
Some info from the official wiki (also see the official stretch release notes.):
Before you move on with the upgrade, be sure that your current Debian Jessie was fully updated:
# apt-get update
# apt-get upgrade
# apt-get dist-upgrade
and make a backup of your current sources.list:
cp /etc/apt/sources.list /etc/apt/sources.list_backup
Then, you can start with the upgrade.
First, update the package repository:
sed -i 's/jessie/stretch/g' /etc/apt/sources.list
Then, update package index
# apt-get update
and finally execute the below commands to start the upgrade process:
# apt-get upgrade
# apt-get dist-upgrade
Once the process completes, check your Debian version:
# cat /etc/issue
Debian GNU/Linux 9 n l
That’s all folks!
On 2010, Hal Pomeranz has started on SANS Digital Forensics blog a series of technical articles about EXT4 filesystem.
EXT4 is a journaling file system for Linux, developed as the successor to ext3: it modifies important data structures of the previous filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability and features.
It was accepted as “stable” in the Linux 2.6.28 kernel in October 2008.
The publication of the ‘episodes’ continued since years, and recently Hal has published the part 6, focused on “Directories”.
Here the list of all parts:
20 Dec 2010
EXT4 has moved to 48-bit block addresses. I’ll refer you to the paper cited above for the whys and wherefores of this decision and what it means as far as maximum file system size, etc. What’s really a departure for EXT4 however, is the use of extents rather than the old, inefficient indirect block[3] mechanism used by earlier Unix file systems (e.g. EXT2/EXT3) for tracking file content. Extents are similar to cluster runs in the NTFS file system- essentially they specify an initial block address and the number of blocks that make up the extent. A file that is fragmented will have multiple extents, but EXT4 tries very hard to keep files contiguous.
14 Mar 2011
The EXT4 developers tried very hard to maintain backwards compatibility with the EXT2/EXT3 inode layout. 64-bit timestamps and a completely new file creation timestamp obviously complicate this goal. The EXT4 developers solved this problem by putting the extra stuff in the upper 128 bits of the new, larger 256-bit EXT4 inode.
28 Mar 2011
[…] you can only have a maximum of 4 extent structures per inode. Furthermore, there are only 16 bits in each extent structure for representing the number of blocks in the extent, and in fact the upper bit is reserved (it’s used to mark the extent as “reserved but initialized”, part of EXT4’s pre-allocation feature). That means each extent can only contain a maximum of 2¹⁵ blocks- which is 128MB assuming 4K blocks.
Now 128MB is pretty big, but what happens when you have a file that’s bigger than half a gigabyte? Such a file would require more than 4 extents to fully index. Or what happens when you have a file that’s small but very fragmented? Again, you could need more than 4 extents to represent the collections of blocks that make up the file.
08 Apr 2011
I got curious about what would happen when I deleted my /var/log/messages file. How does the inode change? What happens to block 131090, which holds my extent tree structure? Well, there’s really only one way to find out: I deleted the file… carefully so I didn’t lose any logging data. In fact, I didn’t just delete the file; I used “shred -u /var/log/messages” to overwrite the data blocks with nulls before unlinking the file. Once the file had been purged, I dumped out the both inode associated with the file as well as block 131090 and took a look at them in my hex editor.
22 Aug 2011
[…] you can only have 32K blocks in an extent. Assuming a typical 4K block size, that means you can only have 128MB of data in a single extent. A 4GB file is therefore going to require at least 32 extents, and even that assumes you can find 32 runs of 32K contiguous blocks to use. More likely we’ll have more than 32 extents, some of which don’t use the full 128MB length.
07 Jun 2017
One item I never got around to was documenting how directories were structured in EXT. Some recent research has caused me to dive back into this topic, and given me an excuse to add additional detail to this EXT4 series.
If you go back and read earlier posts in this series, you will note that the EXT inode does not store file names. Directories are the only place in traditional Unix file systems where file name information is kept. In EXT, and the classic Unix file systems it is evolved from, directories are simply special files that associate file names with inode numbers.
Furthermore, in the simplest case, EXT directories are just sequential lists of file entries. The entries aren’t even sorted. For the most part, directory entries in EXT are simply added to the directory file in the order files are created in the directory.
I wish you a good reading!
linux-insides is a online project developed by 0xAX focused on the making of a book about the linux kernel and its insides:
The goal is simple — to share my modest knowledge about the insides of the linux kernel and help people who are interested in linux kernel insides, and other low-level subject matter.
The project is very detailed and already quite complete, here a content summary:
https://0xax.gitbooks.io/linux-insides/content/
https://0xax.gitbooks.io/linux-insides/content/
It’s true, I didn’t prepare any articles on the weekend, however by accident I saw this nice strip on CommitStrip and…
(Seriously, how many times did he do this?)
http://www.commitstrip.com/en/2017/02/28/definitely-not-lazy/