apinter

1. Create a systemd service and a timer unit with the below contents
2. The units must run with root so create the units under /etc/systemd/system/
3. Enable the timer only (systemctl enable --now zypper-dup-download-only.timer)
4. Use zypper dup whenever you ready to update, packages will be cached daily by the units.

Contents of zypper-dup-download-only.service:

[Unit]
Description=Download available updates

four0four

Zynq BootROM Secrets: Exposing the bootROM with the UART loader

Last time I wrote about this, I lied a little - There is an interesting bug in the UART loader, and it may have been exactly why Xilinx didn't document it. In short: The UART loader writes the entire UART payload to a location in memory (nominally 0x4_0000). The ROM is architected such that when the boot mode is selected, it registers a callback that is called when the ROM wants more data from the boot device. For the UART loader, this is pretty simple - here's the whole thing:

; void uart_callback(u32 r0_offset, void* r1_dest, i32 r2_nbytes)
ROM:0000A578 PUSH            {R3,LR}
ROM:0000A57C MOV             R3, #uart_buff
ROM:0000A584 MOV             R12, #1
ROM:0000A588 LDR             R3, [R3]

four0four

Zynq BootROM Secrets: UART loader

Recently I acquired (md5: ADF639AFE9855EE86C8FAAD216C970D9) the Zynq bootrom, and during the reversing process uncovered some interesting secrets, one of which is an as-of-yet undocumented UART loader. As documented the Zynq bootrom will load from NOR/NAND/SPI flashes, eMMC/SDIO-based storage (unfortunately) not USB, or anything else more complex.

Not sure why Xilinx didn't document this. In my brief testing it is super unreliable if you just spit everything at once - they reset the RX/TX paths during the process, so timing is critical, but that might be the janky meter-long ftdi cable. You can change the baudrate during the process, but I was too lazy to do the math.

Here's the disassembly that made me look twice (that, and checks for the MIO boot_mode[2:0] that weren't specified in the docs :)):

ROM:0000A220 BL              uart_init

uroboro

#!//bin/sh

export PATH=bin:$PATH

self=$0

function print_help() {
	echo "$self [IPSW path]"
	echo "$self [device model] [ios build]"
	echo

uroboro

• mach_portal: bug-tracker

• extra_recipe: post, bug tracker

• ota: part 1, part 2, part 3, bug tracker

• triple_fetch: bug tracker

• async_wake: bug tracker

• Phoenix: pdf

• ziVA: GitHub

• Pegasus: [pdf](http://i

EdOverflow

GitHub for Bug Bounty Hunters

GitHub repositories can disclose all sorts of potentially valuable information for bug bounty hunters. The targets do not always have to be open source for there to be issues. Organization members and their open source projects can sometimes accidentally expose information that could be used against the target company. in this article I will give you a brief overview that should help you get started targeting GitHub repositories for vulnerabilities and for general recon.

Mass Cloning

You can just do your research on github.com, but I would suggest cloning all the target's repositories so that you can run your tests locally. I would highly recommend @mazen160's GitHubCloner. Just run the script and you should be good to go.

$ python githubcloner.py --org organization -o /tmp/output

zmts

Про токены, JSON Web Tokens (JWT), аутентификацию и авторизацию. Token-Based Authentication

Last major update: 25.08.2020

• Что такое авторизация/аутентификация
• Где хранить токены
• Как ставить куки ?
• Процесс логина
• Процесс рефреш токенов
• Кража токенов/Механизм контроля токенов