RLost catgirl. Full-stack hacker.
Formerly infosec, professionally. Recovering from deep burnout.
Sometimes refers to ourselves in plural form.
🏳️⚧️
🏳️🌈
Chuuni rights!
♫ Wake up, leave your hesitation ♫
ABC (American-born Chinese) but not in America
RAlright, impulsive YOLO adventures have been a lot of fun, but we're now looking to get properly hired (UK, London)
Looking for anyone that could use a catgirl who's done a bit of everything.
Here's my CV: https://arcanenibble.github.io/cv.html
#fedihired
R@piku@blahaj.zone the very traditional security model for desktops (which predates personal computers! oldschool centralized unix systems also assume this) is that every program running as "you, the user" has equal access to stuff owned by "you, the user", but you might not have access to "the core system" unless you're an administrator
implications of this include the fact that programs can access files saved by other programs (they're your files, not "an app's" files), programs can capture the screen, programs can capture keyboard input, etc.
the problem with this is that nowadays everybody owns at least one computer. and computers can easily talk to each other. and people who don't know very much about computers can install software on their computer (since, well, it's their computer)
software including ransomware, spyware, etc.
mobile phones were intentionally pushed as a restricted/limited/simplified environment capable of bringing computing to everybody
this is why you now have files associated with "an app" (i.e one specific one), why apps struggle to share files between each other, why the idea of "files" at all is increasingly foreign
but installing, uninstalling, and migrating (by means of a megacorp-controlled Cloud™
️) is much easier
there's still mobile malware, but it's a very different landscape
R@piku@blahaj.zone tl;dr desktops have user isolation (except... what's a "user" on a personal computer?) whereas mobile operating systems have app isolation
Rtime to maybe run some unscientific polls:
if you see this and have at least 5 years of programming experience (any type, any environment, any software stack, etc.)
Have you written code requiring explicit memory management?
RHave you ever written assembly language?
Rtime to maybe run some unscientific polls:
if you see this and have at least 5 years of programming experience (any type, any environment, any software stack, etc.)
Have you written code requiring explicit memory management?
Roops, "how to pwn an nxt" blog post is slowly turning into "introduction to exploit development" more generally
are there any good community resources for this nowadays? or has this all been taken over by consultancies trying to sell you training?
what happened to the era of "person from a non-english-speaking country with a 'weak' currency makes a screen recording teaching you how to crack software"?
Rfirmware get!
Rit turns out that there's a """security vulnerability""" allowing for native ARM code execution on the NXT brick
definitely over USB, possibly over bluetooth as well?
of course, the NXT is intentionally hackable and designed to allow you to be able to modify the firmware (it even came with public schematics!), so this isn't actually a big deal
would anybody be interested in a writeup of this?
Rpwnage successful!
Rfirmware get!
Rtoday we have (unsuccessfully) woken up and chosen violence^W...
... to try and figure out how to dump the running firmware off of an NXT brick
it appears that this isn't supported using any standard tools ( https://bricks.stackexchange.com/q/16909 )
but we're good at reading between the lines, and there appears to be a trick we can do...
Rpwnage successful!
Rtoday we have (unsuccessfully) woken up and chosen violence^W...
... to try and figure out how to dump the running firmware off of an NXT brick
it appears that this isn't supported using any standard tools ( https://bricks.stackexchange.com/q/16909 )
but we're good at reading between the lines, and there appears to be a trick we can do...
Rhuh, reading the OHCI spec and we're finally starting to understand why "... and then there's isochronous" is a thing
while the packets aren't too different and many lower-end device controller IPs don't treat them that differently, apparently OHCI requires doing a whole Separate Thing for them
Rwhich frustrated hardware/driver engineer caused this paragraph to be added to the spec?
Rtime to deal with OHCI and the landscape that is "embedded"-compatible USB host stacks
hopefully we don't get Pybricks on EV3 "pwned" like so many other devices
Rhuh, reading the OHCI spec and we're finally starting to understand why "... and then there's isochronous" is a thing
while the packets aren't too different and many lower-end device controller IPs don't treat them that differently, apparently OHCI requires doing a whole Separate Thing for them