#Android #Dev #Lowlvl_backend

#Lowlvl_backend #sysadmin #emmm 🌚 QEMU KVM

KVM (for Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V).

Hyper-V是微软提出的一种系统管理程序虚拟化技术

这时我看 不同种类并列 会不会 不好( 🌚

#Lowlvl_backend https://iovxw.net/p/the-new-tokio/ Rust tokio 架构果然变了
emmm 不过我其实不知道 tokio 是 什么 🌑

#emmm #backend #Lowlvl_backend https://github.com/tbrand/which_is_the_fastest#all-frameworks

题外话： #emmm #Lowlvl_backend #Learn #life
不像一些 OI dalao, duangsuse 物理数学都很菜的... 物理引擎和计算机图形学是无解（

#Lowlvl_backend #PL
到底编译中重新生成了那些文件 🌝(
S-表达式单就解析上来说 时间消耗少 是真的
emmmm...

#emmm #China #security #Lowlvl_backend

https://github.com/SuperTux/supertux/search?utf8=%E2%9C%93&q=Squirrel&type=
#Lowlvl_backend #Learn #emmm
🌑现在才知道 SuperTux 使用的脚本语言是 Squirrel

#emmm #android #security #Lowlvl_backend
🌚 之前和 360 root 怼，大数字就利用了 install_recovery.sh 启动 360s (好像

#dalao #Lowlvl_backend #Learn #backend
https://oao.moe

感叹：这才是 OS dalao (非 kernel engineering 向)

https://iovxw.net/
https://www.ifxor.com/

#dalao #Lowlvl_backend #backend #Rust #PL
后端&底层向 dalao

#Haha #Web #Lowlvl_backend #backend

🇨🇳 中国特色，虽然也有真正的好人，势单力孤啊 可惜大部分都是这种啥都不做光对心别人的 🌚... 唉
可惜一个学计算机科学的大学生都用 Rust 编写了一个完整的操作系统，某些「院士」呢？？？
https://redox-os.org #dev #Lowlvl_backend #China #emmm #dev

笑死我了，就国内现在这个水平，咱就不说做这种平台的人吧，我国有多少写开发者工具的，累不死他们啊
要不然你想上啥语言平台？C？还是去被 Oracle 告？ #China #emmm #osdev #Lowlvl_backend

#Lowlvl_backend 所以锤子开不开源

#PL #Lowlvl_backend 看了一点帖子后科普一下
内存溢出就是内存越界

#include <stdio.h>

int main(int argc, char **argv) {
  int ary[2] = {233, 666};
  printf("%i, %i, %i, %i\n", ary[0], ary[1], ary[-1], ary[2]);
}

dse@susepc:~$ clang -Wall -Wextra b.c -o bbb
b.c:3:14: warning: unused parameter 'argc' [-Wunused-parameter]
int main(int argc, char **argv) {
             ^
b.c:3:27: warning: unused parameter 'argv' [-Wunused-parameter]
int main(int argc, char **argv) {
                          ^
b.c:5:46: warning: array index -1 is before the beginning of the array [-Warray-bounds]
  printf("%i, %i, %i, %i\n", ary[0], ary[1], ary[-1], ary[2]);
                                             ^   ~~
b.c:4:3: note: array 'ary' declared here
  int ary[2] = {233, 666};
  ^
b.c:5:55: warning: array index 2 is past the end of the array (which contains 2 elements) [-Warray-bounds]
  printf("%i, %i, %i, %i\n", ary[0], ary[1], ary[-1], ary[2]);
                                                      ^   ~
b.c:4:3: note: array 'ary' declared here
  int ary[2] = {233, 666};
  ^
4 warnings generated.
dse@susepc:~$ ./bbb
233, 666, 0, 1936233432

另外上面数组下标越界是一种情况，stackoverflow 也是一种溢出
内存溢出容易和分配失败混淆

#Learn #Lowlvl_backend #sysadmin #android
在学会手动使用 GCC 工具链链接 native ELF 对象文件后 duangsuse 也终于知道为什么在 ./a.out 的时候 bash 会在明明有文件的时候说找不到文件

科普一下，曾经在手机上遇到过的
首先我们有一个 Hello, world! C 程序的代码

#include <stdio.h>

int main(int argc, char **argv) {
  printf("Hello, world!!!\n");
}

clang a.c -fno-stack-protector -std=c99 -o hello -Xlinker —verbose | grep found

found ld-linux-x86-64.so.2 at /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2

然后我们就获得了一个输出的 ELF 可执行文件 hello

file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped
./hello
Hello, world!!!

接下来就是魔改链接器 ld 参数的时候了，首先我们先准备好 helloworld 准备自己链接

clang a.c -c -fno-stack-protector -o hello -std=c99
file hello
hello: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
链接！

dlinker=foo #/lib64/ld-linux-x86-64.so.2
ld -lc -m elf_x86_64 -dynamic-linker $dlinker -o a.out /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu/crt1.o /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu/crti.o /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/crtbegin.o -L/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../.. -L/usr/lib/llvm-4.0/bin/../lib -L/lib -L/usr/lib hello -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/crtend.o /usr/bin/../lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu/crtn.o # 参数可从 clang hello --verbose 里抄

file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter foo, for GNU/Linux 3.2.0, not stripped
./a.out
bash: ./a.out: 没有那个文件或目录
???
明明有这个文件啊

然后我们尝试一下 IPython

import ctypes
ctypes.cdll.LoadLibrary('./a.out')

OSError: ./a.out: cannot dynamically load executable
🌚 无法加载（因为亲定的解释器不存在）
那如果尝试加载一个不存在的文件呢
ctypes.cdll.LoadLibrary('./foo')
OSError: ./foo: cannot open shared object file: No such file or directory

那么我们用 elvish.io 再尝试一下，到底彻底找不到和这种「找不到」有啥区别

./a.out
Exception: fork/exec ./a.out: no such file or directory
./no_such_file
Exception: exec: "./no_such_file": stat ./no_such_file: no such file or directory

那么问题就解决了吗，你为 x86_64-pc-linux-gnu 编译的 ELF 可执行文件，默认使用 /lib64/ld-linux-x86-64.so.2 链接执行
可是到了 Android 上默认动态链接器是 /system/bin/linker ，没有 /lib64/ld-linux-x86-64.so.2
当然找不到解释器无法加载了.... 🙈
ps. 这里默认测试是在 x86_64 架构的 Android 上进行的

补充：
找不到的解释器 ldd 在我的垃圾 Debian x86_64 上默认使用 /lib64/ld-linux-x86-64.so.2 替代
所以我刚才正好编译完了一个 edb 顺便来看看
edb:

Failed to open and attach to process:
execv() failed: 没有那个文件或目录.

有没有平台内建类似 AMD PSP 或 Intel ME 这样的「管理」平台？ 🌚 #apple #Lowlvl_backend

#tech #Lowlvl_backend duangsuse 在 decompiler 工具的帮助下（删除）取得成就：
native code 已经阻止不了我了

https://tttttt.me/solidot/12466
#Lowlvl_backend #linux 🤔草， mmap(), mprotect() 和 prctl()