| #!/bin/bash | |
| # concatenate videos given start and end filenames | |
| # https://trac.ffmpeg.org/wiki/Concatenate | |
| # expect naming convention from achesco's split-to-scenes.sh: | |
| # https://gist.github.com/achesco/4dc2ebf13378a0a61fc26c7fe01f539e | |
| # leading 4 digits from $1 and $2 | |
| begin=${1:0:4} | |
| end=${2:0:4} |
| #!/bin/bash | |
| # set -Eeuo pipefail | |
| # Splits video to separate scenes files | |
| # Source: https://gist.github.com/achesco/4dc2ebf13378a0a61fc26c7fe01f539e | |
| # Inspired by https://stackoverflow.com/a/38205105 | |
| # The "-c:v h264_videotoolbox \" argument makes it work faster on Apple Silicon | |
| # computers. | |
| # ❗The bitrate argument is overriden in this version, we look at the original bitrate. |
llama.cpp version: https://github.com/ggerganov/llama.cpp/commit/925e5584a058afb612f9c20bc472c130f5d0f891
LLM: https://huggingface.co/TheBloke/Llama-2-7B-Chat-GGUF/blob/main/llama-2-7b-chat.Q4_K_M.gguf
llama-bench -m ../models/llama-2-7b-chat.Q4_K_M.gguf
| model | size | params | backend | threads | test | t/s |
|---|
| // time: [1.8843 µs 1.8897 µs 1.8955 µs] | |
| pub fn original(input: &[u8]) -> Option<usize> { | |
| let mut idx = 0; | |
| 'outer: while idx + 13 < input.len() { | |
| let mut state = 0; | |
| for (next_idx, byte) in input[idx..idx + 14].iter().enumerate().rev() { | |
| let bit_idx = byte % 32; | |
| if state & (1 << bit_idx) != 0 { | |
| idx += next_idx + 1; | |
| continue 'outer; |
| """ | |
| Transform a binary file into a C header file. | |
| The binary file is splitted into 16 char strings and rebuild at execution time. | |
| The function buildsc() must be called in your main to rebuild the binary file into the sc C variable. | |
| The length is set in the sc_length variable. | |
| Be carefull, try to avoid compiler code optimization as it will remove all these modifications in the final binary. | |
| """ |
| # run: mitmproxy -k -p 8090 -s mitmproxy-jwt-refresh-addon.py | |
| # set burp upstream proxy to localhost:8090 | |
| # | |
| # use case: | |
| # - application authorization is implemented by OAuth 2.0 | |
| # - testing is performed using Burp as primary and mitmproxy as upstream proxy | |
| # - mitmproxy takes care of the Authorization tokens using this addon | |
| # - user gets an access_token and a refresh_token during the 1st login (e.g. password login) | |
| # - mitmproxy addon caches access_token and refresh_token | |
| # - mitmproxy addon adds Authorization: Bearer [access_token from cache] header for every request |
MS Office docx files may contain external OLE Object references as HTML files. There is an HTML sceme "ms-msdt:" which invokes the msdt diagnostic tool, what is capable of executing arbitrary code (specified in parameters).
The result is a terrifying attack vector for getting RCE through opening malicious docx files (without using macros).
Here are the steps to build a Proof-of-Concept docx:
This is a note for myself describing various Visual Basic macros construction strategies that could be used for remote code execution via malicious Document vector. Nothing new or fancy here, just a list of techniques, tools and scripts collected in one place for a quick glimpse of an eye before setting a payload.
All of the below examples had been generated for using as a remote address: 192.168.56.101.
List:
| //sample: 1554e74b935a61d446cb634f80d7d1e200e864bc | |
| //posted by @JohnLaTwC | |
| // Also see research by Sudeep Singh, Yin Hong Chang @ https://www.fireeye.com/blog/threat-research/2016/05/targeted_attacksaga.html | |
| ----------------------------------------------- macro ---------------------------------- | |
| Private Sub Workbook_Open() | |
| Call doom_Init | |
| Call doom_ShowHideSheets | |
| End Sub |
