| # Decompile | |
| dtc -I dtb -O dts -o devicetree.dts /boot/dtb/<your_devicetree_file_name>.dtb | |
| # Compile | |
| dtc -I dts -O dtb devicetree.dts -o <your_devicetree_file_name>.dtb | |
| # Merge with DTBO | |
| fdtoverlay -i modified-base.dtb -o modified-full.dtb /boot/tegra194-p3668-all-p3509-0000-user-custom.dtbo | |
| # DTS from fs |
| import base64 | |
| from Crypto.Cipher import AES | |
| from Crypto.Util.Padding import pad,unpad | |
| #AES ECB mode without IV | |
| data = 'I love Medium' | |
| key = 'AAAAAAAAAAAAAAAA' #Must Be 16 char for AES128 | |
| def encrypt(raw): |
.ghci-purple-yolk and copy the contents of the .ghci file:l Main.hs to the end of the .ghci-purple-yolk file.ghci-purple-yolk should look something like:
:set -XNoImplicitPrelude
:def source readFile
The list below is compiled to inform, guide, and inspire budding security researchers. Oh and to pick something for bedtime reading too.
Included in the list are works on the following topics related to MCU/SoC security:
At the end of the list, there is also a section with links to articles of potential general interest, not addressing vulnerabilities in any specific device.
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]
This is inspired by A half-hour to learn Rust and Zig in 30 minutes.
Your first Go program as a classical "Hello World" is pretty simple:
First we create a workspace for our project:
This is inspired by https://fasterthanli.me/blog/2020/a-half-hour-to-learn-rust/
the command zig run my_code.zig will compile and immediately run your Zig
program. Each of these cells contains a zig program that you can try to run
(some of them contain compile-time errors that you can comment out to play
with)
| require 'capybara/apparition' | |
| Capybara.server = :puma, { Silent: true } | |
| Capybara.register_driver :chrome_headless do |app| | |
| Capybara::Apparition::Driver.new(app, { headless: true, browser_options: { 'headless': '', 'no-sandbox': '' } }) | |
| end | |
| Capybara.register_driver :chrome do |app| | |
| options = Selenium::WebDriver::Chrome::Options.new(args: %w[no-sandbox]) |
Recently I noticed the number of the same two questions being asked again and again on different Haskell resources. The questions were “How to get a Haskell job” and “Why is it so hard to find Haskellers?” Although these two are coming from the opposite sides of the hiring process, the answer is really just one. There is a single reason, a single core problem that causes difficulties of hiring and being hired in the Haskell community, and we should clearly articulate this problem if we want to increase the Haskell adoption.
We all know that there are many people wishing to get a Haskell job. And a visible increase of Haskell jobs looks like there should be a high demand for Haskellers. The Haskell community has also grown like crazy past years. But still, why is it so difficult to hire and to be hired? Why can’t companies just hire any single person who demonstrates a deep knowledge of Haskell in blog posts, in chats, on forums, and in talks? And why do Haskell companies avoid hirin
