Comments on: Functional languages and reverse engineering http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/ Embedded security, crypto, software protection Mon, 06 Feb 2012 20:16:28 +0000 hourly 1 http://wordpress.com/ By: bluffer http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/comment-page-1/#comment-1099 Tue, 01 May 2007 10:50:02 +0000 http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/#comment-1099 well there seems to be a few hood hatted buddhas lurking out there that were probably designed to analyse and make sense out of this bloat

buddha refuses to get enlightned sitting under my computer

hood needs some green and i refuse to install them

hat is 5 years old so its probably dirty as hell

declarative debuggers nice generic term however

haskell 6.6.1 runs nice so probably i would try play with it and diff them to see how much stagnent pattern emerges

]]> By: newsham http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/comment-page-1/#comment-1091 Tue, 01 May 2007 04:40:58 +0000 http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/#comment-1091 Its pretty easy to whip through the disassembly of a small C/C++ program to recover its semantics.

]]> By: Chris Rohlf http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/comment-page-1/#comment-1071 Mon, 30 Apr 2007 11:47:14 +0000 http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/#comment-1071 “how obfuscated is compiled object code from standard functional programming languages?”

About as obfuscated as using -static on a large C/C++ program IMO. The objdump output looks a bit ‘ugly’, and its bloated as hell, but its certainly follow-able given enough time to recreate all the underlying functions.

]]> By: newsham http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/comment-page-1/#comment-1037 Sun, 29 Apr 2007 07:26:43 +0000 http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/#comment-1037 re: “peano arithmetic” from the old thread that kicked off this new blog thread — Here’s some short python fun I was goofing around with last week:
http://www.thenewsh.com/~newsham/lambda.py
and here’s a cool paper that inspired me to goof with such things:
http://www.cs.nott.ac.uk/~nhn/TFP2006/Papers/03-JansenKoopmanPlasmeijer-EfficientInterpretation.pdf

]]> By: newsham http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/comment-page-1/#comment-1034 Sun, 29 Apr 2007 07:17:40 +0000 http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/#comment-1034 “it seems to be perfectly debuggable in gdb”
Yes, there are no anti-debugging tricks in the code. That’s not the point.

“the disassembly looks pretty straight forward with symbols and names”
The createThread function is part of the runtime, not one of the functions from the source (also listed on the same page). The assembly does look somewhat “normal” but recovering the semantics from the assembly is not straightforward. At the very least, it does not look like code you’d get from an imperative language.

]]> By: bluffer http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/comment-page-1/#comment-1031 Sun, 29 Apr 2007 05:55:22 +0000 http://rdist.root.org/2007/04/28/functional-languages-and-reverse-engineering/#comment-1031 looks like the html markers &gt and &lt got stripped in the previous post

the disassembly looks pretty straight forward with symbols and names

like this
0x8087b4c <createThread>:push ebp
0x8087b4d <createThread+1>:push edi
0x8087b4e <createThread+2>:push esi
0x8087b4f <createThread+3>:push ebx
0x8087b50 <createThread+4>:sub esp,0xc
0x8087b53 <createThread+7>:mov eax,DWORD PTR [esp+32]

]]>