3D printing/OctoPrint Server/Updated Workstation

Guys, only one month before I move into college. One month to do all the things.

I’ve already gotten started by buying myself a 3D printer, a Monoprice Maker Select v2!


I bought it from a guy who had gotten a brand new 3D printer for himself, and apparently had spent around $400 on upgrades and mods for the one he was selling. I got it for a steal at only $200.


Every time you physically move the printer or after a good lot of prints, you have to level the printer bed so the nozzle has an accurate “flat” surface to print on. It’s a bit difficult at first, and super frustrating at times. But once you understand which ways the knobs turn, it gets a lot easier.

So far I’ve been messing up a lot of prints learning how the bed leveling works, practicing with smaller and shorter projects to get used to how it functions.

My first successful print (aside from test prints) was a silver coin stand 😀 Super cute, isn’t it?


Another thing I had to do to actually fit my 3D printer into my room (where my workstation is) was to rearrange some furniture to make room for a new worktable.


And now everything is sturdy and awesome, aside from the fact that nothing is organized.

Here he is in action!

I think I’ll name him Bernie. He just seems like a Bernie.

To slice my STL files, I use Cura, a free software that’s super easy to use. You launch the software, import a file, then adjust the direction in which you want your design to print. Enter the infill and precision, move parts around and print 2 at once, then slice it into a gcode file that you load onto the microSD card 🙂

I also set up a temporary OctoPrint server on one of my free Raspberry Pis. I burned the OctoPi image onto and SD card, then edited the “wpa_supplicant” file on it to my wifi SSID and password. To make your server secure when it’s set up, I highly recommend SSHing into your Pi once it boots and changing the root password with passwd. Plug the Pi into the microUSB port onto the printer, and don’t forget to plug it into power too!

Once that’s done, you can go to http://octoprint.local/ or http://your-pi’s-ip-address/ and you can access the Octoprint page, where you can upload files and print things over the internet 😀 Super cool.

I haven’t toyed around with all the features, but it seems like it can be really useful if you read more into the documentation.

happy printing!


Reverse Engineering | PwnAdventure3 and Xonotic

I’ve been hacking a lot with my friend Gector, a fellow member of the UTW group, and we’ve been playing around with reverse engineering video games.

It all started with PwnAdventure3, a game purposefully made to be hacked. We found some tutorials on YouTube by LiveOverflow, a great hacking/CTF channel if you ever want to learn how to read reverse engineered data or play fun capture the flag challenges online.

LiveOverflow is currently making a great playlist & documentation of his hacks and finding ways to exploit PwnAdventure3, and I highly recommend trying it out for the sake of learning reverse engineering tools and just to have fun exploiting a video game 🙂

To be able to set up and play the game, you will have to set up some sort of game server to play on, which you can follow tutorials on how to do so here: https://github.com/LiveOverflow/PwnAdventure3 in the README section.

In two days of intensive hacking we got through part 6 of the tutorials: learning radare, IDA, using LD_PRELOAD to load the game with your configuration instead of the default game config, hovering, changing values to alter the game experience, and more. It was awesome to be able to see the correlation in the code and the in-game experience.

Gector got a little farther in the series than I did, since I haven’t been able to set up my own game server (my old dell server, kartoffel, isn’t able to support it). But hopefully he can set up a public gaming server that we can both work on, and hopefully rope another one of our hacker friends, Jay, into the fun as well.

A few weeks later, I found Gector reverse engineering another game from scratch: Xonotic. Xonotic is an open source multiplayer FPS game that seems to be fun (I haven’t actually played it, only hacked it).

He had wireshark open and was attempting to disassemble the packets being sent from his client to the server. All the data was in hex, displayed like so when we looked at the values:

0000  46 b3 e2 bc 64 14 6d c5 10 10 00 7d 00 00 65 a6    F…d.m….}..e.
0010  03 a5 65 00 00 e3 dd 7b 42 c8 0b 2c af 00 00 00     ..e….{B..,….
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 e9 43    ……………C
0030  50 44 e0 fe 54 c4 00 f8 04 c3 4a 5d 3c 44 24 34   PD..T…..J]<D$4
0040  81 c4 00 f8 3f c3 00 00 03 a6 65 00 00 dd ec 7b     ….?…..e….{
0050  42 c8 0b 2c af 00 00 00 00 00 00 00 00 00 00 00     B..,…………
0060  00 00 00 00 00 00 e9 43 50 44 e0 fe 54 c4 00 f8      …….CPD..T…
0070  04 c3 4a 5d 3c 44 24 34 81 c4 00 f8 3f c3 00 00      ..J]<D$4….?…
0080  32 a1 06 00 00 2

On the far left there were line numbers. In the middle is all the hex encoded data, and on the far right is the ASCII decoded (?) from it.

After scrolling through a bunch of packets over and over, we noticed a pattern. There’s a slew of random data in the beginning, 16 bytes of zeroes, repeating values, and then 2 byte counters throughout:

[46 b3 e2 bc 64 14 6d c5 10 10 00 7d 00 00 65 a6]       [ ] – random data
(03 a5 65 00 00 e3 dd 7b 42 c8 0b 2c af 00) [[00 00     ( ) – Repeating values + counter
00 00 00 00 00 00 00 00 00 00 00 00 00 00]] {e9 43     [[ ]] – Zeroes
50 44 e0 fe 54 c4 00 f8 04 c3 4a 5d 3c 44 24 34            { } – Repeating + counter
81 c4 00 f8 3f c3 00 00} ((03 a6 65 00 00 dd ec 7b       (( )) – Repeating + counter
42 c8 0b 2c af 00)) [[[00 00 00 00 00 00 00 00 00  00    [[[ ]]] – Zeroes
00 00 00 00 00 00]]] {e9 43 50 44 e0 fe 54 c4 00 f8     { } – Repeating + counter
04 c3 4a 5d 3c 44 24 34 81 c4 00 f8 3f c3 00 00}
<32 a1 06 00 00 2>                                                              < > – Random ending values

Once we figured out that pattern, we knew we could capture a lot of packets and sort through the data. There were consistent patterns that we space out:


The random data, the sequential counters, the zeroes, and then the stuff at the end.

After messing around with seeing what data changed when, we honed in on 2 tasks:

1) to see where the x, y, and z coordinates were, and
2) to see where the data shows buttons being triggered

When separating the zeroes from everything else, it was easy to see that the keystrokes and mouse buttons were the only thing changing in the packets (aside from random data). These were our notes:

– 00 00 68 01 98 fe = Forward LEFT
– 00 00 68 01 68 01 = Forward RIGHT
– 00 00 98 fe 68 01 = Backward RIGHT
– 00 00 98 fe 98 fe = Backward LEFT
– 00 00 1c 02 00 00 = SPECTATOR
– 00 00 00 00 00 00 00 00 04 00 – Right mouse
– 00 00 00 00 00 00 00 00 01 00 – Left mouse (NOT “10”, which is crouch)
– 00 00 00 00 00 00 00 00 08 00 – Middle mouse / zoom
And there is a “12” for scrolling forward, and a “13” for scrolling backward.

combine together it seems:
– 00 00 68 01 00 00 00 00 02 00 – Forward jumping! “02”
– 00 00 68 01 00 00 00 00 10 00 – Forward crouching! “10”

From the beginning we tested w , s, a, and d to see what forward/back/left/right was. Once those were identified, Gector suggested that the data ought to send position/coordinate values to the server as well, so that was our next goal.

When changing only x, y, or z, we found that there was a section of three groups of 4 bytes that contained the information of the coordinates:


To validate this, we tried converting these values, 0x1414adc4, 0x386c2bc2, and 0xb4577d42, to floating point numbers. But when we did, we got crazy values like 7.50636e-27, 5.63075e-05, and -2.0069e-07.


We caught some more packets, found the changing hex and verified that it was only when we moved x, or y, or z, and then put it into the converter again.

Same issue. Super small exponential numbers that didn’t make any sense as coordinates.
We were stumped: we tried different converters on the internet, we tried converting with the Python shell. What were we getting wrong? Surely they were the coordinates, we’d verified only a few dozen times by then.

And suddenly it hit me: we were trying to convert the data as little endian ordering, but the bytes were being ordered as big endian.

For those of you who don’t know this organizational convention, little endian ordering is where the least significant bit (or the last bit) of a byte (or series of bytes) is stored at the very end of the byte – the right side.

For example, little endian looks like this:

Most significant bit >> [1]101 1111 0011 010[1] << least significant bit

0xDF3A –> Most significant byte [DF], [3A] least significant byte

Whereas big endian looks like this, where the most significant is put at the end, and the least significant is at the “beginning”:

LEAST significant bit >> [1]101 0011 1111 110[1] << MOST significant bit

0x3ADF –> Most significant byte is still [DF], it’s just placed at the “end”

Taking this concept and applying it to our original values:

0x1414adc4, 0x386c2bc2, and 0xb4577d42
0xc4ad1414, 0xc22b6c38, and 0x427d57b4

When we put those hex numbers in the converter, we got waaaaaay more accurate results: -1384.63, -42.8557, and 63.3356! You can play with the converter yourself here: https://gregstoll.dyndns.org/~gregstoll/floattohex/

There are a ton of other triggers we could identify in the data, but the next stop is to create a python proxy server and alter our IP to make the game think that we’re one of the master servers: that way we can catch the packets the client sends, alter them, and then pass them through to the real main server for executing hacks 🙂

Until then!


Migrating to Gitlab & xorg errors

With the recent news of Microsoft purchasing GitHub, I’ve increasingly been wanting to try to port all of my repositories over to GitLab. And believe me, it’s super easy and totally worth it!

Once you’ve signed up for GitLab, you can click the “add project” button in the top right by the search bar. It’ll pull up a page where you can enter normal repo information, but there are also tabs that show different options:


The Import Project tab is what you want!
Gitlab’ll give you some options from there:screenshot.png

And you can choose where you’d want to import from.

I imported all my GitHub repositories, and that was great…until I realized all of the cloned repos on my laptop are still connected to GitHub. So how does that work? It’s not too hard.

Just find the repository you want pushing to Gitlab instead, and run these commands:

git remote remove origin
git remote add origin https://gitlab.com/username/projectname.git
git fetch --all

And boom! Everything is all ready to go 🙂
(sourced from: https://stackoverflow.com/questions/20359936/import-an-existing-git-project-into-gitlab)

On another note, I’ve been getting odd errors in my terminal when I execute programs that require a display, like Rofi, pcmanfm, and more.

Failed to open display: (null)
Cannot open Display
And finally, even xorg errored,
xorg: giving up

After some hunting, it seems like all I had to do was reinstall xorg.

sudo apt-get install --reinstall xorg

Then a reboot fixed those errors right up 🙂