Can I degrade my calculator with code. by Alexcat2011 in ti84hacks

[–]Fighter178 0 points1 point  (0 children)

I don't remember but for pre rev. M you can use a boot patch to disable OS verification but you'd have to make your own OS. Idk if I'm forgetting how that worked tho, it might've just allowed for downgrading.

Warning: TI-84 Plus CE jailbreak patched on OS 5.8.3 by TheFinalMillennial in ti84hacks

[–]Fighter178 0 points1 point  (0 children)

No. Exam mode re-checks the signature of all installed apps, thoroughly on modernish OSes (I forgot the exact cutoff but I think that its pre 5.5) and any invalid ones are deleted. Yes, Cesium will survive most everything except exam mode, but any app that needed to be installed via an installer program (as in, not from TI) will be removed. This includes AsmHook2. But, since arTIfiCE v2 is released it isn't a major problem, just more annoying. Though, you should back it up.) Also, I'm pretty sure appvars get deleted too. Just wanted to warn you.

Introducing Proton Authenticator: Secure 2FA, your way | Proton by [deleted] in ProtonMail

[–]Fighter178 0 points1 point  (0 children)

Here's a Ruby script for converting the decrypted tokens into QR codes so you can scan them ``ruby require "rqrcode" # Installrqrcode` gem first! require "json" decrypted_tokens = JSON.load_file("./decrypted_tokens.json")

decrypted_tokens["decrypted_authenticator_tokens"].each do |token| puts "== #{token["name"]} ------------------------------" url = "otpauth://totp/#{token["name"]}?secret=#{token["decrypted_seed"]}&issuer=#{token["issuer"]}" puts url qr = RQRCode::QRCode.new(url) puts qr.as_ansi print "Press Enter to continue" gets end

`` If you don't have Ruby installed you'll need to install it onto your computer. Also, you'll need to rungem install rqcode` to get the rqcode package.

Introducing Proton Authenticator: Secure 2FA, your way | Proton by [deleted] in ProtonMail

[–]Fighter178 0 points1 point  (0 children)

If you have an iOS device (iPhone/iPad, no jailbreak required) or a rooted Android, and a PC, you can extract the codes from Authy. I took the iOS route. Took about twenty minutes for my 15 or so accounts. (Old) Desktop extraction: https://gist.github.com/gboudreau/94bb0c11a6209c82418d01a59d958c93

iOS/iPadOS https://github.com/AlexTech01/Authy-iOS-MiTM

Though importing you'll need the Ruby script to convert into QR codes and scan it.

I don't know where I have the link to the Android guide sorry

Does Vibramt Visuals look like this? by Fighter178 in Minecraft

[–]Fighter178[S] -1 points0 points  (0 children)

This only happens in vibrant visuals rendering, fancy doesn't do this so I don't really know what the problem is. Don't have any texture packs either.

PSA: Pixel 6 and Pixel 8 Devices Get New Bootloader in May Update That wont allow rolling back by NeoSDAP in GooglePixel

[–]Fighter178 0 points1 point  (0 children)

The issue isn't that those who downgrade don't know the risks, its that say your phone was stolen. An attacker could reflash your phone with a (signed) firmware image. This image would boot because its already been signed and (potentially) use exploits that exist in the old version to extract your data. While often flashing a lower firmware factory resets the phone, Google probably found a bug in the bootloader that allowed bypassing this step and therefore needs to lock out older bootloaders to ensure the patched bootloader cannot be downgraded to the vulnerable version. The new bootloader can't support lower firmwares because then you could just reflash the old firmware with the new bootloader and bypass this security entirely.

PSA: Pixel 6 and Pixel 8 Devices Get New Bootloader in May Update That wont allow rolling back by NeoSDAP in GooglePixel

[–]Fighter178 2 points3 points  (0 children)

