rust implementation WIP

praveen commented

2026-05-20 19:11:47 +00:00

Member

Sharing my WIP implementation, its not complete yet, by goal is to try it on my mac + bambu printer to see if I can get it printing first, then go for full parity. If anyone else is further along I'm happy to contribute to theirs instead.

https://f.sfconservancy.org/praveen/reverse-networking/src/branch/master

Sharing my WIP implementation, its not complete yet, by goal is to try it on my mac + bambu printer to see if I can get it printing first, then go for full parity. If anyone else is further along I'm happy to contribute to theirs instead. https://f.sfconservancy.org/praveen/reverse-networking/src/branch/master

bkuhn commented

2026-05-20 22:51:57 +00:00

Owner

Again, this is absolutely amazing that so many people have begun work on this reverse engineering project! I'm having trouble keeping up with everything (which is a good thing in this case!) so it may be the weekend before I get to look at your work in detail. As you can see in my comment over in issue #1, my plan is to create branches in the repository for each person working on this.

BTW, I am figuring that's the “worst solution — except for all the others”. While I realize it's a bit strange to have branches in one repository that share no common artifact ancestry, I've used this approach before for a project that was taking different approaches — some of which might continue alone and some of which might merge with others. The approach worked a lot better than just making a separate repository for every approach.

Of course, long term, if we — arguendo — end up with an excellent Rust implementation and an excellent C++ one as well, splitting the repository at that point can easily be done by just cloning this one and deleting the branches of the other approaches.

Anyway, I am going to spend time tomorrow organizing all the approaches¹ I'm aware of, and then, as mentioned, I'll do some curation work this weekend to figure out where each one is at.

I'm also a bit behind because I don't have my Bambu 3D Printer set up yet, so I don't have an edit-compile-test environment yet, so I gotta do that this weekend as well.

Thanks so much for your interest and your efforts, @praveen! I'll be in touch.

¹ I think there are 4 now, but I'm not sure as I have an embarrassment of riches over here 😆 )

Again, this is absolutely amazing that so many people have begun work on this reverse engineering project! I'm having trouble keeping up with everything (which is a good thing in this case!) so it may be the weekend before I get to look at your work in detail. [As you can see in my comment over in issue #1](https://f.sfconservancy.org/baltobu/reverse-networking/issues/1#issuecomment-1), my plan is to create branches in the repository for each person working on this. BTW, I am figuring that's the “worst solution — except for all the others”. While I realize it's a bit strange to have branches in *one* repository that share no common artifact ancestry, I've used this approach before for a project that was taking different approaches — some of which might continue alone and some of which might merge with others. The approach worked a lot better than just making a separate repository for every approach. Of course, long term, if we — arguendo — end up with an excellent Rust implementation and an excellent C++ one as well, splitting the repository at that point can easily be done by just cloning this one and deleting the branches of the other approaches. Anyway, I am going to spend time tomorrow organizing all the approaches¹ I'm aware of, and then, as mentioned, I'll do some curation work this weekend to figure out where each one is at. I'm also a bit behind because I don't have my Bambu 3D Printer set up yet, so I don't have an edit-compile-test environment yet, so I gotta do that this weekend as well. Thanks so much for your interest and your efforts, @praveen! I'll be in touch. ¹ I think there are 4 now, but I'm not sure as I have an embarrassment of riches over here 😆 )

👍 2

bkuhn self-assigned this

2026-05-20 22:52:31 +00:00

lazerusrm commented

2026-05-22 06:24:11 +00:00

Member

I'll also need a branch. i have gotten most of the way through the dll, with my last step is deep inspection of the aes derivation, which is proving difficult because of vmp ultra, my next round is titanhide and i think i will get it.

ofc tool assisted, but working carefully to validate all the code to make sure i land it all in the right shape with strict guardrails.

I have a working LAN version without dev mode, but it requires pulling the key from Bambu Studio currently, which i can get. im close to figuring this out the rest of the way i think (hope), and have full source code in rust.

BBL has pretty robust debugger detection and nooping that has been successful, but then hitting a wall hard due to VMP Ultra. Turns out the BBL dll is seemingly pretty small (less than 1mb), just large due to all their antics.

Snippet:
The 2026-05-20 push defeated VMProtect's outer packer in
bambu_networking.dll via an autonomous LoadLibraryW + memory-dump

section-table-patch pipeline. The full unpacked plugin is now
statically analyzable.

Sub-goal	Status
Unpack `bambu_networking.dll` (defeat VMP outer shell)	✅ Fully autonomous — no Bambu Studio launch needed.
Locate cert-exchange URL template	✅ RVA 0x5fd9e0: `%1%/iot-service/api/user/applications/%2%/cert?aes256=%3%&ver=1`
Identify cipher	✅ AES-256-GCM (NID 901). Struct at RVA 0x628cf0. Accessor at VA 0x18038c8b0.
Locate AES encrypt functions	✅ Two functions: VA 0x18023b1b0 + VA 0x18023b2e0. Function signature inferred.
Map OpenSSL EVP_* thunks	✅ `EVP_CIPHER_CTX_new`=0x18035deb0, `EVP_EncryptInit_ex`=0x18035edb0, `EVP_EncryptUpdate`=0x18035ee20, `EVP_EncryptFinal_ex`=0x18035d510, `EVP_CIPHER_CTX_ctrl`=0x18035e9d0.
Extract embedded TLS SPKI-pin cert	✅ `docs/reference/bbl_embedded_cert_1.pem` — leaf cert for `service.bambulab.com`.
Build function map of plugin	✅ 7,700 functions enumerated, 396 classified across 15 subsystems. `inventory/33_plugin_function_map.md`.
Extract actual AES key + IV bytes ❌	See "Runtime extraction" subsection below. Static path exhausted.
Python AES-256-GCM replay	✅ Encrypt-side script `tools/replay_cert_aes256.py` ready; round-trip smoke-tested. Will validate the moment we get a real (key, iv, plaintext, tag) capture.

Runtime extraction — 2026-05-21 status

12 attempts at extracting the AES key at runtime. The static intel is
locked in (cipher, helper VAs, EVP thunks, etc. — all above). The
runtime path is blocked at VMProtect's KERNEL-LEVEL anti-debug:

