As Developers are migrating from Monolithic architecture to distributed microservices and Service Mesh, troubleshooting production issues become difficult.

This sample application showcases patterns to implement better Observability at web scale.

• Ready to go docker configuration for set up GILK logging stack in a minutes.
  • GILK – Grafana , InfluxDB, Logstash json format, Kafka
• Monitoring solution for docker hosts and containers with Prometheus, Grafana, cAdvisor, NodeExporter and alerting with AlertManager.
• Vendor-neutral instrumentation
  • Log Aggregation – SLF4J
  • Distributed Tracking – OpenTracing
  • Application Metrics – MicroMeter
• end-to-end Functional Reactive Programming (FRP) with Spring 5.
• Multi-project builds with Gradle Kotlin Script.
• Spring Kotlin Support
• Docker deployment

1. Gradle 4.4 (Install via sdkman)
2. Docker for Mac Setup Instructions

# build all 3 executable jars
gradle build
# continuous build with `-t`. 
# this shoud be started before any run tasks i.e., `gradle ui-app:bootRun`, for spring's devtools to work.
gradle build -x test -t
# build all 3 apps
gradle build -x test
# build all 3 docker images
gradle docker -x test

gradle test

# start infra services
docker-compose  -f docker-compose-infra.yml up cassandra
docker-compose  -f docker-compose-infra.yml up kafka
docker-compose  -f docker-compose-infra.yml up influxdb

Start all 4 apps with gradle xyz:bootRun : cassandra-data-service, stream-service, ui-app , kafka-influxdb-service

If you want to debug the app, add –debug-jvm parameter to Gradle command line

You can also build Docker images and run all via Docker Compose

# start containers in the background
docker-compose up -d
# start containers in the foreground
docker-compose up 
# show runnning containers 
docker-compose ps
# scaling containers and load balancing
docker-compose scale stream=2
# 1. stop the running containers using
docker-compose stop
# 2. remove the stopped containers using
docker-compose rm -f
# just start only infra services
docker-compose  -f docker-compose-infra.yml up
# connect(ssh) to a service and run a command
docker-compose exec cassandra cqlsh
# see logs of a service 
docker-compose logs -f stream
# restart single service
docker-compose restart stream
# start single service
docker-compose -f docker-compose-infra.yml up cassandra
docker-compose -f docker-compose-infra.yml up kafka
docker-compose -f docker-compose-infra.yml up influxdb
# check health for a service
docker inspect --format "{{json .State.Health.Status }}" microservicesobservability_app_1
docker ps
docker-compose -f docker-compose-fluentd.yml up

Access UI App at http://localhost:8080

Prometheus http://localhost:9090/graph

InfluxDB http://localhost:8083

Grafana http://localhost:1634

# upgrade project gradle version
gradle wrapper --gradle-version 4.4.1 --distribution-type all
# gradle daemon status 
gradle --status
gradle --stop
# refresh dependencies
gradle build -x test --refresh-dependencies 

• Reactive Spring and Kotlin-based Application
  • https://github.com/johnsonr/flux-flix-service

Experiments on C Exploits

• 64 bit Linux Systems

• Loads string compare function on runtime
• Self modifies strlen comparison value
• Hides string using bit addition

• Loads compiled library file on runtime
• Loads string compare function from loaded library
• Hides string using XOR from templates

• Spawns/Clones secondary process for self modification
• Secondary process modifies the heap from /proc/{pid}/mem of primary process
• Hides string using bit addition

• Collapsed ELF header with precompiled statically linked _start function
• Uses truncated input as key, for decoding of flag
• Anti-debugging from corrupted header and invalid executable entry point e_entry

• Logistic differential equation to “predict” randomized canary values
• 34 byte overflow vulnerable shellcode array stored as reboot shellcode
• Buffer overflow for canary, egghunter shellcode and XOR exploit decoding

• Corrupts ELF 64-bit or 32-bit headers with 0xffff values for e_shoff, e_shnum and e_shstrndx
• Binary is still able to be run normally, but crashes when debugged

• Proof of work for Linux process hollowing
• Spawns/Clones secondary process for self modification
• Secondary process modifies the main function from /proc/{pid}/mem of primary process

• Searches process name using directory and pid
• Forces ps aux to skip process by process name, thus hiding from process list

