tl;dr

I found a privilegee escalation vulnerability in one of my course's assignment.

I've reported the vulnerability to our instructor, and he fixed it. yaayy.

This article will be about how I found this vulnerability and how I utilized it to get a root shell.

前言

书接上回 微信视频号视频加密逆向。在之前的一篇文章中，我们留下了一个问题，就是WxIsacc64这个加密算法到底是怎么个回事捏。

虽然名字已经很清楚了，必然是ISAAC64算法，但是他具体是怎么生成的捏，今天我们就来一起逆向吧。

不知道咋说，感叹一下吧。

前端时间自己有个需求，去 github 上翻了翻正好有类似的开源项目存在。但是因为缺少一个解密算法，导致那个项目不可用。

我想，逆向这块我熟啊，那就研究研究看看能不能找到解密算法吧。

找到解密算法之后，我顺势提了 pull requests ，仓库主人也 merge 并发布了新版。

今天想到这件事又回去看了眼那个项目，发现作者居然做了收费版本。 （笑

当然之前的开源版本还是能用的。

怎么说呢，我确实没想过还能以服务支持的形式赚钱，感觉自己要学的还挺多的。

前言

大家好啊，我又回来写博客了。由于大四的选了几门超级难的课，导致没多少时间写博客了。（以上50%为真）

现在是2023年11月30日凌晨1点半，我来写点博客。

总之由于某些原因，我研究了一下微信视频号下载视频的方式。我在github上发现一个挺好的解决方法(WeChatVideoDownloader)，原理是利用代理获取视频地址。但是最近出了点问题，微信对视频号做了一点更新，对视频进行了一点小小的加密，导致下载下来的视频无法直接打开。

什么，加密，这能忍?

引言

设计一个高效且完善的业务系统，通常会需要分层。目前主流的分层都大多包含三层delivery, service, repository。当然，我们有时会在这些基础层次之间进行扩展，如在service和repository之间加入一个manager层，正如阿里的架构那样。

层架构下每个层的职责变得清晰，利于实现业务逻辑已经开展迭代。

但是，在设计业务逻辑的时侯，我遇到了一个问题，也就是缓存。究竟是放在service 层更好还是 repository 层更好捏？

Prologue

For example, I have following services running in my local network.

• Git Server: Located at 192.168.1.100:80
• Jellyfin Server: Located at 192.168.1.101:8000
• NAS (Network Attached Storage): Located at 192.168.1.101:8010

Is there any good way to access them without typing ip address?

Yes. In this blog post, I'll walk you through how I set up my internal network.

Part 0

有人曾经问我，你相信这个世界有美好的事情存在吗？

Part 1

从小我就特别喜欢看故事，不管是自己看漫画，听大人讲故事，还是认识字之后自己读故事书，我都非常喜欢。

我记得我小时候，甚至到了睡觉前没有故事听就睡不着的程度。幼时的我，一直以为我喜欢的是故事，喜欢读别人的故事。喜欢跟着故事的主人公走上一个个冒险，喜欢在故事里体验作者笔下的世界。

我的微服务框架开发的也有一段时间了，今天就来简单介绍一下框架的基础架构吧

Prologue

In my previous article, I left a lingering question regarding the decryption methodology inside wasm. Today, let's dive deep into the world of reverse engineering again and uncover the mysteries that lie beneath the code.

Now, some of you might wonder why this post is titled pure guesswork. Well, that's because I tackled this 'reversing' challenge without actually doing any acutally reversing.

引言

在最近的RESTful API设计过程中，我遇到了一个问题。当业务逻辑需要返回一个错误代码时，究竟应该遵循HTTP的原则返回对应的状态码，如200, 403, 500等，还是统一返回200，而将详细的错误信息写入响应体内？

这个问题涉及到了RESTful API是否应该遵循HTTP状态码的原则，让我们一起来探讨一下。