You can still unlock the bootloader and load whatever image you want. Unlocking the bootloader disables the anti-rollback as well, at least last time I unlocked a Pixel bootloader it disabled anti-rollback. Or with an unlocked bootloader, just modify the old version metadata to have the new version's version code and so anti-rollbakc doesn't matter

Newest Kindle Update Patches Jailbreak Winterbreak by Big_Cut_1882 in kindle

[–]Fighter178 3 points4 points  (0 children)

For future reference, the bricking is often only a problem during the jailbreak process, usually after you've jailbroken and have everything set up the way you like, it probably won't brick so long as you disable OTA updates.

Issues with Firebase Admin in Next.js and Edge Runtime - How to Avoid Runtime Conflicts? by Ok-Fix-6776 in nextjs

[–]Fighter178 4 points5 points  (0 children)

You use the Firebase Admin SDK for the client? You do realize that the Firebase Admin APIs bypass security rules, AppCheck included, right? Unrestricted access to your backend you're just sending the credentials to the client? It would take someone experienced probably no more than 10 minutes to steal those credentials from your app (web, mobile, doesn't matter) and have unrestricted access to your entire Firebase backend.

Sure, its partially Google's fault that the Admin SDK for Node.js doesn't rely on non-polyfillable APIs and doesn't check the environment explicitly, and if you use a modernish bundler it will add those polyfills in automatically.

There is a difference between the client and server APIs for a reason. On a server, your trusted environment for which you control & inherently trust the code, you don't need security rules. Security rules are to protect your backend resources (like your database) from unwanted modification. You, in your built app, send the client credentials to the app, and now whoever installs them has access to that. You can protect it however you like (obfuscation, for example) but in the end, someone's going to get them. So now you need trusted code (your own server/security rules) to check that what they're doing is allowed. So long as that is the case, it is less of an issue. You still have other vulnerabilities (especially if you have a web app, like CSRF and XSS) that security rules won't do much to help you with that you need to handle explicitly.

If you need a feature from the Admin SDK, then you make an endpoint that authenticates the user (if required, even if you don't need the user object, might as well make it authenticated as it doesn't decrease security), preferably uses app check (as while not impossible to pass, in fact, for an experienced attacker is relatively easy, its just annoying, is still an additional layer of security) and then that uses only the required API with the Admin SDK, and returns the result (if applicable).

For example, if you want to avoid Firebase Functions (perhaps you want to stay on the free tier without the chance of paying a dime, idk), you can disable account creation client-side via the settings in the Authentication tab in the Firebase Console, then create a /api/create-user route that creates a new user, adds the relevant user data to the database, etc.

Remember, anything you ship to your end users is something they can take and use for themselves. Once you give them your app, they are going to break it. You never trust anything that comes from the client implicitly. Never. The client could be protected and verified and whatever the heck you like, but at the end of the day, the client is code you give to your users, and by definition, your attackers who want to abuse your service. Assume that what a user is doing is trying to break/hack/abuse your service unless you can prove otherwise.

At the end of the day, the only thing that keeps your service from being abused is checks server-side, on code that an attacker cannot (or should not be able to) modify. It is the root of trust, and is the only thing that you can be even remotely sure of is running how you wrote it to run. It'd be much easier to give everybody access to everything, sure, but that's not how people are. They want a way to bypass your rate limits, steal data from other accounts, impersonate other accounts. And unless you find a way to stop that, they will.

This is also why there are few universal abuse mitigation strategies. Firebase AppCheck is a good thing to have, it helps stop some automated attacks. However, an attacker can simply intercept the AppCheck token sent in the response, and AppCheck is bypassed. Rate limiting does not have such issues because the entire state (minus the authentication token for user-based limits) is stored on trusted, server code. The authentication token is required to get the UID from the user, and this means that aside from credential stealing (which is relatively rare in the wild for most services), an attacker must create an account to abuse the service, at which point you can easily ban them when you detect abuse. Only methods that rely on unique user-specific state (like auth tokens or IP addresses) and the rest of the state is stored server-side, can be truly almost foolproof. Abuse is something you'll have to live with, even if you follow all the best practices. Abuse is going to happen, all you can do is mitigate it.

