[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 17463



File: 1468687055913.png (420.13 KB, 300x207, Screen-Shot-2014-05-20-at-4.51.48-PM-640x440.png)

No.17463

Lainons, how do I get into Reverse Engineering? Best book suggestion?
What kind of CS background do I need?
I know some assembly and C. The drive behind this all is that I want to get more into Assembly, figuring out what does what is fun.

  No.17466

Also interested in this subject.

A month ago I tried to reverse engineer the network protocol of an Android game. I downloaded some proxy/VPN apps that would capture all network traffic of the game.

Sadly, only one of the tools could actually perform a MITM attack to decrypt the game communications, and it couldn't export the data in a format that wireshark could read so I wasn't able to do any serious analysis on it.

I almost started a packet capture tool project but decided it was too much effort.

  No.17469

There are a few books like

>Secrets of Reverse Engineering

Published by Wiley. It deals with windows binaries because, as they say, linux stuff has the source code for all to see
>Practical Malware analysis
Published by No Starch. Looks good
>Hacking, the art of exploitation
I suggest this one because it has a lot of relevant information
>Reverse Engineering for beginners
Probably the best book out there, free and almost encyclopedic
>Practical Packet Analysis
Network-oriented. It's meaningful because of the above post

At the end of the day, the best way to go about it is to
>Write something in C
>Assemble it/compile it
>look at the resulting instructions, try to figure out what parts of your code are being translated to what
>change the program a bit
And so on...

You also need to know how the stack AND the heap (as done by malloc()) operate.
Oh and get comfortable with gdb

That's about all I can tell you... Oh yeah:
https://microcorruption.com

  No.17481

File: 1468794647380.png (168.95 KB, 200x184, 1468280470726.png)

I've used the Lena tutorials, but it was many years ago. If it's just for learning assembly: grab your CPU's instruction reference and your favourite debugger or disassembler, go on crackmes.de, download some easy crackmes, play around with them and try not to get too frustrated.

  No.17482

>>17466
I'm pretty sure you could have just put wireshark on your router.

  No.17484

>re thread
What are you working on?
I thought I'd test my skills by cracking a simple program, so I chose winrar because it seemed easy.

Even though I was done with a crack within 2 hours, I still can't seem to get a keygen for it. almost wasted a week and honestly feel stupid now..

How does scene do it the same day a program gets released?

  No.17489

>>17484
They use fancy disassemblers/partial decompilers. Plus many of them are very experienced.

  No.17492

>>17484
Most businesses don't write their own protection but buy finished solutions from companies specialized in it. If you manage to crack a software protected like this, other software using the same solution will be much easier to crack. You can even automate a great deal of it, sometimes even the whole process.

  No.17495

>>17492
The irony.
Because the company that provides the protection service probably automates it. Charges a shitload to the client for just running a script on it and at the end of the day the protection scheme is completely useless

  No.17513

>>17481
I'm starting on the crackmes.de right now. thanks, this is great. Any reading up I can do that you would recommend?

  No.17521

>>17513
If it's just for assembly and having fun, I don't think you need any special material. Maybe some write-ups on how others solve crackmes using the tools that you use.

  No.17610

Anyone here uses radare2 for RE tasks? I'm curious if lainchan knows (and uses) that tool.

  No.17668

Can someone please offer help. I really want to get into cracking. I did one really easy crackmes.de but all it was was the password in a dissassembler. Even the very easy ones with keygens kill me. I don't know what I'm doing.

  No.17669

>>17668
Same guy here, I found this http://web.textfiles.com/software/howtocrk.txt in case anyone else wanted to start.

  No.17678

>>17668
It's a bit dated and you will need flash to follow it, but Lena's tutorial will teach you the basics:
https://tuts4you.com/download.php?view.2876

  No.17683

>>17669
rar is password protected

  No.17684

>>17683
Sorry about that, "tuts4you" is the password.

  No.18042

I'd recommend IDA + Hexrays as debugger/decompiler as well for C/C++ based binaries. Decompiling is quite nice since you qave a quick wide view of what a subroutine is doing more or less. Of course it isn't really decompiling but it just translates the assembly to pseudo C language.

  No.18045

Reverse Engineering for Beginners by Dennis Yurichev

  No.18051

What you need is practice bro. Do some crackmes.

  No.18068

File: 1471629340272.png (36.94 KB, 200x158, 400735f39d3234411e39d7c358a270bf.jpg)

I'm interested in reverse engineering myself, but I am more interested in doing it for anti-virus purposes and to study program flow.

I'm thinking of making a program that decompiles another program. Anyone else have experience or interest in this?

  No.18070

>>18045
That book was subpar.

I already had suitable knowledge of the topic, so take this advice with a grain of salt, but I wouldn't recommend it to anyone.

  No.18072

>>18051
We should pic a crack me and do it as a collab together. Could be a fun project over IRC.

  No.18653

What's the usefulness of reverse engineering?

  No.18757

Does anyone have any tips for unlocking the Intel ME? Is there a way to read the flash too so I could maybe try and reverse it?



  No.19213

Ctfs are good for this also

  No.19241

>>18045
Add the link, you schmock.
https://beginners.re/

  No.19324

>>18757
flashes are signed, so there's not much you can do unless you find a vulnerability in the RTOS or get the private key somehow.

  No.20902

File: 1482095362101.png (322.36 KB, 200x143, stupid.png)

Can somebody help me out with disassembling a dll? I'm still fairly new to this stuff, I've managed to pull the raw data off Arkdasm, but that's probably the most user unfriendly program I've used in a decade and searching in it seems to be impossible. I've tried x64dbg next and it's quite swell for the most part, but it only loads the dll as a database file, afterwards opens DLLLoader64_F466.exe/ntdll.dll instead and I have no idea how to access the original file.

Database file: C:\stuff\x64dbg\release\x64\db\rdx64.dll.dd64
Process Started: 000000013FF70000 C:\DLLLoader64_F466.exe
DLL Loaded: 0000000077350000 C:\Windows\System32\ntdll.dll

from the logs. Neither the website, nor manual nor Google seem to provide more insight here. Any ideas on how do I open rdx64.dll?

  No.20906

figure it our based on this post
WAHAHAHA!

  No.20920

>>20902
Use Dependency Walker, it will show internal calls and structure of the library

  No.20926

File: 1482176599068.png (67.34 KB, 200x200, 1461273689345.jpg)

Does anyone have some suggestion on how to find potential bugs in a program? (also called bug hunting).
You know, some book that explains the methodologies, tools (fuzzers and so on).
Thanks in advance

  No.20927

>>20926

I'd be curious too, I just use fuzzers and windbg but I'm not exactly proficient.

  No.20935

>>20926
Type checking of input/response is a most common bug. If any program asks for some information, it always worth checking what will happen if you feed it: ascii, unicode chars, digits, literals, long string, very long strings and very long numbers and so forth. Same with network response - bugs occur when there is no server-side check implemented.

  No.21341

>really want to get into reverse engineering
>download tools / books / misc.
>start working on it hardcore for a day
>never do it again
>it's now 3 months later and have done nothing
Anyone else have this problem? I do it with everything

  No.21342

>>21341
You'll get over it eventually and go through a burst of activity again.

  No.21343

Is it possible to get a job with reverse engineering skills, so to say?

  No.21344

>>20926
20935 basically laid it down.
Long strings and exotic characters have led to many successful independent finds.
Getting the balance between static and dynamic analysis can't be stressed enough.
As for books, you need to be more specific as to what area.
One would assume binary exploitation and potentially hw hacking based on OP, or maybe attacking web apps is what you prefer?

  No.21356

Pirated IDA 6.95 when? This is taking too long...

  No.21357

>>17610
I use a mix of radare2, IDA and Olly.

>>21343
Yes, but then you would have to work for an anti-virus company and they are all dying.

  No.21363

>>21356
You want someone to crack a cracking tool for you to crack software?
How about you crack it yourself?

  No.21366

>>21363
I would if I had the binary...

  No.21376

I started to learn RE last month. What i do is:

>Write some code in C.

>Dissamble it.
>Repeat.

The idea is get to know the instructions, the disassembler/debugger (i use radare2), detect patterns like a for loop or a switch/case, etc.

Once i was confident enough, i started debugging crackme's and transcribing the assembly to C code.

I'm really interested in RE IoT firmwares.

  No.21377

File: 1484261393734.png (225.26 KB, 134x200, 1482313507528.jpg)

Should I know a programming language before I start to learn to crack programs?

  No.21378

>>20935
Can confirm from writing simple stuff in C. This is especially true for huge programs or stuff written by beginners/Indians: in my case, I found when writing a simple console calculator that my program fell apart when you fed it, say, a string instead of a decimal float.

  No.21379

>>21357
Writing malware/blackhatting is generally very lucrative, and it's not going away. If you want to stay legal, bug reports for major softwares distributors can net some decent cash as well.

  No.21380

>>21377

Absolutely...

At the very least you'll need to learn x86 or another assembly language and a general purpose language probably C. Reversing and cracking is like transcribing Mandarin into Cantonese, or the other way around you're kinda fuarrrked if you don't know how to speak either.

Alternatively if you're looking to crack physical devices you might only need a really good electronics background, but the higher level you go you'll need to learn something like verilog, C, or a bunch of exotic assemblers along the way.

  No.21381

>>21377
I think you should know several of them - cracking programs mostly involves relying on human mistakes made by programmers who do not understand the compiler in such SICK detail as you do. Unless you're a person who learned to read assembly the same time as the alphabet, you'll need to know your way around; and even assembly

  No.21383

>>21377
My advice is start with assembly and then learn C. This way you start hands on with the machine and then learn how high level programs (often they're written in C or something that translates to C) relate to those machine level instructions.

  No.21402

>>21383
or learn both at the same time, http://gcc.godbolt.org/ is especially nice for it.

  No.21405

>>21402
I didn't know of this. Thanks!