TriceHelix

Decoding Input Device (evdev) Capabilities on Linux

Introduction

Input devices (whether physically present, or emulated) may produce any "kind" of input. In other words there is no clear distinction between a keyboard and a mouse, other than the data they (i.e., their drivers) write to their corresponding /dev/input/eventX file (where X is an integer). That can be problematic sometimes, for example if a program in userspace consumes input data from a device and expects that data to only contain certain keycodes, event types, etc. Another example could be a video game which displays different sprites/text when a gamepad is used instead of a keyboard, like key/button prompts in a tutorial or a settings menu. Luckily, most devices only write a strict set of event types and codes to their eventX file, because well, most hardware is only a keyboard, or mouse, or gamepad, or touchscreen, etc. and not a wild combination. The kernel calls these the input device's capabilities, as documented [here](ht

martin-mael

// Tailwind colors for Flexoki theme by Steph Ango. https://stephango.com/flexoki

const colors = {
  base: {
    black: '#100F0F',
    950: '#1C1B1A',
    900: '#282726',
    850: '#343331',
    800: '#403E3C',
    700: '#575653',

kaleidawave

Trying Ezno checking today

This a short overview of some of the things you can do with Ezno today. If you find any problems, file an issue.

The following examples show some errors that have been caught using type checking, partial/const evaluation and effects.

To get started we will install oxidation-compiler which has bindings for Ezno's checker. (you can also get the binary from the releases page).

npm install -g oxidation-compiler@latest

recmo

#![cfg(all(target_arch = "aarch64", target_feature = "sha3"))]
use core::arch::asm;

const RC: [u64; 24] = [
    0x0000000000000001,
    0x0000000000008082,
    0x800000000000808a,
    0x8000000080008000,
    0x000000000000808b,
    0x0000000080000001,

engn33r

#!/bin/bash

# This script is a hacked together PoC, don't trust it to work well
# For proper detection of vulnerable contracts, recursive testing must be performed because CREATE2 in a contract's ancestry could be problematic: https://medium.com/@jason.carver/defend-against-wild-magic-in-the-next-ethereum-upgrade-b008247839d2#3f90
# Improved tool and full research coming from yAcademy next month: https://twitter.com/yAcademyDAO

contract_addr="0x0d4a11d5eeaac28ec3f61d100daf4d40471f1852" # default value is a uniswap V2 pair from https://v2.info.uniswap.org/pairs
etherscan_api_key=""

if [[ -z "$etherscan_api_key" ]]; then

ttesmer

{-# LANGUAGE TypeSynonymInstances #-}
data Dual d = D Float d deriving Show
type Float' = Float

diff :: (Dual Float' -> Dual Float') -> Float -> Float'
diff f x = y'
  where D y y' = f (D x 1)

class VectorSpace v where
  zero  :: v

Saw-mon-and-Natalie

# ▇ => ▇ + ▇
# Minimal runtime bytecode for a contract that mutates 
# into two child contracts and then self-destructs
# 1st child contract receives the call value
# 2nd child contract recevies the remaining balance
# author: Saw-mon and Natalie

# constructor payload for the spawned contract
 
#       ┏━━━━━━━━━━━━━━━━━━━ push1 RUNTIME_BYTECODE_LEN         # L

yorickdowne

Overview

Syncing an Ethereum node is largely reliant on latency of the storage. Budget SSDs will struggle to an extent, and some won't be able to sync at all. IOPS can roughly be used as a proxy of / predictor for latency. Measuring latency directly is arguably better.

This document aims to snapshot some known good and known bad models.

The drive lists are ordered by interface and then by capacity and alphabetically by vendor name, not by preference. The lists are not exhaustive at all. @mwpastore linked a filterable spreadsheet (legacy sheet) in comments that has a far greater variety of drives and their characteristics. Filter it by DRAM yes, NAND Type TLC, Form Factor M.2, and desired capacity.

For size, 4TB is a conservative choice which also supports a Fusaka "supernode". The

rossgalloway

July 9th 2022 Governance Attack Postmortem

Original Gist published shortly after the attack: https://gist.github.com/ethedev/248f931dbb29d054a9366fe43f37d42e

This document expands upon and cleans up that document to make it easier to follow.

Important Wallets and Actors

Attacker

VictorTaelin

Ethereum

Deploy contract:

Code:

pragma solidity >=0.4.22 <=0.9.0;