I've started to add a pehash implementation to YARA. I decided to base my implementation on the description in the paper and only use the totalhash and viper implementations for comparing results. In doing so I've noticed some problems, and it is unclear who is right.
For starters let's take a look at running the pehash.py implementation from totalhash against a binary.
wxs@psh Desktop % shasum 4180ee367740c271e05b3637ee64619fb9fe7b1d2b28866e590e731b9f81de36
Although there are many excellent resources for learning Volatility available (The Art of Memory Forensics book, the vol-users mailing list, the Volatility Labs blog, and the Memory Analysis training course to name a few), I've never really seen a good absolute beginners guide to writing your first plugin. So if you find yourself needing that, hopefully this will help.
Also, it's worth checking out @jameshabben's post on the topic.
| FORMAT: 1A | |
| # Sample API | |
| ## Sample API について | |
| Sample API は、与えられた URL にアクセスしたオーディエンスに対するレコメンド記事を返す、架空の API である。 | |
| ## API 共通のエラー形式 |
| #!/usr/bin/env python2.7 | |
| """ | |
| Extract title from PDF file. | |
| Dependencies: | |
| pip install --user unidecode pyPDF PDFMiner | |
| Usage: | |
| find . -name "*.pdf" | xargs -I{} pdftitle -d tmp --rename {} |
これは以前Twitterに連投したものと、Qiitaに書いたものをまとめて加筆修正したものです。
だいぶ前に一世を風靡し、今はもはや風化し始めている「2位じゃダメなんでしょうか?」という言葉がありました。ここで1位とか2位とか言っているのは、狭義にはスパコンのランキングTOP500の順位のことを指します。TOP500は、HPLというベンチマークによりスパコンの性能を測定し、そのランキングを決めるもので、年に2回ランキングが更新されます。以前、初代地球シミュレータが5期連続でトップを守りましたが、これは5年ではなく、2年半トップであった、というものです。
HPLとは、一言でいえば馬鹿でかい連立一次方程式を解くベンチマークです。問題サイズは自由に決められます。問題サイズが大きいほど性能を出しやすいですが、その分計算時間がかかるようになるため、実際には数時間〜数十時間程度で実行できる範囲のサイズが選ばれることが多いようです。問題が連立一次方程式なので、解いたあとに実際に代入して答えが合っているかどうかを確認します。実際には計算誤差などがあるため、その誤差が規定範囲内に収まっていれば合格となり、その時の演算性能がTOP500への報告値となります。
Although common on x86, it was initially believed that it was not possible to make alphanumeric shellcode for ARM. Later it turned out it was.
Similar to that, I wondered if it was possible to make alphanumeric shell-code for RISC-V.
(Basic shellcode in RISC-V Linux provides a good introduction to shellcode for RISC-V, including how to avoid NUL bytes.)
First, I enumerated all the possible instructions that could be formed from these characters with a little Rust program and generated some statistics.
| from binaryninja import * | |
| log_to_stderr(1) | |
| def get_syscall_no(zwf): | |
| for b in zwf.basic_blocks: | |
| for i in b.get_disassembly_text(): | |
| if str(i).startswith("syscall"): | |
| eax = zwf.get_reg_value_at(i.address, "eax") | |
| if eax.type == RegisterValueType.ConstantValue: |
| #include <stdio.h> | |
| #include <stdlib.h> | |
| #include <libproc.h> | |
| #include <mach/mach.h> | |
| bool | |
| has_modifications(struct task_extmod_info *info) | |
| { | |
| if ((info->extmod_statistics.thread_creation_count > 0) || | |
| (info->extmod_statistics.thread_set_state_count > 0)) { |
This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.
It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.
Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2
The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and