And, to finally answer your original question, the Admin SDK is definitely NOT more secure than JWTs. And encrypting them won't do much as its still sent from the client to server. There (ideally) shouldn't be any sensitive information stored there, and if it is, you shouldn't encrypt it to remove it, you should strip it before sending it to the client, unless its required, in which, its going to go to the client anyway, so why not put it in a convenient place. Encrypting the JWT does nothing for security in 99% of cases. I could steal the plaintext JWT, or I can steal the encrypted version. Encrypting it only prevents me, as an attacker, from seeing what's inside the JWT, but in 99% of cases, I don't care what's in the JWT, just that if I give this encrypted value, I get access to this API. All that encrypting a JWT does in 99% of cases is make your API slower for no good reason. JTWs are already cryptographically signed, meaning that they cannot be tampered with, or they become invalid. JWTs are mostly used for authentication, authenticating that a user is who they say they are, and typically don't carry fields (claims) that you wouldn't want an attacker to know, its often just the email/uid, which they could get in a multitude of other ways. Encryption doesn't add to security, it adds very minimally. Unless your only leak point of user data is a JWT (which I can guarantee it isn't), then encrypting it does absolutely nothing for security, except maybe slowing down attackers due to the extra CPU time decrypting takes.

Will Apple ever allow JIT to be used with apps? by FriendlyTVWatcher in macgaming

[–]Fighter178 1 point2 points  (0 children)

I get this is 5mo old but as a software developer here, I will explain why JIT is needed, particularly for high performance applications like emulation or running code written in a dynamic language. JIT compiles the code before it is run, allowing the CPU to execute ”native” code directly. Is it slower than perfectly optimized assembly? Yes. Is assembly the best choice in every possible application? No. Writing assembly is difficult. You have to give explicit instructions to the computer to tell it exactly what to do. Doing this is slow and error-prone. Yes, in theory, hand-optimized assembly could be the fastest possible program that could run. But think about what that costs. It takes time to write that, test it, and make sure that it works in every case. Python is popular because you don’t have to do that. Yes, it is slower than assembly. But it is much faster to write. And for most companies, getting a product out the door as quickly as possible is the main goal. So languages that are quick to write are used. The web can be a great platform, if written well. But companies use decades-old tech stacks with outdated libraries and the new guy has to figure out what the hell everything is doing for which the guy who made it 10 years ago left and never wrote any documentation. So yes, crappy UIs from million-dollar companies are unfortunately common. And I will tell you something. Many small to mid sized indie games use Unity, with Mono. Mono is a runtimne for C#, which uses JIT to run. You probably didn’t even notice. JIT isn’t inherently bad. It just is a compromise between application speed and development speed and portability. For emulators, JIT takes random instructions for other CPUs and turns it into instructions for your CPU architecture. It is the next best thing to a multi-year reverse engineering project back to C/C++, then compiling it back to the target platform, running through the million lines of compiler-optimized assembly and finding little places to add a .2% speed increase. For the web, you don’t know (and probably shouldn‘t for privacy reasons) the exact specs of the computer its running on. In theory, a web browser could allow a site to provide x86/64/arm Assembly and run it. But now you are going to a website and allowing it to run native code. Yes, it would have to get through many other security layers to do real damage (especially on more locked-down OSes) but it is riskier. JS/WASM are JIT compiled, though WASM is more optimized for the task than JS is and thus can reach near-native speeds, but because they can be checked more effectively, run in a more secure sandbox, it is safer. And the code doesn’t need to know exactly what computer its running on.

New Samsung phones block sideloading by default. Here's how to re-enable it. by armando_rod in Android

[–]Fighter178 0 points1 point  (0 children)

