Flag: Tornado!
Hurricane!
|
|
Topic created on: March 5, 2008 07:08 CST by RemotePush  .
Greetings,
This is my first post, so i thought I would include a little background. I am a Computer Science graduate living in the UK who is currently working as a Pen Tester, which I really enjoy. I have a small amount of RCE experience from years back and want to get back into the field.
I have recently become interested in the idea of vulnerability research and reverse engineering as a career progression. This has left me with some questions I am hoping some kind folks may be able to answer.
How do you go about getting commercial experience of RCE? By this I mean experience empolyers are looking for.
Does anyone know of any UK specific companies that provide RCE services?
Any other general advice about where to start would also be appreciated. I am aware of a previous post by Remc (https://www.openrce.org/forums/posts/276) with some useful information if anyone else is interested in this post.
Regards,
Remote
Here's the problem with RCE and honestly most things akin to it in nature: It is difficult to get the job without experience and it is difficult to get the experience without the job.
But, RCE is moderately different in many respects, there is a free version of IDA Pro, while moderately crippled it will still suffice. Ollydbg is freely available, thus nothing is stopping you from using it or Immunity Debugger. Gather up as many tools as you can (legitimately is generally the best way, lest you have to explain yourself) and start working on the reverse engineering and cracking challenges that are routinely posted here and in other forums. Read everything you can get your hands and eyes on.
Once you have a true baseline understanding of the tools and you can demonstrate that in some capacity (interviewers, including myself are prone to asking pointed questions if you state you know a given tool) then have a go at a "junior-ish" position. There are numerous security companies in Europe proper and I believe several in London.
Bottom line, start now and learn. The vast majority of RCE is genuinely learning - absolutely no way anyone can know everything on the subject as it is entirely too dynamic. Your best bet is to train yourself to learn efficiently and effectively (these two traits are cornerstones of any successful person regardless of what career they choose).
Good luck.
|
I agree with what aeppert said, but I would like to add a little bit. Understanding that RCE typically deals with compiler generated machine code, one needs to have a firm concept of what goes into a compiler in order to understand what comes out of a compiler.
Basically, if you don't have a base understanding of C, you need to get to that point. I would recommend Ivor Horton's "Beginning C." (http://books.google.com/books?id=Nfh5-L3NBTQC) For some odd reason, the google preview of the book, contains the entire book.
The next steps would be to disassemble your own code to see how it works.
gcc -Wall -g hello_world.c -o hello_world.exe
#include <stdio.h>
int main(void)
{
puts("hello world\n");
return 0;
}
objdump -S -l -Mintel hello_world.exe
004012f0 <_main>:
main():
C:/Users/b0ne/Desktop/hello_world.c:4
#include <stdio.h>
int main(void)
{
4012f0: 55 push ebp
4012f1: 89 e5 mov ebp,esp
4012f3: 83 ec 08 sub esp,0x8
4012f6: 83 e4 f0 and esp,0xfffffff0
4012f9: b8 00 00 00 00 mov eax,0x0
4012fe: 83 c0 0f add eax,0xf
401301: 83 c0 0f add eax,0xf
401304: c1 e8 04 shr eax,0x4
401307: c1 e0 04 shl eax,0x4
40130a: 89 45 fc mov DWORD PTR [ebp-4],eax
40130d: 8b 45 fc mov eax,DWORD PTR [ebp-4]
401310: e8 2b 05 00 00 call 401840 <___chkstk>
401315: e8 a6 00 00 00 call 4013c0 <___main>
C:/Users/b0ne/Desktop/hello_world.c:5
puts("hello world\n");
40131a: c7 04 24 00 30 40 00 mov DWORD PTR [esp],0x403000
401321: e8 ba 05 00 00 call 4018e0 <_puts>
C:/Users/b0ne/Desktop/hello_world.c:6
return 0;
401326: b8 00 00 00 00 mov eax,0x0
C:/Users/b0ne/Desktop/hello_world.c:7
}
40132b: c9 leave
40132c: c3 ret
You can use the visual c++ toolchain to generate debugging symbols for your compiled code and use visual studio/windbg to do source/asm debugging and see similar output to the above.
|
I somewhat disagree with Aaron's comment that "it is difficult to get the experience without the job", because I know plenty of skilled people who don't work in the profession, as well as plenty who had their skills before getting their jobs. The best reverse engineer that I know does not do it professionally, and will likely never do so. That said, Aaron is correct in that having a job in the industry affords you the time and the projects to build your skillset, a luxury you may not have if you have an otherwise busy life.
I was tempted to say "a better statement might be that it is difficult to get the experience without participating in reverse engineering regularly", until I thought twice, looked up the definition of the word "experience" and realized that was a tautology: experience is defined as "knowledge gained through direct participation" (without reference to employment). So the answer to "how do I get the experience that employers are looking for" is "just do it".*
Regarding getting a job, if you publish detailed work and are an active-enough participant in the community, the "how do I get a job" question is no longer an issue -- they will come to you, or will be receptive to your inquries. Also, cronyism never fails, so try to make more friends than enemies (or if you can't manage to do that, at least make enough friends).
* Some advice on "just doing it":
Try to accomplish something, fail, try again but harder, or try a different approach or tool. Perhaps take a copy of an advisory and the vulnerable software and locate the bug, and/or read a tutorial and follow along with it. Pick up a piece of malware and analyze it, or teach yourself manual unpacking. Experiment with different reverse engineering styles, e.g. dynamic analysis vs. static analysis. Find a few mentors -- OpenRCE has an IRC channel on FreeNode with bright people in it who might be willing to help you out (there are other IRC channels too). Discuss reverse engineering with others (IRC/IM is again useful here). Read everything you can that's at or above your skill level (I've recently realized that I have been neglecting this aspect, and need to get off my ass regarding things like hypervisors), skim things below your skill level (there might be some good tips in there). Picture everything I just said occurring as part of a montage. Over time you will develop your own unique style and figure out which techniques are fast or reliable.
|
i think anyperson have enough RE skills will have a good job too.
i also hope the ones having perfect RE skills would like to share their experence and/or give some advisory suggestion to others.
to me,as a newbie for RE i like it very much. although i have learnt some asm and c/c++ programming language,i find it's not enough to do some RE work.
so,i wish to learn more about RE here.thnx.
regards
|
Thank you for your replies.
Aeppert, I agree I will need to read and learn a lot, unfortunatly with a full time job and a busy social life it is not always easy to find the time.
b0ne, thankfully i have a faily good grounding in C and have at least a basic understanding of ASM.
RolfRolles, you make it sound so easy :) I really like the idea of identifying and reproducing a vulnerability from an advisory, this is something i will definatly try.
If anyone else has any nuggets of wisdom they would like to share it would be appreciated. Thank you all for your input.
Remote
|
|
If you are not familiar with asm, then try some simple crackmes from crackmes.de, it's a good place to start.
|
Given you are a Computer Science graduate you likely know or should know (realizing that coursework varies like the utter wind everywhere) C in some capacity. You should have a fundamental understanding of operating systems (at least from the academic standpoint) and likely a rudimentary understanding of hardware (you do know what a register is?) - then you have a fairly solid basis for learning the "rest."
Absolute fundamental requirements, in my experience, for someone embarking on RCE as far as fundamental school work is concerned:
1) Data Structures
2) Operating Systems
3) Introduction to Logic Design (has an infinite number of names)
4) Computer Architecture
5) Discrete Math
6) Linear Algebra
7) Programming Language Concepts (again, infinite number of different names for the same idea)
Now, with that said, I know an unbelievably skilled RE individual who happens to be an amazing programmer that has a degree in English. So, what it boils down to is exactly what Rolf stated: "just doing it." Some folks have the aptitude to learn RCE and some do not and it is absolutely not a reflection of intelligence or lack there of. It is a skill like any other (not everyone can hit a golf ball 300yards, some can without a problem.)
Lastly, I do not recommend going into RCE for money alone. Yes, like any advanced skillset it can pay well, but unless you truly like it, the tasks become repetitive and nit picky at best, painful and self-abusive at the worst. Plus, in my experience burnout is an epic problem - it can get very old taking something apart day in and day out and if you enjoy creating versus disassembling it can become disheartening after awhile.
Not sure how much wisdom that imparts, but it certainly filled up the screen. I have been doing this stuff for a long while and have helped train a lot of folks and went through the process myself. I would say the overwhelming "success rate" (which I would define as those who continued doing this type of work and enjoying it) at around 1 in 15 at the most.
|
|
That's why game hacking is pretty fun. The targets are not very complex for the most part, and you get to do both disassembling and creating =)
|
btw, reversing of jvm or mscil code is very far from hardware and OS internals, you just have to know virtual machine architecture and op-code, this is all. jvm is very popular, mscil is going to be popular in the next few years, so...
disassembling native machine code is more complicate thing of course, especially if we're talking about the whole set: x86, x86-64, windows PEs, unix ELFs, kernel APIs/SYS-calls, libraries, packers, anti-reversing tricks, etc. to learn all this stuff you have to spend days and nights inside debuggers and disablers, "smoking" manuals and specifications and you have to compete against other reversers (who have spent their last five-six-eight-ten- years in this stuff) in trade, since they reverse code faster than you and agree to work for fewer money.
how to find a good job? well, it's easy. everyone in commuter industry wants something. someone wants to steal binary code, someone wants to understand how to interact with a closed-source program, someone wants to find their own bug, having only memory dump and knowing nothing about assembler, someone wants to reverse suspicious code to be sure if it's malware or not (or, well, it might be ad-ware or spy-ware).
I was into RE for years (about 10, maybe even more) and I'd never been out of business, work goes on and on, this will never end. I don't know much about US and UK, I prefer to work with Europe and Asia (mostly due to laws, I'm not a lawyer, but seems RE is illegal in US/UK and OK in Europe and Asia, however, I'm not sure about it).
the people who can reverse non-x86 code are very valuable (for example, who knows how ARM code looks like :-)
so, if you're interesting in RE - you have a future, no doubts!
|
I'm both a scripter (for a bank) and a reverser, so it's an interesting dichotomy. I reverse under the premise that "if you can't open it, you don't own it". It's about making my computer *my* tool, and not the tool of a bunch of companies.
I wrote a script that reversed everything on my home system from the hardware up, and helped me to strip out obfuscation code. As a result, everything on my system is significantly faster and smaller.
I've thusfar refused to release the script though because of concern about the reaction to it, but the trick is to follow EIP, and record the instruction there in a control-flow-tree structure. Add nodes when EIP goes somewhere it hasn't been. Note addresses that are data accessed. At the end, you reduce the flow-tree, and then dump it. The cool thing is that with your mnemonic/opcode table, you can dump the tree to either source or directly back to machine code.
Do that, and you'll figure out what else needs to be done rather quickly.
|
Does anybody here have experience with vulnerability bounty programs, like the Zero Day Initiative? I'm self educated and taking it upon myself to become capable of finding vulnerabilities, but that only works as a job if I can get paid for them.
I would think that, even if the pay per flaw wasn't as good, it would give credibility to a pen testing company. But, I have no experience in the field yet.
|
Note: Registration is required to post to the forums.
|
|
|
|
There are 31,328 total registered users.
|
|
![[+] expand](/imagery/files/soysauce_blueprint.gif){kind=link}