#	Approach	Verdict
8-10	LoadLibrary unpacker / URL builder ID / EVP thunks	✅ Each succeeded — see static rows above
11 (a, b)	Frida hooks on EVP thunk + on AES helper	❌ VMP byte-CRC anti-tamper crashes Studio when hook bytes execute
12 (a)	Custom Win32 HW BP runner + PEB.BeingDebugged + NtGlobalFlag + heap-flags patches	❌ Studio shows "debugger detected" — deeper anti-debug fires
12 (b)	+ ScyllaHide injected post-launch	❌ DebugActiveProcess returns ACCESS_DENIED (5) — VMP set ProcessDebugFlags
12 (c)	+ ScyllaHide via CREATE_SUSPENDED pre-injection + SeDebugPrivilege + full VMP-tuned hook profile + DLLStealth	⚠️ DebugActiveProcess worked, But BBStudio exits with `0xDEADC0DE` (VMP's signature kill code) the instant the debug port is opened. Kernel-mediated check ScyllaHide's user-mode hooks cannot intercept.

Next Step: titanhide, secureboot off.

Snapshot code and docs included of where im at, but i have currently a private git repo with all my work history

I'll also need a branch. i have gotten most of the way through the dll, with my last step is deep inspection of the aes derivation, which is proving difficult because of vmp ultra, my next round is titanhide and i think i will get it. ofc tool assisted, but working carefully to validate all the code to make sure i land it all in the right shape with strict guardrails. I have a working LAN version without dev mode, but it requires pulling the key from Bambu Studio currently, which i can get. im close to figuring this out the rest of the way i think (hope), and have full source code in rust. BBL has pretty robust debugger detection and nooping that has been successful, but then hitting a wall hard due to VMP Ultra. Turns out the BBL dll is seemingly pretty small (less than 1mb), just large due to all their antics. Snippet: The 2026-05-20 push **defeated VMProtect's outer packer** in `bambu_networking.dll` via an autonomous `LoadLibraryW` + memory-dump + section-table-patch pipeline. The full unpacked plugin is now statically analyzable. | Sub-goal | Status | |----------|--------| | Unpack `bambu_networking.dll` (defeat VMP outer shell) | ✅ Fully autonomous — no Bambu Studio launch needed. | | Locate cert-exchange URL template | ✅ RVA 0x5fd9e0: `%1%/iot-service/api/user/applications/%2%/cert?aes256=%3%&ver=1` | | Identify cipher | ✅ **AES-256-GCM** (NID 901). Struct at RVA 0x628cf0. Accessor at VA 0x18038c8b0. | | Locate AES encrypt functions | ✅ Two functions: VA 0x18023b1b0 + VA 0x18023b2e0. Function signature inferred. | | Map OpenSSL EVP_* thunks | ✅ `EVP_CIPHER_CTX_new`=0x18035deb0, `EVP_EncryptInit_ex`=0x18035edb0, `EVP_EncryptUpdate`=0x18035ee20, `EVP_EncryptFinal_ex`=0x18035d510, `EVP_CIPHER_CTX_ctrl`=0x18035e9d0. | | Extract embedded TLS SPKI-pin cert | ✅ `docs/reference/bbl_embedded_cert_1.pem` — leaf cert for `service.bambulab.com`. | | Build function map of plugin | ✅ 7,700 functions enumerated, 396 classified across 15 subsystems. `inventory/33_plugin_function_map.md`. | | **Extract actual AES key + IV bytes** ❌ | See "Runtime extraction" subsection below. Static path exhausted. | | Python AES-256-GCM replay | ✅ Encrypt-side script `tools/replay_cert_aes256.py` ready; round-trip smoke-tested. Will validate the moment we get a real (key, iv, plaintext, tag) capture. | ### Runtime extraction — 2026-05-21 status 12 attempts at extracting the AES key at runtime. The static intel is locked in (cipher, helper VAs, EVP thunks, etc. — all above). The runtime path is blocked at VMProtect's KERNEL-LEVEL anti-debug: | # | Approach | Verdict | |---|----------|---------| | 8-10 | LoadLibrary unpacker / URL builder ID / EVP thunks | ✅ Each succeeded — see static rows above | | 11 (a, b) | Frida hooks on EVP thunk + on AES helper | ❌ VMP byte-CRC anti-tamper crashes Studio when hook bytes execute | | 12 (a) | Custom Win32 HW BP runner + PEB.BeingDebugged + NtGlobalFlag + heap-flags patches | ❌ Studio shows "debugger detected" — deeper anti-debug fires | | 12 (b) | + ScyllaHide injected post-launch | ❌ DebugActiveProcess returns ACCESS_DENIED (5) — VMP set ProcessDebugFlags | | 12 (c) | + ScyllaHide via CREATE_SUSPENDED pre-injection + SeDebugPrivilege + full VMP-tuned hook profile + DLLStealth | ⚠️ DebugActiveProcess worked, But BBStudio exits with `0xDEADC0DE` (VMP's signature kill code) the instant the debug port is opened. Kernel-mediated check ScyllaHide's user-mode hooks cannot intercept. | Next Step: titanhide, secureboot off. Snapshot code and docs included of where im at, but i have currently a private git repo with all my work history

Bambu.zip

596 KiB

lazerusrm commented

2026-05-27 01:46:16 +00:00

Member

i know this probably isnt the right place, but ive now got communication and login working with my drop in DLL in orcaslicer, though its not really built for the cloud components yet... still have some commits to land but here is my checkpoint. https://f.sfconservancy.org/lazerusrm/BB-Open

Rows
Columns

rust implementation WIP #2

Runtime extraction — 2026-05-21 status