<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="/rss-style.xsl"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:media="http://search.yahoo.com/mrss/" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
<title><![CDATA[Team IT Security - 📰 Alle Kategorien]]></title>
<link><![CDATA[https://tsecurity.de/export/rss/alle-kategorien.xml?q=sketchprogramming+transpiler+what%2F]]></link>
<description><![CDATA[Das Gesamte Cyber Threat Intelligence Feed-Archiv von TSecurity.de. Alle Nachrichten, Sicherheitsmeldungen, Videos, Downloads und Analysen in einer zentralen Übersicht.]]></description>
<language>de-DE</language>
<lastBuildDate>Tue, 28 Jul 2026 20:10:32 +0200</lastBuildDate>
<pubDate>Tue, 28 Jul 2026 20:10:32 +0200</pubDate>
<ttl>15</ttl>
<copyright>2026 Team IT Security</copyright>
<managingEditor>lakandor@tsecurity.de (Horus Sirius)</managingEditor>
<webMaster>lakandor@tsecurity.de (Horus Sirius)</webMaster>
<category>IT Security</category>
<category>Cybersecurity</category>
<category>Nachrichten</category>
<generator>Team IT Security RSS Generator v2.0</generator>
<image>
<url>https://tsecurity.de/favicon.ico</url>
<title><![CDATA[Team IT Security - 📰 Alle Kategorien]]></title>
<link><![CDATA[https://tsecurity.de/export/rss/alle-kategorien.xml?q=sketchprogramming+transpiler+what%2F]]></link>
</image>
<atom:link href="https://tsecurity.de/export/rss/it-security.xml?q=sketchprogramming+transpiler+what%2F" rel="self" type="application/rss+xml" />
<item>
<title><![CDATA[RISC-Y Business: Raging against the reduced machine]]></title>
<description><![CDATA[Abstract In recent years the interest in obfuscation has increased, mainly because people want to protect their intellectual property. Unfortunately, most of what’s been written is focused on the theoretical aspects. In this article, we will discuss the practical engineering challenges of develop...]]></description>
<link>https://tsecurity.de/de/3303344/hacking/risc-y-business-raging-against-the-reduced-machine/</link>
<guid isPermaLink="true">https://tsecurity.de/de/3303344/hacking/risc-y-business-raging-against-the-reduced-machine/</guid>
<pubDate>Sun, 22 Feb 2026 17:19:24 +0100</pubDate>
<category>🕵️ Hacking</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[Abstract In recent years the interest in obfuscation has increased, mainly because people want to protect their intellectual property. Unfortunately, most of what’s been written is focused on the theoretical aspects. In this article, we will discuss the practical engineering challenges of developing a low-footprint virtual machine interpreter. The VM is easily embeddable, built on open-source technology and has various hardening features that were achieved with minimal effort. Introduction In addition to protecting intellectual property, a minimal virtual machine can be useful for other reasons. You might want to have an embeddable interpreter to execute business logic (shellcode), without having to deal with RWX memory. It can also be useful as an educational tool, or just for fun. Creating a custom VM architecture (similar to VMProtect/Themida) means that we would have to deal with binary rewriting/lifting or write our own compiler. Instead, we decided to use a preexisting architecture, which would be supported by LLVM: RISC-V. This architecture is already widely used for educational purposes and has the advantage of being very simple to understand and implement. Initially, the main contender was WebAssembly. However, existing interpreters were very bloated and would also require dealing with a binary format. Additionally, it looks like WASM64 is very underdeveloped and our memory model requires 64-bit pointer support. SPARC and PowerPC were also considered, but RISC-V seems to be more popular and there are a lot more resources available for it. WebAssembly was designed for sandboxing and therefore strictly separates guest and host memory. Because we will be writing our own RISC-V interpreter, we chose to instead share memory between the guest and the host. This means that pointers in the RISC-V execution context (the guest) are valid in the host process and vice-versa. As a result, the instructions responsible for reading/writing memory can be implemented as a simple memcpy call and we do not need additional code to translate/validate memory accesses (which helps with our goal of small code size). With this property, we need to implement only two system calls to perform arbitrary operations in the host process: uintptr_t riscvm_get_peb(); uintptr_t riscvm_host_call(uintptr_t rip, uintptr_t args[13]); The riscvm_get_peb is Windows-specific and it allows us to resolve exports, which we can then pass to the riscvm_host_call function to execute arbitrary code. Additionally, an optional host_syscall stub could be implemented, but this is not strictly necessary since we can just call the functions in ntdll.dll instead. Toolchain and CRT To keep the interpreter footprint as low as possible, we decided to develop a toolchain that outputs a freestanding binary. The goal is to copy this binary into memory and point the VM’s program counter there to start execution. Because we are in freestanding mode, there is no C runtime available to us, this requires us to handle initialization ourselves. As an example, we will use the following hello.c file: int _start() { int result = 0; for(int i = 0; i &lt; 52; i++) { result += *(volatile int*)&amp;i; } return result + 11; } We compile the program with the following incantation: clang -target riscv64 -march=rv64im -mcmodel=medany -Os -c hello.c -o hello.o And then verify by disassembling the object: $ llvm-objdump --disassemble hello.o hello.o: file format elf64-littleriscv 0000000000000000 &lt;_start&gt;: 0: 13 01 01 ff addi sp, sp, -16 4: 13 05 00 00 li a0, 0 8: 23 26 01 00 sw zero, 12(sp) c: 93 05 30 03 li a1, 51 0000000000000010 &lt;.LBB0_1&gt;: 10: 03 26 c1 00 lw a2, 12(sp) 14: 33 05 a6 00 add a0, a2, a0 18: 9b 06 16 00 addiw a3, a2, 1 1c: 23 26 d1 00 sw a3, 12(sp) 20: 63 40 b6 00 blt a2, a1, 0x20 &lt;.LBB0_1+0x10&gt; 24: 1b 05 b5 00 addiw a0, a0, 11 28: 13 01 01 01 addi sp, sp, 16 2c: 67 80 00 00 ret The hello.o is a regular ELF object file. To get a freestanding binary we need to invoke the linker with a linker script: ENTRY(_start) LINK_BASE = 0x8000000; SECTIONS { . = LINK_BASE; __base = .; .text : ALIGN(16) { . = LINK_BASE; *(.text) *(.text.*) } .data : { *(.rodata) *(.rodata.*) *(.data) *(.data.*) *(.eh_frame) } .init : { __init_array_start = .; *(.init_array) __init_array_end = .; } .bss : { *(.bss) *(.bss.*) *(.sbss) *(.sbss.*) } .relocs : { . = . + SIZEOF(.bss); __relocs_start = .; } } This script is the result of an excessive amount of swearing and experimentation. The format is .name : { ... } where .name is the destination section and the stuff in the brackets is the content to paste in there. The special . operator is used to refer to the current position in the binary and we define a few special symbols for use by the runtime: Symbol Meaning __base Base of the executable. __init_array_start Start of the C++ init arrays. __init_array_end End of the C++ init arrays. __relocs_start Start of the relocations (end of the binary). These symbols are declared as extern in the C code and they will be resolved at link-time. While it may seem confusing at first that we have a destination section, it starts to make sense once you realize the linker has to output a regular ELF executable. That ELF executable is then passed to llvm-objcopy to create the freestanding binary blob. This makes debugging a whole lot easier (because we get DWARF symbols) and since we will not implement an ELF loader, it also allows us to extract the relocations for embedding into the final binary. To link the intermediate ELF executable and then create the freestanding hello.pre.bin: ld.lld.exe -o hello.elf --oformat=elf -emit-relocs -T ..\lib\linker.ld --Map=hello.map hello.o llvm-objcopy -O binary hello.elf hello.pre.bin For debugging purposes we also output hello.map, which tells us exactly where the linker put the code/data: VMA LMA Size Align Out In Symbol 0 0 0 1 LINK_BASE = 0x8000000 0 0 8000000 1 . = LINK_BASE 8000000 0 0 1 __base = . 8000000 8000000 30 16 .text 8000000 8000000 0 1 . = LINK_BASE 8000000 8000000 30 4 hello.o:(.text) 8000000 8000000 30 1 _start 8000010 8000010 0 1 .LBB0_1 8000030 8000030 0 1 .init 8000030 8000030 0 1 __init_array_start = . 8000030 8000030 0 1 __init_array_end = . 8000030 8000030 0 1 .relocs 8000030 8000030 0 1 . = . + SIZEOF ( .bss ) 8000030 8000030 0 1 __relocs_start = . 0 0 18 8 .rela.text 0 0 18 8 hello.o:(.rela.text) 0 0 3b 1 .comment 0 0 3b 1 &lt;internal&gt;:(.comment) 0 0 30 1 .riscv.attributes 0 0 30 1 &lt;internal&gt;:(.riscv.attributes) 0 0 108 8 .symtab 0 0 108 8 &lt;internal&gt;:(.symtab) 0 0 55 1 .shstrtab 0 0 55 1 &lt;internal&gt;:(.shstrtab) 0 0 5c 1 .strtab 0 0 5c 1 &lt;internal&gt;:(.strtab) The final ingredient of the toolchain is a small Python script (relocs.py) that extracts the relocations from the ELF file and appends them to the end of the hello.pre.bin. The custom relocation format only supports R_RISCV_64 and is resolved by our CRT like so: typedef struct { uint8_t type; uint32_t offset; int64_t addend; } __attribute__((packed)) Relocation; extern uint8_t __base[]; extern uint8_t __relocs_start[]; #define LINK_BASE 0x8000000 #define R_RISCV_NONE 0 #define R_RISCV_64 2 static __attribute((noinline)) void riscvm_relocs() { if (*(uint32_t*)__relocs_start != 'ALER') { asm volatile("ebreak"); } uintptr_t load_base = (uintptr_t)__base; for (Relocation* itr = (Relocation*)(__relocs_start + sizeof(uint32_t)); itr-&gt;type != R_RISCV_NONE; itr++) { if (itr-&gt;type == R_RISCV_64) { uint64_t* ptr = (uint64_t*)((uintptr_t)itr-&gt;offset - LINK_BASE + load_base); *ptr -= LINK_BASE; *ptr += load_base; } else { asm volatile("ebreak"); } } } As you can see, the __base and __relocs_start magic symbols are used here. The only reason this works is the -mcmodel=medany we used when compiling the object. You can find more details in this article and in the RISC-V ELF Specification. In short, this flag allows the compiler to assume that all code will be emitted in a 2 GiB address range, which allows more liberal PC-relative addressing. The R_RISCV_64 relocation type gets emitted when you put pointers in the .data section: void* functions[] = { &amp;function1, &amp;function2, }; This also happens when using vtables in C++, and we wanted to support these properly early on, instead of having to fight with horrifying bugs later. The next piece of the CRT involves the handling of the init arrays (which get emitted by global instances of classes that have a constructor): typedef void (*InitFunction)(); extern InitFunction __init_array_start; extern InitFunction __init_array_end; static __attribute((optnone)) void riscvm_init_arrays() { for (InitFunction* itr = &amp;__init_array_start; itr != &amp;__init_array_end; itr++) { (*itr)(); } } Frustratingly, we were not able to get this function to generate correct code without the __attribute__((optnone)). We suspect this has to do with aliasing assumptions (the start/end can technically refer to the same memory), but we didn’t investigate this further. Interpreter internals Note: the interpreter was initially based on riscvm.c by edubart. However, we have since completely rewritten it in C++ to better suit our purpose. Based on the RISC-V Calling Conventions document, we can create an enum for the 32 registers: enum RegIndex { reg_zero, // always zero (immutable) reg_ra, // return address reg_sp, // stack pointer reg_gp, // global pointer reg_tp, // thread pointer reg_t0, // temporary reg_t1, reg_t2, reg_s0, // callee-saved reg_s1, reg_a0, // arguments reg_a1, reg_a2, reg_a3, reg_a4, reg_a5, reg_a6, reg_a7, reg_s2, // callee-saved reg_s3, reg_s4, reg_s5, reg_s6, reg_s7, reg_s8, reg_s9, reg_s10, reg_s11, reg_t3, // temporary reg_t4, reg_t5, reg_t6, }; We just need to add a pc register and we have the structure to represent the RISC-V CPU state: struct riscvm { int64_t pc; uint64_t regs[32]; }; It is important to keep in mind that the zero register is always set to 0 and we have to prevent writes to it by using a macro: #define reg_write(idx, value) \ do \ { \ if (LIKELY(idx != reg_zero)) \ { \ self-&gt;regs[idx] = value; \ } \ } while (0) The instructions (ignoring the optional compression extension) are always 32-bits in length and can be cleanly expressed as a union: union Instruction { struct { uint32_t compressed_flags : 2; uint32_t opcode : 5; uint32_t : 25; }; struct { uint32_t opcode : 7; uint32_t rd : 5; uint32_t funct3 : 3; uint32_t rs1 : 5; uint32_t rs2 : 5; uint32_t funct7 : 7; } rtype; struct { uint32_t opcode : 7; uint32_t rd : 5; uint32_t funct3 : 3; uint32_t rs1 : 5; uint32_t rs2 : 5; uint32_t shamt : 1; uint32_t imm : 6; } rwtype; struct { uint32_t opcode : 7; uint32_t rd : 5; uint32_t funct3 : 3; uint32_t rs1 : 5; uint32_t imm : 12; } itype; struct { uint32_t opcode : 7; uint32_t rd : 5; uint32_t imm : 20; } utype; struct { uint32_t opcode : 7; uint32_t rd : 5; uint32_t imm12 : 8; uint32_t imm11 : 1; uint32_t imm1 : 10; uint32_t imm20 : 1; } ujtype; struct { uint32_t opcode : 7; uint32_t imm5 : 5; uint32_t funct3 : 3; uint32_t rs1 : 5; uint32_t rs2 : 5; uint32_t imm7 : 7; } stype; struct { uint32_t opcode : 7; uint32_t imm_11 : 1; uint32_t imm_1_4 : 4; uint32_t funct3 : 3; uint32_t rs1 : 5; uint32_t rs2 : 5; uint32_t imm_5_10 : 6; uint32_t imm_12 : 1; } sbtype; int16_t chunks16[2]; uint32_t bits; }; static_assert(sizeof(Instruction) == sizeof(uint32_t), ""); There are 13 top-level opcodes (Instruction.opcode) and some of those opcodes have another field that further specializes the functionality (i.e. Instruction.itype.funct3). To keep the code readable, the enumerations for the opcode are defined in opcodes.h. The interpreter is structured to have handler functions for the top-level opcode in the following form: bool handler_rv64_&lt;opcode&gt;(riscvm_ptr self, Instruction inst); As an example, we can look at the handler for the lui instruction (note that the handlers themselves are responsible for updating pc): ALWAYS_INLINE static bool handler_rv64_lui(riscvm_ptr self, Instruction inst) { int64_t imm = bit_signer(inst.utype.imm, 20) &lt;&lt; 12; reg_write(inst.utype.rd, imm); self-&gt;pc += 4; dispatch(); // return true; } The interpreter executes until one of the handlers returns false, indicating the CPU has to halt: void riscvm_run(riscvm_ptr self) { while (true) { Instruction inst; inst.bits = *(uint32_t*)self-&gt;pc; if (!riscvm_execute_handler(self, inst)) break; } } Plenty of articles have been written about the semantics of RISC-V, so you can look at the source code if you’re interested in the implementation details of individual instructions. The structure of the interpreter also allows us to easily implement obfuscation features, which we will discuss in the next section. For now, we will declare the handler functions as __attribute__((always_inline)) and set the -fno-jump-tables compiler option, which gives us a riscvm_run function that (comfortably) fits into a single page (0xCA4 bytes): Hardening features A regular RISC-V interpreter is fun, but an attacker can easily reverse engineer our payload by throwing it into Ghidra to decompile it. To force the attacker to at least look at our VM interpreter, we implemented a few security features. These features are implemented in a Python script that parses the linker MAP file and directly modifies the opcodes: encrypt.py. Opcode shuffling The most elegant (and likely most effective) obfuscation is to simply reorder the enums of the instruction opcodes and sub-functions. The shuffle.py script is used to generate shuffled_opcodes.h, which is then included into riscvm.h instead of opcodes.h to mix the opcodes: #ifdef OPCODE_SHUFFLING #warning Opcode shuffling enabled #include "shuffled_opcodes.h" #else #include "opcodes.h" #endif // OPCODE_SHUFFLING There is also a shuffled_opcodes.json file generated, which is parsed by encrypt.py to know how to shuffle the assembled instructions. Because enums are used for all the opcodes, we only need to recompile the interpreter to obfuscate it; there is no additional complexity cost in the implementation. Bytecode encryption To increase diversity between payloads for the same VM instance, we also employ a simple ‘encryption’ scheme on top of the opcode: ALWAYS_INLINE static uint32_t tetra_twist(uint32_t input) { /** * Custom hash function that is used to generate the encryption key. * This has strong avalanche properties and is used to ensure that * small changes in the input result in large changes in the output. */ constexpr uint32_t prime1 = 0x9E3779B1; // a large prime number input ^= input &gt;&gt; 15; input *= prime1; input ^= input &gt;&gt; 12; input *= prime1; input ^= input &gt;&gt; 4; input *= prime1; input ^= input &gt;&gt; 16; return input; } ALWAYS_INLINE static uint32_t transform(uintptr_t offset, uint32_t key) { uint32_t key2 = key + offset; return tetra_twist(key2); } ALWAYS_INLINE static uint32_t riscvm_fetch(riscvm_ptr self) { uint32_t data; memcpy(&amp;data, (const void*)self-&gt;pc, sizeof(data)); #ifdef CODE_ENCRYPTION return data ^ transform(self-&gt;pc - self-&gt;base, self-&gt;key); #else return data; #endif // CODE_ENCRYPTION } The offset relative to the start of the bytecode is used as the seed to a simple transform function. The result of this function is XOR’d with the instruction data before decoding. The exact transformation doesn’t really matter, because an attacker can always observe the decrypted bytecode at runtime. However, static analysis becomes more difficult and pattern-matching the payload is prevented, all for a relatively small increase in VM implementation complexity. It would be possible to encrypt the contents of the .data section of the payload as well, but we would have to completely decrypt it in memory before starting execution anyway. Technically, it would be also possible to implement a lazy encryption scheme by customizing the riscvm_read and riscvm_write functions to intercept reads/writes to the payload region, but this idea was not pursued further. Threaded handlers The most interesting feature of our VM is that we only need to make minor code modifications to turn it into a so-called threaded interpreter. Threaded code is a well-known technique used both to speed up emulators and to introduce indirect branches that complicate reverse engineering. It is called threading because the execution can be visualized as a thread of handlers that directly branch to the next handler. There is no classical dispatch function, with an infinite loop and a switch case for each opcode inside. The performance improves because there are fewer false-positives in the branch predictor when executing threaded code. You can find more information about threaded interpreters in the Dispatch Techniques section of the YETI paper. The first step is to construct a handler table, where each handler is placed at the index corresponding to each opcode. To do this we use a small snippet of constexpr C++ code: typedef bool (*riscvm_handler_t)(riscvm_ptr, Instruction); static constexpr std::array&lt;riscvm_handler_t, 32&gt; riscvm_handlers = [] { // Pre-populate the table with invalid handlers std::array&lt;riscvm_handler_t, 32&gt; result = {}; for (size_t i = 0; i &lt; result.size(); i++) { result[i] = handler_rv64_invalid; } // Insert the opcode handlers at the right index #define INSERT(op) result[op] = HANDLER(op) INSERT(rv64_load); INSERT(rv64_fence); INSERT(rv64_imm64); INSERT(rv64_auipc); INSERT(rv64_imm32); INSERT(rv64_store); INSERT(rv64_op64); INSERT(rv64_lui); INSERT(rv64_op32); INSERT(rv64_branch); INSERT(rv64_jalr); INSERT(rv64_jal); INSERT(rv64_system); #undef INSERT return result; }(); With the riscvm_handlers table populated we can define the dispatch macro: #define dispatch() \ Instruction next; \ next.bits = riscvm_fetch(self); \ if (next.compressed_flags != 0b11) \ { \ panic("compressed instructions not supported!"); \ } \ __attribute__((musttail)) return riscvm_handlers[next.opcode](self, next) The musttail attribute forces the call to the next handler to be a tail call. This is only possible because all the handlers have the same function signature and it generates an indirect branch to the next handler: The final piece of the puzzle is the new implementation of the riscvm_run function, which uses an empty riscvm_execute handler to bootstrap the chain of execution: ALWAYS_INLINE static bool riscvm_execute(riscvm_ptr self, Instruction inst) { dispatch(); } NEVER_INLINE void riscvm_run(riscvm_ptr self) { Instruction inst; riscvm_execute(self, inst); } Traditional obfuscation The built-in hardening features that we can get with a few #ifdefs and a small Python script are good enough for a proof-of-concept, but they are not going to deter a determined attacker for a very long time. An attacker can pattern-match the VM’s handlers to simplify future reverse engineering efforts. To address this, we can employ common obfuscation techniques using LLVM obfuscation passes: Instruction substitution (to make pattern matching more difficult) Opaque predicates (to hinder static analysis) Inject anti-debug checks (to make dynamic analysis more difficult) The paper Modern obfuscation techniques by Roman Oravec gives a nice overview of literature and has good data on what obfuscation passes are most effective considering their runtime overhead. Additionally, it would also be possible to further enhance the VM’s security by duplicating handlers, but this would require extra post-processing on the payload itself. The VM itself is only part of what could be obfuscated. Obfuscating the payloads themselves is also something we can do quite easily. Most likely, manually-integrated security features (stack strings with xorstr, lazy_importer and variable encryption) will be most valuable here. However, because we use LLVM to build the payloads we can also employ automated obfuscation there. It is important to keep in mind that any overhead created in the payloads themselves is multiplied by the overhead created by the handler obfuscation, so experimentation is required to find the sweet spot for your use case. Writing the payloads The VM described in this post so far technically has the ability to execute arbitrary code. That being said, it would be rather annoying for an end-user to write said code. For example, we would have to manually resolve all imports and then use the riscvm_host_call function to actually execute them. These functions are executing in the RISC-V context and their implementation looks like this: uintptr_t riscvm_host_call(uintptr_t address, uintptr_t args[13]) { register uintptr_t a0 asm("a0") = address; register uintptr_t a1 asm("a1") = (uintptr_t)args; register uintptr_t a7 asm("a7") = 20000; asm volatile("scall" : "+r"(a0) : "r"(a1), "r"(a7)); return a0; } uintptr_t riscvm_get_peb() { register uintptr_t a0 asm("a0") = 0; register uintptr_t a7 asm("a7") = 20001; asm volatile("scall" : "+r"(a0) : "r"(a7) : "memory"); return a0; } We can get a pointer to the PEB using riscvm_get_peb and then resolve a module by its’ x65599 hash: // Structure definitions omitted for clarity uintptr_t riscvm_resolve_dll(uint32_t module_hash) { static PEB* peb = 0; if (!peb) { peb = (PEB*)riscvm_get_peb(); } LIST_ENTRY* begin = &amp;peb-&gt;Ldr-&gt;InLoadOrderModuleList; for (LIST_ENTRY* itr = begin-&gt;Flink; itr != begin; itr = itr-&gt;Flink) { LDR_DATA_TABLE_ENTRY* entry = CONTAINING_RECORD(itr, LDR_DATA_TABLE_ENTRY, InLoadOrderLinks); if (entry-&gt;BaseNameHashValue == module_hash) { return (uintptr_t)entry-&gt;DllBase; } } return 0; } Once we’ve obtained the base of the module we’re interested in, we can resolve the import by walking the export table: uintptr_t riscvm_resolve_import(uintptr_t image, uint32_t export_hash) { IMAGE_DOS_HEADER* dos_header = (IMAGE_DOS_HEADER*)image; IMAGE_NT_HEADERS* nt_headers = (IMAGE_NT_HEADERS*)(image + dos_header-&gt;e_lfanew); uint32_t export_dir_size = nt_headers-&gt;OptionalHeader.DataDirectory[0].Size; IMAGE_EXPORT_DIRECTORY* export_dir = (IMAGE_EXPORT_DIRECTORY*)(image + nt_headers-&gt;OptionalHeader.DataDirectory[0].VirtualAddress); uint32_t* names = (uint32_t*)(image + export_dir-&gt;AddressOfNames); uint32_t* funcs = (uint32_t*)(image + export_dir-&gt;AddressOfFunctions); uint16_t* ords = (uint16_t*)(image + export_dir-&gt;AddressOfNameOrdinals); for (uint32_t i = 0; i &lt; export_dir-&gt;NumberOfNames; ++i) { char* name = (char*)(image + names[i]); uintptr_t func = (uintptr_t)(image + funcs[ords[i]]); // Ignore forwarded exports if (func &gt;= (uintptr_t)export_dir &amp;&amp; func &lt; (uintptr_t)export_dir + export_dir_size) continue; uint32_t hash = hash_x65599(name, true); if (hash == export_hash) { return func; } } return 0; } Now we can call MessageBoxA from RISC-V with the following code: // NOTE: We cannot use Windows.h here #include &lt;stdint.h&gt; int main() { // Resolve LoadLibraryA auto kernel32_dll = riscvm_resolve_dll(hash_x65599("kernel32.dll", false)) auto LoadLibraryA = riscvm_resolve_import(kernel32_dll, hash_x65599("LoadLibraryA", true)) // Load user32.dll uint64_t args[13]; args[0] = (uint64_t)"user32.dll"; auto user32_dll = riscvm_host_call(LoadLibraryA, args); // Resolve MessageBoxA auto MessageBoxA = riscvm_resolve_import(user32_dll, hash_x65599("MessageBoxA", true)); // Show a message to the user args[0] = 0; // hwnd args[1] = (uint64_t)"Hello from RISC-V!"; // msg args[2] = (uint64_t)"riscvm"; // title args[3] = 0; // flags riscvm_host_call(MessageBoxA, args); } With some templates/macros/constexpr tricks we can probably get this down to something more readable, but fundamentally this code will always stay annoying to write. Even if calling imports were a one-liner, we would still have to deal with the fact that we cannot use Windows.h (or any of the Microsoft headers for that matter). The reason for this is that we are cross-compiling with Clang. Even if we were to set up the include paths correctly, it would still be a major pain to get everything to compile correctly. That being said, our VM works! A major advantage of RISC-V is that, since the instruction set is simple, once the fundamentals work, we can be confident that features built on top of this will execute as expected. Whole Program LLVM Usually, when discussing LLVM, the compilation process is running on Linux/macOS. In this section, we will describe a pipeline that can actually be used on Windows, without making modifications to your toolchain. This is useful if you would like to analyze/fuzz/obfuscate Windows applications, which might only compile an MSVC-compatible compiler: clang-cl. Link-time optimization (LTO) Without LTO, the object files produced by Clang are native COFF/ELF/Mach-O files. Every file is optimized and compiled independently. The linker loads these objects and merges them together into the final executable. When enabling LTO, the object files are instead LLVM Bitcode (.bc) files. This allows the linker to merge all the LLVM IR together and perform (more comprehensive) whole-program optimizations. After the LLVM IR has been optimized, the native code is generated and the final executable produced. The diagram below comes from the great Link-time optimisation (LTO) post by Ryan Stinnet: Compiler wrappers Unfortunately, it can be quite annoying to write an executable that can replace the compiler. It is quite simple when dealing with a few object files, but with bigger projects it gets quite tricky (especially when CMake is involved). Existing projects are WLLVM and gllvm, but they do not work nicely on Windows. When using CMake, you can use the CMAKE_&lt;LANG&gt;_COMPILER_LAUNCHER variables and intercept the compilation pipeline that way, but that is also tricky to deal with. On Windows, things are more complex than on Linux. This is because Clang uses a different program to link the final executable and correctly intercepting this process can become quite challenging. Embedding bitcode To achieve our goal of post-processing the bitcode of the whole program, we need to enable bitcode embedding. The first flag we need is -flto, which enables LTO. The second flag is -lto-embed-bitcode, which isn’t documented very well. When using clang-cl, you also need a special incantation to enable it: set(EMBED_TYPE "post-merge-pre-opt") # post-merge-pre-opt/optimized if(NOT CMAKE_CXX_COMPILER_ID MATCHES "Clang") if(WIN32) message(FATAL_ERROR "clang-cl is required, use -T ClangCL --fresh") else() message(FATAL_ERROR "clang compiler is required") endif() elseif(CMAKE_CXX_COMPILER_FRONTEND_VARIANT MATCHES "^MSVC$") # clang-cl add_compile_options(-flto) add_link_options(/mllvm:-lto-embed-bitcode=${EMBED_TYPE}) elseif(WIN32) # clang (Windows) add_compile_options(-fuse-ld=lld-link -flto) add_link_options(-Wl,/mllvm:-lto-embed-bitcode=${EMBED_TYPE}) else() # clang (Linux) add_compile_options(-fuse-ld=lld -flto) add_link_options(-Wl,-lto-embed-bitcode=${EMBED_TYPE}) endif() The -lto-embed-bitcode flag creates an additional .llvmbc section in the final executable that contains the bitcode. It offers three settings: -lto-embed-bitcode=&lt;value&gt; - Embed LLVM bitcode in object files produced by LTO =none - Do not embed =optimized - Embed after all optimization passes =post-merge-pre-opt - Embed post merge, but before optimizations Once the bitcode is embedded within the output binary, it can be extracted using llvm-objcopy and disassembled with llvm-dis. This is normally done as the follows: llvm-objcopy --dump-section=.llvmbc=program.bc program llvm-dis program.bc &gt; program.ll Unfortunately, we discovered a bug/oversight in LLD on Windows. The section is extracted without errors, but llvm-dis fails to load the bitcode. The reason for this is that Windows executables have a FileAlignment attribute, leading to additional padding with zeroes. To get valid bitcode, you need to remove some of these trailing zeroes: import argparse import sys import pefile def main(): # Parse the arguments parser = argparse.ArgumentParser() parser.add_argument("executable", help="Executable with embedded .llvmbc section") parser.add_argument("--output", "-o", help="Output file name", required=True) args = parser.parse_args() executable: str = args.executable output: str = args.output # Find the .llvmbc section pe = pefile.PE(executable) llvmbc = None for section in pe.sections: if section.Name.decode("utf-8").strip("\x00") == ".llvmbc": llvmbc = section break if llvmbc is None: print("No .llvmbc section found") sys.exit(1) # Recover the bitcode and write it to a file with open(output, "wb") as f: data = bytearray(llvmbc.get_data()) # Truncate all trailing null bytes while data[-1] == 0: data.pop() # Recover alignment to 4 while len(data) % 4 != 0: data.append(0) # Add a block end marker for _ in range(4): data.append(0) f.write(data) if __name__ == "__main__": main() In our testing, this doesn’t have any issues, but there might be cases where this heuristic does not work properly. In that case, a potential solution could be to brute force the amount of trailing zeroes, until the bitcode parses without errors. Applications Now that we have access to our program’s bitcode, several applications become feasible: Write an analyzer to identify potentially interesting locations within the program. Instrument the bitcode and then re-link the executable, which is particularly useful for code coverage while fuzzing. Obfuscate the bitcode before re-linking the executable, enhancing security. IR retargeting, where the bitcode compiled for one architecture can be used on another. Relinking the executable The bitcode itself unfortunately does not contain enough information to re-link the executable (although this is something we would like to implement upstream). We could either manually attempt to reconstruct the linker command line (with tools like Process Monitor), or use LLVM plugin support. Plugin support is not really functional on Windows (although there is some indication that Sony is using it for their PS4/PS5 toolchain), but we can still load an arbitrary DLL using the -load command line flag. Once we loaded our DLL, we can hijack the executable command line and process the flags to generate a script for re-linking the program after our modifications are done. Retargeting LLVM IR Ideally, we would want to write code like this and magically get it to run in our VM: #include &lt;Windows.h&gt; int main() { MessageBoxA(0, "Hello from RISC-V!", "riscvm", 0); } Luckily this is entirely possible, it just requires writing a (fairly) simple tool to perform transformations on the Bitcode of this program (built using clang-cl). In the coming sections, we will describe how we managed to do this using Microsoft Visual Studio’s official LLVM integration (i.e. without having to use a custom fork of clang-cl). The LLVM IR of the example above looks roughly like this (it has been cleaned up slightly for readability): source_filename = "hello.c" target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-windows-msvc19.38.33133" @message = dso_local global [19 x i8] c"Hello from RISC-V!\00", align 16 @title = dso_local global [7 x i8] c"riscvm\00", align 1 ; Function Attrs: noinline nounwind optnone uwtable define dso_local i32 @main() #0 { %1 = call i32 @MessageBoxA(ptr noundef null, ptr noundef @message, ptr noundef @title, i32 noundef 0) ret i32 0 } declare dllimport i32 @MessageBoxA(ptr noundef, ptr noundef, ptr noundef, i32 noundef) #1 attributes #0 = { noinline nounwind optnone uwtable "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" } attributes #1 = { "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" } !llvm.linker.options = !{!0, !0} !llvm.module.flags = !{!1, !2, !3} !llvm.ident = !{!4} !0 = !{!"/DEFAULTLIB:uuid.lib"} !1 = !{i32 1, !"wchar_size", i32 2} !2 = !{i32 8, !"PIC Level", i32 2} !3 = !{i32 7, !"uwtable", i32 2} !4 = !{!"clang version 16.0.5"} To retarget this code to RISC-V, we need to do the following: Collect all the functions with a dllimport storage class. Generate a riscvm_imports function that resolves all the function addresses of the imports. Replace the dllimport functions with stubs that use riscvm_host_call to call the import. Change the target triple to riscv64-unknown-unknown and adjust the data layout. Compile the retargeted bitcode and link it together with crt0 to create the final payload. Adjusting the metadata After loading the LLVM IR Module, the first step is to change the DataLayout and the TargetTriple to be what the RISC-V backend expects: module.setDataLayout("e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"); module.setTargetTriple("riscv64-unknown-unknown"); module.setSourceFileName("transpiled.bc"); The next step is to collect all the dllimport functions for later processing. Additionally, a bunch of x86-specific function attributes are removed from every function: std::vector&lt;Function*&gt; importedFunctions; for (Function&amp; function : module.functions()) { // Remove x86-specific function attributes function.removeFnAttr("target-cpu"); function.removeFnAttr("target-features"); function.removeFnAttr("tune-cpu"); function.removeFnAttr("stack-protector-buffer-size"); // Collect imported functions if (function.hasDLLImportStorageClass() &amp;&amp; !function.getName().startswith("riscvm_")) { importedFunctions.push_back(&amp;function); } function.setDLLStorageClass(GlobalValue::DefaultStorageClass); Finally, we have to remove the llvm.linker.options metadata to make sure we can pass the IR to llc or clang without errors. Import map The LLVM IR only has the dllimport storage class to inform us that a function is imported. Unfortunately, it does not provide us with the DLL the function comes from. Because this information is only available at link-time (in files like user32.lib), we decided to implement an extra -importmap argument. The extract-bc script that extracts the .llvmbc section now also has to extract the imported functions and what DLL they come from: with open(importmap, "wb") as f: for desc in pe.DIRECTORY_ENTRY_IMPORT: dll = desc.dll.decode("utf-8") for imp in desc.imports: name = imp.name.decode("utf-8") f.write(f"{name}:{dll}\n".encode("utf-8")) Currently, imports by ordinal and API sets are not supported, but we can easily make sure those do not occur when building our code. Creating the import stubs For every dllimport function, we need to add some IR to riscvm_imports to resolve the address. Additionally, we have to create a stub that forwards the function arguments to riscvm_host_call. This is the generated LLVM IR for the MessageBoxA stub: ; Global variable to hold the resolved import address @import_MessageBoxA = private global ptr null define i32 @MessageBoxA(ptr noundef %0, ptr noundef %1, ptr noundef %2, i32 noundef %3) local_unnamed_addr #1 { entry: %args = alloca ptr, i32 13, align 8 %arg3_zext = zext i32 %3 to i64 %arg3_cast = inttoptr i64 %arg3_zext to ptr %import_address = load ptr, ptr @import_MessageBoxA, align 8 %arg0_ptr = getelementptr ptr, ptr %args, i32 0 store ptr %0, ptr %arg0_ptr, align 8 %arg1_ptr = getelementptr ptr, ptr %args, i32 1 store ptr %1, ptr %arg1_ptr, align 8 %arg2_ptr = getelementptr ptr, ptr %args, i32 2 store ptr %2, ptr %arg2_ptr, align 8 %arg3_ptr = getelementptr ptr, ptr %args, i32 3 store ptr %arg3_cast, ptr %arg3_ptr, align 8 %return = call ptr @riscvm_host_call(ptr %import_address, ptr %args) %return_cast = ptrtoint ptr %return to i64 %return_trunc = trunc i64 %return_cast to i32 ret i32 %return_trunc } The uint64_t args[13] array is allocated on the stack using the alloca instruction and every function argument is stored in there (after being zero-extended). The GlobalVariable named import_MessageBoxA is read and finally riscvm_host_call is executed to call the import on the host side. The return value is truncated as appropriate and returned from the stub. The LLVM IR for the generated riscvm_imports function looks like this: ; Global string for LoadLibraryA @str_USER32.dll = private constant [11 x i8] c"USER32.dll\00" define void @riscvm_imports() { entry: %args = alloca ptr, i32 13, align 8 %kernel32.dll_base = call ptr @riscvm_resolve_dll(i32 1399641682) %import_LoadLibraryA = call ptr @riscvm_resolve_import(ptr %kernel32.dll_base, i32 -550781972) %arg0_ptr = getelementptr ptr, ptr %args, i32 0 store ptr @str_USER32.dll, ptr %arg0_ptr, align 8 %USER32.dll_base = call ptr @riscvm_host_call(ptr %import_LoadLibraryA, ptr %args) %import_MessageBoxA = call ptr @riscvm_resolve_import(ptr %USER32.dll_base, i32 -50902915) store ptr %import_MessageBoxA, ptr @import_MessageBoxA, align 8 ret void } The resolving itself uses the riscvm_resolve_dll and riscvm_resolve_import functions we discussed in a previous section. The final detail is that user32.dll is not loaded into every process, so we need to manually call LoadLibraryA to resolve it. Instead of resolving the DLL and import hashes at runtime, they are resolved by the transpiler at compile-time, which makes things a bit more annoying to analyze for an attacker. Trade-offs While the retargeting approach works well for simple C++ code that makes use of the Windows API, it currently does not work properly when the C/C++ standard library is used. Getting this to work properly will be difficult, but things like std::vector can be made to work with some tricks. The limitations are conceptually quite similar to driver development and we believe this is a big improvement over manually recreating types and manual wrappers with riscvm_host_call. An unexplored potential area for bugs is the unverified change to the DataLayout of the LLVM module. In our tests, we did not observe any differences in structure layouts between rv64 and x64 code, but most likely there are some nasty edge cases that would need to be properly handled. If the code written is mainly cross-platform, portable C++ with heavy use of the STL, an alternative design could be to compile most of it with a regular C++ cross-compiler and use the retargeting only for small Windows-specific parts. One of the biggest advantages of retargeting a (mostly) regular Windows C++ program is that the payload can be fully developed and tested on Windows itself. Debugging is much more difficult once the code becomes RISC-V and our approach fully decouples the development of the payload from the VM itself. CRT0 The final missing piece of the crt0 component is the _start function that glues everything together: static void exit(int exit_code); static void riscvm_relocs(); void riscvm_imports() __attribute__((weak)); static void riscvm_init_arrays(); extern int __attribute((noinline)) main(); // NOTE: This function has to be first in the file void _start() { riscvm_relocs(); riscvm_imports(); riscvm_init_arrays(); exit(main()); asm volatile("ebreak"); } void riscvm_imports() { // Left empty on purpose } The riscvm_imports function is defined as a weak symbol. This means the implementation provided in crt0.c can be overwritten by linking to a stronger symbol with the same name. If we generate a riscvm_imports function in our retargeted bitcode, that implementation will be used and we can be certain we execute before main! Example payload project Now that all the necessary tooling has been described, we can put everything together in a real project! In the repository, this is all done in the payload folder. To make things easy, this is a simple cmkr project with a template to enable the retargeting scripts: # Reference: https://build-cpp.github.io/cmkr/cmake-toml [cmake] version = "3.19" cmkr-include = "cmake/cmkr.cmake" [project] name = "payload" languages = ["CXX"] cmake-before = "set(CMAKE_CONFIGURATION_TYPES Debug Release)" include-after = ["cmake/riscvm.cmake"] msvc-runtime = "static" [fetch-content.phnt] url = "https://github.com/mrexodia/phnt-single-header/releases/download/v1.2-4d1b102f/phnt.zip" [template.riscvm] type = "executable" add-function = "add_riscvm_executable" [target.payload] type = "riscvm" sources = [ "src/main.cpp", "crt/minicrt.c", "crt/minicrt.cpp", ] include-directories = [ "include", ] link-libraries = [ "riscvm-crt0", "phnt::phnt", ] compile-features = ["cxx_std_17"] msvc.link-options = [ "/INCREMENTAL:NO", "/DEBUG", ] In this case, the add_executable function has been replaced with an equivalent add_riscvm_executable that creates an additional payload.bin file that can be consumed by the riscvm interpreter. The only thing we have to make sure of is to enable clang-cl when configuring the project: cmake -B build -T ClangCL After this, you can open build\payload.sln in Visual Studio and develop there as usual. The custom cmake/riscvm.cmake script does the following: Enable LTO Add the -lto-embed-bitcode linker flag Locale clang.exe, ld.lld.exe and llvm-objcopy.exe Compile crt0.c for the riscv64 architecture Create a Python virtual environment with the necessary dependencies The add_riscvm_executable adds a custom target that processes the regular output executable and executes the retargeter and relevant Python scripts to produce the riscvm artifacts: function(add_riscvm_executable tgt) add_executable(${tgt} ${ARGN}) if(MSVC) target_compile_definitions(${tgt} PRIVATE _NO_CRT_STDIO_INLINE) target_compile_options(${tgt} PRIVATE /GS- /Zc:threadSafeInit-) endif() set(BC_BASE "$&lt;TARGET_FILE_DIR:${tgt}&gt;/$&lt;TARGET_FILE_BASE_NAME:${tgt}&gt;") add_custom_command(TARGET ${tgt} POST_BUILD USES_TERMINAL COMMENT "Extracting and transpiling bitcode..." COMMAND "${Python3_EXECUTABLE}" "${RISCVM_DIR}/extract-bc.py" "$&lt;TARGET_FILE:${tgt}&gt;" -o "${BC_BASE}.bc" --importmap "${BC_BASE}.imports" COMMAND "${TRANSPILER}" -input "${BC_BASE}.bc" -importmap "${BC_BASE}.imports" -output "${BC_BASE}.rv64.bc" COMMAND "${CLANG_EXECUTABLE}" ${RV64_FLAGS} -c "${BC_BASE}.rv64.bc" -o "${BC_BASE}.rv64.o" COMMAND "${LLD_EXECUTABLE}" -o "${BC_BASE}.elf" --oformat=elf -emit-relocs -T "${RISCVM_DIR}/lib/linker.ld" "--Map=${BC_BASE}.map" "${CRT0_OBJ}" "${BC_BASE}.rv64.o" COMMAND "${OBJCOPY_EXECUTABLE}" -O binary "${BC_BASE}.elf" "${BC_BASE}.pre.bin" COMMAND "${Python3_EXECUTABLE}" "${RISCVM_DIR}/relocs.py" "${BC_BASE}.elf" --binary "${BC_BASE}.pre.bin" --output "${BC_BASE}.bin" COMMAND "${Python3_EXECUTABLE}" "${RISCVM_DIR}/encrypt.py" --encrypt --shuffle --map "${BC_BASE}.map" --shuffle-map "${RISCVM_DIR}/shuffled_opcodes.json" --opcodes-map "${RISCVM_DIR}/opcodes.json" --output "${BC_BASE}.enc.bin" "${BC_BASE}.bin" VERBATIM ) endfunction() While all of this is quite complex, we did our best to make it as transparent to the end-user as possible. After enabling Visual Studio’s LLVM support in the installer, you can start developing VM payloads in a few minutes. You can get a precompiled transpiler binary from the releases. Debugging in riscvm When debugging the payload, it is easiest to load payload.elf in Ghidra to see the instructions. Additionally, the debug builds of the riscvm executable have a --trace flag to enable instruction tracing. The execution of main in the MessageBoxA example looks something like this (labels added manually for clarity): main: 0x000000014000d3a4: addi sp, sp, -0x10 = 0x14002cfd0 0x000000014000d3a8: sd ra, 0x8(sp) = 0x14000d018 0x000000014000d3ac: auipc a0, 0x0 = 0x14000d4e4 0x000000014000d3b0: addi a1, a0, 0xd6 = 0x14000d482 0x000000014000d3b4: auipc a0, 0x0 = 0x14000d3ac 0x000000014000d3b8: addi a2, a0, 0xc7 = 0x14000d47b 0x000000014000d3bc: addi a0, zero, 0x0 = 0x0 0x000000014000d3c0: addi a3, zero, 0x0 = 0x0 0x000000014000d3c4: jal ra, 0x14 -&gt; 0x14000d3d8 MessageBoxA: 0x000000014000d3d8: addi sp, sp, -0x70 = 0x14002cf60 0x000000014000d3dc: sd ra, 0x68(sp) = 0x14000d3c8 0x000000014000d3e0: slli a3, a3, 0x0 = 0x0 0x000000014000d3e4: srli a4, a3, 0x0 = 0x0 0x000000014000d3e8: auipc a3, 0x0 = 0x0 0x000000014000d3ec: ld a3, 0x108(a3=&gt;0x14000d4f0) = 0x7ffb3c23a000 0x000000014000d3f0: sd a0, 0x0(sp) = 0x0 0x000000014000d3f4: sd a1, 0x8(sp) = 0x14000d482 0x000000014000d3f8: sd a2, 0x10(sp) = 0x14000d47b 0x000000014000d3fc: sd a4, 0x18(sp) = 0x0 0x000000014000d400: addi a1, sp, 0x0 = 0x14002cf60 0x000000014000d404: addi a0, a3, 0x0 = 0x7ffb3c23a000 0x000000014000d408: jal ra, -0x3cc -&gt; 0x14000d03c riscvm_host_call: 0x000000014000d03c: lui a2, 0x5 = 0x14000d47b 0x000000014000d040: addiw a7, a2, -0x1e0 = 0x4e20 0x000000014000d044: ecall 0x4e20 0x000000014000d048: ret (0x14000d40c) 0x000000014000d40c: ld ra, 0x68(sp=&gt;0x14002cfc8) = 0x14000d3c8 0x000000014000d410: addi sp, sp, 0x70 = 0x14002cfd0 0x000000014000d414: ret (0x14000d3c8) 0x000000014000d3c8: addi a0, zero, 0x0 = 0x0 0x000000014000d3cc: ld ra, 0x8(sp=&gt;0x14002cfd8) = 0x14000d018 0x000000014000d3d0: addi sp, sp, 0x10 = 0x14002cfe0 0x000000014000d3d4: ret (0x14000d018) 0x000000014000d018: jal ra, 0x14 -&gt; 0x14000d02c exit: 0x000000014000d02c: lui a1, 0x2 = 0x14002cf60 0x000000014000d030: addiw a7, a1, 0x710 = 0x2710 0x000000014000d034: ecall 0x2710 The tracing also uses the enums for the opcodes, so it works with shuffled and encrypted payloads as well. Outro Hopefully this article has been an interesting read for you. We tried to walk you through the process in the same order we developed it in, but you can always refer to the riscy-business GitHub repository and try things out for yourself if you got confused along the way. If you have any ideas for improvements, or would like to discuss, you are always welcome in our Discord server! We would like to thank the following people for proofreading and discussing the design and implementation with us (alphabetical order): Brit herrcore JustMagic Renegade veritas Additionally, we highly appreciate the open source projects that we built this project on! If you use this project, consider giving back your improvements to the community as well. Merry Christmas!]]></content:encoded>
</item>
<item>
<title><![CDATA[CVE-2025-10622 | Foreman Transpiler Command ct_location/fcct_location os command injection (EUVD-2025-37786)]]></title>
<description><![CDATA[A vulnerability was found in Foreman. It has been declared as critical. Affected is an unknown function of the component Transpiler Command Handler. The manipulation of the argument ct_location/fcct_location results in os command injection.

This vulnerability is identified as CVE-2025-10622. The...]]></description>
<link>https://tsecurity.de/de/3083860/sicherheitsluecken/cve-2025-10622-foreman-transpiler-command-ctlocationfcctlocation-os-command-injection-euvd-2025-37786/</link>
<guid isPermaLink="true">https://tsecurity.de/de/3083860/sicherheitsluecken/cve-2025-10622-foreman-transpiler-command-ctlocationfcctlocation-os-command-injection-euvd-2025-37786/</guid>
<pubDate>Thu, 06 Nov 2025 17:06:11 +0100</pubDate>
<category>🕵️ Sicherheitslücken</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[A vulnerability was found in <a href="https://vuldb.com/?product.foreman">Foreman</a>. It has been declared as <a href="https://vuldb.com/?kb.risk">critical</a>. Affected is an unknown function of the component <em>Transpiler Command Handler</em>. The manipulation of the argument <em>ct_location/fcct_location</em> results in os command injection.

This vulnerability is identified as <a href="https://vuldb.com/?source_cve.331177">CVE-2025-10622</a>. The attack can only be performed from the local network. There is not any exploit available.]]></content:encoded>
</item>
<item>
<title><![CDATA[Measuring Quantum Noise in IBM Quantum Computers]]></title>
<description><![CDATA[A discussion around measuring error rates in IBM quantum processors, with code examples, using QiskitPicture by Gerd Altmann from PixabayQuantum computing has made significant strides in recent years, with breakthroughs in hardware stability, error mitigation, and algorithm development bringing u...]]></description>
<link>https://tsecurity.de/de/2539455/ai-nachrichten/measuring-quantum-noise-in-ibm-quantum-computers/</link>
<guid isPermaLink="true">https://tsecurity.de/de/2539455/ai-nachrichten/measuring-quantum-noise-in-ibm-quantum-computers/</guid>
<pubDate>Wed, 08 Jan 2025 12:19:28 +0100</pubDate>
<category>🔧 AI Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[<h4>A discussion around measuring error rates in IBM quantum processors, with code examples, using Qiskit</h4><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*BAHV-MW1iJ5lHE-KBjqBow.png"><figcaption>Picture by <a href="https://pixabay.com/users/geralt-9301/">Gerd Altmann</a> from <a href="https://pixabay.com/">Pixabay</a></figcaption></figure><p>Quantum computing has made significant strides in recent years, with breakthroughs in hardware stability, error mitigation, and algorithm development bringing us closer to solving problems that classical computers cannot tackle efficiently. Companies and research institutions worldwide are pushing the boundaries of what quantum systems can achieve, transforming this once-theoretical field into a rapidly evolving technology. IBM has emerged as a key player in this space, offering <a href="https://docs.quantum.ibm.com/">IBM Quantum</a>, a platform that provides access to state-of-the-art quantum processors (QPUs) with a qubit capacity in the hundreds. Through the open-source <a href="https://docs.quantum.ibm.com/guides">Qiskit SDK</a>, developers, researchers, and enthusiasts can design, simulate, and execute quantum circuits on real quantum hardware. This accessibility has accelerated innovation while also highlighting key challenges, such as managing the error rates that still limit the performance of today’s quantum devices.</p><p>By leveraging the access to quantum processors available for free on the IBM platform, we propose to run a few quantum computations to measure the current level of quantum noise in basic circuits. Achieving a low enough level of quantum noise is the most important challenge in making quantum computing useful. Unfortunately, there is not a ton of material on the web explaining the current achievements. It is also not obvious what quantity we want to measure and how to measure it in practice.</p><p>In this blogpost,</p><ul><li>We will review some basics of quantum circuits manipulations in Qiskit.</li><li>We will explain the minimal formalism to discuss quantum errors, explaining the notion of quantum <em>state fidelity</em>.</li><li>We will show how to estimate the fidelity of states produced by simple quantum circuits.</li></ul><p>To follow this discussion, you will need to know some basics about Quantum Information Theory, namely what are qubits, gates, measurements and, ideally, density matrices. The <a href="https://learning.quantum.ibm.com/">IBM Quantum Learning platform</a> has great free courses to learn the basics and more on this topic.</p><p><em>Disclaimer:</em> Although I am aiming at a decent level of scientific rigorousness, this is not a research paper and I do not pretend to be an expert in the field, but simply an enthusiast, sharing my modest understanding.</p><p>To start with, we need to install Qiskit tools</p><pre>%pip install qiskit qiskit_ibm_runtime<br>%pip install 'qiskit[visualization]'</pre><pre>import qiskit<br>import qiskit_ibm_runtime<br><br>print(qiskit.version.get_version_info())<br>print(qiskit_ibm_runtime.version.get_version_info())</pre><pre>1.3.1<br>0.34.0</pre><h3>Running a quantum circuit and observing errors</h3><p>Quantum computations consist in building quantum circuits, running them on quantum hardware and collecting the measured outputs.</p><p>To build a quantum circuit, we start by specifying a number <em>n</em> of qubits for our circuits, where <em>n</em> can be as large as 127 or 156, depending on the underling QPU instance (see <a href="https://quantum.ibm.com/services/resources">processor types</a>). All <em>n</em> qubits are initialised in the |0⟩ state, so the initial state is |0 ⟩<em>ⁿ </em>. Here is how we initialise a circuit with 3 qubits in Qiskit.</p><pre>from qiskit.circuit import QuantumCircuit<br><br># A quantum circuit with three qubits<br>qc = QuantumCircuit(3)<br>qc.draw('mpl')</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/144/1*g8SkdT93PAtnOiQ-VVktBw.png"><figcaption>Initialised 3-qubit quantum circuit</figcaption></figure><p>Next we can add operations on those qubits, in the form of <em>quantum gates, </em>which are unitary operations acting typically on one or two qubits. For instance let us add one <a href="https://docs.quantum.ibm.com/api/qiskit/qiskit.circuit.library.HGate">Hadamard gate</a> acting on the first qubit and two <a href="https://docs.quantum.ibm.com/api/qiskit/qiskit.circuit.library.CXGate#cxgate">CX</a> (aka CNOT) gates on the pairs of qubits (0, 1) and (0, 2).</p><pre># Hadamard gate on qubit 0.<br>qc.h(0)<br># CX gates on qubits (0, 1) and (0, 2).<br>qc.cx(0, 1)<br>qc.cx(0, 2)<br><br>qc.draw('mpl')</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/305/1*qh4YvAUyBFk19cMfZSVkrg.png"><figcaption>A 3-qubit circuit</figcaption></figure><p>We obtain a 3-qubit circuit preparing the state</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/232/1*iJIrdnnuYW85HJ9csPJdhw.png"></figure><p>To measure the output qubits of the circuit, we add a measurement layer</p><pre>qc.measure_all()<br>qc.draw('mpl')</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/595/1*U3A7nnRU_6pL5ocpQPHAgA.png"></figure><p>It is possible to run the circuit and to get its output measured bits as a simulation with StatevectorSampleror on real quantum hardware with SamplerV2 . Let us see the output of a simulation first.</p><pre>from qiskit.primitives import StatevectorSampler<br>from qiskit.transpiler.preset_passmanagers import generate_preset_pass_manager<br>from qiskit.visualization import plot_distribution<br><br>sampler = StatevectorSampler()<br>pm = generate_preset_pass_manager(optimization_level=1)<br># Generate the ISA circuit<br>qc_isa = pm.run(qc)<br># Run the simulator 10_000 times<br>num_shots = 10_000<br>result = sampler.run([qc_isa], shots=num_shots).result()[0]<br># Collect and plot measurements<br>measurements= result.data.meas.get_counts()<br>plot_distribution(measurements)</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/627/1*_tYSWI07RQPX8GaWEOzkJA.png"><figcaption>Result from a sampling simulation</figcaption></figure><p>The measured bits are either (0,0,0) or (1,1,1), with approximate probability close to 0.5. This is precisely what we expect from sampling the 3-qubit state prepared by the circuit.</p><p>We now run the circuit on a QPU (see <a href="https://docs.quantum.ibm.com/guides/setup-channel#set-up-to-use-ibm-quantum-platform">instructions</a> on setting up an IBM Quantum account and retrieving your personal token)</p><pre>from qiskit_ibm_runtime import QiskitRuntimeService<br>from qiskit_ibm_runtime import SamplerV2 as Sampler<br><br>service = QiskitRuntimeService(<br>    channel="ibm_quantum",<br>    token=&lt;YOUR_TOKEN&gt;, # use your IBM Quantum token here.<br>)<br># Fetch a QPU to use<br>backend = service.least_busy(operational=True, simulator=False)<br>print(f"QPU: {backend.name}")<br>target = backend.target<br>sampler = Sampler(mode=backend)<br>pm = generate_preset_pass_manager(target=target, optimization_level=1)<br># Generate the ISA circuit<br>qc_isa = pm.run(qc)<br># Run the simulator 10_000 times<br>num_shots = 10_000<br>result = sampler.run([qc_isa], shots=num_shots).result()[0]<br># Collect and plot measurements<br>measurements= result.data.meas.get_counts()<br>plot_distribution(measurements)</pre><pre>QPU: ibm_brisbane</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/627/1*Bw4KeU6fNPkFqC8wu5v17A.png"><figcaption>Result from sampling on a QPU</figcaption></figure><p>The measured bits are similar to those of the simulation, but now we see a few occurrences of the bit triplets (0,0,1), (0,1,0), (1,0,0), (0,1,1), (1,0,1) and (1,1,0). Those measurements should not occur from sampling the 3-qubit state prepared by the chosen circuit. They correspond to quantum errors occurring while running the circuit on the QPU.</p><p>We would like to quantify the error rate somehow, but it is not obvious how to do it. In quantum computations, what we really care about is that the qubit quantum state prepared by the circuit is the correct state. The measurements which are <strong>not</strong> (0,0,0) or (1,1,1) indicate errors in the state preparation, but this is not all. The measurements (0,0,0) and (1,1,1) could also be the result of incorrectly prepared states, e.g. the state (|0,0,0⟩ + |0,0,1⟩)/√2 can produce the output (0,0,0). Actually, it seems very likely that a few of the “correct” measurements come from incorrect 3-qubit states.</p><p>To understand this “noise” in the state preparation we need the formalism of density matrices to represent quantum states.</p><h3>Density matrices and state fidelity</h3><p>The state of an <em>n</em>-qubit circuit with incomplete information is represented by a 2ⁿ× 2ⁿ <a href="https://en.wikipedia.org/wiki/Definite_matrix">positive semi-definite</a> hermitian matrix with trace equal to 1, called the <em>density matrix ρ</em>. Each diagonal element corresponds to the probability pᵢ of measuring one of the 2ⁿ possible states in a projective measurement, pᵢ = ⟨ψᵢ| ρ |ψᵢ⟩. The off-diagonal elements in ρ do not really have a physical interpretation, they can be set to zero by a change of basis states. In the computational basis, i.e. the standard basis |bit₀, bit₁, …, bitₙ⟩, they encode the entanglement properties of the state. Vector states |ψ⟩ describing the possible quantum states of the qubits have density matrices ρ = |ψ⟩⟨ψ|, whose eigenvalues are all 0, except for one eigenvalue, which is equal to 1. They are called <em>pure states</em>. Generic density matrices represent probabilistic quantum states of the circuit and have eigenvalues between 0 and 1. They are called <em>mixed states</em>. To give an example, a circuit which is in a state |ψ₁⟩ with probability <em>q</em> and in a state |ψ₂⟩ with probability 1-<em>q</em> is represented by the density matrix ρ = <em>q|</em>ψ₁⟩⟨ψ₁| + (1-<em>q</em>)|ψ₂⟩⟨ψ₂|.</p><p>In real quantum hardware, qubits are subject to all kinds of small unknown interactions with the environment, leading to a “loss of information”. This is the source of an incoherent quantum noise. Therefore, when applying gates to qubits or even when preparing the initial state, the quantum state of qubits cannot be described by a pure state, but ends up in a mixed state, which we must describe with a density matrix ρ. Density matrices provide a convenient way to describe quantum circuits in isolation, abstracting the complex and unknown interactions with the environment.</p><p>To learn more about density matrix representation of quantum states, you can look at any quantum information course. The excellent <a href="https://www.youtube.com/watch?v=CeK9ry8G8HQ">Qiskit lecture</a> on this topic is available on YouTube.</p><p>For a single qubit, the density matrix, in the computational basis (i.e. the basis {|0⟩, |1⟩}), is a 2×2 matrix</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/144/1*6hvM5v1oBFhKKLGS7ZKwoQ.png"></figure><p>with p₀ = ⟨0|ρ|0⟩ the probability to measure 0, p₁ = 1 — p₀ = ⟨1|ρ|1⟩ the probability to measure 1, and <em>c</em> is a complex number bounded by |<em>c</em>|² ≤ p₀p₁. Pure states have eigenvalues 0 and 1, so their determinant is zero, and they saturate the inequality with |<em>c</em>|² = p₀p₁.</p><p>In the following, we will consider quantum circuits with a few qubits and we will be interested in quantifying how close the output state density matrix ρ is from the expected (theoretical) output density matrix ρ₀. For a single qubit state, we could think about comparing the values of p₀, p₁ and <em>c</em>, provided we are able to measure them, but in a circuit with more qubits and a larger matrix ρ, we would like to come up with a single number quantifying how close ρ and ρ₀ are. Quantum information theory possesses such quantity. It is called <a href="https://en.wikipedia.org/wiki/Fidelity_of_quantum_states"><em>state fidelity</em></a> and it is defined by the slightly mysterious formula</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/300/1*_IHf9e-4RdXX0qElAUrliQ.png"></figure><p>The state fidelity F is a real number between 0 an 1, 0 ≤ F ≤ 1, with F = 1 corresponding to having identical states ρ = ρ₀ , and F = 0 corresponding to ρ and ρ₀ having orthogonal images. Although it is not so obvious from the definition, it is a symmetric quantity, F(ρ,ρ₀) = F(ρ₀,ρ).</p><p>In quantum circuit computations, the expected output state ρ₀ is always a pure state ρ₀ = |ψ₀⟩⟨ψ₀| and, in this case, the state fidelity reduces to the simpler formula</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/146/1*nZuLDmS9EwaYoAmOMdXzPw.png"></figure><p>which has the desired interpretation as the probability for the state ρ to be measured in the state |ψ₀⟩ (in a hypothetical experiment implementing a projective measurement onto the state |ψ₀⟩ ).</p><p>In the noise-free case, the produced density matrix is ρ = ρ₀ = |ψ₀⟩⟨ψ₀| and the state fidelity is 1. In the presence of noise the fidelity decreases, F &lt; 1.</p><p>In the remainder of this discussion, our goal will be to measure the state fidelity F of simple quantum circuit in Qiskit, or, more precisely, to estimate a lower bound F̃ &lt; F.</p><h3>State fidelity estimation in quantum circuits</h3><p>To run quantum circuits on QPUs and collect measurement results, we define the function run_circuit .</p><pre>def run_circuit(<br>        qc: QuantumCircuit, <br>        service: QiskitRuntimeService = service, <br>        num_shots: int = 100,<br>    ) -&gt; tuple[dict[str, int], QuantumCircuit]:<br>    """Runs the circuit on backend 'num_shots' times. Returns the counts of <br>    measurements and the ISA circuit."""<br>    # Fetch an available QPU<br>    backend = service.least_busy(operational=True, simulator=False)<br>    target = backend.target<br>    pm = generate_preset_pass_manager(target=target, optimization_level=1)<br>    <br>    # Add qubit mesurement layer and compute ISA circuit<br>    qc_meas = qc.measure_all(inplace=False)<br>    qc_isa = pm.run(qc_meas)<br><br>    # Run the ISA circuit and collect results<br>    sampler = Sampler(mode=backend)<br>    result = sampler.run([qc_isa], shots=num_shots).result()<br>    dist = result[0].data.meas.get_counts()<br><br>    return dist, qc_isa</pre><p>The ISA (Instruction Set Architecture) circuit qc_isa returned by this function is essentially a rewriting of the provided circuit in terms of the physical gates available on the QPU, called <em>basis gates</em>. This is the circuit that is actually constructed and run on the hardware.</p><p>Note: The run_circuit function starts by fetching an available QPU. This is convenient to avoid waiting too long for the computation to be processed. However this also means that we use different QPUs each time we call the function. This is not ideal, as it is possible that different QPUs have different level of quantum noise. However, in practice, the fetched QPUs all turned out to be in the <a href="https://docs.quantum.ibm.com/guides/processor-types#eagle">Eagle family</a> and we present noise estimation only for this QPU family. To keep our analysis simple, we just assume that the level of quantum noise among the possible QPU instances is stable. The interested reader could try to find whether there are differences between instances.</p><h4>Bare |0⟩ state</h4><p>Let us start with the simplest circuit, which comprises only an initialised qubit |0⟩ without any gate operation.</p><pre># A quantum circuit with a single qubit |0&gt;<br>qc = QuantumCircuit(1)<br>dist, qc_isa = run_circuit(qc, num_shots=100_000)<br>qc_isa.draw(output="mpl", idle_wires=False, style="iqp")</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/309/1*hsFJBBcC82b28FMN3Do5xA.png"><figcaption>Bare single-qubit circuit (ISA)</figcaption></figure><pre>import numpy as np<br><br>def print_results(dist: dict[str, int]) -&gt; None:<br>    print(f"Measurement counts: {dist}")<br>    num_shots = sum([dist[k] for k in dist])<br>    for k, v in dist.items():<br>        p = v / num_shots<br>        # 1% confidence interval estimate for a Bernoulli variable<br>        delta = 2.575 * np.sqrt(p*(1-p)/num_shots)<br>        print(f"p({k}): {np.round(p, 4)}  ± {np.round(delta, 4)}")<br><br>print_results(dist)</pre><pre>Measurement counts: {'0': 99661, '1': 339}<br>p(0) = 0.9966 ± 0.0005<br>p(1) = 0.0034 ± 0.0005</pre><p>We get a small probability, around 0.3%, to observe the incorrect result 1. The interval estimate “± 0.0005” refers to a 1% <a href="https://en.wikipedia.org/wiki/Confidence_interval">confidence interval</a> estimate for a <a href="https://en.wikipedia.org/wiki/Bernoulli_distribution">Bernoulli</a> variable.</p><p>The fidelity of the output state ρ, relative to the ideal state |0⟩, is F = ⟨0|ρ|0⟩ = p₀. We have obtained an estimate of 0.9966 ± 0.0005 for p₀ from the repeated measurements of the circuit output state. But the measurement operation is a priori imperfect (it has its own error rate). It may add a bias to the p₀ estimate. We assume that these measurement errors tend to decrease the estimated fidelity by incorrect measurements of |0⟩ states. In this case, the estimated p₀ will be a lower bound on the true fidelity F:</p><p>F &gt; F̃ = 0.9966 ± 0.0005</p><p>Note: We have obtained estimated probabilities p₀, p₁ for the diagonal components of the single-qubit density matrix ρ. We also have an estimated bound on the off-diagonal component |<em>c</em>| &lt; √(p₀ p₁) ~ 0.06. To get an actual estimate for <em>c</em>, we would need to run a circuit some gates and design a more complex reasoning.</p><h4>Basis gates</h4><p>Qiskit offers a large number of quantum gates encoding standard operations on one or two qubits, however all these gates are encoded in the QPU hardware with combinations of a very small set of physical operations on the qubits, called <em>basis gates.</em></p><p>There are three single-qubit basis gates: X, SX and RZ(λ) and one two-qubit basis gate: ECR. All other quantum gates are constructed from these building blocks. The more basis gates are used in a quantum circuit, the larger is the quantum noise. We will analyse the noise resulting from applying these basis gates in isolation, when possible, or with a minimal number of basis gates, to get a sense of quantum noise in the current state of QPU computations.</p><h4>X gate</h4><p>We consider the circuit made of a single qubit and an <a href="https://docs.quantum.ibm.com/api/qiskit/qiskit.circuit.library.XGate#xgate">X gate</a>. The output state, in the absence of noise, is X|0⟩ = |1⟩.</p><pre># Quantum circuit with a single qubit and an X gate. <br># Expected output state X|0&gt; = |1&gt;.<br>qc = QuantumCircuit(1)<br>qc.x(0)<br><br>dist, qc_isa = run_circuit(qc, num_shots=100_000)<br>qc_isa.draw(output="mpl", idle_wires=False, style="iqp")</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/338/1*h00PARZ9tFeoo4G9FrqvqQ.png"><figcaption>Single qubit with an X gate (ISA)</figcaption></figure><pre>print_results(dist)</pre><pre>Measurement counts: {'1': 99072, '0': 928}<br>p(0) = 0.0093 ± 0.0008<br>p(1) = 0.9907 ± 0.0008</pre><p>The state fidelity of the output state ρ, relative to the ideal state |1⟩, is</p><p>F = ⟨1|ρ|1⟩ = p₁ &gt; F̃ = 0.9907 ± 0.0008</p><p>where we assumed again that the measurement operation lower the estimated fidelity and we get a lower bound F̃ on the fidelity.</p><p>We observe that the fidelity is (at least) around 99.1%, which is a little worse than the fidelity measured without the X gate. Indeed, adding a gate to the circuit should add noise, but there can be another effect contributing to the degradation of the fidelity, which is the fact that the |1⟩ state is a priori less stable than the |0⟩ state and so the measurement of a |1⟩ state itself is probably more noisy. We will not discuss the physical realisation of a qubit in IBM QPUs, but one thing to keep in mind is that the |0⟩ state has lower energy than the |1⟩ state, so that it is quantum mechanically more stable. As a result, the |1⟩ state can decay to the |0⟩ state through interactions with the environement.</p><h4>SX gate</h4><p>We now consider the <a href="https://docs.quantum.ibm.com/api/qiskit/qiskit.circuit.library.SXGate#sxgate">SX gate</a>, i.e. the “square-root X” gate, represented by the matrix</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/318/1*rhB2ppBAz_kfB6kqV7ybCQ.png"></figure><p>It transforms the initial qubit state |0⟩ into the state</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/550/1*AA3yWoRjt-WwJhSTC5WP7Q.png"></figure><pre># Quantum circuit with a single qubit and an SX gate. <br>qc = QuantumCircuit(1)<br>qc.sx(0)<br><br>dist, qc_isa = run_circuit(qc, num_shots=100_000)<br>qc_isa.draw(output="mpl", idle_wires=False, style="iqp")</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/338/1*4Btx81j_qtuHE7iihofPVg.png"><figcaption>Single qubit qith an SX gate (ISA)</figcaption></figure><pre>print_results(dist)</pre><pre>Measurement counts: {'1': 50324, '0': 49676}<br>p(0) = 0.4968 ± 0.0041<br>p(1) = 0.5032 ± 0.0041</pre><p>We observe roughly equal distributions of zeros and ones, which is as expected. But we face a problem now. The state fidelity cannot be computed from these p₀ and p₁ estimates. Indeed, the fidelity of the output state ρ, relative to the ideal output state SX|0⟩ is</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/462/1*dMRdRS2LQqK8g6YeOACCRA.png"></figure><p>Therefore, to get an estimate of F, we also need to measure <em>c</em>, or rather its imaginary part <em>Im(c)</em>. Since there is no other measurement we can do on the SX gate circuit, we need to consider a circuit with more gates to evaluate F, but more gates also means more sources of noise.</p><p>One simple thing we can do is to add either another SX gate or an SX⁻¹ gate. In the former case, the full circuit implements the X operation and the expected final state |1⟩, while in the latter case, the full circuit implements the identity operation and the expected final state is |0⟩.</p><p>Let us consider the case of adding an SX gate: the density matrix ρ produced by the first SX gate gets transformed into</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/416/1*tY3HtiQHwpsRR4bicZ-YSQ.png"></figure><p>leading to p’₁ = 1/2— <em>Im(c)</em> = F, in the ideal case when the second SX gate is free of quantum noise. In practice the SX gate is imperfect and we can only measure p’₁ = 1/2 — <em>Im(c) — </em>δp = F — δp, where δp is due to the noise from the second SX gate. Although it is theoretically possible that the added noise δp combines with the noise introduced by the first SX gate and results in a smaller combined noise, we will assume that no such “happy” cancelation happens, so that we have δp&gt;0. In this case, p’₁ &lt; F gives us a lower bound on the state fidelity F.</p><pre>qc = QuantumCircuit(1)<br>qc.sx(0)<br>qc.barrier() # Prevents simplification of the circuit during transpilation.<br>qc.sx(0)<br><br>dist, qc_isa = run_circuit(qc, num_shots=100_000)</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/474/1*05Je4G4NimF6BdcKb40xpQ.png"></figure><pre>print_results(dist)</pre><pre>Measurement counts: {'1': 98911, '0': 1089}<br>p(1): 0.9891  ± 0.0008<br>p(0): 0.0109  ± 0.0008</pre><p>We obtain a lower bound F &gt; p’₁ = 0.9891 ± 0.0008, on the fidelity of the output state ρ for the SX-gate circuit, relative to the ideal output state SX|0⟩.</p><p>We could have considered the two-gate circuit with an SX gate followed by an SX⁻¹ gate instead. The SX⁻¹ gate is not a basis gate. It is implemented in the QPU as SX⁻¹ = RZ(-π) SX RZ(-π). We expect this setup to add more quantum noise due the presence of more basis gates, but in practice we have measured a higher (better) lower bound F̃. The interested reader can check this as an exercise. We believe this is due to the fact that the unwanted interactions with the environment tend to bring the qubit state to the ground state |0⟩, improving incorrectly the lower bound estimate, so we do not report this alternative result.</p><h4>RZ(λ) gate</h4><p>Next we consider the <a href="https://docs.quantum.ibm.com/api/qiskit/qiskit.circuit.library.RZGate#rzgate">RZ(λ) gate</a>. The RZ(λ) gate is a parametrised gate implementing a rotation around the z-axis by an angle λ/2.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/394/1*zd14NYG5Yu9jaDuX1XE_Ow.png"></figure><p>Its effect on the initial qubit |0⟩ is only to multiply it by a phase exp(-iλ/2), leaving it in the same state. In general, the action of RZ(λ) on the density matrix of a single qubit is to multiply the off-diagonal coefficient <em>c</em> by exp(iλ), leaving the p₀ and p₁ values of the state unchanged. To measure a non-trivial effect of the RZ(λ) gate, one needs to consider circuits with more gates. The simplest is to consider the circuit composing the three gates SX, RZ(λ) and SX, preparing the state</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/468/1*F9KTlB3M2cj6BV0oNAt18w.png"></figure><p>The expected p(0) and p(1) values are</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/344/1*NjhgTO-YUlbeI6lqZCsxUw.png"></figure><p>Qiskit offers the possibility to run parametrised quantum circuits by specifying an array of parameter values, which, together with the ISA circuit, define a Primitive Unified Bloc (PUB). The PUB is then passed to the sampler to run the circuit with all the specified parameter values.</p><pre>from qiskit.primitives.containers.sampler_pub_result import SamplerPubResult<br><br>def run_parametrised_circuit(<br>        qc: QuantumCircuit, <br>        service: QiskitRuntimeService = service, <br>        params: np.ndarray | None = None,<br>        num_shots: int = 100,<br>    ) -&gt; tuple[SamplerPubResult, QuantumCircuit]:<br>    """Runs the parametrised circuit on backend 'num_shots' times. <br>    Returns the PubResult and the ISA circuit."""<br>    # Fetch an available QPU<br>    backend = service.least_busy(operational=True, simulator=False)<br>    target = backend.target<br>    pm = generate_preset_pass_manager(target=target, optimization_level=1)<br>    <br>    # Add mesurement layer<br>    qc_meas = qc.measure_all(inplace=False)<br>    # Define ISA circuit and PUB<br>    pm = generate_preset_pass_manager(target=target, optimization_level=1)<br>    qc_isa = pm.run(qc_meas)<br>    sampler_pub = (qc_isa, params)<br>    <br>    # Run the circuit<br>    result = sampler.run([sampler_pub], shots=num_shots).result()<br>    return result[0], qc_isa</pre><pre>from qiskit.circuit import Parameter<br><br># Circuit preparing the state SX.RZ(a).SX|0&gt; = sin(a/2)|0&gt; + cos(a/2)|1&gt;.<br>qc = QuantumCircuit(1)<br>qc.sx(0)<br>qc.rz(Parameter("a"), 0)<br>qc.sx(0)<br><br># Define parameter range<br>params = np.linspace(0, 2*np.pi, 21).reshape(-1, 1)<br># Run parametrised circuit<br>pub_result, qc_isa = run_parametrised_circuit(qc, params=params, num_shots=10_000)<br><br>qc_isa.draw(output="mpl", idle_wires=False, style="iqp")</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/474/1*u06041x9cIhoA03CwAFCyw.png"></figure><pre>bit_array = pub_result.data.meas.bitcount()<br>print(f"bit_array shape: {bit_array.shape}")<br>p0 = (bit_array.shape[1] - bit_array.sum(axis=1)) / bit_array.shape[1]<br>p1 = bit_array.sum(axis=1) / bit_array.shape[1]<br>print(f"p(0): {p0}")<br>print(f"p(1): {p1}")</pre><pre>bit_array shape: (21, 10000)<br>p(0): [0.0031 0.0265 0.095  0.2095 0.3507 0.4969 0.6567 0.7853 0.9025 0.9703<br> 0.9983 0.976  0.901  0.7908 0.6543 0.5013 0.3504 0.2102 0.0982 0.0308<br> 0.0036]<br>p(1): [0.9969 0.9735 0.905  0.7905 0.6493 0.5031 0.3433 0.2147 0.0975 0.0297<br> 0.0017 0.024  0.099  0.2092 0.3457 0.4987 0.6496 0.7898 0.9018 0.9692<br> 0.9964]</pre><pre>import matplotlib.pyplot as plt<br><br>x = params/(2*np.pi)<br>plt.scatter(x, p0)<br>plt.scatter(x, p1)<br>plt.plot(x, np.sin(np.pi*x)**2, linestyle="--")<br>plt.plot(x, np.cos(np.pi*x)**2, linestyle="--")<br>plt.xlabel("λ/2π")<br>plt.ylabel("Estimated probabilities")<br>plt.legend(["p(0)", "p(1)", "sin(λ/2)^2", "cos(λ/2)^2"])<br>plt.show()</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/567/1*HRFHqqKf67zW-JpWEWfXBg.png"></figure><p>We see that the estimated probabilities (blue and orange dots) agree very well with the theoretical probabilities (blue and orange lines) for all tested values of λ.</p><p>Here again, this does not give us the state fidelity. We can give a lower bound by adding another sequence of gates SX.RZ(λ).SX to the circuit, bringing back the state to |0⟩. As in the case of the SX gate of the previous section, the estimated F̃ := p’₀ from this 6-gate circuit gives us a lower bound on the fidelity of the F of the 3-gate circuit, assuming the extra gates lower the output state fidelity.</p><p>Let us compute this lower bound F̃ for one value, λ = π/4.</p><pre># Circuit implementing SX.RZ(π/4).SX.SX.RZ(π/4).SX|0&gt; = |0&gt;<br>qc = QuantumCircuit(1)<br>qc.sx(0)<br>qc.rz(np.pi/4, 0)<br>qc.sx(0)<br>qc.barrier()  # Prevents circuit simplifications.<br>qc.sx(0)<br>qc.rz(np.pi/4, 0)<br>qc.sx(0)<br><br>dist, qc_isa = run_circuit(qc, num_shots=100_000)<br>qc_isa.draw(output="mpl", idle_wires=False, style="iqp")</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/731/1*0oZAdSRKDAh5aJx8f5fovA.png"></figure><pre>dist = pub_result.data.meas.get_counts()<br>print_results(dist)</pre><pre>Measurement counts: {'0': 99231, '1': 769}<br>p(0): 0.9923  ± 0.0007<br>p(1): 0.0077  ± 0.0007</pre><p>We find a pretty high lower bound estimate F̃ = 0.9923 ± 0.0007.</p><h4>Digression: a lower bound estimate procedure</h4><p>The above case showed that we can estimate a lower bound on the fidelity F of the output state of a circuit by extending the circuit with its inverse operation and measuring the probability of getting the initial state back.</p><p>Let us consider an <em>n</em>-qubit circuit preparing the state |ψ⟩ = U|0,0, … ,0⟩. The state fidelity of the output density matrix ρ is given by</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/164/1*7clFIcsEPttk5d2q91Fasg.png"></figure><p>U⁻¹ρU is the density matrix of the circuit composed of a (noisy) U gate and a noise-free U⁻¹ gate. F is equal to the fidelity of the |0,0, …, 0⟩ state of this 2-gate circuit. If we had such a circuit, we could sample it and measure the probability of (0, 0, …, 0) as the desired fidelity F.</p><p>In practice we don’t have a noise-free U⁻¹ gate, but only a noisy U⁻¹ gate. By sampling this circuit (noisy U, followed by noisy U⁻¹) and measuring the probability of the (0, 0, …, 0) outcome, we obtain an estimate F̃ of F — δp, with δp the noise overhead added by the U⁻¹ operation (and the measurement operation). Under the assumption δp&gt;0, we obtain a lower bound F &gt; F̃. This assumption is not necessarily true because the noisy interactions with the environment likely tend to bring the qubits to the ground state |0,0, …, 0⟩, but for “complex enough” operations U, this effect should be subdominant relative to the noise introduced by the U⁻¹ operation. We have used this approach to estimate the fidelity in the SX.RZ(λ).SX circuit above. We will use it again to estimate the fidelity of the ECR-gate and the 3-qubit state from the initial circuit we considered.</p><h4>ECR gate</h4><p>The <a href="https://docs.quantum.ibm.com/api/qiskit/qiskit.circuit.library.ECRGate#ecrgate">ECR gate</a> (Echoed Cross-Resonance gate) is the only two-qubit basis gate in the Eagle family of IBM QPUs (other families support the CZ or CX gate instead, see <a href="https://docs.quantum.ibm.com/guides/native-gates#tables-of-gates-and-operations-by-processor-family">tables of gates</a>). It is represented in the computational basis by the 4x4 matrix</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/506/1*IDpBUlJXFmpq1gvw70AHxw.png"></figure><p>Its action on the initial 2-qubit state is</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/570/1*GoZOaIFweO3bQ6ITiRoCSg.png"></figure><p>The measurements of a noise-free ECR gate circuit are (0,1) with probability 1/2 and (1,1) with probability 1/2. The outcome (0,0) and (1,0) are not possible in the noise-free circuit.</p><pre>qc = QuantumCircuit(2)<br>qc.ecr(0, 1)<br>dist, qc_isa = run_circuit(qc, num_shots=100_000)<br><br>qc_isa.draw(output="mpl", idle_wires=False, style="iqp")</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/402/1*fVcuIGvXC3qBwRpraoopfQ.png"><figcaption>Two qubits with an ECR gate (ISA)</figcaption></figure><pre>print_results(dist)</pre><pre>Measurement counts: {'11': 49254, '01': 50325, '00': 239, '10': 182}<br>p(11): 0.4925  ± 0.0041<br>p(01): 0.5032  ± 0.0041<br>p(00): 0.0024  ± 0.0004<br>p(10): 0.0018  ± 0.0003</pre><p>We observe a distribution of measured classical bits roughly agreeing with the expected ideal distribution, but the presence of quantum errors is revealed by the presence of a few (0,0) and (1, 0) outcomes.</p><p>The fidelity of the output state ρ is given by</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/644/1*s3znNAu2R9PhTWvvDCoYqA.png"></figure><p>As in the case of the SX-gate circuit, we cannot directly estimate the fidelity of the ρ state prepared by the ECR-gate circuit by measuring the output bits of the circuit, since it depends on off-diagonal terms in the ρ matrix.</p><p>Instead we can follow the procedure described in the previous section and estimate a lower bound on F by considering the circuit with an added ECR⁻¹ gate. Since ECR⁻¹ = ECR, we consider a circuit with two ECR gates.</p><pre>qc = QuantumCircuit(2)<br>qc.ecr(0, 1)<br>qc.barrier()  # Prevents circuit simplifications.<br>qc.ecr(0, 1)<br>dist, qc_isa = run_circuit(qc, num_shots=100_000)<br>qc_isa.draw(output="mpl", idle_wires=False, style="iqp")</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/539/1*Ofi4hiO4e5qxnIMmdQbHyg.png"></figure><pre>print_results(dist)</pre><pre>Measurement counts: {'00': 99193, '01': 153, '10': 498, '11': 156}<br>p(00): 0.9919  ± 0.0007<br>p(01): 0.0015  ± 0.0003<br>p(10): 0.005  ± 0.0006<br>p(11): 0.0016  ± 0.0003</pre><p>We find the estimated lower bound F &gt; 0.9919 ± 0.0007 on the ρ state prepared by the ECR-gate circuit.</p><h4>3-qubit state fidelity</h4><p>To close the loop, in our final example, let us compute a lower bound on the state fidelity of the 3-qubit state circuit which we considered first. Here again, we add the inverse operation to the circuit, bringing back the state to |0,0,0⟩ and measure the circuit outcomes.</p><pre>qc = QuantumCircuit(3)<br>qc.h(0)<br>qc.cx(0, 1)<br>qc.cx(0, 2)<br>qc.barrier(). # Prevents circuit simplifications.<br>qc.cx(0, 2)<br>qc.cx(0, 1)<br>qc.h(0)<br>qc.draw('mpl')</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/563/1*e9kBjFwKGAee8Lx8415cRQ.png"></figure><pre>dist, qc_isa = run_circuit(qc, num_shots=100_000)<br>qc_isa.draw(output="mpl", idle_wires=False, style="iqp")</pre><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*WCF94CnnFCR8JKHfijCMaQ.png"><figcaption>ISA circuit</figcaption></figure><pre>print_results(dist)</pre><pre>Measurement counts: {'000': 95829, '001': 1771, '010': 606, '011': 503, '100': 948, '101': 148, '111': 105, '110': 90}<br>p(000): 0.9583  ± 0.0016<br>p(001): 0.0177  ± 0.0011<br>p(010): 0.0061  ± 0.0006<br>p(011): 0.005  ± 0.0006<br>p(100): 0.0095  ± 0.0008<br>p(101): 0.0015  ± 0.0003<br>p(111): 0.001  ± 0.0003<br>p(110): 0.0009  ± 0.0002</pre><p>We find the fidelity lower bound F̃ = p’((0,0,0)) = 0.9583 ± 0.0016 for the 3-qubit state circuit.</p><h3>Summary of results and discussion</h3><p>Let us summarise our results in a table of fidelity lower bounds for the circuits we considered, using IBM QPUs.</p><figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Op4KKgGjigKTIDSds1x_tA.png"></figure><p>We find that the fidelity of states produced by circuits with a minimal number of basis gate is around 99%, which is not a small achievement. As we add more qubits and gates, the fidelity decreases, as we see with the 96% fidelity for the 3-qubit state, whose circuit has 13 basis gates. With more qubits and circuit depth, the fidelity would decrease further, to the point that the quantum computation would be completely unreliable. Nevertheless, these results look quite encouraging for the future of quantum computing.</p><p>It is likely that more accurate and rigorous methods exist to evaluate the fidelity of the state produced by a quantum circuit, giving more robust bounds. We are just not aware of them. The main point was to provide hands-on examples of Qiskit circuit manipulations for beginners and to get approximate quantum noise estimates.</p><p>While we have run a number of circuits to estimate quantum noise, we have only scratched the surface of the topic. There are many ways to go further, but one important idea to make progress is to make assumptions on the form of the quantum noise, namely to develop a model for a <em>quantum channel</em> representing the action of the noise on a state. This would typically involve a separation between “coherent” noise, preserving the purity of the state, which can be described with a unitary operation, and “incoherent” noise, representing interactions with the environment. The <a href="https://www.youtube.com/watch?v=3Ka11boCm1M">Qiskit Summer School lecture on the topic</a> provides a gentle introduction to these ideas.</p><p>Finally, here are a few reviews related to quantum computing, if you want to learn more on this topic. [1] is an introduction to quantum algorithms. [2] is a review of quantum mitigation techniques for near-term quantum devices. [3] is an introduction to quantum error correction theory. [4] is a review of quantum computing ideas and physical realisation of quantum processors in 2022, aimed at a non-scientific audience.</p><p>Thanks for getting to the end of this blogpost. I hope you had some fun and learned a thing or two.</p><p><em>Unless otherwise noted, all images are by the author</em></p><p>[1] Blekos, Kostas and Brand, Dean and Ceschini, Andrea and Chou, Chiao-Hui and Li, Rui-Hao and Pandya, Komal and Summer, Alessandro, <a href="https://arxiv.org/abs/1804.03719"><em>Quantum Algorithm Implementations for Beginners</em></a><em> </em>(2023), Physics Reports Volume 1068, 2 June 2024.</p><p>[2] Cai, Zhenyu and Babbush, Ryan and Benjamin, Simon C. and Endo, Suguru and Huggins, William J. and Li, Ying and McClean, Jarrod R. and O’Brien, Thomas E., <a href="https://arxiv.org/abs/2210.00921"><em>Quantum error mitigation</em></a> (2023), Reviews of Modern Physics 95, 045005.</p><p>[3] J. Roffe, <a href="https://arxiv.org/abs/1907.11157"><em>Quantum error correction: an introductory guide</em></a> (2019), Contemporary Physics, Oct 2019.</p><p>[3] A. K. Fedorov, N. Gisin, S. M. Beloussov and A. I. Lvovsky, <a href="https://arxiv.org/abs/2203.17181"><em>Quantum computing at the quantum advantage threshold: a down-to-business review</em></a> (2022).</p><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=60a6b739a547" width="1" height="1" alt=""><hr><p><a href="https://towardsdatascience.com/measuring-quantum-noise-in-ibm-quantum-computers-60a6b739a547">Measuring Quantum Noise in IBM Quantum Computers</a> was originally published in <a href="https://towardsdatascience.com/">Towards Data Science</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>]]></content:encoded>
</item>
<item>
<title><![CDATA[IBM, 신규 양자 하드웨어 및 소프트웨어 공개]]></title>
<description><![CDATA[IBM에 따르면 퀀텀 헤론(IBM Quantum Heron)은 IBM 글로벌 양자 데이터 센터를 통해 사용할 수 있는 현존 최고 성능의 IBM의 양자 프로세서다. IBM은 퀀텀 헤론이 이제 퀴스킷(Qiskit)을 활용해 특정 클래스의 양자 회로를 최대 5,000개의 2큐비트 게이트 연산까지 정확하게 실행할 수 있다고 밝혔다. 사용자들은 IBM 퀀텀 헤론의 성능을 활용해 재료, 화학, 생명과학, 고에너지 물리학 등 다양한 분야의 과학적 문제를 양자 컴퓨터로 해결하는 방법을 탐구할 수 있다는 설명이다.



IBM은 이를 통해 양...]]></description>
<link>https://tsecurity.de/de/2441040/it-security-nachrichten/ibm/</link>
<guid isPermaLink="true">https://tsecurity.de/de/2441040/it-security-nachrichten/ibm/</guid>
<pubDate>Thu, 14 Nov 2024 04:33:48 +0100</pubDate>
<category>📰 IT Security Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[<div>
		<div class="grid grid--cols-10@md grid--cols-8@lg article-column">
					  <div class="col-12 col-10@md col-6@lg col-start-3@lg">
						<div class="article-column__content">
<section class="wp-block-bigbite-multi-title"><div class="container"></div></section>



<p>IBM에 따르면 퀀텀 헤론(IBM Quantum Heron)은 IBM 글로벌 양자 데이터 센터를 통해 사용할 수 있는 현존 최고 성능의 IBM의 양자 프로세서다. IBM은 퀀텀 헤론이 이제 퀴스킷(Qiskit)을 활용해 특정 클래스의 양자 회로를 최대 5,000개의 2큐비트 게이트 연산까지 정확하게 실행할 수 있다고 <a href="https://www.ibm.com/quantum/blog/qdc-2024" rel="nofollow">밝혔다</a>. 사용자들은 IBM 퀀텀 헤론의 성능을 활용해 재료, 화학, 생명과학, 고에너지 물리학 등 다양한 분야의 과학적 문제를 양자 컴퓨터로 해결하는 방법을 탐구할 수 있다는 설명이다.</p>



<p>IBM은 이를 통해 양자 개발 로드맵의 또 하나의 주요 목표를 달성했다. IBM과 비즈니스 파트너가 양자 우위와 2029년으로 예정된 오류 수정 첨단 시스템을 향해 나아가 양자 유용성 시대를 더욱 앞당길 수 있는 성과라고 회사는 설명했다.</p>



<p>IBM 헤론과 퀴스킷의 성능 향상으로 사용자는 최대 5,000개의 게이트로 구성된 양자 회로를 실행할 수 있다. 이는 2023년 IBM의 양자 유용성 시연에서 정확하게 실행된 게이트 수의 약 2배에 달하는 수치다. IBM 퀀텀의 컴퓨터 성능은 무차별 대입 방식의 기존 시뮬레이션 방식보다 향상됐다. 네이처(Nature)에 게재된 2023년 유용성 실험에서는 데이터 당 처리 시간이 총 112시간 소요됐으나, 동일한 데이터를 사용한 실험을 최신 IBM 헤론 프로세서에서 실행한 결과 2.2시간 만에 완료할 수 있었다.</p>



<p>IBM은 개발자가 안정성과 정확성, 속도를 갖춘 복잡한 양자 회로를 보다 쉽게 구축할 수 있도록 고성능 양자 소프트웨어로 퀴스킷을 발전시켜 왔다. IBM은 이를 오픈소스 벤치마킹 도구인 벤치프레스를 사용해 측정한 결과로 입증할 수 있다면서, 제3자 기관의 1, 000여 개의 테스트를 통해 퀴스킷이 다른 플랫폼 대비 가장 높은 성능과 안정성을 갖춘 양자 소프트웨어 개발 키트라는 것을 확인했다고 언급했다.</p>



<p>제이 감베타 IBM 퀀텀 부사장은 “IBM 퀀텀 하드웨어와 퀴스킷의 발전으로 사용자들은 첨단 양자 및 기존 슈퍼컴퓨팅 자원을 결합해 각자의 강점을 결합한 새로운 알고리즘을 구축할 수 있게 됐다. 오류 수정 양자 시스템을 향한 로드맵을 향해 나아가는 가운데, 현재 산업 전반에서 발견되는 알고리즘은 QPU, CPU, GPU의 융합으로 만들어지는 미개척 컴퓨팅 분야의 잠재력을 실현하는 데 핵심이 될 것”이라고 말했다.</p>



<p>IBM 퀀텀 플랫폼은 이제 생성형 AI 기반 기능과 IBM 파트너들의 새로운 소프트웨어와 같은 신규 퀴스킷 서비스로 선택지를 확장하고 있다. 이는 산업 전반의 전문가 네트워크가 과학 연구를 위한 차세대 알고리즘을 구축할 수 있도록 지원한다.</p>



<p>이런 도구에는 AI로 양자 하드웨어를 위한 양자 회로의 효율적인 최적화를 지원하는 퀴스킷 트랜스파일러 서비스(Qiskit Transpiler Service), 개발자가 IBM 그래니트 기반 생성 AI 모델로 양자 코드를 생성하는 데 도움을 주는 퀴스킷 코드 어시스턴트(Qiskit Code Assistant), 양자 및 기존 시스템에서 초기 양자 중심 슈퍼컴퓨팅 접근법을 실행하는 퀴스킷 서버리스(Qiskit Serverless) 등이 있다. 또한 양자 노이즈의 성능 관리에 필요한 리소스를 줄이고 양자 회로의 복잡성을 추상화해 양자 알고리즘 개발을 간소화하기 위한 도구로는 IBM 퀴스킷 함수 카탈로그(IBM Qiskit Functions Catalog)가 있다. 퀴스킷 함수 카탈로그는 IBM, 알고리즘믹(Algorithmiq), 케드마(Qedma), 큐나시스(QunaSys), Q-CTRL 및 멀티버스 컴퓨팅의 서비스를 이용할 수 있다.</p>



<p>IBM은 차세대 고성능 컴퓨팅을 위해 양자 중심 슈퍼컴퓨팅을 개발하고 있다. 이 시스템은 최첨단 양자 컴퓨터와 기존 컴퓨터를 하나로 통합해, 병렬 처리가 가능한 작업들을 수행한다. 고성능 소프트웨어를 통해 복잡한 문제를 쉽게 나누고, 각 부분을 가장 적합한 컴퓨팅 구조에 배정하여 해결한 뒤, 그 결과들을 신속하고 원활하게 통합한다. 이를 통해 기존의 단일 컴퓨팅 방식으로는 접근하기 어렵거나 불가능했던 알고리즘도 효과적으로 실행할 수 있다.</p>



<p>이미 몇몇 기관은 유용성 단계의 IBM 퀀텀 시스템 원을 통해 화학의 기본이 되는 전자 구조 문제에 대한 알고리즘을 연구하고 있다. 대표적으로 일본의 국립 과학 연구 기관인 이화학연구소(RIKEN)와 선도적인 학술 의료 센터이자 생의학 연구 기관인 클리블랜드 클리닉(Cleveland Clinic)가 있다. 이 기관의 프로젝트는 복잡한 화학 및 생물학적 시스템을 현실적으로 모델링하기 위한 양자 중심 슈퍼컴퓨팅 접근 방식의 첫 단계에 있다. 과거에는 무결함 양자 컴퓨터가 필요할 것이라고 여겨졌던 작업이라고 IBM은 설명했다.<br>dl-ciokorea@foundryco.com</p>
</div></div></div></div>]]></content:encoded>
</item>
<item>
<title><![CDATA[(g+) Modernisierung in Softwareprojekten: Von Cobol nach Java in zehn Minuten]]></title>
<description><![CDATA[Mit einem Transpiler können Entwickler in Modernisierungsprojekten Cobol unkompliziert nach Java konvertieren. Wir zeigen, wie das geht. Eine Anleitung von Uwe Graf (Softwareentwicklung, Java)]]></description>
<link>https://tsecurity.de/de/2207297/it-nachrichten/g-modernisierung-in-softwareprojekten-von-cobol-nach-java-in-zehn-minuten/</link>
<guid isPermaLink="true">https://tsecurity.de/de/2207297/it-nachrichten/g-modernisierung-in-softwareprojekten-von-cobol-nach-java-in-zehn-minuten/</guid>
<pubDate>Mon, 01 Jul 2024 12:02:20 +0200</pubDate>
<category>📰 IT Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[Mit einem Transpiler können Entwickler in Modernisierungsprojekten Cobol unkompliziert nach Java konvertieren. Wir zeigen, wie das geht. Eine Anleitung von Uwe Graf (<a href="https://www.golem.de/specials/softwareentwicklung/">Softwareentwicklung</a>, <a href="https://www.golem.de/specials/java/">Java</a>) <img src="https://cpx.golem.de/cpx.php?class=17&amp;aid=186281&amp;page=1&amp;ts=1719828002" alt="" width="1" height="1">]]></content:encoded>
</item>
<item>
<title><![CDATA[Google is Making Its Internal Video-Blurring Privacy Tool Open Source]]></title>
<description><![CDATA[Google has announced that two of its latest privacy-enhancing technologies (PETs), including one that blurs objects in a video, will be provided to anyone for free via open source. From a report: The new tools are part of Google's Protected Computing initiative designed to transform "how, when an...]]></description>
<link>https://tsecurity.de/de/1743681/it-security-nachrichten/google-is-making-its-internal-video-blurring-privacy-tool-open-source/</link>
<guid isPermaLink="true">https://tsecurity.de/de/1743681/it-security-nachrichten/google-is-making-its-internal-video-blurring-privacy-tool-open-source/</guid>
<pubDate>Thu, 22 Dec 2022 19:16:08 +0100</pubDate>
<category>📰 IT Security Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[Google has announced that two of its latest privacy-enhancing technologies (PETs), including one that blurs objects in a video, will be provided to anyone for free via open source. From a report: The new tools are part of Google's Protected Computing initiative designed to transform "how, when and where data is processed to technically ensure its privacy and safety," the company said. The first is an internal project called Magritte, now out on Github, which uses machine learning to detect objects and apply a blur as soon as they appear on screen. It can disguise arbitrary objects like license plates, tattoos and more. 

The other with the unwieldy name "Fully Homomorphic Encryption (FHE) Transpiler, allows developers to perform computations on encrypted data without being able to access personally identifiable information. Google says it can help industries like financial services, healthcare and government, "where a robust security guarantee around the processing of sensitive data is of highest importance." Google notes that PETs are starting to enter the mainstream after being mostly an academic exercise. The White House recently touted the technology, saying "it will allow researchers, physicians, and others permitted access to gain insights from sensitive data without ever having access to the data itself."<p></p><div class="share_submission">
<a class="slashpop" href="http://twitter.com/home?status=Google+is+Making+Its+Internal+Video-Blurring+Privacy+Tool+Open+Source%3A+https%3A%2F%2Fbit.ly%2F3YUlhho"><img src="https://a.fsdn.com/sd/twitter_icon_large.png"></a>
<a class="slashpop" href="http://www.facebook.com/sharer.php?u=https%3A%2F%2Fnews.slashdot.org%2Fstory%2F22%2F12%2F22%2F1730257%2Fgoogle-is-making-its-internal-video-blurring-privacy-tool-open-source%3Futm_source%3Dslashdot%26utm_medium%3Dfacebook"><img src="https://a.fsdn.com/sd/facebook_icon_large.png"></a>



</div><p><a href="https://news.slashdot.org/story/22/12/22/1730257/google-is-making-its-internal-video-blurring-privacy-tool-open-source?utm_source=rss1.0moreanon&amp;utm_medium=feed">Read more of this story</a> at Slashdot.</p>]]></content:encoded>
</item>
<item>
<title><![CDATA[Developer Proposes New (and Compatible) 'Extended Flavor' of Go]]></title>
<description><![CDATA[While listening to a podcast about the Go programming language, backend architect Aviv Carmi heard some loose talk about forking the language to keep its original design while also allowing the evolution of an "extended flavor." 
If such a fork takes place, Carmi writes on Medium, he hopes the tw...]]></description>
<link>https://tsecurity.de/de/1679409/it-security-nachrichten/developer-proposes-new-and-compatible-extended-flavor-of-go/</link>
<guid isPermaLink="true">https://tsecurity.de/de/1679409/it-security-nachrichten/developer-proposes-new-and-compatible-extended-flavor-of-go/</guid>
<pubDate>Sun, 30 Oct 2022 01:48:05 +0200</pubDate>
<category>📰 IT Security Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[While listening to a podcast about the Go programming language, backend architect Aviv Carmi heard some loose talk about forking the language to keep its original design while also allowing the evolution of an "extended flavor." 
If such a fork takes place, Carmi writes on Medium, he hopes the two languages could interact and share the same runtime environment, libraries, and ecosystem — citing lessons learned from the popularity of other language forks:
There are well-known, hugely successful precedents for such a move. Unarguably, the JVM ecosystem will last longer and keep on gaining popularity thanks to Scala and Kotlin (a decrease in Java's popularity is overtaken by an increase in Scala's, during the previous decade, and in Kotlin's, during this one). All three languages contribute to a stronger, single community and gain stronger libraries and integrations. JavaScript has undoubtedly become stronger thanks to Typescript, which quickly became one of the world's most popular languages itself. I also believe this is the right move for us Gophers... 

Carmi applauds Go's readability-over-writability culture, its consistent concurrency model (with lightweight threading), and its broad ecosystem of tools. But in a second essay Carmi lists his complaints — about Go's lack of keyword-based visibility modifiers (like "public" and "private"), how any symbol declared in a file "is automatically visible to the entire package," and Go's abundance of global built-in symbols (which complicate the choice of possible variable names, but which can still be overriden, since they aren't actually keywords). After a longer wishlist — including null-pointer safety features and improvements to error handling — Carmi introduces a third article with "A Proposition for a Better Future."
I would have loved to see a compile time environment that mostly looks like Go, but allows developers to be a bit more expressive to gain maintainability and runtime safety. But at the same time, allow the Go language itself to largely remain the same and not evolve into something new, as a lot of us Gophers fear. As Gophers, why not have two tools in our tool set? 

The essay proposes a new extended flavor of Go called Goat — a "new compile-time environment that will produce standard, compatible, and performant Go files that are fully compatible with any other Go project. This means they can import regular Go files but also be safely imported from any other Go file." 


"Goat implementation will most likely be delivered as a code generation tool or as a transpiler producing regular go files," explains a page created for the project on GitHub. "However, full implementation details should be designed once the specification provided in this document is finalized." 

Carmi's essay concludes, "I want to ignite a thorough discussion around the design and specification of Goat.... This project will allow Go to remain simple and efficient while allowing the community to experiment with an extended flavor. Goat spec should be driven by the community and so it needs the opinion and contribution of any Gopher and non-Gopher out there." 

"Come join the discussion, we need your input." 

Related link: Go principal engineer Russ Cox gave a talk at GopherCon 2022 that was all about compatibility and "the strategies Go uses to continue to evolve without breaking your programs."<p></p><div class="share_submission">
<a class="slashpop" href="http://twitter.com/home?status=Developer+Proposes+New+(and+Compatible)+'Extended+Flavor'+of+Go%3A+https%3A%2F%2Fbit.ly%2F3NlyzxK"><img src="https://a.fsdn.com/sd/twitter_icon_large.png"></a>
<a class="slashpop" href="http://www.facebook.com/sharer.php?u=https%3A%2F%2Fdevelopers.slashdot.org%2Fstory%2F22%2F10%2F29%2F0329232%2Fdeveloper-proposes-new-and-compatible-extended-flavor-of-go%3Futm_source%3Dslashdot%26utm_medium%3Dfacebook"><img src="https://a.fsdn.com/sd/facebook_icon_large.png"></a>



</div><p><a href="https://developers.slashdot.org/story/22/10/29/0329232/developer-proposes-new-and-compatible-extended-flavor-of-go?utm_source=rss1.0moreanon&amp;utm_medium=feed">Read more of this story</a> at Slashdot.</p>]]></content:encoded>
</item>
<item>
<title><![CDATA[Google leverages open-source fully homomorphic encryption library]]></title>
<description><![CDATA[Duality Technologies has unveiled that Google integrated its open-source Fully Homomorphic Encryption (FHE) Transpiler, which was built using XLS SDK and resides on GitHub, with the Duality-led OpenFHE, the open-source fully homomorphic encryption library, to make cryptographic expertise more acc...]]></description>
<link>https://tsecurity.de/de/1631458/it-security-nachrichten/google-leverages-open-source-fully-homomorphic-encryption-library/</link>
<guid isPermaLink="true">https://tsecurity.de/de/1631458/it-security-nachrichten/google-leverages-open-source-fully-homomorphic-encryption-library/</guid>
<pubDate>Thu, 15 Sep 2022 04:03:15 +0200</pubDate>
<category>📰 IT Security Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[<p>Duality Technologies has unveiled that Google integrated its open-source Fully Homomorphic Encryption (FHE) Transpiler, which was built using XLS SDK and resides on GitHub, with the Duality-led OpenFHE, the open-source fully homomorphic encryption library, to make cryptographic expertise more accessible and streamlined, thus accelerating FHE adoption by developers. Yuriy Polyakov, senior director of cryptography research and principal scientist at Duality commented, “Our team has achieved significant milestones with our OpenFHE library, and it has quickly … <a href="https://www.helpnetsecurity.com/2022/09/15/duality-technologies-google-fhe-transpiler/" rel="nofollow">More <span class="meta-nav">→</span></a></p>
<p>The post <a rel="nofollow" href="https://www.helpnetsecurity.com/2022/09/15/duality-technologies-google-fhe-transpiler/">Google leverages open-source fully homomorphic encryption library</a> appeared first on <a rel="nofollow" href="https://www.helpnetsecurity.com/">Help Net Security</a>.</p>]]></content:encoded>
</item>
<item>
<title><![CDATA[Meet Bun, a Speedy New JavaScript Runtime]]></title>
<description><![CDATA[Bun is "a modern JavaScript runtime like Node or Deno," according to its newly-launched web site, "built from scratch to focus on three main things." 
- Start fast (it has the edge in mind).
- New levels of performance (extending JavaScriptCore, the engine).
- Being a great and complete tool (bun...]]></description>
<link>https://tsecurity.de/de/1565624/it-security-nachrichten/meet-bun-a-speedy-new-javascript-runtime/</link>
<guid isPermaLink="true">https://tsecurity.de/de/1565624/it-security-nachrichten/meet-bun-a-speedy-new-javascript-runtime/</guid>
<pubDate>Sun, 10 Jul 2022 16:48:37 +0200</pubDate>
<category>📰 IT Security Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[Bun is "a modern JavaScript runtime like Node or Deno," according to its newly-launched web site, "built from scratch to focus on three main things." 
- Start fast (it has the edge in mind).
- New levels of performance (extending JavaScriptCore, the engine).
- Being a great and complete tool (bundler, transpiler, package manager). 

Bun is designed as a drop-in replacement for your current JavaScript &amp; TypeScript apps or scripts — on your local computer, server or on the edge. Bun natively implements hundreds of Node.js and Web APIs, including ~90% of Node-API functions (native modules), fs, path, Buffer and more. [And Bun also implements Node.js' module resolution algorithm, so you can use npm packages in bun.js] 

The goal of Bun is to run most of the world's JavaScript outside of browsers, bringing performance and complexity enhancements to your future infrastructure, as well as developer productivity through better, simpler tooling.... Why is Bun fast? An enormous amount of time spent profiling, benchmarking and optimizing things. The answer is different for every part of Bun, but one general theme: [it's written in Zig.] Zig's low-level control over memory and lack of hidden control flow makes it much simpler to write fast software. 

An infographic on the site claims its server-side rendering of React is more than three times faster than Node or Deno. And Bun.js can even automatically load environment variables from .env files, according to the site.

No more require("dotenv").load() 

Hackaday describes it as "a performant all-in-one approach," including "bundling, transpiling, module resolution, and a fantastic foreign-function interface."
Many Javascript projects have a bundling and transpiling step that takes the source and packages it together in a more standard format. Typescript needs to be packaged into javascript, and modules need to be resolved. Bun bakes all this in. Typescript and JSX "just work." This dramatically simplifies many projects as much of the build infrastructure is part of Bun itself, lowering cognitive load when trying to understand a project...
Some web-specific APIs, such as fetch and Websockets, are also built-in. 
"What's even wilder is that Bun is written by one person, Jared Sumner," the article points out — adding that the all the code is available on GitHub under the MIT License ("excluding dependencies which have various licenses.")<p></p><div class="share_submission">
<a class="slashpop" href="http://twitter.com/home?status=Meet+Bun%2C+a+Speedy+New+JavaScript+Runtime%3A+https%3A%2F%2Fbit.ly%2F3nTbnva"><img src="https://a.fsdn.com/sd/twitter_icon_large.png"></a>
<a class="slashpop" href="http://www.facebook.com/sharer.php?u=https%3A%2F%2Fdevelopers.slashdot.org%2Fstory%2F22%2F07%2F10%2F000246%2Fmeet-bun-a-speedy-new-javascript-runtime%3Futm_source%3Dslashdot%26utm_medium%3Dfacebook"><img src="https://a.fsdn.com/sd/facebook_icon_large.png"></a>



</div><p><a href="https://developers.slashdot.org/story/22/07/10/000246/meet-bun-a-speedy-new-javascript-runtime?utm_source=rss1.0moreanon&amp;utm_medium=feed">Read more of this story</a> at Slashdot.</p>]]></content:encoded>
</item>
<item>
<title><![CDATA[Fully-Homomorphic-Encryption - Libraries And Tools To Perform Fully Homomorphic Encryption Operations On An Encrypted Data Set]]></title>
<description><![CDATA[This repository contains open-source libraries and tools to perform fully  homomorphic encryption (FHE) operations on an encrypted data set.About Fully Homomorphic Encryption  Fully Homomorphic Encryption (FHE) is an emerging data processing paradigm that  allows developers to perform transformat...]]></description>
<link>https://tsecurity.de/de/1509775/it-security-nachrichten/fully-homomorphic-encryption-libraries-and-tools-to-perform-fully-homomorphic-encryption-operations-on-an-encrypted-data-set/</link>
<guid isPermaLink="true">https://tsecurity.de/de/1509775/it-security-nachrichten/fully-homomorphic-encryption-libraries-and-tools-to-perform-fully-homomorphic-encryption-operations-on-an-encrypted-data-set/</guid>
<pubDate>Sat, 26 Jun 2021 15:00:45 +0200</pubDate>
<category>📰 IT Security Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[<div class="separator"><a href="https://1.bp.blogspot.com/-IPNg3x9YrPY/YNDzteYEcfI/AAAAAAAAc4Q/_k5sNODZMbwcT_EBV9iH0GPzJGys7OIhwCNcBGAsYHQ/s991/Fully-Homomorphic-Encryption.png" imageanchor="1"><img border="0" data-original-height="635" data-original-width="991" height="410" src="https://1.bp.blogspot.com/-IPNg3x9YrPY/YNDzteYEcfI/AAAAAAAAc4Q/_k5sNODZMbwcT_EBV9iH0GPzJGys7OIhwCNcBGAsYHQ/w640-h410/Fully-Homomorphic-Encryption.png" width="640"></a></div><p><br></p>  <p>This repository contains open-source libraries and tools to perform fully  homomorphic encryption (FHE) <a href="https://www.kitploit.com/search/label/Operations" target="_blank" title="operations">operations</a> on an encrypted data set.</p><p><span></span></p><a name="more"></a><p></p><p><strong><br></strong></p><p><strong>About Fully Homomorphic Encryption</strong></p>  <p>Fully Homomorphic Encryption (FHE) is an emerging data processing paradigm that  allows developers to perform transformations on encrypted data. FHE can change  the way computations are performed by preserving <a href="https://www.kitploit.com/search/label/Privacy" target="_blank" title="privacy">privacy</a> end-to-end, thereby  giving users even greater confidence that their information will remain private  and secure.</p>  <br><span><b>FHE C++ Transpiler</b></span><br><p>The FHE C++ Transpiler is a general purpose <a href="https://www.kitploit.com/search/label/Library" target="_blank" title="library">library</a> that converts C++ into  FHE-C++ that works on encrypted input. The code, examples, and more information  is in the <a href="https://github.com/google/fully-homomorphic-encryption/blob/main/transpiler" rel="nofollow" target="_blank" title="Libraries and tools to perform fully homomorphic encryption operations on an encrypted data set. (5)"><code>transpiler</code></a> subdirectory.</p>  <br><span><b>Support</b></span><br><p>We will continue to publish updates and improvements to the FHE library. We are  not yet accepting external contributions to this project. We will respond to  issues filed in this project. If we ever intend to stop publishing improvements  and responding to issues we will publish notice here at least 3 months in  advance.</p>  <br><span><b>Support disclaimer</b></span><br><p>This is not an officially supported Google product.</p>  <br><span><b>License</b></span><br><p>Apache License 2.0. See <a href="https://github.com/google/fully-homomorphic-encryption/blob/main/LICENSE" rel="nofollow" target="_blank" title="Libraries and tools to perform fully homomorphic encryption operations on an encrypted data set. (6)"><code>LICENSE</code></a>.</p>  <br><span><b>Contact information</b></span><br><p>We are committed to open-sourcing our work to support your use cases. We want to  know how you use this library and what problems it helps you to solve. We have  two communication channels for you to contact us:</p>  <ul><li>  <p>A <a href="https://groups.google.com/g/fhe-open-source-users" rel="nofollow" target="_blank" title="public discussion group">public discussion group</a>  where we will also share our preliminary roadmap, updates, events, and more.</p>  </li>  <li>  <p>A private <a href="https://www.kitploit.com/search/label/Email" target="_blank" title="email">email</a> alias at  <a href="mailto:fhe-open-source@google.com" rel="nofollow" target="_blank" title="fhe-open-source@google.com">fhe-open-source@google.com</a>  where you can reach out to us directly about your use cases and what more we can  do to help and improve the library.</p>  </li>  </ul><p>Please refrain from sending any sensitive or confidential information. If you  wish to delete a message you've previously sent, please contact us.</p>  <br><span><b>Contributors</b></span><br><p>The contributors to this project are (sorted by last name):</p>  <ul><li><a href="https://github.com/ericastor" rel="nofollow" target="_blank" title="Eric Astor">Eric Astor</a></li>  <li><a href="https://desfontain.es/serious.html" rel="nofollow" target="_blank" title="Damien Desfontaines">Damien Desfontaines</a></li>  <li>Christoph Dibak</li>  <li><a href="https://people.scs.carleton.ca/~aforget/" rel="nofollow" target="_blank" title="Alain Forget">Alain Forget</a></li>  <li><a href="https://www.linkedin.com/in/bryant-gipson-33478419" rel="nofollow" target="_blank" title="Bryant Gipson">Bryant Gipson</a></li>  <li><a href="https://github.com/code-perspective" rel="nofollow" target="_blank" title="Shruthi Gorantala">Shruthi Gorantala</a> (Lead)</li>  <li><a href="https://www.linkedin.com/in/miguel-guevara-8a5a332a" rel="nofollow" target="_blank" title="Miguel Guevara">Miguel Guevara</a></li>  <li><a href="https://www.linkedin.com/in/aishe-k" rel="nofollow" target="_blank" title="Aishwarya Krishnamurthy">Aishwarya Krishnamurthy</a></li>  <li>Sasha Kulankhina</li>  <li><a href="https://www.linkedin.com/in/william-m-lam" rel="nofollow" target="_blank" title="William Lam">William Lam</a></li>  <li><a href="http://dmarn.org/" rel="nofollow" target="_blank" title="David Marn">David Marn</a></li>  <li>Bernat Guillén Pegueroles</li>  <li><a href="https://milinda-perera.com/" rel="nofollow" target="_blank" title="Milinda Perera">Milinda Perera</a></li>  <li><a href="https://www.linkedin.com/in/sean-purser-haskell-30b5268" rel="nofollow" target="_blank" title="Sean Purser-Haskell">Sean Purser-Haskell</a></li>  <li><a href="https://www.linkedin.com/in/samuelruth" rel="nofollow" target="_blank" title="Sam Ruth">Sam Ruth</a></li>  <li><a href="https://github.com/RobSpringer" rel="nofollow" target="_blank" title="Rob Springer">Rob Springer</a></li>  <li><a href="https://www.linkedin.com/in/midnighter" rel="nofollow" target="_blank" title="Yurii Sushko">Yurii Sushko</a></li>  <li><a href="https://github.com/cam2337" rel="nofollow" target="_blank" title="Cameron Tew">Cameron Tew</a></li>  <li><a href="https://research.google/people/RoyceJWilson" rel="nofollow" target="_blank" title="Royce Wilson">Royce Wilson</a></li>  <li><a href="https://github.com/xinyuye" rel="nofollow" target="_blank" title="Xinyu Ye">Xinyu Ye</a></li>  <li><a href="https://github.com/izuk" rel="nofollow" target="_blank" title="Itai Zukerman">Itai Zukerman</a></li>  </ul><br><br><div><b><span><a class="kiploit-download" href="https://github.com/google/fully-homomorphic-encryption" rel="nofollow" target="_blank" title="Download Fully-Homomorphic-Encryption">Download Fully-Homomorphic-Encryption</a></span></b></div><img src="http://feeds.feedburner.com/~r/PentestTools/~4/NwhFFOomloI" height="1" width="1" alt="">]]></content:encoded>
</item>
<item>
<title><![CDATA[Google's fully homomorphic encryption package]]></title>
<description><![CDATA[The Google Developers Blog has this
announcement describing the release of a fully
homomorphic encryption project under the Apache license.
"With FHE, encrypted data can travel across the Internet to a server,
where it can be processed without being decrypted. Google’s transpiler will
enable deve...]]></description>
<link>https://tsecurity.de/de/1504499/linux-tipps/googles-fully-homomorphic-encryption-package/</link>
<guid isPermaLink="true">https://tsecurity.de/de/1504499/linux-tipps/googles-fully-homomorphic-encryption-package/</guid>
<pubDate>Mon, 14 Jun 2021 20:30:21 +0200</pubDate>
<category>🐧 Linux Tipps</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[The Google Developers Blog has <a href="https://developers.googleblog.com/2021/06/our-latest-updates-on-fully-homomorphic-encryption.html">this
announcement</a> describing the release of a <a href="https://github.com/google/fully-homomorphic-encryption">fully
homomorphic encryption project</a> under the Apache license.
"<span>With FHE, encrypted data can travel across the Internet to a server,
where it can be processed without being decrypted. Google’s transpiler will
enable developers to write code for any type of basic computation such as
simple string processing or math, and run it on encrypted data. The
transpiler will transform that code into a version that can run on
encrypted data. This then allows developers to create new programming
applications that don’t need unencrypted data.</span>"  See <a href="https://github.com/google/fully-homomorphic-encryption/blob/main/transpiler/docs/whitepaper.pdf">this
white paper</a> for more details on how it all works.]]></content:encoded>
</item>
<item>
<title><![CDATA[Java Geeks Discuss 'The War for the Browser' and the State of Java Modularization]]></title>
<description><![CDATA[Self-described "Java geek" nfrankel writes:

At the beginning of 2019, I wrote about the state of Java modularization. I took a sample of widespread libraries, and for each of them, I checked whether: 

- It supports the module system i.e. it provides an automatic module name in the manifest 
- I...]]></description>
<link>https://tsecurity.de/de/1276213/it-security-nachrichten/java-geeks-discuss-the-war-for-the-browser-and-the-state-of-java-modularization/</link>
<guid isPermaLink="true">https://tsecurity.de/de/1276213/it-security-nachrichten/java-geeks-discuss-the-war-for-the-browser-and-the-state-of-java-modularization/</guid>
<pubDate>Sun, 25 Oct 2020 21:46:38 +0100</pubDate>
<category>📰 IT Security Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[Self-described "Java geek" nfrankel writes:

At the beginning of 2019, I wrote about the state of Java modularization. I took a sample of widespread libraries, and for each of them, I checked whether: 

- It supports the module system i.e. it provides an automatic module name in the manifest 
- It's a full-fledged module i.e. it provides a module-info 

The results were interesting. 14 out of those 29 libraries supported the module system, while 2 were modules in their own right.

 Nearly 2 years later, and with Java 16 looming around the corner, it's time to update the report. I kept the same libraries and added Hazelcast and Hazelcast Jet. I've checked the latest version... 

Three full years after that release, 10 out of 31 libraries still don't provide a module-compatible JAR. Granted, 3 of them didn't release a new version in the meantime. That's still 7 libraries that didn't add a simple line of text in their MANIFEST.MF 

Meanwhile, long-time Slashdot reader AirHog argues that "Java is in a war for the browser. Can it regain the place it once held in its heyday?"

All major browsers have disabled support for Java (and indeed most non-JavaScript technologies). Web-based front-ends are usually coded in JavaScript or some wrapper designed to make it less problematic (like TypeScript). Yes, you can still make websites using Java technology. There are plenty of 'official' technologies like JSP and JSF. Unfortunately, these technologies are entirely server-side. You can generate the page using Java libraries and business logic, but once it is sent to the browser it is static and lifeless... Java client-side innovation has all but stopped, at least via the official channels.... 


How can Java increase its relevance? How can Java win back client-side developers? How can Java prevent other technologies from leveraging front-end dominance to win the back-end, like Java once did to other technologies? 

 To win the war, Java needs a strong client-side option. One that lets developers make modern web applications using Java code. One that leverages web technologies. One that supports components. One that builds quickly. One that produces fast-downloading, high performance, 100-Lighthouse-scoring apps. One that plays nicely with other JVM languages. What does Java need? 
Spoiler: The article concludes that "What Java needs Is TeaVM... an ahead-of-time transpiler that compiles Java classes to JavaScript."<p></p><div class="share_submission">
<a class="slashpop" href="http://twitter.com/home?status=Java+Geeks+Discuss+'The+War+for+the+Browser'+and+the+State+of+Java+Modularization%3A+https%3A%2F%2Fbit.ly%2F37EjyV0"><img src="https://a.fsdn.com/sd/twitter_icon_large.png"></a>
<a class="slashpop" href="http://www.facebook.com/sharer.php?u=https%3A%2F%2Fdevelopers.slashdot.org%2Fstory%2F20%2F10%2F25%2F190257%2Fjava-geeks-discuss-the-war-for-the-browser-and-the-state-of-java-modularization%3Futm_source%3Dslashdot%26utm_medium%3Dfacebook"><img src="https://a.fsdn.com/sd/facebook_icon_large.png"></a>



</div><p><a href="https://developers.slashdot.org/story/20/10/25/190257/java-geeks-discuss-the-war-for-the-browser-and-the-state-of-java-modularization?utm_source=rss1.0moreanon&amp;utm_medium=feed">Read more of this story</a> at Slashdot.</p>]]></content:encoded>
</item>
<item>
<title><![CDATA[LibreSignage v0.2.0 released (x-post r/selfhosted)]]></title>
<description><![CDATA[Hi everyone, I have just released LibreSignage v0.2.0. This release marks an important point in LibreSignage development, since it's the first non-beta release. This release has a lot of new and shiny features as well as important bug fixes and smaller improvements. Among the most notable new fea...]]></description>
<link>https://tsecurity.de/de/396642/linux-tipps/libresignage-v020-released-x-post-rselfhosted/</link>
<guid isPermaLink="true">https://tsecurity.de/de/396642/linux-tipps/libresignage-v020-released-x-post-rselfhosted/</guid>
<pubDate>Sat, 27 Oct 2018 18:30:16 +0200</pubDate>
<category>🐧 Linux Tipps</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[
<!-- SC_OFF --><div class="md">
<p>Hi everyone,</p> <p>I have just released LibreSignage v0.2.0. This release marks an important point in LibreSignage development, since it's the first non-beta release. This release has a lot of new and shiny features as well as important bug fixes and smaller improvements. Among the most notable new features are file uploading, support for embedding videos in slides, the completely rewritten markup transpiler with improved error reporting and the live slide preview for instant feedback when editing slides.</p> <p>The full changelog is included below. I welcome everyone to try it out. Please tell me what you think and report any bugs you might find in the GitHub issue tracker at <a href="https://github.com/eerotal/LibreSignage/issues">https://github.com/eerotal/LibreSignage/issues</a>. If you have any problems installing or using LibreSignage, feel free to ask me here on Reddit and I'll guide you in the right direction. You can clone the LibreSignage repo from <a href="https://github.com/eerotal/LibreSignage.git">https://github.com/eerotal/LibreSignage.git</a>.</p> <p>Changelog v0.2.0:</p> <pre><code>- [feature] Implement keyboard shortcuts for the editor. - [feature] Make it possible to preserve instance data when reinstalling. - [feature] Implement a live slide preview in the editor. - [internal] Self host font files. (I actually don't particularly like including binary files in the GIT tree but I don't know of a better way so the font files are now included in the tree.) - [internal] Use SCSS instead of plain CSS for the stylesheets. - [internal] Import Bootstrap straight into the _default.scss file instead of including it in the HTML &lt;head&gt; tag. - [internal] Process CSS using PostCSS /w Autoprefixer. - [bugfix] Fix a major security issue where the contents of the 'data/' directory were accessible by requesting the different files with eg. a web browser. Even directory listings were enabled. - [feature] Completely rewrite the markup transpiler system to improve its error detecting and reporting capabilities. The rewrite also introduced many other improvements. The transpiler now uses the familiar lexer-parser-evaluator architecture that most compilers use. - [feature] Improve markup error reporting in the editor UI. Erroneous code lines are now highlighted in the editor input. - [bugfix] Confirm before changing the queue if an unsaved slide is being edited in the editor (#17). - [bugfix] Prevent creating duplicate queues in the editor. - [bugfix] Don't show unstyled slide previews to users in the editor by making sure the necessary CSS is loaded before showing content. - [bugfix] Fix a bug resulting in spurious slide changes on the display page. - [improve] Make the login and user manager pages more mobile friendly. - [feature] Implement a Quick Help view in the editor. - [Internal] Implement a new way of exporting PHP object data by using a class called Exportable. - [feature] Implement slide locking to prevent simultaneous editing of slides (issue #18). - [internal] Rewrite most of the PHP session handling code. Implement a new class called Session for handling &amp; storing session data. - [internal] Implement a simple assertion system in JavaScript. - [internal] Implement file uploading via the API system. - [feature] Implement media storage &amp; uploading in the backend and editor. - [feature] Implement embedding video in slides using [video] tags. </code></pre> </div>
<!-- SC_ON -->   submitted by   <a href="https://www.reddit.com/user/ctrlxc"> /u/ctrlxc </a> <br><span><a href="https://www.reddit.com/r/linux/comments/9rv1w4/libresignage_v020_released_xpost_rselfhosted/">[link]</a></span>   <span><a href="https://www.reddit.com/r/linux/comments/9rv1w4/libresignage_v020_released_xpost_rselfhosted/">[comments]</a></span>
]]></content:encoded>
</item>
<item>
<title><![CDATA[Javascript-Transpiler: Babel erscheint nach drei Jahren in Version 7]]></title>
<description><![CDATA[Drei Jahre nach Version 6 ist nun Babel 7 erschienen. Der Javascript-Compiler verwandelt modernes Javascript in altes, damit das auch für betagte Browser ausführbar wird. Das Team hat das Projekt aufgeräumt, Support für alte Abhängigkeiten entfernt und unterstützt neue Syntax. (Javascript, Techno...]]></description>
<link>https://tsecurity.de/de/363395/it-nachrichten/javascript-transpiler-babel-erscheint-nach-drei-jahren-in-version-7/</link>
<guid isPermaLink="true">https://tsecurity.de/de/363395/it-nachrichten/javascript-transpiler-babel-erscheint-nach-drei-jahren-in-version-7/</guid>
<pubDate>Tue, 28 Aug 2018 14:33:34 +0200</pubDate>
<category>📰 IT Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[Drei Jahre nach Version 6 ist nun Babel 7 erschienen. Der Javascript-Compiler verwandelt modernes Javascript in altes, damit das auch für betagte Browser ausführbar wird. Das Team hat das Projekt aufgeräumt, Support für alte Abhängigkeiten entfernt und unterstützt neue Syntax. (<a href="https://www.golem.de/specials/javascript/">Javascript</a>, <a href="https://www.golem.de/specials/technologie/">Technologie</a>) <img src="https://cpx.golem.de/cpx.php?class=17&amp;aid=136231&amp;page=1&amp;ts=1535458500" alt="" width="1" height="1">
]]></content:encoded>
</item>
<item>
<title><![CDATA[Grumpy: Google erstellt Python-Runtime in Go]]></title>
<description><![CDATA[Mit Grumpy hat Google eine experimentelle Laufzeitumgebung für Python in der Programmiersprache Go erstellt. Begründet wird das mit der Unzufriedenheit über verfügbare Alternativen. Grumpy ist zudem ein Transpiler, kein Interpreter. (Programmiersprache, Google)]]></description>
<link>https://tsecurity.de/de/108910/it-nachrichten/grumpy-google-erstellt-python-runtime-in-go/</link>
<guid isPermaLink="true">https://tsecurity.de/de/108910/it-nachrichten/grumpy-google-erstellt-python-runtime-in-go/</guid>
<pubDate>Thu, 05 Jan 2017 14:16:40 +0100</pubDate>
<category>📰 IT Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[Mit Grumpy hat Google eine experimentelle Laufzeitumgebung für Python in der Programmiersprache Go erstellt. Begründet wird das mit der Unzufriedenheit über verfügbare Alternativen. Grumpy ist zudem ein Transpiler, kein Interpreter. (<a href="http://www.golem.de/specials/programmiersprache/">Programmiersprache</a>, <a href="http://www.golem.de/specials/google/">Google</a>) <img src="http://cpx.golem.de/cpx.php?class=17&amp;aid=125414&amp;page=1&amp;ts=1483621260" alt="" width="1" height="1">]]></content:encoded>
</item>
<item>
<title><![CDATA[Grumpy: Google erstellt Python-Runtime in Go]]></title>
<description><![CDATA[Mit Grumpy hat Google eine experimentelle Laufzeitumgebung für Python in der Programmiersprache Go erstellt. Begründet wird das mit der Unzufriedenheit über verfügbare Alternativen. Grumpy ist zudem ein Transpiler, kein Interpreter. (Programmiersprache, Google)]]></description>
<link>https://tsecurity.de/de/108910/it-nachrichten/grumpy-google-erstellt-python-runtime-in-go/</link>
<guid isPermaLink="true">https://tsecurity.de/de/108910/it-nachrichten/grumpy-google-erstellt-python-runtime-in-go/</guid>
<pubDate>Thu, 05 Jan 2017 14:16:40 +0100</pubDate>
<category>📰 IT Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[Mit Grumpy hat Google eine experimentelle Laufzeitumgebung für Python in der Programmiersprache Go erstellt. Begründet wird das mit der Unzufriedenheit über verfügbare Alternativen. Grumpy ist zudem ein Transpiler, kein Interpreter. (<a href="http://www.golem.de/specials/programmiersprache/">Programmiersprache</a>, <a href="http://www.golem.de/specials/google/">Google</a>) <img src="http://cpx.golem.de/cpx.php?class=17&amp;aid=125414&amp;page=1&amp;ts=1483621260" alt="" width="1" height="1">]]></content:encoded>
</item>
<item>
<title><![CDATA[How Would You Generate C Code Using Common Lisp Macros?]]></title>
<description><![CDATA[Long-time Slashdot reader kruhft brings news about a new S-Expression based language transpiler that has the feel of C.
 This structure allows for the creation of code generation macros using the full power of the host Common Lisp environment, a language designed for operating on S-Expressions, a...]]></description>
<link>https://tsecurity.de/de/105279/it-security-nachrichten/how-would-you-generate-c-code-using-common-lisp-macros/</link>
<guid isPermaLink="true">https://tsecurity.de/de/105279/it-security-nachrichten/how-would-you-generate-c-code-using-common-lisp-macros/</guid>
<pubDate>Sat, 24 Dec 2016 22:15:29 +0100</pubDate>
<category>📰 IT Security Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[Long-time Slashdot reader kruhft brings news about a new S-Expression based language transpiler that has the feel of C.
 This structure allows for the creation of code generation macros using the full power of the host Common Lisp environment, a language designed for operating on S-Expressions, also known as Lists. It is unknown exactly what power might come about from this combination of low level processing with high level code generation. 

This has prompted some discussion online about other attempts to convert Lisp to C -- raising several more questions. How (and why) would you convert your Lisp code into C, and what would then be the best uses for this capability?<p></p><div class="share_submission">
<a class="slashpop" href="http://twitter.com/home?status=How+Would+You+Generate+C+Code+Using+Common+Lisp+Macros%3F%3A+http%3A%2F%2Fbit.ly%2F2hj2cTb"><img src="https://a.fsdn.com/sd/twitter_icon_large.png"></a>
<a class="slashpop" href="http://www.facebook.com/sharer.php?u=https%3A%2F%2Fdevelopers.slashdot.org%2Fstory%2F16%2F12%2F24%2F0552254%2Fhow-would-you-generate-c-code-using-common-lisp-macros%3Futm_source%3Dslashdot%26utm_medium%3Dfacebook"><img src="https://a.fsdn.com/sd/facebook_icon_large.png"></a>

<a class="nobg" href="http://plus.google.com/share?url=https://developers.slashdot.org/story/16/12/24/0552254/how-would-you-generate-c-code-using-common-lisp-macros?utm_source=slashdot&amp;utm_medium=googleplus"><img src="http://www.gstatic.com/images/icons/gplus-16.png" alt="Share on Google+"></a>                                                                                                                                                                              



</div><p><a href="https://developers.slashdot.org/story/16/12/24/0552254/how-would-you-generate-c-code-using-common-lisp-macros?utm_source=rss1.0moreanon&amp;utm_medium=feed">Read more of this story</a> at Slashdot.</p>]]></content:encoded>
</item>
<item>
<title><![CDATA[How Would You Generate C Code Using Common Lisp Macros?]]></title>
<description><![CDATA[Long-time Slashdot reader kruhft brings news about a new S-Expression based language transpiler that has the feel of C.
 This structure allows for the creation of code generation macros using the full power of the host Common Lisp environment, a language designed for operating on S-Expressions, a...]]></description>
<link>https://tsecurity.de/de/105279/it-security-nachrichten/how-would-you-generate-c-code-using-common-lisp-macros/</link>
<guid isPermaLink="true">https://tsecurity.de/de/105279/it-security-nachrichten/how-would-you-generate-c-code-using-common-lisp-macros/</guid>
<pubDate>Sat, 24 Dec 2016 22:15:29 +0100</pubDate>
<category>📰 IT Security Nachrichten</category>
<source url="https://tsecurity.de">tsecurity.de</source>
<content:encoded><![CDATA[Long-time Slashdot reader kruhft brings news about a new S-Expression based language transpiler that has the feel of C.
 This structure allows for the creation of code generation macros using the full power of the host Common Lisp environment, a language designed for operating on S-Expressions, also known as Lists. It is unknown exactly what power might come about from this combination of low level processing with high level code generation. 

This has prompted some discussion online about other attempts to convert Lisp to C -- raising several more questions. How (and why) would you convert your Lisp code into C, and what would then be the best uses for this capability?<p></p><div class="share_submission">
<a class="slashpop" href="http://twitter.com/home?status=How+Would+You+Generate+C+Code+Using+Common+Lisp+Macros%3F%3A+http%3A%2F%2Fbit.ly%2F2hj2cTb"><img src="https://a.fsdn.com/sd/twitter_icon_large.png"></a>
<a class="slashpop" href="http://www.facebook.com/sharer.php?u=https%3A%2F%2Fdevelopers.slashdot.org%2Fstory%2F16%2F12%2F24%2F0552254%2Fhow-would-you-generate-c-code-using-common-lisp-macros%3Futm_source%3Dslashdot%26utm_medium%3Dfacebook"><img src="https://a.fsdn.com/sd/facebook_icon_large.png"></a>

<a class="nobg" href="http://plus.google.com/share?url=https://developers.slashdot.org/story/16/12/24/0552254/how-would-you-generate-c-code-using-common-lisp-macros?utm_source=slashdot&amp;utm_medium=googleplus"><img src="http://www.gstatic.com/images/icons/gplus-16.png" alt="Share on Google+"></a>                                                                                                                                                                              



</div><p><a href="https://developers.slashdot.org/story/16/12/24/0552254/how-would-you-generate-c-code-using-common-lisp-macros?utm_source=rss1.0moreanon&amp;utm_medium=feed">Read more of this story</a> at Slashdot.</p>]]></content:encoded>
</item>
</channel>
</rss>
<!-- Generated in 0,01ms -->