Results 1 to 10 of 10

Thread: Questions: Reverse Engineers of RCE

  1. #1

    Question Questions: Reverse Engineers of RCE

    Hi all,

    I am currently a student (actually just finished highschool ) and I was wondering how you guys managed to become 'pro's' at reverse engineering.
    I too want to be able to reverse engineer programs.I have managed to successfully reverse engineer programs that require simple dongle checks or registration checks, but I feel as if I do not understand fully what is actually going on.

    So my question(s) are.....

    1. When did you start cracking?
    2. Did you have previous knowledge in other programming languages ( if so, what were they? And did it help?)
    3. Did you start off with simple programs or the advanced stuff?
    4. How did you guys get good at reading assembly?
    5. Finally, are there any resources or tips that you would recommend to a beginner? If so what would they be?




    Many thanks!
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2
    Alright!

    Here goes...

    1. When did you start cracking? - (When I opened my eyes. My first words were not Mama or Papa. They were IDA PRO and ICE) -- just kidding. I began when I was around 26.

    2. Did you have previous knowledge in other programming languages ( if so, what were they? And did it help?) - C and FORTRAN. Helped, well, not really. Or didn't you hear - "writing" a program and "reading" a program are two different skills.

    3. Did you start off with simple programs or the advanced stuff? - Started with ORC's tuts, Win95, SoftICE, W32dasm and worked the way up.

    4. How did you guys get good at reading assembly? - Habit.

    5. Finally, are there any resources or tips that you would recommend to a beginner? If so what would they be? - Two pro tips: a) Start with the historically "older" stuff, work up to "newer" stuff as you get experience and b) Understand how to work your "tools" blindfolded, and ensure you cover their entire "surface area of capabilities" "before" you begin even "thinking" of hitting the apps.

    Finally, a tip that will help you break impossibles at higher levels in the far future... "Just because something is, doesn't mean it should be."

    Have Phun
    Last edited by Aimless; December 9th, 2015 at 09:40.
    Blame Microsoft, get l337 !!

  3. #3
    Howdy,



    1. When did you start cracking. Shit, 97/98 for programs. I think I was born a reality cracka.
    2. Did you have previous knowledge in other programming languages ( if so, what were they? And did it help?)I had none at all. My biggest mistake was not keeping up with all the changes. The languages evolved and I did not.
    3. Did you start off with simple programs or the advanced stuff? Simple, simple, simple. Always remember KISS, Keep It Simple Stupid. Once you have somewhat mastered what you are currently on, then move to the next. A great tip above, learn one tool inside and out before you start with others. Same for languages.
    4. How did you guys get good at reading assembly? You have to keep current with the latest stuff to STAY good. You cant get good without the basics. Read all you can and see it in the code. Once you have seen enough it will become almost second nature. Until they change it.
    5. Finally, are there any resources or tips that you would recommend to a beginner? If so what would they be? Master the tools while you work with tuts. Dont just follow the tut, understand what the programmer was trying to do when it was written. Once you start to see code schemes and stunts to obfuscate, and see them with very little effort, perhaps you will be ready.
    Learn Or Die.

  4. #4
    It is always great to hear from the professionals.
    I am currently writing programs in c++ and then viewing the assembly. However I just struggle to wrap my head around assembly code.

    Also bypassing the the anti-debugging techniques are a pain!

    Did the programs during the 90s just use simple checks for authentication or where they quite sophisticated.e.g encryption,anti-debugging?

    Also Woodmann how did you manage to get pass anti-debugging techniques without writing code?
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  5. #5
    Currently I have no idea how to get past a certain programs anti-debugging techniques even though I can see they are being called for e.g DbgBreakPoinUI and may more.
    Is there any good TestMe programs that have anti-debugging techniques you need to bypass?
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  6. #6
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,456
    Blog Entries
    15
    anti debugging is twin of debugging both were born at the same time live their life opposing each other and will never die
    to write code you don't need to reverse engineer (all the bloatware belong to this category)
    to reverse engineer you don't have to write code they are mutually exclusive skills
    (all the cracks and keygens in kilobyte footprint for a terabyte software belong to this category)

    look for peter ferries anti_debugging_tricks in that pdf he collated and published a concise explanation for
    a lot of the tricks employed by whitehat / grayhat / blackhat players in the field

    as to programs there are a lot and lot of them point your browser / wget to crackmes.de for a start and look at level 1 easy crackmes
    also nowadays a lot of ctf (capture the flag are written and some very good analysis of the contest are published by the organizers get them and read them
    most of the time anti-debugging tricks tend to be camouflaging a tree in the jungle

    and last but not least if you know how to reverse engineer you tend to write better code
    and if you understand how to code better you tend to write software that is harder to reverse engineer

    as to your original questions
    circumstances /anger /frusturation at under performance of high priced bloatware induces cracking the shit out of it
    i was dragged into cracking a statistical software that took 10 minutes to take input and print a process capability index graph ( cp / cpk > 1.33)
    the software costed a huge amount during circa late 90's the firm had one legitimate purchase and the shit printed about 20 30 graphs at the most the audit was just around the corner the ENGINEER the CREW the SELLER all were clueless and were lying i could calculate better with lotus 123 and print better in dot-matrix printer it had a small matchbox sized container with several needles struck in the back of the pc and thus i inherited the legacy of cracking and in two straight day night session hundreds probably thousands of graphs were printed with fake/ doctored inputs that all said all our pathetic processes had a capability index > 1.33 and the rest as they say is history

    prior to this skirmish i hadn't written a single line of code unless you think writing a few lotus 123 macros means programming

    as to reading assembly it is a byproduct of staring over debuggers / disassemblers / hexeditors / notepad / wordpad / display of gibberish worms squiggling around after viewing them for so long you tend to separate centipedes from millipedes unconsciously

    destinations never change their places ways do change

    learn to navigate equally well in debug.com or windbg , sourcer or ida , trw or ollydbg , hiew or hxd , perl or powershell
    they all lead you to destination though each travels through different paths

  7. #7
    son of Bungo & Belladonna bilbo's Avatar
    Join Date
    Mar 2004
    Location
    Rivendell
    Posts
    310
    look for peter ferries anti_debugging_tricks
    Thanks to you, I discovered his site - unfortunately not updated anymore:
    http://pferrie.host22.com

    A lot of serious info from a Microsoft researcher...

    Best regards
    bilbo

    P.S: just a little advice to qd0097: do not ask too much to people, you should be like a pioneer, who discovers himself the road; you should be unconventional, without following the well-thinking or experienced people; you should be crazy, and trust that the impossible can happen...
    IMHO, your method ("I am currently writing programs in c++ and then viewing the assembly") is the best.
    Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt.[Seneca, Epistulae Morales 104, 26]

  8. #8
    Thanks Blabberer, appreciate the detailed advice, and thanks for the links!

    Also thanks for the advice bilbo! I'll take it on board.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  9. #9
    Quote Originally Posted by blabberer View Post
    learn to navigate equally well in debug.com or windbg , sourcer or ida , trw or ollydbg , hiew or hxd , perl or powershell
    Most importantly...softice...in XP.

    Thanks for link to the Ferrie pdf Blabs.

  10. #10
    Quote Originally Posted by bilbo View Post
    P.S: just a little advice to qd0097: do not ask too much to people, you should be like a pioneer, who discovers himself the road; you should be unconventional, without following the well-thinking or experienced people; you should be crazy, and trust that the impossible can happen...
    Good advice Bilbo.

    I realize this thread is getting old but I haven't been around for a bit and thought I'd throw in my two-bits worth.

    Speaking of crazy, I enjoyed breaking at the entry point of an app and single-stepping right through to the Windows entry point and beyond, taking notes as I traced. When you do it a couple of times you get used to the functions you can jump over and which functions do what. Before the Windows entry point there is a lot of initialization going on.

    Many people would find single-stepping overly tedious but if you persist, and take notes with addresses, you learn how to extract yourself from nested calls by using the stack. If you get lost, you can terminate the app and start again, this time setting a breakpoint where you got lost and jumping straight to it from the entry point.

    After the Windows entry point, which leads into a big loop, you can watch the windows being formed into structures then later they appear on the screen behind a debugger like softice. Many apps used to put up a small screen before the main window that was helpful in finding serials.

    When you get used to what should be there, when protection code shows up, it is often really obvious. An instruction seems out of place and you get suspicious. Some protections use assembly instructions that look totally out of place. You can see which ones by ready through the Ferrie pdf that Blabberer mention.
    Last edited by WaxfordSqueers; October 20th, 2016 at 20:03.

Similar Threads

  1. Compiler Optimizations for Reverse Engineers
    By OpenRCE_RolfRolles in forum Blogs Forum
    Replies: 0
    Last Post: March 8th, 2010, 17:17
  2. Replies: 3
    Last Post: January 29th, 2010, 21:18
  3. 2 Questions
    By DaBookshah in forum The Newbie Forum
    Replies: 5
    Last Post: November 2nd, 2006, 09:06
  4. Some DRx Questions
    By Lenus in forum The Newbie Forum
    Replies: 2
    Last Post: December 28th, 2004, 18:11
  5. RegOrganizer 1.3B4: Questions and More Questions (sv / +spl/\j guru!)
    By foxthree in forum Malware Analysis and Unpacking Forum
    Replies: 17
    Last Post: March 9th, 2002, 06:43

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •