Video Summary and Transcription
JavaScript's power and versatility make it the programming language of choice for consumer applications worldwide. A JavaScript engineer should understand how things work, even if they don't know everything. The Talk discusses modifying websites, uncovering game rigging through developer tools, analyzing fetch requests and overrides, refactoring and state management, and website modification. The speaker shares personal experiences and highlights the importance of understanding and being able to modify code in real-time.
1. JavaScript's Power and Versatility
Hi there, JS Nation. Thank you for tuning in. As a JavaScript engineer, you might have seen this classic interview question about the order of console logs. It's okay not to know everything, but it's nice to understand how things work. JavaScript has become the programming language of choice for consumer applications worldwide. It's versatile and allows you to modify and change code at runtime.
Hi there, JS Nation. Thank you so much for tuning in, and I hope you are having a fantastic day today. Regardless of if you turned in just for the remote section or you got a chance to maybe meet me in person, in which case, hello again.
Right. So as a fellow JavaScript engineer, you might have seen an interview question similar to this. This is your classic old one, which is what's the order in which the console log is going to pop out, right? And if you're an interviewer, maybe you've even asked a question like this during the interview, and in which case, kind of shame on you, but who am I to judge? And I think the correct, good way in my opinion to answer this question is, I have no idea, but I know how to find out. And my name is Mikhail, and I work as a developer experience engineer in a company called TopTel.
Right? These days, I'm mostly obsessed with developer happiness and frontend infrastructure. I usually talk about silly things, but today, I want to state that you don't have to know everything. You know, every other week, there's something crazy happening in the JS world, and you feel like you're going to miss out if you don't jump right into it, right? For instance, of course, if you are a React developer, you've obviously used hooks, and I hope you do use them now. And do you actually know how the hooks work under the hood? Do you know how those magical functions appear? How do they know when to get called, right? Or what is the source of swell to reactivity? How does it work? What's this magic dollar sign? And I think it is okay to not know. With time and experience, you accumulate all the, you know, all the edge cases, how to use them, how to not use them. With any tool, you learn how to use it, but you don't actually have to know, to understand it works under the hood in order to use it effectively, right? But it's nice to know, isn't it?
Anyway, however, I don't know how many last years that JavaScript has taken all over the world as a programming language of choice for consumer application space. It's very easy to find JavaScript developers to build your desktop app, mobile app, website, web app. It's on the edge, in the cloud, everywhere. We even sent JavaScript to space and I'm not blaming the business for that because, you know, it's relatively cheapish to find a nice developer that's gonna do a lot of stuff in the same time. That is good. Mostly, those use cases are good enough for JavaScript, right? And no matter how you cook it, at the end, it's always the JavaScript that comes out. It can be TypeScript, ReasonML, any other superset of JavaScript, but what's runs in the runtime is always JavaScript. There's no way around that. Some of you may hate it. I could say I've been in a similar camp myself, right? Like you don't know, you don't need those 150 megabytes of extra browser with your Slack, right? And all those JavaScript is slow and yada yada yada. You know that well, right? But I actually think that JavaScript, everything running on JavaScript gives you the never before seen power to modify and change the code at runtime. You can inspect everything. You can override everything. It's kind of like, you know, this changing the car tires. You go. I have a very good example. So for instance, let's say you want to look up what are the browser cookies. You, you know, usual thing.
2. Modifying Websites and Daily Lottery
You go on Google, find an article, but something prevents you from browsing further. In a native app, you can't modify the website. Storytime: a US-based healthy food store offers a promotion page where customers can enroll in a daily lottery by spending $200. After logging in, flipping cards reveals discount offers. Users can buy vegan bars at a discount. I experienced discounts ranging from 40% to 87%.
You go on Google, you find a nice article, you start reading it, blah, blah, blah. Something happens. And that is something that prevents you from browsing further. And you know what, what I usually do, I hope I'm not the only one who does that, but I just go to the developer tools and just remove that, right? Maybe something about my ad block or whatever else, but there's that you just do, you just done that you just modify the website. Imagine doing this in a native app. It is not possible whatsoever.
Okay. Storytime. There is a website called the garden.com.us, which is a US based healthy and expensive food store. And there is a promotion page on the website, which is assumed to facilitate the sales for every $200 spent. You get a chance to enroll into a daily lottery. That looks like this. So you go in, you log in as a respectable customer. You log in with your loyalty ID, you press the login button, then start the game. You flip some cards, get a discount offers. It's all good. Then my user can go and buy your vegan bars with 40% discount in the store in person. The next day you come back, there's a 24 hour cool down, and then you come back to the store, you do all the thing again. Right? I was like, okay, that's fine. It seems okay. That was interesting. There's 40%, there's 35%. That was good. It looks like I could get some pretty good discounts here. 60%. 87%. Imagine getting that. That is good. So I did that. Then I left.
3. Uncovering Game Rigging Through Developer Tools
I came back the next day and rolled some discounts for two or three days. On the fourth day, I became suspicious as I never received good discounts. I used different loyalty IDs and inspected the website using developer tools. I filtered out unnecessary analytics and discovered that the game was rigged. The requests for cards were not made, indicating that the game already knew the outcome. In the cookies, I found a base64 encoded timestamp of when I last played the game.
And then on the next day I came back, I did roll some of the discounts again. I did this for two or three days. And then on the fourth day I thought to myself, okay, I never seem to get those like really good discounts. Right? So I got a little bit suspicious. I don't know why, but it's just something that happens to me from time to time.
I actually have a different loyalty ID here. So let's see, what I usually do when I want to inspect all the bits and bobs of how the website runs, I just open up the web browser, sorry, developer tools. Right? I open the network tab. Obviously nothing is, it is not possible to run a promotion like this without server being involved. So at some point you will get the data for like those pop-up cards or something like that, you're going to get them in the network tab. So that's what I did. Press login. And you can see a couple of requests popping in here and there. So we get analytics, which actually something that we don't need to see in here because analytics, you know, every time you click anywhere, analytics gets requested. So analytics, we just filtered out so we can only see the stuff that matters. Right? Let's clean it up. And then I'm going to press start right here and we got two requests. It's fair. Now let's continue clicking. One, I got a request for the image. Boom, boom. Then the rest of the images load, you know, anything suspicious around here? No. Because if you notice that when I click a card, the request is not made, which means that these bastards rigged the game. They already knew what I'm going to get even before I click on the cards. Right? And I don't like that. I mean, I could understand that because myself, even working in a growth team at some point before in my life, I know I did the same stuff on every major holiday, like Friday, I would do something like this. This is always beneficial for the business, but you know what? As a consumer, you could maybe still get some profit out of it.
Okay. So honestly, I will spare you some of the details, but what I also found out that if you just go to cookies right here, you can see a couple of those and this right here in the cookie value is actually something that is, it looks like this. That is a base64 decoded, encoded timestamp of when you last played the game.
4. Unveiling Website Code and Fetch Requests
It doesn't look safe to validate on the client side. Removing the cookies allows me to repeat the game and get the best offers without clicking. By modifying the website code, I can tap into the JavaScript and break the code to see the fetch requests for the cards from the server. Stopping whenever any kind of fetch request is made reveals the analytics.
It doesn't look really safe, doesn't it? It's not something you would validate on the client side. It's like, okay, what if I remove the cookies, which is what I did. There's the website. Boom. Logged in again. And would you look at that? I can play again. That gives me the nice point of repeatability. I can just remove the cookie and play again. It's like, wow. I could get all the best offers. So if I just click here, boom, I got this. Remove the cookie, refresh again, start. There it goes. It's magic. I can get more offers, but those are still never good for some reason, right?
I was like, okay, maybe I can, you know, even avoid clicking if I modify the website code. We'll see about that. So there are several ways in which you can go if you want to tap into the website code. So what you want is to break the code, which means stop JavaScript execution at some point, right? And we know we get all those goodies, all this data for the cards from the server, right? Not on the client. At which point is what I would do is I would go to my second favorite Chrome developer tools tab, which is sources. And right here, you got, you know, all the JavaScript. Let me pop this off. It's like that. We got all the JavaScript here that comes back from the server to our client lives there now.
So there are a couple of ways to do that. For instance, you could say when I click the button, stop the JavaScript, then we can see if there is a fetch request being made. And then we can break into the code that way. But what I like is actually to stop whenever, just whatever happens, whenever any kind of fetch request is being made. So I click on this. Boom. And this is, you can see, this is the analytics.
5. Analyzing Fetch Requests and Overrides
We can remove cookies and repeat the process. By enabling a breakpoint, we can stop JavaScript execution at any fetch request. Analyzing the call stack, we can identify the initiator of the request. By using the overrides feature in Chrome Developer Tools, we can replace a remote file with a local file. Skipping irrelevant code, we can focus on the function that matters.
That's fair. Let's keep that. Okay. Let me pause this for a second. Actually, we will get to the place that matters. So we already know we can just remove the cookies and repeat the stuff, right? Login, arrive right here. And at this point, I will enable my break point that will stop the JavaScript execution at any fetch request being made. So start, analytics, not interesting. Moving on.
And here is the second thing, which we could see in the debugger, we could see that the URL is slash promo slash game. Okay, something interesting. And let's move on to the call stack. This beautiful place that allows me to kind of time travel on the short period of time, of course, to traverse the call stack and see what was the initiator of the request. And you know, going through all of this, this all looks like a framework in terms, I assume, actually, I mean, I already know that. But by looking at all of this, you can kind of see that this is Next.js, it's a Next.js app, right? And all of those things are framework internals. But somewhere around here, I can see on start, which is something that is human readable. And it does something, there's a promise, then something happens. And I can see that this kind of file kind of looks like business logic ish code. So I'm interested in that. That's exactly what I'm going to do. So there's this nice feature in Chrome Developer Tools called overrides, you can take any remote, any file that is a part of the bundle, so to say, and you can override it with your local file and say, okay, this local file is now replacing the one on the server. It would just do that, you can click on this, right click, override content. And there we go. Now this file right here, exactly the same file, but it is now some stored somewhere locally, a computer. And to move on, I would actually go to ID, which is what I prefer for things that will stay slightly later.
Okay, so I'm going to skip some of the stuff that is not, I know that is not relevant, but you can figure it out when you own by traversing the code, you know, and get to the function that actually matters, which is, if you ever, I don't know if you ever experienced like this, but if you ever tried to disassemble machine code, it's just one of my favorite type of YouTube videos, you just go on and watch people disassemble the machine code. And the process here is very similar. So a lot of this stuff doesn't make sense. It looks like an unreadable code of webpack chunks, encoding, mangled, and all this stuff together. But here, there is a, let me see.
6. Refactoring and State Management
I'm going to use the refactoring capabilities of my ID to rename components and variables, making the code more readable. The use state hook is used to manage game state and card state. The code also initializes an array and a number variable.
Start, where was this function? Is it here? Oh, yeah, there you go. And there's the function that matters again. Okay, so what I'm going to do is I'm going to use this kind of refactoring capabilities of my ID and just start renaming stuff. So this is going to be some component, and it's going to be props. So we can see that's react, we have use state here, there's props, last played, has played props, and you can see our code is starting to get more and more human readable.
Last date props. There you go. Now we have a use state. So React, you know how you state works. So this is a use state with the default value of if has played from props, then it's restored. Otherwise it's intro. And by looking at this, we can assume that this is some kind of game state, state. And this is one is going to be set game state.
This one, we don't know what it is just yet, because this is just an array. I'm going to call it some array. This one's going to be set some array. Just like that. We don't know what it does yet, so it's just going to be some array. This one, an x use state that is object from entries, array, nine, keys. So this looks like it creates a Q value object with nulls from zero to nine, zero to eight. That actually kind of does look like our little card grid here. So I assume this is something like card state. Let's say it, card state. And this is going to be set card state. There you go. This one, no comments, nothing too big of, is just a zero. It's going to call it a number. It's going to be set a number, just like that.
7. Game State and Server Interaction
The code sets a number, uses a promise to set an array, and reveals cards based on a function called on card click. The on start function interacts with the server, retrieving and displaying product information such as smoothie mix, kale chips, and detox tea.
It's going to be set a number, just like that. Okay. Now we're done with all this use states, we get a one use effect here. If you have played from props, then it's a promise and it sets some array to whatever comes out of it. Makes sense, right? That's fair.
Now there is this function. I actually also like to kind of collapse the functions and I'm done with. That's also one of the reasons you can do that in the IDE much easier. So this one, there's a big function that if a number is less than two, you increment the number and set card state to something. And by looking at this, we can kind of understand that this is probably a function that gets called when you click on a card. So we'll just do that on card click. And this is probably a card index, card index. And the number on this one, number is turning into amped. So you can already get kind of, so set number is now set at amped. And there you go. This code is already, you can already kind of see where all this stuff is kind of slowly coming together. So what we do is attempt less than two, we reveal a card, we reveal a card with the selected index and so on and so on until we arrive at game state finished, right?
And then there is actually our thing that's called on start that's doing something, grabbing, I assume maybe those are the promises that go towards the server, blah, blah, blah. But this is what happens when we start the game, right? What if we, you know, do the good thing and say console log E right here, and we save the file. And now if we go back, let me actually disable the breakpoints here. We don't want to need them. We have found the place. So going back, and you remember, we can still clear the cookies through set our temp, boom, there you go. So you press start, open a console here, and you can see, would you look at that. These are all the things that we have requested from the server. And it even says possible true, which is kind of funny. There's a discount, discounted price, and for every one of those, you see that some of those are possible. I assume the first three are the ones that you're going to open. And the last ones are possible false that have bigger discounts, right? There's a lot of fun. And by looking at this, we could see that the products that we are getting, let's assume the first three, there's smoothie mix, kale chips, and detox tea. Smoothie, kale chips, detox tea, all is well.
8. Website Modification and Conclusion
To refresh, modify the component's initial state, press start, roll discounts, and play again instantly. Enjoy the detective game of connecting the website's elements. Modify the website to your liking, but beware of promotions.
And finally, just, you know, for a refresher, let's see, we want to keep on rerolling those attempts. Actually, if you notice at the beginning, there is this fine property, the component that says, has played from props. And the initial state is, if you have played, then it's restored, otherwise it's intro. What if we just make it intro? Just, you know, just to see what happens. And with that in mind, refresh the page, press and start, roll your discounts, all good, refresh the page, play again instantly. You don't even need to clear the cookie. And that's how actually I did that. I enjoyed it a lot. It's kind of like a little detective game by, you know, figuring out how all the bits and bobs connect together. And there is that. And this is how you modify the website, make it do what you want. Don't be a fool. Don't be fooled by the promotions.
Okay. And with that in mind, I think it's time for the final slide, at which point is I say thank you for tuning in for this fun little experiment. I hope you learned something new. And if you want to look at my silly website with all the contact info, the QR code is there. Thank you.
Comments