[ cyb / tech / λ / layer ] [ zzz / drg / lit / diy / art ] [ w / rpg / r ] [ q ] [ / ] [ popular / ???? / rules / radio / $$ / news ] [ volafile / uboa / sushi / LainTV / lewd ]

λ - programming

/lam/bda /lam/bda duck
Name
Email
Subject
Comment
File
Password (For file deletion.)

BUY LAINCHAN STICKERS HERE

STREAM » LainTV « STREAM

[Return][Go to bottom]

 No.9455

I've started learning about reverse engineering, and I thought it would be a interesting to create a thread about it.

Currently I'm reading Grey Hat Python, which is pretty neat. It teaches you how debuggers work, and works you though creating your own.

Also, to any mods reading. I don't know what the proper board for this would be (I think /cyb/ works). So feel free to move this if you want.
>>

 No.9456

Is that Intel syntax, or did you just make your own for the project?

>>

 No.9457

>>9456
I didn't have any reverse engineering Pictures, so I just used a generic Immunity Debugger picture.

Here's my current setup. I'm still programming the debugger. I'm actually having trouble with the one part.

>>

 No.9458

>>9457
I just found out that my problem is because I'm using a 64 bit OS, while the book assumes a 32 bit OS. Why is it that every book I find does this?

>>

 No.9459

>>9458
With this in mind, can I ask anyone who may know a question? Is it worth learning to reverse engineer 32-bit? I'm afraid that if I set up 32-bit virtual machine to continue learning, everything will end up being outdated. So, is it worth it, or should I just look for stuff on 64-bit?

>>

 No.9460

>>9459
It won't matter. The register and instruction names will just be slightly different because now everything is a little bigger. You can even still use the old code. The registers and instructions aren't really renamed. There's just a new set.

>>

 No.9461

>>9459
Modern x86 is backwards compatible with the iterations from 30 years ago.
You're fine. I 64-bit x86 processor doesn't add too much.

>>

 No.9462

https://microcorruption.com/login

Not x86, but indispensable knowledge nonetheless.


http://tdhack.com/

Create an account and tear through the software challenges.

>>

 No.9463

I was thinking about starting a thread about this; glad I found this one.
Recently, I've been spending a lot of my time learning about reverse engineering as it pertains to malware analysis (also been studying memory forensics - kind of related). I just finished going through a great book, Practical Malware Analysis, that provides you with "live" malware samples (either they were handmade for the labs in the book or taken from the wild and modified to be non-malicious) and teaches you how to reverse engineer them. I would highly recommend it to anyone interested in reverse engineering, even if malware isn't your main interest; It still taught me a lot about reverse engineering in general. The chapters include topics on: Various methods of static/dynamic analysis, disassembling with IDA Pro, debugging with OllyDbg, kernel debugging with WinDbg, simple data encryption, and anti-reverse engineering techniques. The book is easy to pick up for someone who has little to no experience as well, even if you've never seen assembly before.

For the question about 32-bit vs 64-bit, there's a chapter specifically on differences with 64-bit malware. If anything, read through that chapter to get your answer (it's not specific to malware; They go through the differences in registers, calling conventions, addressing, etc.).

>>

 No.9464

I found some neat reverse engineering blogs

http://randywestergren.com

http://blog.malwaremustdie.org/

> Semper legerent "Salve Regina" ante venatione malware

>>

 No.9465

is it hard to learn?

>>

 No.9466

I started doing the riddle in this site not long ago, though I didn't follow up because the third one is about finding an easter egg in Internet Explorer. But they are fun and maybe someone will want to try them out. It's not exactly reverse engineering but it is inspired on that...
http://3564020356.org

>>

 No.9467

The only way in to http://skullcode.com is a bit of reverse engineering.

It's certainly not worth figuring out the weird architecture just to deal with what that community thinks is "all in good fun" (hacking each other's VM code to bits), unless you seriously enjoy reverse engineering...

>>

 No.9468

>>9467
How do you get started with skullcode?

I expected some kind of explanation, but are you really just dropped into the memory editor of a system that is accepting your exploration as input the entire time, with no help whatsoever?

>>

 No.9469

>>9468
Well, sort of.

The beginner will find a hook to execute whatever code they like. Zero the byte at address 6666h. The jump address is already filled, and demonstrates that the machine is little endian. The next hint is usually another address. After demonstrating a few incremental reverse engineering feats the self modifying code may do just that...

The intermediary reverse engineer will probably think outside of the presented box. After jumping through a series of hoops in a different direction they'll discover a sort of "map" to potentially secure a mid level login.

Some skilled hackers think the skullcode landing page is too full of holes begging to be filled with exploits, but I disagree. Determined hackers can apparently get root if they're interested enough, but they attract attention from other pranksters so only the dedicated say root for long.

The lack of documentation is probably because the entry site has moved a few times in the past and the landing page architecture changes periodically making documented entry methods less than helpful. In fact, the underlying code changed last week, but the bytecode didn't. Internally, one's programs can specify which VM to use so as not to require recompilation.

Personally, I like skullcode for its persistent "stickyness". It's not an ephemeral completion like nearly every vuln group. The exploits developed therein don't have security ramifications for the real world so there's no ethical pressure to publish exploits, and there's no ready made library of exploits to deploy (see: Metasploit, which allows point and click skiddie tier cracking, and makes lots of CTFs unfun). There's a certain 16-bit era charm to skullcode, nowadays the security landscape is much different. The down side is there's not much help to be found on the external web. There's been talk of changing that, but this may fracture (or destroy) the community.

If you're looking for something welcoming, more mainstream, less challenging, and for popular chipsets with tons of documentation, that niche has already been filled to the brim by any of the existing security CTF (Capture The Flag) competitions.
https://www.vulnhub.com/
https://blog.whitehatsec.com/capture-all-the-flags/
I'm sure you'll find more with a bit of search-fu. There's even some CTF sub reddits: r/OpenToAllCTFteam/ r/securityctf

Happy Hacking!

>>

 No.9470

>>9455
>Also, to any mods reading. I don't know what the proper board for this would be (I think /cyb/ works). So feel free to move this if you want.
It's at the end of the /cyb/ board now, so I'm going to move this to /λ/ like I should have by now.

There was a flaw in the thread-moving system and the images didn't survive.

>>

 No.11049

I'm currently drudging through this:
http://beginners.re/

I haven't seen much I don't already know, but I'm keeping up with it. I think it will get better.

It's a shame x86 is the most popular instruction set for these things. MIPS is so much nicer.



Delete Post [ ]
[ cyb / tech / λ / layer ] [ zzz / drg / lit / diy / art ] [ w / rpg / r ] [ q ] [ / ] [ popular / ???? / rules / radio / $$ / news ] [ volafile / uboa / sushi / LainTV / lewd ]