←back to thread

Reverse engineering the obfuscated TikTok VM

(github.com)
412 points xfeeefeee | 3 comments | 21 Apr 25 01:59 UTC | HN request time: 0.527s | source
Show context
godelski ◴[21 Apr 25 05:11 UTC] No.43748662[source]▶
This seems like quite a lot of work to hide the code. What would the legitimate reasons for this be? Because it looks like it would make the program less optimized and more complexity just leads to more errors.

I understand the desire to make it harder for bots, but 1) it doesn't seem to be effective and bots seem to be going a very different route 2) there's got to be better ways that are more effective. It's not like you're going to stop clones through this because clones can replicate by just seeing how things work and reverse engineer blackbox style.

replies(8): >>43748681 #>>43748712 #>>43748741 #>>43748839 #>>43749167 #>>43749282 #>>43750130 #>>43752385 #
noduerme ◴[21 Apr 25 05:25 UTC] No.43748712[source]▶
A generous take would be that they have their own internal GUI tools that make it easier for non-programmers to set up visual elements in this. That was historically the reason to invent VMs like Flash. A less generous take would account for the enormous potential for hiding nefarious code inside such a thing, and account for the nature of the government which deployed it, and conclude that it was a national security / defense project disguised as a candy-coated trojan horse.
replies(1): >>43748994 #
supriyo-biswas ◴[21 Apr 25 06:37 UTC] No.43748994[source]▶
VM-based architectures are really common in the obfuscation space, which is why you have executable packers[1], JS packers[2] and bot management products[3][4] leveraging similar techniques.

As for why the obfuscation is needed: bot management products suffer from a fundamental weakness in that ultimately, all of them simply collect static data from the environment, therefore it would make much more sense to make the steps involved as difficult to reverse engineer as possible. Once that is done, all you need to do is slightly change the schematics of your script every few weeks and publish a new bundle, and you've got yourself a pretty unsubvertible* protection scheme.

Regarding the "trojan horse", I think someone is yet to show proof that it's a Javascript exploit.

(*Unsubvertible is obviously relative, but raising the cost the attack, from say, $0.01/1000 requests to $10/1000 requests would massively cut down on abuse.)

[1] https://vmpsoft.com/

[2] https://jscrambler.com/

[3] https://github.com/neuroradiology/InsideReCaptcha

[4] https://www.zenrows.com/blog/bypass-cloudflare#_qEu5MvVdnILJ...

replies(1): >>43750071 #
noduerme[dead post] ◴[21 Apr 25 09:50 UTC] No.43750071[source]▶
[flagged]
supriyo-biswas ◴[21 Apr 25 10:00 UTC] No.43750136[source]▶
> Packers and obfuscators are not a "VM". It may look like a VM and act like a VM, in that it has opcodes that you can write to in another higher-level "language", but that is not a VM. It's in the same sandbox as the thing you're trying to obfuscate.

Indignant, caustic comments that simply discard all presented evidence such as this is the primary reason why people with the relevant experience have reduced their contributions on HN. I suspect I'll join their ranks too.

replies(3): >>43750173 #>>43750254 #>>43752054 #
esseph ◴[21 Apr 25 10:06 UTC] No.43750173[source]▶
If you explain what you disagree with, maybe people would learn something.

If you joint "their ranks", you've simply gone down the bit of the "social media + expertise" bell curve, where the more expertise you get on a particular topic, the less you want to engage about it in public.

This is not unique to any one field or realm of knowledge.

replies(3): >>43750216 #>>43750331 #>>43750929 #
oefrha ◴[21 Apr 25 12:00 UTC] No.43750929[source]▶
> I can't think of a scenario where you'd need to deconstruct their front-end to mimic the calls. Just observe the calls and mimic them.

Just about everything in that wall of text is wrong, but it’s rather pointless to engage someone who clearly has never reverse engineered a single thing with a modicum of defense, yet has tons of opinions on the subject. It’s like debating the pros and cons of programming languages with someone whose claim of expertise is having used computers. I totally get gp’s frustration. Denial of service with too many absurd points is real.

> If you explain what you disagree with, maybe people would learn something.

TFA explains in detail why reverse engineering is necessary, and specifically what is achieved by reverse engineering which part. ggp clearly has zero interest in learning when much of what they wrote has been refuted in the damn post being discussed. Other people can RTFA to learn as well, it’s a good technical post, and we don’t get enough of those these days.

replies(2): >>43750994 #>>43751315 #
1. noduerme ◴[21 Apr 25 12:39 UTC] No.43751315[source]▶
k, you're saying you can't understand the obfuscated bullet they're sending to the backend unless you understand how it's turned into a particular nut on the front, and understand both sides of the request. I see how that makes sense, if you can't even figure out how to decipher the requests as you read them going out. Is that what you're trying to say? If so, say it, rather this this "wall of text" about why technical posts are scarce and bla bla bla. I'm more interested in the reason for this kind of obfuscation (and no, I don't think it's just to protect against bots, as there are many ways to do that).
replies(2): >>43751829 #>>43751832 #
2. oefrha ◴[21 Apr 25 13:31 UTC] No.43751829[source]▶
You see a parameter called signature in the request with a random looking value, you try to "mimic" it (how?) and you always get 403 back. How do you proceed? TFA tells you know, and tells you why reverse engineering is necessary (TFA in fact goes one step further than what is necessary, but you have to do at least half of the work there — I have done exactly that myself in the past).

All you've posted so far is "I don't think <other people's points>" while being wildly wrong. It's on you to explain handwaves like "just observe the calls and mimic them", but I don't think you'll do that, plus anyone with experience here can tell it's nonsense anyway, so here's where I disengage.

Edit: I'll add another point of view as someone who has implemented my own obfuscation scheme in a product where throwing up a third party CAPTCHA isn't an option (the above is from having studied and worked around other people's obfuscation schemes, including TikTok's). Obfuscation is an arms race so there's no 100% winning, but my implementation, while vastly simpler and probably won't stop LukasOgunfeitimi, reduced the observable abuse of our product down to effectively zero. Turns out most hackers are pretty dumb. So, this shit works, "I don't think" be damned.

3. gruez ◴[21 Apr 25 13:31 UTC] No.43751832[source]▶
>I'm more interested in the reason for this kind of obfuscation (and no, I don't think it's just to protect against bots, as there are many ways to do that).

see: https://news.ycombinator.com/item?id=43748681 and https://news.ycombinator.com/item?id=43749282

all of those can't really work if the javascript payload is easily comprehensible, because you can just write your own implementation in python or whatever.