Anycubic Kobra X - First Impressions

The Anycubic Kobra X is a relatively new entry into the increasingly crowded space of consumer grade 3D printers. On paper, it promises a compelling mix of solid hardware, multi-color / multi-material capabilities, and a streamlined user experience. Out of the box, the first impression is indeed very positive: assembly is quick, the mechanical design feels robust and the system appears well thought out.

However, as soon as one moves beyond the default plug-and-print workflow, the picture begins to shift slightly. The software ecosystem surrounding the device introduces significant constraints: undocumented protocols, reliance on vendor-specific tooling and a strong push toward cloud-based operation. For users who value control, transparency, and integration into existing toolchains, this raises important questions.

This article takes a closer look at the Kobra X from a practical and technical perspective. After a brief overview of the hardware and initial setup, we go on a short journey reverse engineering the devices local communication interfaces, analyze its network behavior and explore what is required to operate it outside the vendors intended ecosystem.

• Unboxing and Assembling
• First Power Up
• The Software - Where it Unfortunately Gets Messy And Inconvenient
  • LAN mode
  • Slicers
• A First Test Print
  • Trying Again with Proper Temperature and Dry Filament
• Intermediate Conclusion
• Maintenance and Accidents
  • Brittle filament: Breaking inside the extruder head
  • The optical sensor board in the print head
  • Filament Feed Errors
• Some Reverse Engineering and Peeking Into Protocols (In LAN Mode)
  • Tapping Into the MQTT Stream
  • Finally, MQTT dumps
  • Connecting
  • Device Identification
  • Topic Structure
  • Read-Only Commands Without Side Effects
• Conclusion
  • The Good Stuff
  • The (Very) Bad Stuff
• References

Unboxing and Assembling

They did a great job in designing the printer. It is extremely simple to build up. Everything comes very well packaged - the whole package weights around 13kg. As one can see the package is properly lined with foam. Nothing moves during transport.

Beware that mine was unpacked upside down. Not really a problem due to the good packaging by the manufacturer. Here one can see the instruction manual, that is also available on the net and that contains basic installation and assembly instructions, as well as the base with the moving bed.

Below the gantry resides, properly secured with additional clamps that one is reminded to remove felt around 100 times during the manual and also during initial startup of the printer

All moving components are additionally packaged with foam and secured via plastic straps that have to be cut away with pliers (those are not delivered, this is about the only additional tool you require).

Additional material is composed of four PTFE tubes to interface the extruder head to the filament spools, the rather improvised filament spools (they will later snap on top of the printer but they - in contrast to the remaining part of the printer - fell somewhat improvised and added later, which makes sense when one takes a look at the Anycubic ACE Pro that one can of course also interface to the Kobra X (then it can in theory operate up to 16 colors in a very simple fashion), a power cable for the specific region that you ordered for, some Allen keys that are required during assembly including a magnet that can be used to magnetize the keys so they attach to the screws (which is a pretty nice thought by the product designers), some covers, cleaning filament and a cleaning needle. In addition the purge knife and some lube is provided.

The first step is not unlocking and mounting of the gantry.

On both sides the gantry features mounting brackets that are mounted via 3 screws each. Have i mentioned that we will be told to remove them multiple times to prevent printer damage? Now is the time to remove them.

The next step is to actually mount the gantry. The system is well thought through. One slides the printbed to the front, the z axis to the top (this may require a bit more force) and just puts the gantry in place. Alignment pins make sure one slides in the correct place and the 8 screws are then tightened (switching between sides and tightening them by switching between the screws frequently like always when attaching stuff that is mounted via multiple screws).

After tightening add the covers. These are there for aesthetic purposes only though - but a product designer has designed them very well. The same goes for the mounting positions for automatic build plate swapping systems that are available on the front and the back below the print plate.

Then one attaches the cabling on the bottom of the printer. Again - very well designed. All connectors differ and even though the manual mentions that one should only put a 4 pin connector in a 4 pin socket and so on I think it is obvious.

Then one applies the cover again. This is the only cover that does not feel well matched. It fits of course but somehow not as good as all other parts. But it doesn’t matter on the bottom anyways.

The last step is to mount the purge knife on the side of the gantry. This will be used to get rid of filament during automatic filament change. It is sled into place and secured from the back with a single screw. This again feels like a later addition to the whole system but still well designed.

The last step is mounting the filament spool holders. As usual they are only suited for small 1kg spools - and as for any printer you will earlier or later migrate to the 8kg or larger spools for sure as a heavy user. These really feel like more of a hack in case you do not use an external filament multiplexer. But that is the case for all printers I had at hands till now. The spool holders simply clamp into place on the top of the gantry. Note that they are numbered so make sure to not swap them if you want to have correct numbering there.

Now after installing the PTFE tubes - in case one uses the top spool holders - the printer is ready to be powered up.

As a comment - the printer also has a built in camera hidden behind a cover on the right side of the gantry

The camera can be used for print monitoring.

First Power Up

The first start of the machine takes some time. Plan for at least 40 minutes of calibration runs. Place the machine on the surface you will use it later on (or you will have to re-run the calibration sequence later again! Actually I have not figured out how to do this without clearing all data on the device though, which I had to do after a power outage during the first sequence). Before performing calibration the printer will ask you for language and region and then offer to connect to WiFi and the mobile phone app. People who read my other articles will immediately know: I do not think such devices should be in WiFi, connected to any external cloud service or require a smartphone app - but the step can be skipped and then later there will be LAN mode

Oh and by the way: The screen is a touch screen of course.

The Software - Where it Unfortunately Gets Messy And Inconvenient

If you like to run the device with a smartphone app after is has used your PSK secured WiFi to connect to it’s cloud service it does not feel messy. But let’s be honest - a 3D printer …

• … should never connect to a network via WiFi by default. Ethernet is good. Or no network at all and allow controlling via USB and runners like Octoprint
• … should never reach out to an external cloud service. First such services are not guaranteed to run forever, they pose a security risk and simply printers should never be located in your default network. They should be isolated from other interactive machines and clients and especially be isolated from the internet. And keep in mind that any networked device needs periodic security updates!
• … should always be firewalled
• … should never ever rely on any smartphone app (or even any specific host application since they are not portable). Especially if the applications communicate over the cloud service forth and back over the internet. Very bad idea.

LAN mode

This is something I am very disappointed. LAN mode is a bit misleading since the Kobra X does not have an Ethernet interface. It only supports WiFi out of the box - and it only is enable-able after you connected to the WiFi so the system will try to connect to the cloud of the manufacturer on the first network connection anyways. This means you will have to block this on the network level or run the device in a separate subnet to prevent this phoning home. I think this should be fixed.

Only after connecting to a network one can enable LAN mode which disables cloud services. In addition the device only seems to support Legacy IP, IPv6 support seems to be lacking.

Next, the used network protocols seem not to be documented, which makes the device hard to use in sane environments. A quick scan with nmap reveals that there are two HTTP endpoints and some SSL protected endpoint:

• Port 18088 is an HTTP speaking endpoint that seems to be camera related. Any request triggers the camera light.
• Port 18910 is an HTTP endpoint, most likely related to file upload
• Port 9883 performs a TLS handshake. I suspect this looks like MQTT over TLS.

Slicers

Officially the printer is only supported by the manufacturers Slicer AnycubicSlicerNext, which is actually directly derived and minimally modified from the Open Source OrcaSlicer project. Unfortunately at the time of writing the machine profile for the Kobra X was not backported into OrcaSlicer so it cannot be used to communicate with the printer either. The official Slicer is only supported on a limited set of operating systems (Windows, a specific Ubuntu version and MacOS) so it’s totally useless unfortunately.

A short rant: I don’t get why they did not just put their changes for their own printers directly into a pull request for Orca. This does not make sense. They use OrcaSlicer directly and rebrand it - that’s totally ok. But it also does not make sense from the point of view from the manufacturer. If they do their own fork they have to periodically fetch upstream changes, take care of running builds, etc. If they would just push their profiles and potential modules into the upstream repository the community would take care of it - also on the long term. Which would give them basically infinite time to support also old devices with new software without having to invest in more and more developers or drop device support (dropping support makes sense for the commercial provider but the devices would still be usable for users if they would push this kind of stuff upstream). The same goes for the network protocol. If it would be documented there would be really no loss for the manufacturer, they would get support in different utilities basically for free. Customers would have even more incentive to buy their product (since the hardware will still be required) and would be able to use it with their existing toolchains or in totally exotic settings that the manufacturers would not even imagined. It’s totally ok to provide some kind of low-key enduser app based process but this should be made totally optional, not the only vendor locked way of using devices.

A First Try to Use OrcaSlicer With The Profile Files from Anycubic Slicer Next

So obviously, since I can build OrcaSlicer (or even install it from packages via pkg install OrcaSlicer due to the available FreeBSD port) and it runes despite some warnings during startup from the wx rendering backend (a problem I also had with Slic3r unfortunately, which made me move to Cura which turned out to be portable and very usable) I tried to copy the profile files from Anycubic Slicer Next from a Windows installation (Found at %AppData%/Roaming/AnycubicSlicerNext/system/Anycubic) to the local profile directory on my machine (residing at /usr/local/share/OrcaSlicer/profiles/Anycubic). Unfortunately this did not work.

A First Test Print

So before going further and getting the device usable for me I decided to run a quick multicolor test print. For this I used the fantastic MiniMonsters Dracula model by rhinodk I stumbled over on thingiverse. This guy is sweet. It took around 20 minutes after loading in the manufacturers slicer and color the surfaces. I also tried to load a generated model from Tripo3D that I exported as 3MF into the slicer but I still had to perform coloring manually. In addition my first impression is that the slicer is mainly designed for the artistic use of multi-color filament. I suspect - but have not figured out quickly - that one can also load in different STL or 3MF models consisting of different materials for technical applications. In addition the usage of a separate filament for supports may make life much easier, especially since water soluble support filaments are available. The default settings supplied with the slider turned out to be very useful - I only had to do minor tweaking on temperatures since I used my own (older - around 14 years of non-dried shelf life to be honest which lead to some blobs forming with higher temperatures, tuning to lower temperatures fixed this) colored PLA.

As for a multicolor print usual the amount of waste was considerable:

• The model itself weights 12g
• The waste of cutted filament and the priming tower together summed up to 98g

This totals to 110g for the whole model (89% of used filament was waste). Of course this was a hollow small 3d print. As the objects get larger or switching rarer (this print had up to 3 colors in a single layer) the ratio of waste goes down. In addition you can reduce the size of the priming tower.

And of course while weighting the waste as depicted the weight of the peel is not included.

Trying Again with Proper Temperature and Dry Filament

So after the previous result showed blobs - it was time to just tune the temperature back to the well known working values for this filament and dry it. The results immediately looked better:

Now that the setup worked I also designed a complementary figure and printed 3 at the same time:

Again the models totaled up to 30g (18%), the waste (prime tower and supports as well as purged filament) to 136g (82%), a total of 166g of filament. This yields a unit cost of around 83 Cent (at time of writing) per figure compared to around 15 Cent per figure for a single-color print (i.e. 453% price increase of the colored version in comparison to one that one will draw by hand). Of course for technical applications the choice of different filaments in the same model is a huge gain.

Intermediate Conclusion

So first in between a short conclusion:

• Cool hardware.
• Software is a catastrophy.
  • But would be easy to use. Just drop out vendor lock in and document it openly and everything is very great.

Using the software of the manufacturer was extremely simple and intuitive and it works out of the box. In the most simple case - load your model, hit print. It works. If the problem with undocumented software, missing printer files and the try of enforcing cloud operation and vendor lock-in would not be there - this would a a very fantastic product.

Maintenance and Accidents

Of course not everything worked without minor trouble - but again the design of the Kobra X actually turned out to be pretty solid.

Brittle filament: Breaking inside the extruder head

So the first thing that has happened to me was brittle filament breaking. Most of the time this has happened at the inlets of the PTFE tubes that lead towards the print head. But at some point the printer stopped working, claiming not to be able to extrude or retract. This was caused by filament residue inside the reversal and selection unit. It turned out to be required to dismantle the print head, clean it and reassemble it. Overall this works pretty straight forward - and the Wiki of the manufacturer gives a good guide on how to perform the disassembly. Here you see that some minor details were added in hindsight that have not been thought of by the product designers upfront. For example you have to flex the housing of the print head whenever you want to remove the cover because the cutting lever does not fit through nicely. This will limit the amount of times you can disassemble and reassemble the head for sure. Overall the disassemble and also reassembly went pretty strait forward. Except for the optical sensor that was obviously retrofitted in the head. More on this in the next section. Reassembling afterwards also went smooth and the printer worked - again without trouble for some time.

The optical sensor board in the print head

Inside the extruder head a small board resides that was obviously added to the design later than everything else. It’s neither screwed in place nor properly clamped. If you position it correctly it will be held in place the cover that you add on the front of the print head in the end. If you do not have that luck the printer may seem to work for some time - but at some point my print head started to trigger the wrong camshaft locations. It showed up selecting filament 3 but triggered 1, of course detecting there was no feed or retract movement (using the four optical sensors on the top of the print head who are properly mounted) and thus shutting down. It turned out the board was not clamped properly while I reassembled the print head - it just worked for some prints but vibrations just tilted the sensor board. At this point in time it stopped working properly. Disassembly, re-seating the sensor board and closing the extruder head again and everything worked again. I think this is the only major design flaw of the system I spotted on the hardware side until now - a single screw would have prevented this kind of potential failure and would have made assembly and disassembly way more convenient.

Filament Feed Errors

Especially when working with PET-G I sometimes noticed the extrusion randomly stopped. This was usually due to the cut on the front of the filament being exactly horizontal and the filament then jamming after retraction. This ruined a few prints but was easily solvable by retracting the filament, cutting again in 45 degree angle and re-inserting. Though on a huge print farm this may be problematic.

Some Reverse Engineering and Peeking Into Protocols (In LAN Mode)

So the next step was clear - figuring out how to get control over the device, how to access parameters and how to upload your own prints without the manufacturers hardware, figuring out which GCode is used for initialization and for filament change, etc.

Since the quick port scan above already suggested two network protocols on 3 different ports:

• HTTP on 18088 and 18910, where 18088 seems to be camera related and 18910 seems to be file transfer related (which was confirmed later as we will see soon)
• MQTT over TLS on port 9883

the first step was to take a look into the data transfer. Obviously using Wireshark only helped to peek into the HTTP streams which are unencrypted. The TLS encrypted MQTT stream was totally opaque. In addition trying to subscribe with a simple Python based MQTT client to all topics failed - any subscription actually failed as being Unauthorized. In addition the HTTP transfer that I saw from the stock slicer software indicated that there was some kind of authentication token used - that seemed to be randomly changing at least over device restarts. So MQTT was the main target.

⚠️ Work in progress This section will be expanded as additional protocol analysis is completed.

Tapping Into the MQTT Stream

Since I could not peek into the network traffic directly the next step was to just hook into the software. frida was my tool of choice since it allows just adding custom instrumentation - written in JavaScript - to hook into an arbitrary application. The first try was to simply use the Windows version of the software and hook into WinSocks send and recv calls. I got the data dumps and of course - as expected - saw only encrypted data streams. Then I took a peek if the application would actually import schannel or an openssl library - but it appears to be statically compiled into the software. During normal usage I utilized backtrace from the WinSock send call to identify the modules that where causing the data to be assembled. As it turned out a single library mqtt_client.dll, that is runtime loaded by the Slicer, performs all the MQTT communication so the next guess was that it’s methods will most likely be the ones who receive unencrypted messages. This turned out to be true - tracing the function calls lead to a list of methods (and thanks to C++ function decorators also to the argument types) and thus very fast to interpretable dumps of the function calls.

The relevant DLL exports that I looked into had been:

mqtt_create_client
mqtt_connect_to_broker
mqtt_publish
mqtt_subscribe
mqtt_unsubscribe
mqtt_disconnect
mqtt_enable_feature
mqtt_disable_feature
mqtt_is_connected
mqtt_clone_client
mqtt_init_client
mqtt_destroy_client
Anycubic::MQTT::MultiSink::on_message(...)
Anycubic::MQTT::MultiSink::on_event(...)
?on_message@MultiSink@MQTT@Anycubic@@QEAAXPEBD0I@Z
?on_event@MultiSink@MQTT@Anycubic@@QEAAXW4Event@23@_NPEBD@Z

From the C++ name mangling one can infer for example

void MultiSink::on_message(
    char const *topic,
    char const *payload,
    unsigned int payload_len
);

Also the mqtt_connect method seems to accept a configuration object and a TLS configuration object. Relevant fields are:

• arg0 + 0x10: A std::string that seems to be the username
• arg0 + 0x18: A std::string that seems to be the password or token
• arg1 + 0x38: The private key in PEM format as std::string
• arg1 + 0x58: The certificate in PEM format as std::string

Upfront I saw that the subscription to the broker was done with mutual TLS - the client offers an TLS certificate. In addition a username and password - I do not know where they are generated at time of writing, they may even be constant over all devices - is utilized. First I tried to simply change the username and password, suspecting that the certificate may be the only relevant identifier. It turned out to be the opposite - one can use a random self signed certificate with O=AnyCubic as organization but requires a defined username and password. Since I never connected the device to any account or to the cloud I am still wondering where this comes from.

Finally, MQTT dumps

After digging through a huge load of stacktraces and dumps I ended up with a pretty simple frida script (omitted here for potential legal reasons).

This script has then be used with frida to tap into the executable to read the messages directly before the encryption layer:

frida -f "AnycubicSlicerNext.exe" -l anycubic_mqtt_capture.js

It captures all MQTT transactions that are seen (after some minor filtering). Due to the late binding it does to the mqtt_connect method it missed the first connection. This turned out to be no problem since the original slicer actually creates two different MQTT connections - I suspect the first one goes to their cloud service (which I have no interest in and which also would legally not permissible to look into in many countries) while the second is definetely the LAN printer. I then executed some prints and methods (like uploading GCode, using camera streams, taking image captures, performing movement commands, etc.) and recorded also the status messages emitted while running multicolor prints. Of course I have not tested all error cases till now.

In the following sections I will summarize my current findings about how the device works (this is work in progress at the time of writing)

Connecting

The main connection is MQTT over TLS on port 9883 via IPv4. The broker on the device requires:

• A valid username
• A valid password
• A self signed client certificate and private key to perform TLS negotiation

The certificate is self signed. The original slicer seems to generate it on installation or first connection as it seems from the creation date. To create an own certificate one can use openssl and set the subject with the appropriate organization identifier.

Device Identification

It seems the device is identified by a model id (20030 in my case) and a unique device_id. Those appear in the topic names! Thus there has to be an additional method the application uses at first to determine the model and device ID that I still have to figure out. I would suspect some kind of broadcast message.

Topic Structure

Topics seem to implement a proper command-query-responsibility-segregation approach. The application subscribes to topics under the structure

anycubic/anycubicCloud/v1/printer/+/20030/<device_id>/#

Commands seem to be published to a different path - namely to

anycube/anycubicCloud/v1/web/printer/20030/<device_id>/<command>

This looks like a professional design (resembling the pattern of Command Query Responsibility Segregation (CQRS)) for an MQTT operated device. Most queries use the following structure:

{
  "type": "<command>",
  "action": "query",
  "timestamp": TIMESTAMP_HERE,
  "msgid": "uuid-here",
  "data": null
}

The printer often sends two kinds of responses:

Empty ACK-like responses sent back to anycubic/anycubicCloud/v1/printer/public/20030/<device_id>/response. These use the msgid as correlation ID:

{
  "action": "",
  "code": 0,
  "data": null,
  "msg": "",
  "msgid": "original-request-msgid",
  "state": "",
  "timestamp": 0,
  "type": ""
}

On the other hand the actual report, which is sent to anycubic/anycubicCloud/v1/printer/public/20030/<device_id>/<type>/report. Those reports do not correlate via the original msgid! Here the clients have to perform correlation via sequence or time. For a simple user interface this implementation actually even makes more sense.

Read-Only Commands Without Side Effects

The following commands are currently known to me (and yes tempature is a typo that the vendor made in their code, it needs to be misspelled.

The info/report

This is a very useful structure and contains information about the printer as well as it’s state:

{
  "action": "report",
  "code": 200,
  "data": {
    "ip": "198.51.100.2",
    "model": "Anycubic Kobra X",
    "printerName": "Anycubic Kobra X",
    "version": "1.1.5.3",
    "state": "busy",
    "project": {
      "filename": "example.gcode",
      "progress": 29,
      "curr_layer": 179,
      "total_layers": 315,
      "print_time": 96,
      "remain_time": 226
    },
    "temp": {
      "curr_hotbed_temp": 60,
      "curr_nozzle_temp": 205,
      "target_hotbed_temp": 60,
      "target_nozzle_temp": 205
    },
    "urls": {
      "fileUploadurl": "http://198.51.100.2:18910/gcode_upload?s=<token>",
      "rtspUrl": "http://198.51.100.2:18088/live/<token>"
    }
  },
  "msg": "done",
  "state": "done",
  "type": "info"
}

This contains information about the printer itself, the currently running print job, temperatures and URLs for file upload as well as the RTSP video stream. Note that the URLs contain again access tokens that one has to use, they seem to change at least also on device restart.

• Temperatures are given in degree Celsius
• Durations and times are given in minutes
• The URLs contain access tokens that one has to use!

The tempature/report

Yes this is deliberately misspelled. The topic has a wrong name.

{
  "action": "query",
  "code": 200,
  "data": {
    "curr_hotbed_temp": 60,
    "curr_nozzle_temp": 205,
    "target_hotbed_temp": 60,
    "target_nozzle_temp": 205
  },
  "msg": "done",
  "state": "done",
  "type": "tempature"
}

I suspect code is just a response code like for HTTP and it seems to mirror the HTTP numbering. 200 would indicate ok. Temperatures are again given in Celsius.

Fan Speed Report fan/report

{
  "action": "query",
  "code": 200,
  "data": {
    "fan_speed_pct": 0,
    "taskid": "-1"
  },
  "msg": "done",
  "state": "done",
  "type": "fan"
}

The fan_speed_pct is given in percent as a value from 0 to 100, the taskid sometimes is present and sometimes not.

Print Status print/report

This report contains information about the currently executed print - like the filename, progress, current and total layer, print and remaining time in minutes, temperatures and settings for various components:

{
  "action": "update",
  "code": 200,
  "data": {
    "filename": "dracu_2_plate(01)_PLA_0.2_5h19m42s.gcode",
    "progress": 29,
    "curr_layer": 179,
    "total_layers": 315,
    "print_time": 96,
    "remain_time": 226,
    "curr_hotbed_temp": 60,
    "curr_nozzle_temp": 205,
    "settings": {
      "aux_fan_speed_pct": 100,
      "fan_speed_pct": 100,
      "print_speed_mode": 2,
      "target_hotbed_temp": 60,
      "target_nozzle_temp": 205,
      "z_comp": 0.0
    }
  },
  "state": "updated",
  "type": "print"
}

⚠️ Work in progress This section will be expanded as additional protocol analysis is completed.

Conclusion

To sum up there are a few good things that would make me recommend the device and then unfortnuately there are many bad things on the software side that would lead me to not recommend it:

The Good Stuff

• The hardware is solid
• Performance of the hardware is good, print speed can get high for a device of this price class
• It is very simple to assemble while still being extremly rigit
• The product designers have well thought also about the small details that give the device a very good feel.
• For users who prefer a turnkey, app-driven workflow, and do not care too much about the ability to include the device in their own frameworks and infrastructure as well as to operate it secure from a software perspective the default setup may actually be convenient.

The (Very) Bad Stuff

This is mainly the software side (and could very easily be fixed so this gets one of the best cost efficient products out there)

• A device that only connects via WiFi and directly connects to a cloud service significantly limits deployment in professional or security-conscious environments.
• Designing around a smartphone application is again imposing the same limitations.
• Requiring a very specific Host application is a very bad idea considering the available landscape of open source tools and how they can be combined. Also it makes the device unuseable on many operating systems.
• No documented protocols, no publically available printer profiles outside the own walled garden of softawre. This is something that leads immeadiatly to the conclusion to recommend more open products.

As one can see above this idea of undocumented behaviour and vendor lcok-in also does not provide additional security. It is very easy to circumvent (don’t get me wrong - using TLS for communication is not ment with this of course, there is just no publically available information on the protocol and internals of the control in LAN mode).

References

• Products:
  • The Anycubic Kobra X itself (or a combination including the external colormanagement device)
  • You really need at least a knife and a string cutter to unpack, everything else is provided
  • A multimeter and an USB storage oscillscope which turned out to be useful to figure out whats up with the undocumented 4 pin and 6 pin connector on the side of the printer
  • An external RCD that I usually use when testing new products that I don’t know till now
  • A automatic fire extinguisher is a good idea when operating printers unattended. These devices got cheap and are usually very reliable. Be better safe than sorry.
• Reverse engineering tools:
  • The frida dynamic instrumentation toolkit that has been used to trace through the software
  • Wireshark as tool to inspect (unencrypted) network traffic.
  • OpenAIs ChatGPT and codex that helped with walking through the captured data - it did not reveal secrets but made work easier.
• Modelling software:
  • FreeCAD, the best (parametric) CAD software out there
  • Blender, the best modelling solution for artistic designs
• AI based 3D modeling:
  • A Local Image/Text to 3D Solution: Hunyuan3D as a locally running, uncensored text to model and image to model application
  • Programmatic 3D Model Generation with the Tripo3D API
  • FreeCAD MCP, a simple MCP server for FreeCAD that allows LLM agents to operate your CAD application
• Bringing XPPen Tablets to FreeBSD: Reverse Engineering a USB Protocol to use graphics tablets in Blender or other applications during design processes. Also very convenient for assigning color in Anycubics SilcerNext or OrcaSlicer

This article is tagged:

• Hardware
• Machining
• 3D printing
• Reverse engineering