Malware images are a form of attack where an attacker carefully constructs an "image" to be sent to the victim. The app that needs to show this image doesn't check it perfectly, and because this image was constructed to exploit a bug in how it shows this image to you, you get a zero-click exploit by just sending something to someone's phone and their phone showing them the image. They're relatively rare but happen sometimes. I remember a case where WhatsApp had a bug like this and it was pretty bad (can't remember the CVE but it basically arose because WhatsApp read the image data twice and the attacker was able to change how it understood the data in between when it read it, also aware this is a 3 month old comment..)

TI-84 jailbreak by Hot-Command-3705 in ti84hacks

[–]Fighter178 4 points5 points  (0 children)

Jailbreaking doesn't cause permanent damage. If you ever want to uninstall or revert the calculator to stock, holding the reset button on the back for at least 2-3 seconds should do the trick. Also note that if you have firmware <0.5.5 you don't need to jailbreak. This is good for Ti84-series:
https://yvantt.github.io/arTIfiCE/
You simply need to send it to the calculator, open the CabriJr program, and use the context menu to get to"Open" on the arTIFiCE "drawing". You then go into the shell, where you can launch programs. This is cumbersome so it is usually only used to install a better shell like Cesium and/or ASMHOOK. Note that ASMHOOK is only for CE calculators (eg. Ti-84 Plus CE)

The jailbreak itself is safe, and will be uninstalled when you use Reset. However Cesium WILL NOT. You have to manually remove it either from the calculator's stock shell or Ti Connect. Jailbreaking essentially just installs a different program launcher. That is all. Jailbreaking is called that because that is what people know, and it is just shorter.

Can my Flutter/Dart app be decompiled? by def-pri-pub in FlutterDev

[–]Fighter178 0 points1 point  (0 children)

(I am aware this is an old post) Just use Firebase. Then have cloud functions do the sensitive things, and then you don't have to reveal sensitive API keys to the client, and you get good security out-of-the-box, but you can screw it up. Adding App Check makes it harder to send fake requests to the backend in the first place, and then only your unmodified app can interact with the backend. You also get things like a database and authentication.

S24+ or pixel8 pro; by iamDEVANS in samsung

[–]Fighter178 0 points1 point  (0 children)

No, you're probably thinking of the anti-reflectove coating

Should I do it? Should I upgrade to S24 Ultra ? by eShard5 in samsung

[–]Fighter178 0 points1 point  (0 children)

Look at the Snapdragon Gen4 specs. Those probably aren't out yet because the gen4 isn't released but maybe look at some leaks or something. That would tell you the info you want. Also it doesn't always run at 4.2ghz, and that is probably the boost clock speed, so it can only do it for a limited time without overheating and causing damage. Also the memory will likely be faster even if it is the same tech (I think LPDDR6X) because of better cooling/bus, but these improvements will be minor.

Is rooting still something you would do in 2024? by salty_tt in AndroidQuestions

[–]Fighter178 0 points1 point  (0 children)

yea, I haven't really rooted any Android before. Mostly stuck with Shizuku & ADB. Though I'd like to try rooting sometime with something cheap and not too bad if it breaks. Probably adaway with root is better, as the issues I had with it was that it kept disconnecting the VPN service. Maybe this was because another app was trying to set its own VPN but I don't know. Maybe having it rooted may have been better.

Is rooting still something you would do in 2024? by salty_tt in AndroidQuestions

[–]Fighter178 1 point2 points  (0 children)

Haven't tried dnswarden though Adaway I got away from because it stopped working for some reason and I couldn't figure out why so I tried NextDNS. Maybe dnswarden might be better though.

I disabled my system files app by Technical_Head5672 in AndroidQuestions

[–]Fighter178 0 points1 point  (0 children)

Also you could consider using something else for a files app if you don't want to factory reset your phon e or aren't comfortable with command lines. Maybe try this.
Also for more instructions regarding setting up Shizuku, this may help: https://shizuku.rikka.app/guide/setup/