1. MPROTECT and editing of value using C address pointer

   > objdump -d dynamic

   

   Calculate address of value to overwrite, eg.

   void *add = (void*)ch;
   unsigned char *ins = (unsigned char*)add + 84;
   *ins = 0x24;

   0x14 is overwritten as 0x24

   if (strlen(sr)==20) => if (strlen(sr)==36)

2. Fork processes and editing of value within /proc/{pid}/mem

   Primary process pipes its information (pid, address and length of string to overwrite) to secondary process

   int pipe1[2];
   int pipe2[2];
   int pipe3[2];
   pid_t f = fork();
   if (f == 0) {
       close(pipe1[1]);
       close(pipe2[1]);
       close(pipe3[1]);
   
       read(pipe1[0], addr_buf, 100);
       read(pipe2[0], length_buf, 100);
       read(pipe3[0], pid_buf, 100);
       // ...
   } else {
       close(pipe1[0]);
       close(pipe2[0]);
       close(pipe3[0]);
   
       // Calculate address, length of string and pid of process
   
       sprintf(addr_buf, "%lx", addr);
       sprintf(length_buf, "%lu", length);
       sprintf(pid_buf, "%d", pid);
   
       write(pipe1[1], addr_buf, strlen(addr_buf)+1);
       close(pipe1[1]);
       write(pipe2[1], length_buf, strlen(length_buf)+1);
       close(pipe2[1]);
       write(pipe3[1], pid_buf, strlen(pid_buf)+1);
       close(pipe3[1]);
       //...
   }

   Secondary process to use pid to read /proc/{pid}/mem and overwrite string at given address and length

   strncpy(buf, new_string, *length_given);
   lseek(mem_file, *address, SEEK_SET);
   if (write(mem_file, buf, *length_given) == -1) {
       puts("Incorrect");
       return 1;
   }

   Temporary string s is overwritten with flag (First string s != Second string s)

   printf("\nThe flag is \"%s\"!\n", s);
   puts("\nValidating......");
   sleep(1);
   if (!strcmp(s, inp)) {
       puts("Correct");
   } else {
       puts("Incorrect");
   }

1. Load function from struct function list

   // Struct to load function
   typedef struct functions{
       const char *function_name;
       TW address;
   } functions;
   
   // List of dynamic functions
   functions function_struct[] = {
       {"string_compare", &sc},
       {NULL, NULL}
   };
   
   // Compare called_function with function list, then load and run matched function
   int call_func(const char *called_function, const char* key, long* flag, long* buffer, char* input)
   {
       int k;
       for(k=0; function_struct[k].function_name != NULL; ++k){
           if(strcmp(called_function, function_struct[k].function_name) == 0){
               return function_struct[k].address(key, flag, buffer, input);
           }
       }
       return -1;
   }

   Calling “string_compare” on call_func() will compare with function list in function_struct, then is loaded and run when matched

   (One function is stored within the struct for simplicity)

2. Load function from self-created library

   // Pipe for loaded function
   struct S {
       string input, flag;
       int output;
   };
   
   static const auto library = "\
       #include<stdlib.h>\n\
       #include<string>\n\
       struct S {std::string a,b;int i;};\n\
       extern \"C\" void F(S &s) {\n\
           if ((s.input.length()==0||\
           s.flag.length()==0)||\
           s.input.compare(s.flag)!=0||\
           s.input.length()!=s.flag.length())\
           {\n\
               s.output=1;\n\
               return;\n\
           }\n\
           s.output=0;}\n\
       ";
   create(library) // Create library using gcc
   
   void * function_library = load() // Load library
   if ( function_library ) {
       // Load function F from created library
       int ( *func ) ( S & ) = (int (*)( S & )) dlsym ( function_library, "F" );
   }

   Create its own library with hidden function on runtime, such that loaded function will not be shown during decompilation

1. Collapse header via assembly

   

   Entrypoint of executable is fit into the Magic bytes in the ELF header, on top of the collapsed headers

   Entrypoint gives problems to static debuggers and disassemblers from disassembling the full binary

   Radare2 and other dynamic disassemblers are able to ignore the ELF header and follow the jump instruction after the entrypoint, thus able to disassemble much more of the executable

