This is one of the biggest issues people don't realize. A react dev doing fully frontend stuff is usually paid more than a security guy. Management views this as the developer making a product and giving money. But with insurance no longer covering hacks like they used to, and with the absolute amount of ways into organizations, security people can literally save a company from millions of losses and possible collapse.
Are you trying to run your own business? Me, my friends, and all of my coworkers have to live in the shadows because recruiters hunt us. Like, my buddy posted on Indeed and not has 5 unsolicited phone calls and 12 emails a day.
If you really can't find work in this market, you should really try fixing your resume since you most likely aren't selling your skills or have a red flag. Some of my older coworkers only put their last 12 years experience, or don't list dates on them to avoid age discrimination at the resume filter stage.
I tried that. I already have an issue with people wanting to hire me on less senior roles than I'm used to functioning, with pretty poor results. hacking my resume in half only made that worse and only made me less attractive to the kinds of positions where they actually thought that background was a strength (the ones I really wanted)
I was recently looking for positions and it seems like most of these companies are hiring you as a filler until they get someone just as good. So you're 100 % right.
Without sounding controversial. Most promotions and good things at a job come from people skills rather than technical. And if you can get into the "Good old boys" club or just make friends, then you usually succeed. WFH doesn't really have those options, so not only does the company not want you to WFH, you also arn't making connections and relationships.
After hearing some horror stories from people who took the jump earlier in Covid, I decided against it, since it's exactly what you said. 100 % stagnation.
Although, the only people I have heard doing well are our sysadmins/IT friends. They are very asynchronous and can easily work 3 jobs with no conflicts and are doing very well.
If you're trying to enter the field I would highly suggest ARM. Mobile malware is the wild west and they really need analysts and hire a bunch of people with no experience out of college. X86/64 is alot harder to enter the field in since theres alot more saturation so the barrier to entry is higher.
Specifically my main gripe with this is the fact that X64 code changes alot of what this is assuming and can lead into ALOT of pitfalls. So make sure you read https://www.nasm.us/xdoc/2.15.05/html/nasmdo12.html (The x64 bit programming section) if you do follow this guide.
Had this issue with a coworker who uses a decade old version of Linux and refuses to install anything other than base packages cus it's "Stable". Well I made an in house tool, and it's not stable, since his glibc had a bug that's been fixed for a decade that made it so pthreads would break. Everytime I tried telling him it's his system before someone else found the bugfix, he would go "YOU JUST DON'T KNOW HOW TO WRITE MULTITHREADED CODE! MAKE IT SINGLETHREADED AND FIND THE BUG!"
You want to use C anyhow as you want to make sure you have control over the code that is output.
For example the following code you know what the assembly is going to be.
strcmp(char* a, char* b);
strcmp(str1,str2);
If you do the above as a template you can run into some weird issues that you may not be expecting. So while tedious, you would need to make your own wscmp. You also have to be very careful so that you don't pull in ANY libraries. Since your code needs to be 100 % independent and do the loading itself.
C++ exceptions are implemented at the OS level in windows. C++ exceptions using SEH, while there's also VEH and unhandled exceptions. You can easily use SEH for your shell code, it's just not documented well. But sadly you have to manually set this up by having something like
SetExceptionHandler(curAddr,Handler) // Where curaddr can be found by doing something like call $+5 so you remain position independent.
You do end with modules having the same address in every process if untampered though. This is due to Copy on Write windows implements internally with DLL's to save space. So while not guaranteed. On X64 you can be certain that because of COW the module will have the same address.
That's not true. You're not considering different virtual addresses backed by the same pages.
Yes, the loader will create file-backed memory mappings and not redundantly store read-only parts. However, it is free to load it at a different address in each process. This can happen via ASLR, or if the mapping is already claimed by the time the module loads.
They may get the same base address repeatedly in multiple processes and work most of the time, but it's not guaranteed.
It's extremely likely for stuff from Kernel32.dll.
> That's not true. You're not considering different virtual addresses backed by the same pages.
technically I suppose, but PEs don't tend to be relocatable, so if it mapped it in at different virtual addresses that would be extremely unlikely to be backed by the same pages as much of the just-mapped-in code would need relocs
Emulations is pretty much literally just mapping instructions between processors. So there may be an instruction in my custom chipset called "Add4", which adds 4 inputs. I would emulate ADD4 RAX, 0x1234, 0x2345, 0x3456 that by
It gets a bit more complicated with architecture differences like memory configurations. But that all emulation is.
When you're virtualizing, you pretty much just need to manage hardware. The hypervisor does this for you by managing which resources go to where. You could virtualize it by just running it like a program. But that's really painful and tedious, so you rely on the CPU to support it. Each chip has it's differences, but it's effectively just like a syscall. You have VMCALL and VMEXIT instructions. And then you have a handler in your vmexit table, which is exactly like a syscall table. So if(exitreason == CPUID_EXIT) cpuid_handler();
Maybe - but if you don't know what QWER is and I explain that "QWER is just like ASDF" but you don't know what ASDF is either, I haven't really clarified anything for you.
