mirror of
https://git.qwik.space/left4code/left4code.neocities.org.git
synced 2025-07-28 00:13:38 +05:30
filesystem additions
This commit is contained in:
24
blog.html
24
blog.html
@@ -10,20 +10,16 @@
|
||||
<body>
|
||||
|
||||
<div class="container">
|
||||
|
||||
|
||||
<section>
|
||||
<div class="small">
|
||||
<nav>
|
||||
<a href="index.html">Home</a>
|
||||
</nav>
|
||||
|
||||
|
||||
|
||||
</nav>
|
||||
</div>
|
||||
<h1 class="blog-header">This is my fun little blog, fancy something you like?</h1>
|
||||
|
||||
<h1>This is my fun little blog, fancy something you like?</h1>
|
||||
|
||||
|
||||
|
||||
<h4><a href="blogs/jun-09-2025.html">:~$ Personal notes for the ly Display Manager - [2025-6-09]</a></h4>
|
||||
<hr>
|
||||
<h4><a href="blogs/apr-19-2025.html">:~$ A General Guide to GPG - [2025-4-19]</a></h4>
|
||||
<hr>
|
||||
<h4><a href="blogs/apr-17-2025.html">:~$ Vim Macros for Speedy HTML - [2025-4-17]</a></h4>
|
||||
@@ -39,9 +35,9 @@
|
||||
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
|
||||
@@ -56,7 +52,6 @@
|
||||
</div>
|
||||
|
||||
|
||||
</body>
|
||||
<footer>
|
||||
|
||||
<h5>This entire site and it's material are licensed under a Creative Commons Attribution-NonCommercial 4.0 International License</h5>
|
||||
@@ -64,5 +59,6 @@
|
||||
<p><a href="https://creativecommons.org/licenses/by-nc/4.0/">https://creativecommons.org/licenses/by-nc/4.0/</a></p>
|
||||
|
||||
</footer>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
|
||||
445
blogs/jun-09-2025.html
Normal file
445
blogs/jun-09-2025.html
Normal file
@@ -0,0 +1,445 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="description" content="These are some personal notes regarding the installation of ly on an Ubuntu system and some of the problems I encountered.">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="author" content="Left4Code">
|
||||
<meta name="keywords" content="ly, ly display manager, ly display manager problem, ly ubuntu">
|
||||
<link rel="icon" type="image/x-icon" href="../favicon/favicon.ico">
|
||||
<title>Left4Code - (Blog) - {ly Personal Notes}</title>
|
||||
<link rel="stylesheet" type="text/css" href='../style.css'>
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<span>Left4Code</span>
|
||||
</header>
|
||||
|
||||
<nav>
|
||||
<div>
|
||||
<a href="../index.html">Home</a>
|
||||
<a href="../blog.html">Blog</a>
|
||||
</div>
|
||||
</nav>
|
||||
|
||||
<div class="container">
|
||||
<section>
|
||||
<h1 class="blog-header">Personal notes for the ly Display Manager</h1>
|
||||
<h3>--| Posted: 2025-06-09</h3>
|
||||
|
||||
<h4 class="blog-header">Table of Contents</h4>
|
||||
<div id="toc_container">
|
||||
<hr>
|
||||
<ul class="toc_list">
|
||||
<li><a href="#>~(1)">1. Background</a></li>
|
||||
<li><a href="#>~(2)">2. Compiling ly using Zig</a></li>
|
||||
<li><a href="#>~(3)">3. Additional Commands Used</a></li>
|
||||
<li><a href="#>~(4)">4. Conclusion</a></li>
|
||||
</ul>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
|
||||
<h4 id=">~(1)" class="blog-header">1. Background</h4>
|
||||
|
||||
<p>This is going to be some personal notes for memory. I tried to install the ly display manager and after about 3-hours of messing around, I have figured out how to get it to work under ubuntu seemingly properly under xorg with systemd.</p>
|
||||
|
||||
<p>This is not meant to be a real "Installation guide" of sorts, and is going to be a lot more informal than other posts.</p>
|
||||
|
||||
<h4 id=">~(2)" class="blog-header">2. Compiling ly using Zig</h4>
|
||||
|
||||
<p>Because ly does not have a native ubuntu package that you can just install, you need to build it from source. To do this, I specifically used build 0.14.0, 0.15.0 is a dev package at this time and does not want to compile ly. It should also be noted that any versions of zig under version 0.14.0 will be rejected from compiling as the ly project requires a minimum of 0.14.0 (so use that version exactly)</p>
|
||||
|
||||
<p>and since zig also does not have its own package on ubuntu, I downloaded version 0.14.0 in tar form for x86_64 and ran "tar xf <the_tarfile>"</p>
|
||||
|
||||
<p>from there what I did was I made a symlink from the location of the folder created from the tar archive to /usr/bin/zig</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
sudo ln -s ~/Downloads/zig-linux-x86_64-0.14.0/zig /usr/bin/zig</pre>
|
||||
|
||||
<p>Since this is after everything is working and I don't exactly remember what I did, I would recommend making another link but putting it in /bin also</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
sudo ln -s ~/Downloads/zig-linux-x86_64-0.14.0/zig /bin/zig </pre>
|
||||
|
||||
<p>from here you should be able to type "zig verision" in your home directory and it should show version 0.14.0.</p>
|
||||
|
||||
<p>I did not have to modify my path for this, but if you run echo $PATH and you don't see /usr/bin or /bin there (you should), then export and add them. Search up a guide to do this, should be very simple.</p>
|
||||
|
||||
|
||||
<p>for ly specifically, I used the new version from codeberg, which seems to be version "1.2.0-dev.192+a8b8292" which is what ly shows in the top left when I run it.</p>
|
||||
|
||||
<p>for the clone command, I simply just did a normal git clone, if you end up getting a newer version in the future it may have different compile results.</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
git clone https://codeberg.org/AnErrupTion/ly </pre>
|
||||
|
||||
|
||||
<p>move into the ly directory and then run the zig build commands, I don't know specifically if you need both, but both is what worked for me.</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
zig build </pre>
|
||||
|
||||
<p>because I'm using xorg, and I need the ly.service file.</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
sudo zig build installexe </pre>
|
||||
|
||||
<p>If you haven't gotten any NoDIR or relative errors like that and it actually compiled completely, congrats, you're like 50% of the way there, and that was the easy part.</p>
|
||||
|
||||
<p>the compilation should have made a new configuration file, which is at "/etc/ly/config.ini", and a new service file for ly, "ly.service", which is located at "/lib/systemd/system/ly.service". </p>
|
||||
|
||||
<p>Additionally, there will be a PAM (Pluggable Authentication Modules) file for ly that should be made potentially after you try to start ly. it is at "/etc/pam.d/ly"</p>
|
||||
|
||||
<p>The contents of each one of these files are below as I have modified them for a working solution. (I don't know if it'll work for you, but let's hope)</p>
|
||||
|
||||
<details>
|
||||
<summary class="header">/etc/ly/config.ini</summary>
|
||||
|
||||
|
||||
<pre class="preformatted">
|
||||
# Ly supports 24-bit true color with styling, which means each color is a 32-bit value.
|
||||
# The format is 0xSSRRGGBB, where SS is the styling, RR is red, GG is green, and BB is blue.
|
||||
# Here are the possible styling options:
|
||||
#define TB_BOLD 0x01000000
|
||||
#define TB_UNDERLINE 0x02000000
|
||||
#define TB_REVERSE 0x04000000
|
||||
#define TB_ITALIC 0x08000000
|
||||
#define TB_BLINK 0x10000000
|
||||
#define TB_HI_BLACK 0x20000000
|
||||
#define TB_BRIGHT 0x40000000
|
||||
#define TB_DIM 0x80000000
|
||||
# Programmatically, you'd apply them using the bitwise OR operator (|), but because Ly's
|
||||
# configuration doesn't support using it, you have to manually compute the color value.
|
||||
# Note that, if you want to use the default color value of the terminal, you can use the
|
||||
# special value 0x00000000. This means that, if you want to use black, you *must* use
|
||||
# the styling option TB_HI_BLACK (the RGB values are ignored when using this option).
|
||||
|
||||
# Allow empty password or not when authenticating
|
||||
allow_empty_password = false
|
||||
|
||||
# The active animation
|
||||
# none -> Nothing
|
||||
# doom -> PSX DOOM fire
|
||||
# matrix -> CMatrix
|
||||
# colormix -> Color mixing shader
|
||||
animation = colormix
|
||||
|
||||
# Stop the animation after some time
|
||||
# 0 -> Run forever
|
||||
# 1..2e12 -> Stop the animation after this many seconds
|
||||
animation_timeout_sec = 0
|
||||
|
||||
# The character used to mask the password
|
||||
# You can either type it directly as a UTF-8 character (like *), or use a UTF-32
|
||||
# codepoint (for example 0x2022 for a bullet point)
|
||||
# If null, the password will be hidden
|
||||
# Note: you can use a # by escaping it like so: \#
|
||||
asterisk = *
|
||||
|
||||
# The number of failed authentications before a special animation is played... ;)
|
||||
auth_fails = 10
|
||||
|
||||
# Background color id
|
||||
bg = 0x00000000
|
||||
|
||||
# Change the state and language of the big clock
|
||||
# none -> Disabled (default)
|
||||
# en -> English
|
||||
# fa -> Farsi
|
||||
bigclock = none
|
||||
|
||||
# Blank main box background
|
||||
# Setting to false will make it transparent
|
||||
blank_box = true
|
||||
|
||||
# Border foreground color id
|
||||
border_fg = 0x00FFFFFF
|
||||
|
||||
# Title to show at the top of the main box
|
||||
# If set to null, none will be shown
|
||||
box_title = Login Bro!
|
||||
|
||||
# Brightness increase command
|
||||
brightness_down_cmd = /usr/bin/brightnessctl -q s 10%-
|
||||
|
||||
# Brightness decrease key, or null to disable
|
||||
brightness_down_key = F5
|
||||
|
||||
# Brightness increase command
|
||||
brightness_up_cmd = /usr/bin/brightnessctl -q s +10%
|
||||
|
||||
# Brightness increase key, or null to disable
|
||||
brightness_up_key = F6
|
||||
|
||||
# Erase password input on failure
|
||||
clear_password = false
|
||||
|
||||
# Format string for clock in top right corner (see strftime specification). Example: %c
|
||||
# If null, the clock won't be shown
|
||||
clock = %c
|
||||
|
||||
# CMatrix animation foreground color id
|
||||
cmatrix_fg = 0x0000FF00
|
||||
|
||||
# CMatrix animation minimum codepoint. It uses a 16-bit integer
|
||||
# For Japanese characters for example, you can use 0x3000 here
|
||||
cmatrix_min_codepoint = 0x21
|
||||
|
||||
# CMatrix animation maximum codepoint. It uses a 16-bit integer
|
||||
# For Japanese characters for example, you can use 0x30FF here
|
||||
cmatrix_max_codepoint = 0x7B
|
||||
|
||||
# Color mixing animation first color id
|
||||
colormix_col1 = 0x0000A300
|
||||
|
||||
# Color mixing animation second color id
|
||||
colormix_col2 = 0x00A30000
|
||||
|
||||
# Color mixing animation third color id
|
||||
colormix_col3 = 0x20000000
|
||||
|
||||
# Console path
|
||||
console_dev = /dev/console
|
||||
|
||||
# Input box active by default on startup
|
||||
# Available inputs: info_line, session, login, password
|
||||
default_input = login
|
||||
|
||||
# DOOM animation top color (low intensity flames)
|
||||
doom_top_color = 0x00FF0000
|
||||
|
||||
# DOOM animation middle color (medium intensity flames)
|
||||
doom_middle_color = 0x00FFFF00
|
||||
|
||||
# DOOM animation bottom color (high intensity flames)
|
||||
doom_bottom_color = 0x00FFFFFF
|
||||
|
||||
# Error background color id
|
||||
error_bg = 0x00000000
|
||||
|
||||
# Error foreground color id
|
||||
# Default is red and bold
|
||||
error_fg = 0x01FF0000
|
||||
|
||||
# Foreground color id
|
||||
fg = 0x00FFFFFF
|
||||
|
||||
# Remove main box borders
|
||||
hide_borders = false
|
||||
|
||||
# Remove power management command hints
|
||||
hide_key_hints = false
|
||||
|
||||
# Initial text to show on the info line
|
||||
# If set to null, the info line defaults to the hostname
|
||||
initial_info_text = null
|
||||
|
||||
# Input boxes length
|
||||
input_len = 34
|
||||
|
||||
# Active language
|
||||
# Available languages are found in /etc/ly/lang/
|
||||
lang = en
|
||||
|
||||
# Load the saved desktop and username
|
||||
load = true
|
||||
|
||||
# Command executed when logging in
|
||||
# If null, no command will be executed
|
||||
# Important: the code itself must end with `exec "$@"` in order to launch the session!
|
||||
# You can also set environment variables in there, they'll persist until logout
|
||||
login_cmd = null
|
||||
|
||||
# Command executed when logging out
|
||||
# If null, no command will be executed
|
||||
# Important: the session will already be terminated when this command is executed, so
|
||||
# no need to add `exec "$@"` at the end
|
||||
logout_cmd = null
|
||||
|
||||
# Main box horizontal margin
|
||||
margin_box_h = 2
|
||||
|
||||
# Main box vertical margin
|
||||
margin_box_v = 1
|
||||
|
||||
# Event timeout in milliseconds
|
||||
min_refresh_delta = 5
|
||||
|
||||
# Set numlock on/off at startup
|
||||
numlock = false
|
||||
|
||||
# Default path
|
||||
# If null, ly doesn't set a path
|
||||
path = /sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
|
||||
|
||||
# Command executed when pressing restart_key
|
||||
restart_cmd = /sbin/shutdown -r now
|
||||
|
||||
# Specifies the key used for restart (F1-F12)
|
||||
restart_key = F2
|
||||
|
||||
# Save the current desktop and login as defaults
|
||||
save = true
|
||||
|
||||
# Service name (set to ly to use the provided pam config file)
|
||||
service_name = ly
|
||||
|
||||
# Session log file path
|
||||
# This will contain stdout and stderr of Wayland sessions
|
||||
# By default it's saved in the user's home directory
|
||||
# Important: due to technical limitations, X11 and shell sessions aren't supported, which
|
||||
# means you won't get any logs from those sessions
|
||||
session_log = ly-session.log
|
||||
|
||||
# Setup command
|
||||
setup_cmd = /etc/ly/setup.sh
|
||||
|
||||
# Command executed when pressing shutdown_key
|
||||
shutdown_cmd = /sbin/shutdown -a now
|
||||
|
||||
# Specifies the key used for shutdown (F1-F12)
|
||||
shutdown_key = F1
|
||||
|
||||
# Command executed when pressing sleep key (can be null)
|
||||
sleep_cmd = null
|
||||
|
||||
# Specifies the key used for sleep (F1-F12)
|
||||
sleep_key = F3
|
||||
|
||||
# Center the session name.
|
||||
text_in_center = false
|
||||
|
||||
# TTY in use
|
||||
tty = 1
|
||||
|
||||
# Default vi mode
|
||||
# normal -> normal mode
|
||||
# insert -> insert mode
|
||||
vi_default_mode = insert
|
||||
|
||||
# Enable vi keybindings
|
||||
vi_mode = false
|
||||
|
||||
# Wayland desktop environments
|
||||
# You can specify multiple directories,
|
||||
# e.g. /usr/share/wayland-sessions:/usr/local/share/wayland-sessions
|
||||
waylandsessions = /usr/share/wayland-sessions
|
||||
|
||||
# Xorg server command
|
||||
x_cmd = /usr/bin/X
|
||||
|
||||
# Xorg xauthority edition tool
|
||||
xauth_cmd = /usr/bin/xauth
|
||||
|
||||
# xinitrc
|
||||
# If null, the xinitrc session will be hidden
|
||||
xinitrc = ~/.xinitrc
|
||||
|
||||
# Xorg desktop environments
|
||||
# You can specify multiple directories,
|
||||
# e.g. /usr/share/xsessions:/usr/local/share/xsessions
|
||||
xsessions = /usr/share/xsessions </pre>
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary class="header">/lib/systemd/system/ly.service</summary>
|
||||
|
||||
<pre class="preformatted">
|
||||
[Unit]
|
||||
Description=TUI display manager
|
||||
After=systemd-user-sessions.service getty.target
|
||||
Conflicts=getty@tty1.service
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
ExecStart=/usr/bin/ly
|
||||
StandardInput=tty
|
||||
StandardOutput=tty
|
||||
Restart=always
|
||||
TTYPath=/dev/tty1
|
||||
TTYReset=yes
|
||||
TTYVHangup=yes
|
||||
|
||||
[Install]
|
||||
Alias=display-manager.service </pre>
|
||||
</details>
|
||||
<details>
|
||||
|
||||
<summary class="header">/etc/pam.d/ly</summary>
|
||||
|
||||
<pre class="preformatted">
|
||||
#%PAM-1.0
|
||||
|
||||
auth include login
|
||||
#-auth optional pam_gnome_keyring.so
|
||||
#-auth optional pam_kwallet5.so
|
||||
|
||||
account include login
|
||||
|
||||
password include login
|
||||
#-password optional pam_gnome_keyring.so use_authtok
|
||||
|
||||
#-session optional pam_systemd.so class=greeter
|
||||
#-session optional pam_elogind.so
|
||||
session include login
|
||||
#-session optional pam_gnome_keyring.so auto_start
|
||||
#-session optional pam_kwallet5.so auto_start </pre>
|
||||
</details>
|
||||
|
||||
<p>If for some reason the code I put here renders out badly in HTML and it's hard to copy, I'll have these files up in my dotfiles section on my gitea.</p>
|
||||
|
||||
<p>you can clone all of my dotfiles down and go into the ly directory and you will have the files:</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
git clone https://git.qwik.space/left4code/Dotfiles && cd ly </pre>
|
||||
|
||||
<h4 id=">~(3)" class="blog-header">3. Additional Commands Used</h4>
|
||||
|
||||
<p>This will be in no particular order, but these were some of the commands used, some of them may have an affect on the success of ly running. But I ran them.</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
sudo systemctl disable getty@tty1.service
|
||||
|
||||
sudo systemctl mask getty@tty1.service
|
||||
|
||||
sudo systemctl mask getty@tty2.service
|
||||
|
||||
sudo systemctl mask getty@tty2.service
|
||||
|
||||
sudo rm /etc/systemd/system/display-manager.service</pre>
|
||||
|
||||
|
||||
|
||||
<p>After this, it seems to work, I think login as the default service was loading in above or there was some other display manager stealing the default output from tty1 or tty2, </p>
|
||||
|
||||
<p>you will for sure want to enable ly.service and disable whatever your current display manager's service (lightdm.service in my case)</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
sudo systemctl enable ly.service
|
||||
|
||||
sudo systemctl disable lightdm.service</pre>
|
||||
|
||||
<p>note that stopping lightdm (or your current display manager) with the command below will kick you out of your graphical session if you're in one and you will need to use CTRL + ALT + {F1,F2,F3,F4,F5,F6} if you want to get into a login tty to actually start ly.service</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
sudo systemctl stop <your_display_manager>
|
||||
|
||||
sudo systemctl start ly.service</pre>
|
||||
|
||||
<p>From here pray to the gods that you see something, if you don't then login to a tty session that is available and try just running ly from the terminal and see if you get something, if you don't the ly program might not be in your path or in the /bin or /usr/bin directories or might not be marked as executable.</p>
|
||||
|
||||
<p>If you can start it but upon rebooting you don't get put into ly, it might be the ly pam file or the ly service file make sure the service file is booting into tty1, if what I've provided above doesn't work then you might need to boot, run "sudo journalctl -u ly.service" and see the errors for the most recent ly boot attempt, if there's anything to do with gnome-keyring, it's probably the ly pam file or something else is hooking into the tty you have set for ly to start in by default, which is controlled by the ly service file.</p>
|
||||
|
||||
<h4 id=">~(4)" class="blog-header">4. Conclusion</h4>
|
||||
|
||||
<p>You should probably just use Arch and use ly that way if you want to, or just stick to lightdm, having to tinker around with ly like this can be quite annoying, and not exactly knowing what you're doing can make you appreciate an out-of-the-box working solution.</p>
|
||||
|
||||
<p>To the ly dev. You're cool, I can get to my window manager a bit faster now because of your efforts. Thank you.</p>
|
||||
|
||||
</section>
|
||||
</div>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
@@ -35,13 +35,12 @@
|
||||
|
||||
<h3 class="blog-header">Filesystem Imaging & hashing</h3>
|
||||
<ul>
|
||||
<li><a href="itscoming.html">dd — [🛠️]</a></li>
|
||||
<li><a href="itscoming.html">ddc3dd — [❌]</a></li>
|
||||
<li><a href="filesystem_imaging_forensics/dd.html">dd — [✅]</a></li>
|
||||
<li><a href="filesystem_imaging_forensics/dc3dd.html">dc3dd —[✅]</a></li>
|
||||
<li><a href="itscoming.html">Guymager — [❌]</a></li>
|
||||
<li><a href="itscoming.html">Cyclone — [❌]</a></li>
|
||||
<li><a href="itscoming.html">ddrescue — [❌]</a></li>
|
||||
<li><a href="itscoming.html">ftkimage — [❌]</a></li>
|
||||
<li><a href="itscoming.html">Guymager — [❌]</a></li>
|
||||
<li><a href="itscoming.html">ftkimager — [❌]</a></li>
|
||||
<hr>
|
||||
<li><a href="hash_forensics/gtkhash.html">GtkHash — [✅]</a></li>
|
||||
<li><a href="hash_forensics/shasum.html">sha*sum — [✅]</a></li>
|
||||
@@ -56,7 +55,6 @@
|
||||
<li><a href="itscoming.html">Acquire — [❌]</a></li>
|
||||
<li><a href="itscoming.html">artifactcollector — [❌]</a></li>
|
||||
<li><a href="itscoming.html">AVML — [❌]</a></li>
|
||||
<li><a href="itscoming.html">LiME — [❌]</a></li>
|
||||
<li><a href="itscoming.html">unix_collector — [❌]</a></li>
|
||||
<li><a href="itscoming.html">velociraptor — [❌]</a></li>
|
||||
</ul>
|
||||
@@ -71,8 +69,10 @@
|
||||
|
||||
<h3 class="blog-header">Memory Analysis</h3>
|
||||
<ul>
|
||||
|
||||
<li><a href="itscoming.html">LiME — [❌]</a></li>
|
||||
<li><a href="itscoming.html">Rekall — [❌]</a></li>
|
||||
<li><a href="itscoming.html">volatility — [❌]</a></li>
|
||||
<li><a href="itscoming.html">volatility — [🛠️]</a></li>
|
||||
<li><a href="itscoming.html">volUtility — [❌]</a></li>
|
||||
</ul>
|
||||
<h3 class="blog-header">Common Types of Steganography & Detection</h3>
|
||||
|
||||
145
courses/filesystem_imaging_forensics/dc3dd.html
Normal file
145
courses/filesystem_imaging_forensics/dc3dd.html
Normal file
@@ -0,0 +1,145 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="description" content="dc3dd is a forensic variant of the dd software, it allows on the fly hashing as a feature and different options for output.">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="author" content="Left4Code">
|
||||
<meta name="keywords" content="dc3dd, forensics, dc3dd forensics">
|
||||
<link rel="icon" type="image/x-icon" href="../../favicon/favicon.ico">
|
||||
<title>Left4Code - (Courses) - {dc3dd}</title>
|
||||
<link rel="stylesheet" type="text/css" href='../../style.css'>
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<span>Left4Code</span>
|
||||
</header>
|
||||
<nav>
|
||||
<div>
|
||||
<a href="../../index.html">Home</a>
|
||||
<a href="../../blog.html">Blog</a>
|
||||
</div>
|
||||
</nav>
|
||||
<div class="container">
|
||||
<section>
|
||||
<h1 class="blog-header">dc3dd</h1>
|
||||
<h3>--| Posted: 06-01-25</h3>
|
||||
<h4 class="blog-header">Table of Contents</h4>
|
||||
<div id="toc_container">
|
||||
<hr>
|
||||
<ul class="toc_list">
|
||||
<li><a href="#>~(1)">1. Background Information</a></li>
|
||||
<ul>
|
||||
<li><a href="#>~{1.1}">1.1 Warnings</a></li>
|
||||
<li><a href="#>~{1.2}">1.2 Links Used on This Page</a></li>
|
||||
</ul>
|
||||
<li><a href="#>~(2)">2. Basic dc3dd Usage</a></li>
|
||||
<li><a href="#>~(3)">3. Advanced (Specialized) dc3dd Usage</a></li>
|
||||
<ul>
|
||||
<li><a href="#>~{3.1}">3.1 Understanding the "BASE.FMT" format</a></li>
|
||||
<li><a href="#>~{3.2}">3.2 Multi-Input dc3dd Parameters</a></li>
|
||||
<li><a href="#>~{3.3}">3.3 Wiping Devices with dc3dd</a></li>
|
||||
</ul>
|
||||
<li><a href="#>~(4)">4. Conclusion</a></li>
|
||||
</div>
|
||||
<hr>
|
||||
<h4 id=">~(1)" class="blog-header">1. Background Information</h4>
|
||||
<p>dc3dd is a forensically-expanded version of dd. It should not be used to recover data from damaged drives, <a href="ddrescue.html">ddrescue</a> should be used instead. dc3dd has expanded features which include the following according to the <a href="https://www.kali.org/tools/dc3dd/">Kali Linux Tools Webpage</a>:</p>
|
||||
<p>This guide directly uses information from the dc3dd manual, to find the manual, install dc3dd using your favorite package manager and check the manual.</p>
|
||||
<pre class="preformatted">
|
||||
sudo apt install dc3dd
|
||||
|
||||
man dc3dd</pre>
|
||||
<pre class="preformatted">
|
||||
1: In-program hashing support for md5, sha-1, sha-256, and sha-512 algorithms.
|
||||
|
||||
2: can split output into multiple files.
|
||||
|
||||
3: can wipe a device according to a certain pattern.
|
||||
|
||||
4: write errors to a file.</pre>
|
||||
<p>Additionally, dc3dd can be used to write data to standard output use a string of text as input.</p>
|
||||
<h4 id=">~{1.1}" class="blog-header">1.1 Warnings</h4>
|
||||
<p>Much like <a href="dd.html">dd</a>, you should be careful while using dc3dd, dc3dd posesses the ability to delete all of your data and does not have safety parameters in place to prevent it if a command is mistypes or misunderstood. dc3dd is a motorcycle with extra mirrors, wear a helmet and train in your local parking-lot before diving in head first.</p>
|
||||
<details>
|
||||
<summary id=">~{1.2}" class="blog-header">1.2 Links Used on This Page</summary>
|
||||
<pre class="preformatted">
|
||||
<a href="https://www.kali.org/tools/dc3dd/">▶[https://www.kali.org/tools/dc3dd/]</a>
|
||||
|
||||
◉───╡ dc3dd kali tools description page.
|
||||
|
||||
<a href="dd.html">left4code's dd webpage</a>
|
||||
|
||||
◉───╡ left4code dd page.</pre>
|
||||
</details>
|
||||
<hr>
|
||||
<h4 id=">~(2)" class="blog-header">2. Basic dc3dd Usage</h4>
|
||||
<p>For the initial purposes of this section, I will create a simple test file to show the hashing and logging functionality of dc3dd. dc3dd does not have the <code>'bs='</code> and <code>'count='</code> parameters like dd, so I will use that.</p>
|
||||
<h4 id=">~()">Creates file 'out.dd' from /dev/random input using dd</h4>
|
||||
<pre class="preformatted">
|
||||
dd if=/dev/random of=out.dd bs=1024 count=4 </pre>
|
||||
<p>dc3dd is able to directly calculate the hashes during program execution. An example of this is the following: </p>
|
||||
<h4 id=">~()">Creates file 'dc3dd_test.dc3' from 'out.dd', hashing with sha256</h4>
|
||||
<pre class="preformatted">
|
||||
sudo dc3dd if=out.dd of=dc3dd_test.dc3 hash=sha256 </pre>
|
||||
<p>if you run this command, you will notice that the hash dc3dd produces will only be sent to standard output and will not be actually saved to a file. dc3dd's <code>'log='</code> option can be used to save the hash along with all other information that was outputted to standard output.</p>
|
||||
<h4 id=">~()">Creates file 'dc3dd_test.dc3' from 'out.dd', hashing with sha256, saves output to 'dc3dd_test.log'</h4>
|
||||
<pre class="preformatted">
|
||||
|
||||
sudo dc3dd if=out.dd of=dc3dd_test.dc3 hash=sha256 log=dc3dd_test.log </pre>
|
||||
|
||||
<p>Additionally, there is functionality for logging output of the hashes generated from files and can be specified with the <code>'hlog='</code> parameter. This parameter can be used for multiple files.</p>
|
||||
<h4 id=">~()">Creates file 'dc3dd_test.dc3' from 'out.dd', hashing with sha256, saves output to 'dc3_test.hlog'</h4>
|
||||
<pre class="preformatted">
|
||||
sudo dc3dd if=out.dd of=dc3dd_test.dc3 hash=sha256 hlog=dc3_test.hlog </pre>
|
||||
<p>The <code>'hofs='</code> and BASE.FMT parameters will be used and explained in a little more detail in the section after this one, if you want to log the hash of each output file make from the <code>'hofs='</code> parameter, use the following command:</p>
|
||||
<pre class="preformatted">
|
||||
sudo dc3dd if=out.dd hofs=test.00 hash=sha256 hlog=dc3_test.hlog </pre>
|
||||
<h4 id=">~(3)" class="blog-header">3. Advanced (Specialized) dc3dd Usage</h4>
|
||||
<p>dc3dd has more unique command parameters that are used for more advanced usage of the program.</p>
|
||||
<h4 id=">~{3.1}" class="blog-header">3.1 Understanding the "BASE.FMT" format</h4>
|
||||
<p>Without practically testing out how the "BASE.FMT" format specifier works, it can be quite confusing to read note #5 of the manual for the first time. I will try to explain how the format specifier works in detail because it is required for the <code>'ifs='</code>,<code>'ofs='</code>, and <code>'hofs='</code> parameters.</p>
|
||||
<h4 id=">~()">Note #5 of the dc3dd Manual (BASE.FMT)</h4>
|
||||
<p><code>"4. FMT is a pattern for a sequence of file extensions that can be numerical starting at zero, numerical starting at one, or alphabetical. Specify FMT by using a series of zeros, ones, or a's, respectively. The number of characters used indicates the desired length of the extensions. For example, a FMT specifier of 0000 indicates four character numerical extensions starting with 0000."</code></p>
|
||||
<p>"BASE.FMT" Is essentially "FILENAME.INDEX". Where BASE represents the filename of the file and FMT represents the index type of the file. Which as the outline says, is either "zeros, ones, or a's"</p>
|
||||
<h4 id=">~()">Verbose Understanding of FMT</h4>
|
||||
<p>Below shows the specifier, a parameter example, and the resulting output of the index as it would show up after using <code>ls</code> in the working directory of dc3dd's output.</p>
|
||||
<pre class="preformatted">
|
||||
"zeros" (<code>File.00</code>) = 00,01,02,03,04..99
|
||||
|
||||
"ones" (<code>File.11</code>) = 11,12,13,14..99
|
||||
|
||||
"a's" (<code>File.aa</code>) = aa,ab,ac,ad..zz</pre>
|
||||
<p>As shown from the output, "a's" does not mean hexadecimal (0-9,a-f) as some might assume.</p>
|
||||
<p>Unfortunately, output types do not seem to be combinable and you can not specify 'File.0a' for example. For naming files in this manner, you would need to use external programs. A way this could be done is to use that standard 'File.0' parameter and then write a script to change the end of the filename. </p>
|
||||
<p>The amount of zeros, ones, or a's is able to be changed. The manual explains that 0000 means a format specifier of 4 digit spaces starting at 0000 for the filename.</p>
|
||||
<h4 id=">~{3.2}" class="blog-header">3.2 Multi-Input dc3dd Parameters</h4>
|
||||
<p>dc3dd is able to take multiple input files and combine them into a single output file. This would be useful when you receive a file from someone else that is split, either using the <code>'split'</code> command or the <code>'ofs='</code> parameter in dc3dd.</p>
|
||||
<h4 id=">~()">Creates file 'tf_combined.dc3' from 'tf.00' files.</h4>
|
||||
<pre class="preformatted">
|
||||
dc3dd ifs=tf.00 of=tf_combined.dc3 </pre>
|
||||
<p>dc3dd is also able to take a single input file and split it into multiple output files.</p>
|
||||
<h4 id=">~()">Creates files using 'tf.00' "BASE.FMT" parameter, uses "test.dd" as input, sets output size as 500 bytes</h4>
|
||||
<pre class="preformatted">
|
||||
dc3dd if=test.dd ofs=tf.00 ofsz=500 </pre>
|
||||
<p><code>'ofsz='</code> means "output file size", which is a value you can specify in bytes that will determine the size of each output file fragment.</p>
|
||||
<h4 id=">~{3.3}" class="blog-header">3.3 Wiping Devices with dc3dd</h4>
|
||||
<p>dc3dd can be used to overwrite devices with data using different patterns or text some examples of this use are shown below:</p>
|
||||
<h4 id=">~()">Overwrites device using <code>'tpat='</code> parameter and string "L4C". </h4>
|
||||
<pre class="preformatted">
|
||||
sudo dc3dd wipe=/dev/<drive> tpat=L4C </pre>
|
||||
<p>Additionally, if you want to write a certain hexadecimal value to the drive when wiping, you can use the <code>'pat='</code> parameter followed by your hex values</p>
|
||||
<h4 id=">~()">Overwrites device using <code>'pat='</code> parameter and HEX value 2B.</h4>
|
||||
<pre class="preformatted">
|
||||
sudo dc3dd wipe=/dev/<drive> pat=2B </pre>
|
||||
<p>dc3dd is also able to use hashing to verify if a drive is wiped (by comparing the input and output hashes after the wipe is completed).</p>
|
||||
<h4 id=">~()">Overwrites device using <code>'pat='</code> parameter and HEX value 2C. Uses <code>'hwipe='</code> to verify wipe.</h4>
|
||||
<pre class="preformatted">
|
||||
sudo dc3dd hwipe=/dev/<drive> hash=sha256 pat=2C </pre>
|
||||
<p>the same log parameters can also be appended to this command which will save the output of the hash to a file. Additionally in the output of the command when using hwipe, the input and output will be checked against eachother and if all bytes were copied from the input to the output sucessfully, dc3dd will give an '[ok]' in its output.</p>
|
||||
<h4 id=">~(4)" class="blog-header">4. Conclusion</h4>
|
||||
<p>This concludes the main usage for dc3dd in most forensic situations. There are however some things that I did not got over in this guide and it is recommended that you check the manual to see if a specific parameter not mentioned here is functionally available in dc3dd.</p>
|
||||
</section>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
299
courses/filesystem_imaging_forensics/dd.html
Normal file
299
courses/filesystem_imaging_forensics/dd.html
Normal file
@@ -0,0 +1,299 @@
|
||||
|
||||
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="description" content="dd is part of the gnu core utilities. It can be used to create or copy block data from different devices or files.">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<meta name="author" content="Left4Code">
|
||||
<meta name="keywords" content="dd, gnu dd">
|
||||
<link rel="icon" type="image/x-icon" href="../../favicon/favicon.ico">
|
||||
<title>Left4Code - (Courses) - {dd}</title>
|
||||
<link rel="stylesheet" type="text/css" href='../../style.css'>
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<span>Left4Code</span>
|
||||
</header>
|
||||
|
||||
<nav>
|
||||
<div>
|
||||
<a href="../../index.html">Home</a>
|
||||
<a href="../../blog.html">Blog</a>
|
||||
</div>
|
||||
</nav>
|
||||
|
||||
<div class="container">
|
||||
<section>
|
||||
<h1 class="blog-header">dd</h1>
|
||||
<h3>--| Posted: 05-06-25</h3>
|
||||
|
||||
<h4 class="blog-header">Table of Contents</h4>
|
||||
<div id="toc_container">
|
||||
<hr>
|
||||
<ul class="toc_list">
|
||||
<li><a href="#>~(1)">1. Background Information</a></li>
|
||||
<ul>
|
||||
<li><a href="#>~{1.1}">1.1 Warnings</a></li>
|
||||
<li><a href="#>~{1.2}">1.2 Links Used on This Page</a></li>
|
||||
<li><a href="#>~{1.3}">1.3 How A Hard Disk Drive Works (Optional)</a></li>
|
||||
</ul>
|
||||
<li><a href="#>~(2)">2. DD Usage</a></li>
|
||||
<ul>
|
||||
<li><a href="#>~{2.1}">2.1 Additional Parameters</a></li>
|
||||
</ul>
|
||||
<li><a href="#>~(3)">3. Read-only Mounting of a Drive</a></li>
|
||||
<ul>
|
||||
|
||||
<li><a href="#>~{3.1}">3.1 Warnings for Mounting a Drive as Read-only</a></li>
|
||||
|
||||
</ul>
|
||||
<li><a href="#>~(4)">4. Example of dd Usage with Parameters</a></li>
|
||||
<li><a href="#>~(5)">5. Using Hashing with dd</a></li>
|
||||
<li><a href="#>~(6)">6. Conclusion</a></li>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
<hr>
|
||||
|
||||
|
||||
|
||||
<h4 id=">~(1)" class="blog-header">1. Background Information</h4>
|
||||
|
||||
<p>dd is part of the gnu core utilities. It can be used to create or copy block data from different devices or files.</p>
|
||||
|
||||
<p>For the purposes of this course, I will show how to copy data from a partition or entire drive to an image file, and how to write random data to an image file.</p>
|
||||
|
||||
<h4 id=">~{1.1}" class="blog-header">1.1 Warnings</h4>
|
||||
|
||||
<p>Most programs you use on a daily basis can be compared to a car, it has seatbelts, a (hopefully) strong exterior, and if your car is a bit newer, sensors for road obstructions. This could be programs like Firefox, your GUI calculator software, and that fun video game.</p>
|
||||
|
||||
<p>dd is not like this, dd can be compared more to a motorcycle than a car. dd is a small program prioritizing efficiency and has little to no safety measures. Much like a motorcycle, you should learn to use dd in a safe environment where potential damage is minimized. You should also bring a helmet too. (understanding of commands, virtual environment, patience.)</p>
|
||||
|
||||
|
||||
<details>
|
||||
<summary id=">~{1.2}" class="blog-header">1.2 Links Used on This Page</summary>
|
||||
|
||||
<pre class="preformatted">
|
||||
<a href="https://en.wikipedia.org/wiki/Hard_disk_drive?lang=en">▶[https://en.wikipedia.org/wiki/Hard_disk_drive?lang=en]</a>
|
||||
|
||||
◉───╡ Wikipedia Link for How a Hard Drive Works.
|
||||
|
||||
<a href="https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html">▶[https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html]</a>
|
||||
|
||||
◉───╡ dd GNU coreutils manual.
|
||||
|
||||
<a href="https://maizure.org/projects/decoded-gnu-coreutils/index.html">▶[https://maizure.org/projects/decoded-gnu-coreutils/index.html]</a>
|
||||
|
||||
◉───╡ A Project which explains the GNU coreutil functionality from a programmers perspective (written by MaiZure, my hero.)
|
||||
|
||||
<a href="https://youtube.com/channel/UCnjRWRyHTLZo5l7cfq04Uwg">▶[https://youtube.com/channel/UCnjRWRyHTLZo5l7cfq04Uwg]</a>
|
||||
|
||||
◉───╡ MaiZure's Youtube Channel.
|
||||
|
||||
<a href="https://dfir.ru/2018/07/21/a-live-forensic-distribution-executing-malicious-code-from-a-suspect-drive/">https://dfir.ru/2018/07/21/a-live-forensic-distribution-executing-malicious-code-from-a-suspect-drive/</a>
|
||||
|
||||
◉───╡ Maxim Suhanov's PoC for malicious code from a drive being executed in a live forensic distribution.
|
||||
|
||||
<a href="https://dfir.ru/2018/07/25/a-live-forensic-distribution-writing-to-a-suspect-drive/">https://dfir.ru/2018/07/25/a-live-forensic-distribution-writing-to-a-suspect-drive/</a>
|
||||
|
||||
◉───╡ Maxim Suhanov's Additional implications for the PoC.</pre>
|
||||
|
||||
|
||||
</details>
|
||||
<hr>
|
||||
<details>
|
||||
|
||||
|
||||
<summary id=">~{1.3}" class="blog-header">1.3 How A Hard Disk Drive (HDD) Works (Click to Expand)</summary>
|
||||
<p>A HDD consist of the following major components:</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
1. Platter: Magnetic glass disk responsible for storing binary data in a non-volatile way.
|
||||
|
||||
2. Spindle: The thing that holds a single platter or multiple platters together.
|
||||
|
||||
3. Actuator: Magnetic Motor responsible for controlling the actuator arm and read/write head for precise data operation.
|
||||
|
||||
4. Actuator Arm: holds the read/write head
|
||||
|
||||
5. read/write head: an Electromagnet responsible for writing ones and zeros to the platter.</pre>
|
||||
|
||||
<p>The hard disk will begin by spinning up to around 5,400 or 7,200 RPM.</p>
|
||||
|
||||
<p>Physically on the disk, the platter is grouped up into sectors which are readable by the disk firmware.</p>
|
||||
|
||||
<p>When an operating system is installed into the disk, the entire boot process is run and the disk IO process is mainly managed by the kernel and operating system filestructure schemes, which are for example: NTFS, ext4, btrfs.</p>
|
||||
|
||||
<p>When a program on the operating system requires the use of the disk, this is managed by the kernel through system calls, which are the layer of abstraction between the user and the kernel.</p>
|
||||
|
||||
<p>normally, a program will call a wrapper function in a standard library (glibc, musl) and this function will then invoke the system call to the kernel.</p>
|
||||
|
||||
<p>In the Case of dd, (I'm not 100% on this, I'm really bad at reading C code I haven't written) the program uses the internal functions iread and iread_fullblock to read data from a file and put it into a buffer, then writing it to the output parameter. the iread function seems to call read(). By default, dd will write in 512-byte blocks. </p>
|
||||
|
||||
<p>After doing some searching, I found <a href="https://maizure.org/projects/decoded-gnu-coreutils/index.html">MaiZure's graphical guide for the GNU coreutils</a> This project has to be one of the most underrated things ever. I can not thank this person enough for the work they have done here. Just amazing. Seriously, Amazing. </p>
|
||||
|
||||
<p>It covers all relevant GNU coreutils in a way that is super easy to understand, providing graphical representations of the control flow of the program. MaiZure also outlined all of the functions and literally broke everything down.</p>
|
||||
|
||||
<p>MaiZure also has a <a href="https://youtube.com/channel/UCnjRWRyHTLZo5l7cfq04Uwg">Youtube channel</a>. Support and learn!</p>
|
||||
|
||||
<p>I guess that serves as my personal thank you to MaiZure since I'm silly and can't figure out how to contact you directly.</p>
|
||||
|
||||
|
||||
</details>
|
||||
<hr>
|
||||
|
||||
<h4 id=">~(2)" class="blog-header">2. DD Usage</h4>
|
||||
|
||||
<p>The standard dd usage for most forensic purposes is the following:</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
dd if=<input> of=<output> </pre>
|
||||
|
||||
<p>This command will function to copy all bytes from the specified input file to the specified output file. By default, dd will copy 512 bytes of information from the input file to the output file at a time.</p>
|
||||
|
||||
|
||||
<p>The general format for dd follows the old IBM Job Control Language parameters, which is why this may look different from the standard flag-style "<b>-</b>" or "<b>--</b>" system.</p>
|
||||
|
||||
<h4 id=">~{2.1}" class="blog-header">2.1 Additional Parameters</h4>
|
||||
|
||||
<p>dd parameters are able to manipulate the placement, input, and output of data. </p>
|
||||
|
||||
<p>the parameters you would probably only be using for a forensic investigation would be:</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
'if' (input file) - the file that dd will copy data from. Default is stdin.
|
||||
|
||||
'of' (output file) - the file that dd will copy data to.
|
||||
|
||||
'bs' (byte size) - the rate of bytes transferred from 'if' to 'of'. Default is 512 Bytes.
|
||||
|
||||
'count' - the amount of times a transfer of the value assigned to 'bs' will happen.
|
||||
|
||||
the 'noerror' convention - dd will continue to operate despite a read error.
|
||||
|
||||
the 'excl' convention - if the file specified in 'of' already exists, dd will not overwrite it.
|
||||
|
||||
the 'progress' status convention - will show the progress of longer file copying procedures.</pre>
|
||||
|
||||
<h4 id=">~(3)" class="blog-header">3. Read-only Mounting of a Drive</h4>
|
||||
|
||||
<p>In a forensic situation, you would want to make sure you are mounting the drive in read only mode, you would do this by first running:</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
blockdev --setro </pre>
|
||||
|
||||
<p>After, you would then mount the device like this:</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
sudo mount -o ro,noreload /dev/<partition> </pre>
|
||||
|
||||
<p>the device should then be able to be only read from and should not be modified for the most part.</p>
|
||||
|
||||
<h4 id=">~{3.1}" class="blog-header">3.1 Warnings for Mounting a Drive as Read-only</h4>
|
||||
|
||||
<p>NOTE: It is quite hard to 100% mark a device as read-only when doing a forensic investigation. As detailed in the readme for a Linux kernel patch for software write blocking which modifies the block device driver to check for read only conditions more, <a href="https://github.com/msuhanov/Linux-write-blocker">the issue is quite complex</a> and there are many potential problems that could arise from both userland processes and the actual block device driver or operating system fighting you and modifying or clearing data.</p>
|
||||
|
||||
|
||||
|
||||
<p>Using a forensically-focused Linux distribution which supports software write-blocking is a wise decision instead of trying to manually patch your kernel if you're using a different distribution. Tsurugi Linux supports such a feature natively and will block write access and open drives in read-only mode by default.</p>
|
||||
|
||||
<p>Out of curiosity, I was wondering what the difference is between how Tsurugi Linux handles this issue and how the kernel patch handles this issue. So I contacted the Tsurugi Linux developers for some insight. The Project founder of Tsurugi Linux, 'sug4r' informed me of the following:</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
1: Tsurugi Linux uses their own write-blocker system, and originally used the previously linked github patch
|
||||
|
||||
2: Tsurugi Linux will build a dirty filesystem for ext4 and check the hash before and after mounting the image.</pre>
|
||||
|
||||
<p>This ensures that the chance that writing to the drive is heavily minimized and there should be no problems.</p>
|
||||
|
||||
<p>Huge thanks to sug4r for replying to my message, I probably wouldn't have found the answer to my question without it.</p>
|
||||
|
||||
<p>If you would like to read the initial articles by Maxim Suhanov which describes executing malicious code on a target hard drive from a forensic live Linux distribution, they are here:</p>
|
||||
|
||||
<pre class="preformatted">
|
||||
<a href="https://dfir.ru/2018/07/21/a-live-forensic-distribution-executing-malicious-code-from-a-suspect-drive/">The initial article</a>
|
||||
|
||||
<a href="https://dfir.ru/2018/07/25/a-live-forensic-distribution-writing-to-a-suspect-drive/">Additional article explaining further implications</a></pre>
|
||||
|
||||
<p>Maxim has a lot of very interesting blog posts at <a href="https://dfir.ru">dfir.ru</a>. If anything from there interests you, I highly recommend you read it.</p>
|
||||
|
||||
<h4 id=">~(4)" class="blog-header">4. Example of dd Usage with Parameters</h4>
|
||||
|
||||
<p>Let's start by making a test input file. As the reader, you can make this however you want. Personally, typing some funny stuff into a text file seems like the best way. But for the purposes of using dd, you can generate a file of any chosen size using /dev/random.</p>
|
||||
|
||||
<p>the command below will generate a file 4Kb in size using data from /dev/random as the input and will place the output file in the current directory you are operating in. /dev/random is a special virtual device on Linux that will produce random data:</p>
|
||||
<h4>Creates a 4Kb file named "testfile.txt".</h4>
|
||||
<pre class="preformatted">
|
||||
dd if=/dev/random of=testfile.txt bs=1024 count=4 </pre>
|
||||
|
||||
<p>upon examining the file, you will notice that the data in the file is not made up entirely of human-readable ASCII, if you would like to make a file that is made up of random ASCII data, you can use the following command:</p>
|
||||
|
||||
<h4>Creates a 4Kb File Named "testfile.txt" Filled only with ASCII Readable Text.</h4>
|
||||
<pre class="preformatted">
|
||||
tr -dc [:alnum:] </dev/random | head -c 4096 > testfile.txt </pre>
|
||||
|
||||
<p>This command sequence will take input from /dev/random and use tr to only take alphanumeric characters as defined by "[:alnum:]", this output will then be sent to head, where it will load 4096 bytes of the translated output into testfile.txt</p>
|
||||
|
||||
|
||||
<p>the 'ucase' and 'lcase' conventions can be used to modify data at the block level from lower-case to upper-case and vice-versa.</p>
|
||||
|
||||
<h4>Converts the Content from <testfile_created> to Uppercase.</h4>
|
||||
<pre class="preformatted">
|
||||
dd if=<testfile_created> of=<testfile_created>_new.txt conv=ucase </pre>
|
||||
|
||||
<p>for forensics, dd can be used to create image files from entire disks or disk partitions on the system. These image files can then be processed by other forensic tools like Autopsy or Foremost.</p>
|
||||
|
||||
<h4>Puts Contents from /dev/sda Into an Image File Using noerror Convention.</h4>
|
||||
<pre class="preformatted">
|
||||
sudo dd if=/dev/sda of=sda_image.dd bs=4096 conv=noerror status=progress </pre>
|
||||
|
||||
<p>This example will make a complete copy of the entire /dev/sda drive and save the output to the image file "sda_image.dd"</p>
|
||||
|
||||
<p>additionally, individual partitions can be copied like so:</p>
|
||||
|
||||
<h4>Copies Content from /dev/sda1 Partition to Image File.</h4>
|
||||
<pre class="preformatted">
|
||||
sudo dd if=/dev/sda1 of=sda1_image.dd bs=4096 status=progress </pre>
|
||||
|
||||
|
||||
<h4 id=">~(5)" class="blog-header">5. Using Hashing with dd</h4>
|
||||
|
||||
<p>When you only have the choice to use dd for data acquisition, the method used for hashing is generally as follows:</p>
|
||||
|
||||
<h5 id=">()" class="blog-header">1: Take a Hash of the Drive you Intend to Make a Copy of</h5>
|
||||
|
||||
|
||||
<p>If you do not understand what I mean when I use "sha*sum" in the command, please refer to the beginning of the 'sha*sum' page for context.</p>
|
||||
|
||||
|
||||
<pre class="preformatted">
|
||||
sha*sum /dev/sdX </pre>
|
||||
|
||||
<h5 id=">()" class="blog-header">2: Use dd to Copy the Contents of the Drive to an Image File</h5>
|
||||
|
||||
<pre class="preformatted">
|
||||
dd if=/dev/sdX of=<outputfile.dd> </pre>
|
||||
|
||||
<h5 id=">()" class="blog-header">3: Calculate the Hash of the Resulting Output File</h5>
|
||||
|
||||
|
||||
<pre class="preformatted">
|
||||
sha*sum <outputfile.dd> </pre>
|
||||
|
||||
<h5 id=">()" class="blog-header">4: Compare the Hash of the /dev/sdX Drive to the <outputfile.dd> file</h5>
|
||||
|
||||
<p>You should make sure the hash of the drive and the image file match</p>
|
||||
|
||||
<h4 id=">~(6)" class="blog-header">6. Conclusion</h4>
|
||||
|
||||
<p>This concludes the general usage of dd for a forensic application. Additional tooling using the original dd framework with extended features such as ddrescue, dcfldd, or ddc3dd will be subsequently covered.</p>
|
||||
|
||||
</section>
|
||||
</div>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
|
||||
408
style.css
408
style.css
@@ -1,193 +1,215 @@
|
||||
html {
|
||||
margin: 0;
|
||||
height: 100%;
|
||||
background-repeat: no-repeat;
|
||||
}
|
||||
:root {
|
||||
--text: #e0e0e0;
|
||||
--border: #4a4a4a;
|
||||
--accent: #b03e3e;
|
||||
--bg: #1e1e1e;
|
||||
--gradientTop: #3a3a3a;
|
||||
--gradientBottom: #2c2c2c;
|
||||
}
|
||||
|
||||
* {
|
||||
box-sizing: border-box;
|
||||
}
|
||||
body {
|
||||
padding: 10px;
|
||||
font-family: sans-serif;
|
||||
color: var(--text);
|
||||
background: #1e1e1e;
|
||||
background-repeat: no-repeat;
|
||||
background-attachment: fixed;
|
||||
}
|
||||
.container {
|
||||
width: 95%;
|
||||
margin: 5vw auto 12px auto;
|
||||
border: 10px ridge var(--border);
|
||||
outline: 5px solid var(--border);
|
||||
outline-offset: 4px;
|
||||
border-radius: 10px;
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
padding: 5px;
|
||||
gap: 5px;
|
||||
background-image: linear-gradient(135deg, var(--gradientTop), var(--gradientBottom));
|
||||
min-height: 500px;
|
||||
}
|
||||
.small { flex: 1 1 9%; }
|
||||
.large { flex: 1 1 82%; }
|
||||
.full { flex: 1 1 100%; }
|
||||
.half { flex: 1 1 49%; }
|
||||
header {
|
||||
background-size: cover;
|
||||
background-position: center;
|
||||
width: 100%;
|
||||
height: 190px;
|
||||
border: 2px ridge var(--border);
|
||||
border-radius: 5px;
|
||||
position: relative;
|
||||
background-image: linear-gradient(135deg, var(--gradientTop), var(--gradientBottom));
|
||||
display: flex;
|
||||
justify-content: center;
|
||||
align-items: center;
|
||||
}
|
||||
header span {
|
||||
font-size: 2.5rem;
|
||||
font-weight: bold;
|
||||
text-shadow: 1px 1px black,
|
||||
-1px 1px black,
|
||||
1px -1px black,
|
||||
-1px -1px black;
|
||||
color: var(--accent);
|
||||
text-align: center;
|
||||
}
|
||||
nav {
|
||||
text-align: center;
|
||||
border: 2px ridge var(--border);
|
||||
border-radius: 5px;
|
||||
padding: 5px;
|
||||
background: linear-gradient(var(--gradientTop), var(--gradientBottom));
|
||||
}
|
||||
nav div {
|
||||
text-align: center;
|
||||
font-size: 1.25rem;
|
||||
margin: 5px 5px 10px 5px;
|
||||
}
|
||||
nav a {
|
||||
display: block;
|
||||
margin: 5px;
|
||||
background: linear-gradient(to right, #4a4a4a, #4a4a4a);
|
||||
border-radius: 5px;
|
||||
padding: 2px 4px;
|
||||
text-decoration: none;
|
||||
}
|
||||
nav a:link, nav a:visited {
|
||||
color: var(--text);
|
||||
}
|
||||
nav a:hover, nav a:focus {
|
||||
background: linear-gradient(to right, var(--bg), var(--gradientBottom), var(--gradientTop));
|
||||
}
|
||||
div.small > img {
|
||||
display: block;
|
||||
margin: 5px auto;
|
||||
border: 2px ridge var(--border);
|
||||
border-radius: 5px;
|
||||
}
|
||||
section {
|
||||
width: 100%;
|
||||
border: 2px ridge var(--border);
|
||||
border-radius: 5px;
|
||||
background-image: linear-gradient(135deg, var(--gradientTop), var(--gradientBottom));
|
||||
padding: 5px;
|
||||
}
|
||||
footer {
|
||||
text-align: center;
|
||||
margin-bottom: 5vw;
|
||||
font-size: 0.8rem;
|
||||
}
|
||||
h1, h2, h3, h4, h5, h6, p {
|
||||
margin: 5px;
|
||||
line-height: 1.2;
|
||||
}
|
||||
h1 {
|
||||
font-size: 1.4rem;
|
||||
letter-spacing: 2px;
|
||||
font-weight: normal;
|
||||
text-align: center;
|
||||
border-bottom: 2px ridge var(--border);
|
||||
padding-bottom: 5px;
|
||||
}
|
||||
h2 {
|
||||
font-size: 1.25rem;
|
||||
font-weight: normal;
|
||||
text-align: center;
|
||||
margin-top: 20px;
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
h3 {
|
||||
font-size: 1.1rem;
|
||||
margin-top: 20px;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
h4 {
|
||||
font-size: 1rem;
|
||||
color: var(--accent);
|
||||
margin-top: 10px;
|
||||
margin-bottom: 5px;
|
||||
}
|
||||
h6 {
|
||||
font-size: 2rem;
|
||||
letter-spacing: 0.3px;
|
||||
font-weight: bold;
|
||||
text-align: center;
|
||||
border-bottom: 2px ridge var(--border);
|
||||
padding-bottom: 5px;
|
||||
white-space: pre;
|
||||
color: var(--accent);
|
||||
}
|
||||
.preformatted {
|
||||
background-color: #2c2c2c;
|
||||
color: var(--text);
|
||||
padding: 10px;
|
||||
border: 1px solid var(--border);
|
||||
border-radius: 5px;
|
||||
overflow-x: auto;
|
||||
white-space: pre-wrap;
|
||||
|
||||
}
|
||||
img { max-width: 100%; }
|
||||
pre { overflow-x: auto; }
|
||||
a:hover, a:focus, a:hover, a {
|
||||
color: var(--accent);
|
||||
font-style: normal;
|
||||
font-weight: bold;
|
||||
}
|
||||
hr.new1 {
|
||||
border-top: 1px solid red;
|
||||
}
|
||||
pre {
|
||||
background-color: #2c2c2c;
|
||||
color: var(--text);
|
||||
padding: 10px;
|
||||
border: 1px solid var(--border);
|
||||
border-radius: 5px;
|
||||
}
|
||||
.blog-header {
|
||||
background-color: var(--gradientTop);
|
||||
color: var(--text);
|
||||
padding: 10px;
|
||||
border-radius: 5px;
|
||||
margin-bottom: 20px;
|
||||
text-align: center;
|
||||
font-weight: bold;
|
||||
box-shadow: 0 2px 5px rgba(0, 0, 0, 0.5);
|
||||
}
|
||||
p {
|
||||
margin-bottom: 15px; /* Adjust the value as needed */
|
||||
}
|
||||
white-space: pre-wrap;
|
||||
|
||||
|
||||
html {
|
||||
margin: 0;
|
||||
height: 100%;
|
||||
background-repeat: no-repeat;
|
||||
}
|
||||
:root {
|
||||
--text: #e0e0e0;
|
||||
--border: #4a4a4a;
|
||||
--accent: #cc0000;
|
||||
--bg: #1e1e1e;
|
||||
--gradientTop: #3a3a3a;
|
||||
--gradientBottom: #2c2c2c;
|
||||
}
|
||||
|
||||
* {
|
||||
box-sizing: border-box;
|
||||
}
|
||||
body {
|
||||
padding: 10px;
|
||||
font-family: sans-serif;
|
||||
color: var(--text);
|
||||
background: #1e1e1e;
|
||||
background-repeat: no-repeat;
|
||||
background-attachment: fixed;
|
||||
}
|
||||
.container {
|
||||
width: 95%;
|
||||
margin: 5vw auto 12px auto;
|
||||
border: 10px ridge var(--border);
|
||||
outline: 5px solid var(--border);
|
||||
outline-offset: 4px;
|
||||
border-radius: 10px;
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
padding: 5px;
|
||||
gap: 5px;
|
||||
background-image: linear-gradient(135deg, var(--gradientTop), var(--gradientBottom));
|
||||
min-height: 500px;
|
||||
}
|
||||
.small { flex: 1 1 9%; }
|
||||
.large { flex: 1 1 82%; }
|
||||
.full { flex: 1 1 100%; }
|
||||
.half { flex: 1 1 49%; }
|
||||
header {
|
||||
background-size: cover;
|
||||
background-position: center;
|
||||
width: 100%;
|
||||
height: 190px;
|
||||
border: 2px ridge var(--border);
|
||||
border-radius: 5px;
|
||||
position: relative;
|
||||
background-image: linear-gradient(135deg, var(--gradientTop), var(--gradientBottom));
|
||||
display: flex;
|
||||
justify-content: center;
|
||||
align-items: center;
|
||||
}
|
||||
header span {
|
||||
font-size: 2.5rem;
|
||||
font-weight: bold;
|
||||
text-shadow: 1px 1px black,
|
||||
-1px 1px black,
|
||||
1px -1px black,
|
||||
-1px -1px black;
|
||||
color: var(--accent);
|
||||
text-align: center;
|
||||
}
|
||||
nav {
|
||||
text-align: center;
|
||||
border: 2px ridge var(--border);
|
||||
border-radius: 5px;
|
||||
padding: 5px;
|
||||
background: linear-gradient(var(--gradientTop), var(--gradientBottom));
|
||||
}
|
||||
nav div {
|
||||
text-align: center;
|
||||
font-size: 1.25rem;
|
||||
margin: 5px 5px 10px 5px;
|
||||
}
|
||||
nav a {
|
||||
display: block;
|
||||
margin: 5px;
|
||||
background: linear-gradient(to right, #4a4a4a, #4a4a4a);
|
||||
border-radius: 5px;
|
||||
padding: 2px 4px;
|
||||
text-decoration: none;
|
||||
}
|
||||
nav a:link, nav a:visited {
|
||||
color: var(--text);
|
||||
}
|
||||
nav a:hover, nav a:focus {
|
||||
background: linear-gradient(to right, var(--bg), var(--gradientBottom), var(--gradientTop));
|
||||
}
|
||||
div.small > img {
|
||||
display: block;
|
||||
margin: 5px auto;
|
||||
border: 2px ridge var(--border);
|
||||
border-radius: 5px;
|
||||
}
|
||||
section {
|
||||
width: 100%;
|
||||
border: 2px ridge var(--border);
|
||||
border-radius: 5px;
|
||||
background-image: linear-gradient(135deg, var(--gradientTop), var(--gradientBottom));
|
||||
padding: 5px;
|
||||
}
|
||||
footer {
|
||||
text-align: center;
|
||||
margin-bottom: 5vw;
|
||||
font-size: 0.8rem;
|
||||
}
|
||||
h1, h2, h3, h4, h5, h6, p {
|
||||
margin: 5px;
|
||||
line-height: 1.2;
|
||||
}
|
||||
h1 {
|
||||
font-size: 1.4rem;
|
||||
letter-spacing: 2px;
|
||||
font-weight: normal;
|
||||
text-align: center;
|
||||
border-bottom: 2px ridge var(--border);
|
||||
padding-bottom: 5px;
|
||||
}
|
||||
h2 {
|
||||
font-size: 1.25rem;
|
||||
font-weight: normal;
|
||||
text-align: center;
|
||||
margin-top: 20px;
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
h3 {
|
||||
font-size: 1.1rem;
|
||||
margin-top: 20px;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
h4 {
|
||||
font-size: 1rem;
|
||||
color: var(--accent);
|
||||
margin-top: 10px;
|
||||
margin-bottom: 5px;
|
||||
}
|
||||
h6 {
|
||||
font-size: 2rem;
|
||||
letter-spacing: 0.3px;
|
||||
font-weight: bold;
|
||||
text-align: center;
|
||||
border-bottom: 2px ridge var(--border);
|
||||
padding-bottom: 5px;
|
||||
white-space: pre;
|
||||
color: var(--accent);
|
||||
}
|
||||
.preformatted {
|
||||
background-color: #2c2c2c;
|
||||
color: var(--text);
|
||||
padding: 10px;
|
||||
border: 1px solid var(--border);
|
||||
border-radius: 5px;
|
||||
overflow-x: auto;
|
||||
white-space: pre-wrap;
|
||||
|
||||
}
|
||||
img { max-width: 100%; }
|
||||
pre { overflow-x: auto; }
|
||||
a:hover, a:focus, a:hover, a {
|
||||
color: var(--accent);
|
||||
font-style: normal;
|
||||
font-weight: bold;
|
||||
}
|
||||
hr.new1 {
|
||||
border-top: 1px solid red;
|
||||
}
|
||||
pre {
|
||||
background-color: #2c2c2c;
|
||||
color: var(--text);
|
||||
padding: 10px;
|
||||
border: 1px solid var(--border);
|
||||
border-radius: 5px;
|
||||
}
|
||||
.blog-header {
|
||||
background-color: var(--gradientTop);
|
||||
color: var(--text);
|
||||
padding: 10px;
|
||||
border-radius: 5px;
|
||||
margin-bottom: 20px;
|
||||
text-align: center;
|
||||
font-weight: bold;
|
||||
box-shadow: 0 2px 5px rgba(0, 0, 0, 0.5);
|
||||
}
|
||||
.header {
|
||||
font-size: 1rem;
|
||||
color: var(--accent);
|
||||
margin-top: 10px;
|
||||
margin-bottom: 5px;
|
||||
}
|
||||
table {
|
||||
width: 100%;
|
||||
border-collapse: collapse;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
td {
|
||||
border: 1px solid #ccc;
|
||||
padding: 10px;
|
||||
text-align: left;
|
||||
}
|
||||
td.term {
|
||||
color: #f08080;
|
||||
}
|
||||
|
||||
td.def {
|
||||
color: var(--text);
|
||||
}
|
||||
p {
|
||||
margin-bottom: 15px;
|
||||
}
|
||||
white-space: pre-wrap;
|
||||
|
||||
|
||||
Reference in New Issue
Block a user