2. Corrupt ELF headers, i.e. e_shoff, e_shnum and e_shstrndx

   static Elf64_Ehdr* header;
   
   header->e_shoff = 0xffff;
   header->e_shnum = 0xffff;
   header->e_shstrndx = 0xffff;

   Disassembler reads ELF binary with overflow, preventing static debuggers and disassemblers from working

   Values can be also be changed to 0x0 for the opposite effect, where the disassembler is unable to read the full binary

• Nishant Pandey
• Jayasuriya Suresh

This project implements a drone obstacle avoidance system using AirSim and the Deep Deterministic Policy Gradient (DDPG) algorithm. The goal is to train a drone to navigate through an environment while avoiding obstacles in real-time.

• stable-baselines3 v1.7.0 (pip install stable-baselines3[extra]==1.7.0)
• airsim v1.8.1
• gym 0.21.0
• Packages as required by the airsim package.
  A requirements.txt has been attached in case of versions mismatches or the conda env fails to be imported.

• Utilizes the AirSim simulator for realistic drone flight dynamics and sensor data.
• Implements the DDPG algorithm for training the drone to avoid obstacles.
• Provides a user-friendly interface for visualizing the obstacle avoidance behavior.

There are three folders, lidar, depth , lidar+depth which have train.py, eval.py and drone_env.py. The instructions to run all have been documented below.
Other folders and files are :

• readme.md
• env.yml
• requirements.txt
• setting.json

1. Unzip the folder if you have not done so

2. Install the required packages from the env.yml file using conda

   conda env create -f env.yml

3. Download and setup the AirSim simulator by following the instructions in the AirSim documentation.
   For this project we used the biniaries provided by airsim under releases , V1.8.1 , AirsimNH.zip.Extract the zip and run the airsimnh.exe for the simulator to work. Also paste the provided config file under Documents/Airsim/settings.json

1. Launch the AirSim simulator.

2. Navigate to Lidar/Lidar+depth folder, run the main script to start the drone obstacle avoidance system:

   python train.py

3. The drone will start training. Once training is over, it will be saved under /models of the root dir. Logs are saved under /tmp of the root dir which can be viewed using

tensorboard --logdir=/tmp/name_of_folder

1. Launch the AirSim simulator.

2. Modify the model_path in the eval.py file to the path of your model. Run the main script to start the drone obstacle avoidance system:

   python  eval.py

3. Evaluation starts and you can see the output in the airsim window. After evaluation is done, we can see the metrics which show up in a matplotlib window and also is saved in the root directory.

• If the code does not connect to the simulator, please change the port in settings.json under ApiServerPort as well as on the code , in the files drone_env_ddpg.py and ddpg_lidar.py in line number 19 for both eval and the normal files.

• AirSim – Open-source simulator for drones and cars developed by Microsoft.

• DDPG – Deep Deterministic Policy Gradient algorithm for continuous control tasks.

• UAV_Navigation_DRL_AirSim for opensourcing his code as it helped us understand a lot and we have used parts of his code in our codebase.

• DDPG-AirSim-Drone-Obstacle-Avoidance for helping us understand DDPG and how to control a drone in airsim using RL.

• Reinforcement-learning

The benchmark collection named Similar-Document-Image-Retrieval-Dataset(SDIRD) is provided for a task, which is finding out the similar document images for a query document image. The structure of SDIRD is as follows:

├── database
├── databaseClassified
├── queryset
├── trainingset
└── database-subject

This is the document image database with 10240 document images.

This directory collects the images of above database according to corresponding original source(148 papers).

This is the query image dataset with 1000 images totally.

This is the target dataset to fine-tune pre-trained CNN models, which including training set with 1000 document images and validation set with 200 images, and the label or category information.

This is the information of document image database about the category id, category label, the number of images from corresponding paper and title.

The benchmark collection named Similar-Document-Image-Retrieval-Dataset(SDIRD) is provided for a task, which is finding out the similar document images for a query document image. The structure of SDIRD is as follows:

├── database
├── databaseClassified
├── queryset
├── trainingset
└── database-subject

This is the document image database with 10240 document images.

This directory collects the images of above database according to corresponding original source(148 papers).

This is the query image dataset with 1000 images totally.

This is the target dataset to fine-tune pre-trained CNN models, which including training set with 1000 document images and validation set with 200 images, and the label or category information.

