In the first part, we learned the basics of using Apktool to decompile an APK, modify its resources, reassemble it, and install the aligned and signed APK on a device.
In this part, we will learn how to modify the code.
Our goal is to bypass the root detection check on a rooted device and make the app display that it is not rooted. If you are testing on a non-rooted device, you can do the opposite and modify the app to detect that you have root access.
Five years ago, I wrote an article titled [Android] Everyone Can Reverse Engineer APKs. At that time, I was an Android engineer who, due to work requirements, researched basic Android reverse engineering with my colleagues. Our goal was to achieve a fully automated process: upload an APK, automatically decompile it, insert some strange things, and then repackage it.
Now, due to work requirements, I have revisited and reinforced my knowledge of APK reverse engineering and modification, and have written this series of articles to share with you.
First of all, I want to emphasize that this series is only an “introduction.” By using various tools to decompile and rebuild APKs, it should be sufficient for apps that are not obfuscated. However, if the app has been obfuscated, deeper knowledge of binary is required to unlock it, which is another world.
In any case, this series is suitable for those who have not been exposed to Android app reverse engineering and want to try it out, as well as for Android engineers who want to decompile their own apps and see what they look like. I think it’s quite useful.
Recently, as a beginner in Zero-Day Japanese, I started studying and passed Japan’s Basic Information Technology and Information Security Management exams. In this post, I will share how I prepared and what exam techniques I used.
The outline of the article is as follows:
This year, Water Paddler got second place, solving 8 out of 9 web challenges (I contributed to 2 of them). Overall, I think the web challenges were easier than last year, and there were fewer participants.
Recently, I noticed that I haven’t been writing as many writeups as before. One reason is that I’ve been busy, and the other reason is that there haven’t been as many interesting challenges (client-side) lately. Or maybe my teammates have become stronger, and they solve the challenges before I even get a chance to look at them. So, I’ve been too lazy to write notes XD
In this post, I’ll only write about the challenges that I participated in or found interesting. I’ll skip the others.
Although it’s been almost two months, I’m still going to take some notes. Last year, I was electrocuted badly. I thought it would be better this year since it’s been a year, but I still got electrocuted.
Keywords:
First, let me post the official repo, which contains the code and answers: https://github.com/dicegang/dicectf-2023-challenges
As usual, there is a Intigriti challenge in January, but this time it’s not an XSS challenge. It’s about “second order injection” which is relatively uncommon, so I decided to write a blog post.
Recently, someone posted a post in the Facebook frontend exchange community, which he saw a problem: Is there a problem with passing account and password json plaintext when logging in to the API?, and wanted to know everyone’s opinion on this issue.
Most of the answers below think that “using HTTPS is enough, there is no need to implement an additional layer of encryption, and there is not much meaning.”
To be honest, I used to think so too, and there have been similar discussions in the community in the past. At that time, I thought that since HTTPS already exists, and the purpose of HTTPS itself is to ensure the security of transmission, why do we need to do encryption ourselves?
But after being exposed to information security for the past year or two, my thinking has changed. I think it is meaningful for the frontend to encrypt passwords before transmission, and I will explain my reasons in detail below.
This year, I seriously followed Water Paddler to play CTF for a whole year. I saw someone wrote a CTF: Best Web Challenges 2022 and found that I had played most of the challenges inside. So I thought it would be better for me to write a summary, documenting the challenges that I personally felt I had learned something new from.
Because of my personal interest, the challenges that I played were related to frontend and JS. Challenges related to backend (PHP, Java, etc.) are not included.
Also, the techniques or solutions recorded in this article do not represent the first appearance in CTF. They are just the first time I saw them or thought they were worth recording, so I wrote them down.
I divided the challenges into several categories:
Here are some notes on the challenges I solved during RCTF 2022. I won’t be including those I didn’t attempt.
As usual, here are the keywords:
Recently, there were several CTF challenges that were quite good, such as SECCON and HITCON, but unfortunately, I was traveling abroad at that time and was too lazy to write complete writeups after returning. Originally, I was even too lazy to take notes, but once time passed, it became difficult to find related information, so I decided to write a brief summary.
In addition, I will also briefly mention several challenges that I think I should have taken notes on before, but for some reason, I did not.
Keywords:
