YouTubeShop VS frida

It's a very significant increase indeed. The increase is (or was) large enough to entirely wipe out most adversaries and restructure the battlefield in ways very advantageous to those playing defense. At least, in the social web space. It's something of a secret weapon to those who know about it: because so many developers assume it can't work the companies that master it have a large competitive advantage.

Source: About a decade ago I created Google's main "device detection" platform, as this article calls it (not Picasso, the thing that executes Picasso). It's actually more like an automation detection platform, as it's not a fingerprinting or device tracker, it just tries to separate human operated from automated clients. These days I'm told there's a large-ish team that maintains it full time and has ported the concepts to other platforms like Android.

It started as a 20% project because at that time almost nobody at Google took the idea seriously. Fortunately, my manager was happy to support my experiments. People had the same common (but incorrect) intuition you're displaying here, that any sort of client integrity technique is so easy to work around it's hardly worth the bother. Actually even I believed this to a large extent, just less so than the others. This turned out to be wrong for some not entirely obvious reasons related to the structure of the spam industry:

1. Most spammers are either not programmers at all, or are extremely poor programmers compared to a typical tech firm employee. They can in fact be out-coded.

2. This is because spamming is usually not all that profitable, so programmers who get good can find better and steadier money in the white market. The ones who remain are typically those who live in places without any local software opportunities (e.g. developing countries).

3. Because of this mounting even a not very strong defense is sufficient to corral your adversaries into a shallow economic pyramid, in which a small number of "skilled" people produce tools and services they sell the others, who then run the individual campaigns. This means you are probably not fighting as many people as you think you are. Screwing with the supply chain is an excellent way to wreak havoc on spammers.

When we first deployed the system we spent several months tuning it in what was effectively a running battle with the major Google account sellers. We discovered that the sellers were in turn buying their account creation bots from other people, and some sellers were actually re-sellers. One of the sellers had been using a "raw" bot that didn't embed a browser engine, and thus was knocked out of the market for months as they waited for a new bot to be written from scratch. When that came online there were mistakes in its browser automation that we were able to detect. The developer of the bot couldn't de-obfuscate the JavaScript we used (too hard for them) so treated the platform as a black box, just trying random things in the hope it'd work. We could watch this evolution in real time and block new versions as they were released. After a few rounds of this the seller got sick of it and switched to a new bot supplier. This new bot also took months to complete, and when it arrived it had fixed the bug we were using to spot the first bot, but introduced new bugs the other didn't have, meaning even then it was detectable.

At that point the seller gave up, as presumably paying for the development of all these bots was quite expensive relative to the margins involved. This in turn nuked all the resellers that had been relying on that guy, and blew a hole in the entire Google-oriented spam ecosystem. Spammers had to start phone verifying accounts en-masse, and for most of them it just wasn't worth it (a few switched to using stolen accounts instead of creating them). I haven't been there for years so don't know what the current state of play is, but you do still see public threads crop up from time to time where spammers say they tried to beat the system and couldn't, like this one:

https://github.com/BitTheByte/YouTubeShop/issues/14

If you want some insights into the minds of the typical newbie spammer when faced with this system, try this search and flick through some of the results:

https://www.google.com/search?q=site%3Ablackhatworld.com+bot...

Frida, uff this is just AMAZING, yes with uppercase and in bold letters. They also has bindings on different languages that can be found in their github repository. Spoiler alert...the Go binding it's pure shit...really couldn't run it. Use just the default that it's installed with pip install frida-tools.

A great framework for doing something along those lines is Frida (https://github.com/frida/frida). Works on a bunch of stuff, including Android and iOS. Some global-ish certificate pinning bypasses work through Frida, by patching http libraries to not raise exceptions, accept system certificates, etc and just quietly hum along instead. Certificate unpinning in turn enables network MITM with mitmproxy, which makes it a lot quicker and easier to inspect, block, or modify network traffic.

Funnily enough, I've seen much stronger obfuscation from reverse engineering from my cheap Tuya IoT devices app than from my bank app.

Install Frida from Github :- https://github.com/frida/frida

// see: https://github.com/frida/frida/issues/382

If anyone needs a "monkey" not for web pages but for any process on your computer system, may I recommend Frida:

https://frida.re

https://github.com/frida/frida

With Frida, you write JavaScript programs and inject them into arbitrary processes, to hook and modify and call whatever you please.

It gets a lot of use in the reverse engineering and vulnerability research communities, but has broader scope too. For instance, I used it recently to automate the UI of a video production program on Windows, by injecting a thread that sends window messages to the main message loop and hooks into various system dialog functions.

var android_log_write = new NativeFunction( Module.getExportByName(null, '__android_log_write'), 'int', ['int', 'pointer', 'pointer'] ); var tag = Memory.allocUtf8String("[frida-sript][ax]"); var work = function() { setTimeout(function() { android_log_write(3, tag, Memory.allocUtf8String("ping @ " + Date.now())); work(); }, 1000); } work(); // console.log does not seems to work. see: https://github.com/frida/frida/issues/382 console.log("console.log"); console.error("console.error"); console.warn("WARN"); android_log_write(3, tag, Memory.allocUtf8String(">--(O.o)-<)");

Go to https://github.com/frida/frida/releases and download the latest frida-server--android-arm64.xz. Extract it and run adb push frida-server--android-arm64 /sdcard/frida-server

It sounds like a kind of black magic:

> ...It’s a dynamic code instrumentation toolkit. It lets you inject snippets of JavaScript or your own library into native apps on Windows, macOS, GNU/Linux, iOS, Android, and QNX.

> ...Frida’s core is written in C and injects QuickJS into the target processes, where your JS gets executed with full access to memory, hooking functions and even calling native functions inside the process.

> There’s a bi-directional communication channel that is used to talk between your app and the JS running inside the target process.

Here's a description of the architecture:

https://frida.re/docs/hacking/

And the source:

https://github.com/frida/frida

---

Apparently using "wxWindows Library Licence, Version 3.1":

> This is essentially the LGPL, with an exception stating that derived works in binary form may be distributed on the user's own terms. This is a solution that satisfies those who wish to produce GPL'ed software using Frida, and also those producing proprietary software.

https://github.com/frida/frida/blob/master/COPYING