This is the information of document image database about the category id, category label, the number of images from corresponding paper and title.

English Version (README-EN.md)

这是一个基于 MCP (Model Context Protocol) 的 GitHub 工具，它能让 AI 模型通过标准化接口访问 GitHub API。

简单来说，它让 AI 助手能够执行各种 GitHub 操作，如创建仓库、提交代码、管理分支等，无需用户手动输入复杂的 API 调用。

功能演示 (点击展开)

以下是 GitHub MCP 工具的一些核心功能演示：

仓库创建演示

分支操作演示

Pull Request 管理演示

Issue 跟踪演示

通过简单的自然语言指令，AI 可以帮助你完成上述所有操作，无需手动编写 API 调用或在浏览器中操作 GitHub 界面。

git clone https://github.com/shuakami/mcp-github.git
cd mcp-github
npm install
npm run build

⚠️ 重要提示：安装后请不要删除克隆或解压的文件，插件需要持续访问这些文件！

npm run build

根据你的操作系统，按照以下步骤配置 MCP：

{
  "mcpServers": {
    "github-mcp": {
      "command": "pythonw",
      "args": [
        "你的安装路径/mcp-github/bridging_github_mcp.py"
      ],
      "env": {
        "GITHUB_TOKEN": "你的GitHub令牌"
      }
    }
  }
}

{
  "mcpServers": {
    "github-mcp": {
      "command": "python3",
      "args": [
        "/Users/你的用户名/mcp-github/bridging_github_mcp.py"
      ],
      "env": {
        "GITHUB_TOKEN": "你的GitHub令牌"
      }
    }
  }
}

{
  "mcpServers": {
    "github-mcp": {
      "command": "python3",
      "args": [
        "/home/你的用户名/mcp-github/bridging_github_mcp.py"
      ],
      "env": {
        "GITHUB_TOKEN": "你的GitHub令牌"
      }
    }
  }
}

配置好之后你的 Cursor 编辑器会自动启动 MCP 服务。然后你就可以开始用了。

ISC

UI framework with vuetify-like material components built with Svelte

I made the library to be as easy to setup as possible. No preprocessors for css or js are required.

First, we install sozai with npm

npm i sozai

Then, we surround the main component with <SozaiApp />

And boom, we’ve set up a sozai app. No need to mess around with the bundler to correctly setup purgecss or postcss!

— @KentoNishi (named as one of the top 300 scholars in the 81st Regeneron Science Talent Search—the nation’s oldest and most prestigious science and mathematics competition for high school seniors)

— @anish-lakkapragada (made an ml library when he was 14 although not with sozai)

I mainly have worked on LiveTL which upon rewriting in svelte a year ago, has used a svelte material ui framework. Our journey took the following steps.

1. We find svelte-material-ui as the most popular material toolkit for svelte around the time v2 was in beta. I struggled to set it up and after a day of messing with bundler configs, gave up 😢
2. We find svelte-materialify and start to use it as it initially required no setup. It is also, in our opinion, the best-looking svelte material toolkit. However to use the full library, we needed to setup css preprocessors which was annoying but doable.
3. A few months after we successfully rewrite LiveTL using svelte-materialify, we realize that svelte-materialify is buggy af and bugs out on conditional renders and randomly started flickering.
4. A few months later, we plan to integrate with another project which adds the requirement that the bundle size be small for LiveTL. Unfortunately, svelte-materialify does not tree-shake and produces massive bundles.
5. We swap out the svelte-materialify components with smelte and immediately see a drop in bundle size. However, the build time has increased due to needing to use purgecss in order to not end up with megabytes long css files. Months later, one of the other three core LiveTL devs and I are fed up with tailwind (smelte forces you to add tailwind to your app). In addition, smelte seems to be unmaintained.
6. I say fck it, I’m making my own toolkit.

Everything has pros and cons, let’s compare sozai to the other svelte material design frameworks.

Sozai’s ripple is based off of svelte-materialify’s ripple (we changed it to activate on touch events and fixed some bugs with it). Sozai also makes extensive use of svelte-material-ui’s event forwarding mechanism which forwards all events dom elements emit. Sozai was initially meant to be smelte without tailwind and due to this, sozai’s button and dialog are more or less smelte’s but de-tailwinded.