So I've been trying to figure out how to decompile dlls, java, and Lua files but once I ran into this one I got stumped.
Does anyone have any ideas on how I can decompile this?
Since the script was way too big I put it in a pastebin link. https://pastebin.com/UsdWEHnmIlIIl1liIllIi1II1Ii.lIl1llIllIii1111lIIIii = lIli1IlI11lIlI1il11i1() lIli1IlI11lIlI1il11i1() lIli1IlI11lIlI1il11i1() local ll1ili1i1Ii1II111li = lIlIlll1Ill1illiliIiI() for i1IiIili111iI1lil1l = lIliI1iii11lilII1IIil, ll1ili1i1Ii1II111li do IlIIl1liIllIi1II1Ii.l111II111Il1IiIII11i[i1IiIili111iI1lil1l] = lIlIlll1Ill1illiliIiI() end lIlIlll1Ill1illiliIiI() lIli1IlI11lIlI1il11i1() lIli1IlI11lIlI1il11i1() lIlIlll1Ill1illiliIiI() lIlIlll1Ill1illiliIiI() lIlIlll1Ill1illiliIiI() lIli1IlI11lIlI1il11i1() local ll1ili1i1Ii1II111li = lIlIlll1Ill1illiliIiI() - (#{ 91625, 31274, 132907, 128929, 89879, 28353, 85846, 63662, 120975, 94604, 40073, 120271, 29175, 126728, 55753, 31423, 118592, 112751, 123563, 26653 } + 49 - 22 - 12 + 24 + 10 + 32 - 27 + 22 - 35 + 41 + 25 + 29 + 18 + 33 + 32 + 133485) for i1IiIili111iI1lil1l = lIliI1iii11lilII1IIil, ll1ili1i1Ii1II111li do local l1iI1Illil1i1il1iII = {} local lIlill1IIIlli1iII1ill = lIlIllI1i111lilIi1ilI(i1iIIIii1liiIillilI) l1iI1Illil1i1il1iII.il1li1iilIii1iIll11l = iiIlIlilIlIll1l1l1l(lIlill1IIIlli1iII1ill, #{ 19814, 81950, 109054, 18321, 117777, 126276, 941, 40833, 27393, 25354, 106568, 58140, 73781, 28751, 110509, 42721, 118305, 94680, 18166, 4591 } + 26 - 9 + 9 - 4 - 48 - 2 + 24 + 47 - 35 - 8 - 31 - 1 + 39, #{ 34453, 33661, 37020, 5461, 3935, 7245, 90253, 30010, 122438, 78286, 50375, 62446, 101176, 126539, 91679, 59085, 67167, 93133, 73148, 54067, 13807 } + 29 - 46 - 15 + 41 + 32 - 26 + 6 - 6 + 27 - 43 + 12 - 17 + 11 + 6) l1iI1Illil1i1il1iII.lIlilIilillll11iil1li1 = iiIlIlilIlIll1l1l1l(lIlill1IIIlli1iII1ill, #{ 59738, 38876, 31250, 75801, 96293, 27832, 11774, 9098, 31230, 80836, 129303, 101680, 12689, 60836 } - 3 + 38 + 32 - 43 + 21 - 10 + 5 - 32 + 14 - 8 + 7 - 15 - 19, #{ 37073, 70137, 113242, 21765, 129309, 86407, 33113, 85980, 105005, 59356, 53236, 100694, 61483, 55175, 85902, 33351, 70969, 133357, 55705, 74121, 116292, 132529 } - 13 - 4 - 47 - 36 - 29 + 17 - 49 + 43 - 48 - 42 - 4 - 18 + 16 + 201) l1iI1Illil1i1il1iII.I1i1IiiIlIIl1II11IiI = iiIlIlilIlIll1l1l1l(lIlill1IIIlli1iII1ill, #{ 129902, 68496, 976, 73113, 19012, 12350, 23326, 93845, 88636, 103236, 52249, 70226, 40074,
This is a VERY VERY VERY small sample, in all there are 40,000 chars.
I understand this is quite an old thread but perhaps I can assist with some information you may not know. This script is in lua created by an older version of the current Luraph. Sold on a multi-purpose website called V3rmillion and sold as a service on the black market. Although the "obfuscated" code was paid, since every script you want obfuscated costs $1 PayPal, I assume their obfuscations are quite worth the price. The pastebin provided does not include the watermark, but I know that it's Luraph because of this side message: http://prntscr.com/k37hin This is a good example of custom bytecode which may sound pretty awesome but in return is just Lua bytecode that uses a lua virtual machine to comprehend what it means. Which is also related to Lua bytecode; using a interpreter to understand what the bytecode means and resulting in a executable code. So practically Luraph uses a custom-made interpreter and custom-made bytecode and uses the interpreter to understand the bytecode then turn it into executable code.
Luraph is an LBI.
Here is the lbi: https://github.com/JustAPerson/lbi/blob/master/src/lbi.lua
It uses custom Bytecode, you can easily find the patterns in the script from the lbi, and the luraph vm. Just replace those, and you get a readable vm.
Deobfuscating the Bytecode is a whole different matter.
There are a few different things you can do to help get rid of obfuscation in code.
1. Use Proper Variable and Function Names
One would be to find and replace all of the different variable and function names with something more distinctive than "I1lili1" and so on. This would allow you to follow the code much easier and also prevent you confusing any variables with each other.
2. Indent the Code
Another would be to look for the 'if', 'while', 'function' and 'end' keywords and then start indenting the code to make it more readable and again easier to follow.
3. Solve the Basic Maths
The above code uses the length function (#) very often as it is using most of the lists as another way to represent normal numbers and prevent people seeing the actual numbers easily. For example:
#{ 10, 372, 67298, 2287, 694, 1, 5039 }
will become:
7
when you perform the length function. If you change all of those lists to actual numbers and then solve the simple addition and subtraction equations after you can get rid of nearly all the numbers.
Of course doing this will take a lot of time but that's the point of obfuscating the code after all. If you don't want to spend a few hours going through all the code getting rid of the obfuscation you can just use this version I prepared earlier: https://pastebin.com/Amtt8UMP I have used all of the above methods to get rid of some of the obfuscation in the code however you will still need to trace through the program to find the outputs from all the functions.
As Egor Skriptunoff commented however, all this piece of code will do most likely is activate a loadstring. This code from the loadstring will also probably be obfuscated so in reality this piece of code it useless to you.
Hope this helps!
I've got a symbolicated stack trace that's giving me a headache! Annoyingly, I can't reproduce this on any of our test devices so I only have the crash reports to work from.
Application Specific Information:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Invalid type in JSON write (NSURLResponseInternal)'
Last Exception Backtrace: CoreFoundation
0x2ac7af8f __exceptionPreprocess + 126 libobjc.A.dylib
0x3932bc8b objc_exception_throw + 38 CoreFoundation
0x2ac7aed5 -[NSException initWithCoder:] + 0 Foundation
0x2ba218d1 0x2b8ef000 + 632 Foundation
0x2ba23463 ___writeJSONObject_block_invoke + 186 CoreFoundation
0x2ab96f5d __65-[__NSDictionaryM enumerateKeysAndObjectsWithOptions:usingBlock:]_block_invoke + 92 CoreFoundation
0x2ab96e7f -[__NSDictionaryM enumerateKeysAndObjectsWithOptions:usingBlock:] + 174 Foundation
0x2ba230e3 _writeJSONObject + 414 Foundation
0x2ba2180f _writeJSONValue + 438 Foundation
0x2ba21625 -[_NSJSONWriter dataWithRootObject:options:error:] + 128 Foundation
0x2ba224bf +[NSJSONSerialization dataWithJSONObject:options:error:] + 338 whats-new
0x00315fa3 0xc9000 (WNLoadingView.m:28) whats-new
0x00318683 0xc9000 (WNLoadingView.m:28) whats-new
0x003199fb 0xc9000 (WNLoadingView.m:28) libdispatch.dylib
0x398bc2cf _dispatch_client_callout + 22 libdispatch.dylib
0x398c3a3d _dispatch_barrier_sync_f_invoke + 48 whats-new
0x00319911 0xc9000 (WNLoadingView.m:28) whats-new
0x003185bb 0xc9000 (WNLoadingView.m:28) whats-new
0x0031fac3 0xc9000 (WNLoadingView.m:28) whats-new
0x0031f97f 0xc9000 (WNLoadingView.m:28) whats-new
0x0031dce3 0xc9000 (WNLoadingView.m:28) libdispatch.dylib
0x398bc2e3 _dispatch_call_block_and_release + 10 libdispatch.dylib
0x398c3dff _dispatch_after_timer_callback + 66 libdispatch.dylib
0x398ce173 _dispatch_source_latch_and_call + 1606 libdispatch.dylib
0x398bde15 _dispatch_source_invoke + 212 libdispatch.dylib
0x398c4397 _dispatch_queue_drain + 554 libdispatch.dylib
0x398beaad _dispatch_queue_invoke + 84 libdispatch.dylib
0x398c5f9f _dispatch_root_queue_drain + 394 libdispatch.dylib
0x398c73c3 _dispatch_worker_thread3 + 94 libsystem_pthread.dylib
0x39a20db5 _pthread_wqthread + 668 libsystem_pthread.dylib
0x39a20b08 start_wqthread + 8
The reason for the crash is pretty obvious (and isn't my question!) - I'm trying to write a non-jsonable object into json data. The tricky part is working out exactly where this is happening.
All the references to WNLoadingView.m are a complete red herring - that line of WNLoadingView is just #implementation WNLoadingView and the address 0xc9000 is just the starting point of our binary in memory. However, 0x00315fa3 looks like it's in our space but I don't know how to see what's actually there :)
Sigh.
My current theory is that the crash is occurring in a library that I don't have debug information for (i.e. a 3rd party .a linked from a pod).
I guess I have two questions;
How can I use this stack trace to find out which library is causing this?
or
If my theory isn't correct, does anyone know another approach to try or have another theory?
There's a couple of avenues that you might pursue:
Get yourself a fully-symbolicated crash log. I've found this post to be incredibly helpful, specifically the answer by Andreas (which is NOT the accepted answer, unfortunately). If you can get this to work, you may not need anything else.
Use the link map for your binary to determine where the address in question (0x00315fa3) resides. This can potentially be unsolvable if you didn't set up your build to produce a link map ahead of time for the version of your app that's on the app store (or even an older one), but there's a small chance that you can potentially get in the ballpark by rebuilding the app from scratch at the same commit point in your version control system you used to build the app originally (YMM GREATLY V). Regardless of whether you're already set up or need to set up your build to produce one, you'll want one going forward; read the first part of the second post for instructions on setting up your build in Xcode to produce a link map, and where to find it once it's been generated. If you use command-line tools to build your app for submission, you'll need to dig up the relevant switch(es) (you can use your Xcode build changes to determine what it does and use that in your build script/command). The link map is useful because it can tell you about files/methods from ALL of the app's source code, including third-party libraries, even when you don't have the source for them (it's a complete map of your entire app, not just your code); you can still get useful hints about the overall call flow that led directly to the crash.
While the purpose of the second post doesn't directly address your problem (and are frankly overkill for your specific question), many of the ideas about how to read the link map and the tools you can use to automate certain tasks should give you sufficient insight about how to glean the information that's of relevance. Specifically, you'll want to find the file/method invocation whose address range contains the address in question (0x00315fa3), and, if all goes well (meaning you have an accurate map), that information should point you right to the offending library, file, and method.
I have a problem with my iOS app crashing. It uses core data (one managed object context) and ARC but also has a separate SQLite database, which can be fairly large. I am getting crash reports for it with the error: EXC_BAD_ACCESS and usually with the code: KERN_INVALID_ADDRESS
The problem is that every single crash happens in a different place (there are over 30) and that usually those places don't usually include any of my code in the call stack. I think, therefore that I am doing something fundamentally wrong which is causing these errors to occur.
I have tried turning on NSZombiesEnabled, but then I find that the errors don't occur. Also, I have tried turning on core data debugging (level 1), but I find the same there too. The errors occur across a range of devices and operating systems. The crash reports show between 3.0 to 148.0 mb or ram remaining. All of the crashes are on the main thread.
So my question comes in two parts:
1) I can't find any reference to there being a problem using a separate SQLLite database in a core data project. Is there any potential pitfalls to doing this and docs on how to avoid those pitfalls?
2) Does this patten of errors suggest anything in particular which I may be doing incorrectly?
I have added a single crash report on the off chance it reveals something which my question does not:
0
com.apple.main-thread Crashed
0 CoreFoundation CFRetain + 19
1 CoreFoundation __CFRunLoopDoTimer + 690
2 CoreFoundation __CFRunLoopDoTimer + 690
3 CoreFoundation __CFRunLoopRun + 1232
4 CoreFoundation CFRunLoopRunSpecific + 356
5 CoreFoundation CFRunLoopRunInMode + 104
6 GraphicsServices GSEventRunModal + 74
7 UIKit UIApplicationMain + 1120
8 cleverme
main.m line 14
main
I have an older app that I converted to use ARC. The original version did not have memory leaks, and I fixed all of the errors after the conversion using the memory diagnostics in the debugger. Occasionally, the app will crash and the stack trace looks like ARC is stuck in either an infinite retain or release cycle, like this:
0 CoreFoundation 0x329046a6 CFRelease + 46
1 CoreFoundation 0x329046da CFRelease + 98
2 CoreFoundation 0x329046da CFRelease + 98
3 CoreFoundation 0x329046da CFRelease + 98
4 CoreFoundation 0x329046da CFRelease + 98
Unfortunately, the stack traces cut off at 512 entries, so I can't see where this chain started. Apple said this could happen if the alloc and init methods are separated and the init method returns a different object than alloc. I checked all of our allocations and they follow the recommended format:
Class *var = [[Class alloc] initMethod:arg];
Has anyone seen an infinite loop of this sort? I have not been able to catch it while using the Xcode debugger, and it is very inconsistent. Since ARC is injecting the retains and releases, I don't have any idea where the crash originates.
I am using Bugsense in my app to get crash reports.
I have a repeating bug with SIGSEGV and no other details about it.
I tried to symbolicate the report but I get this:
0 libobjc.A.dylib 0x33417f78 0x33414000 + 16248
1 CoreFoundation 0x36f651fb 0x36f4d000 + 98811
2 Foundation 0x32c42747 0x32b9e000 + 673607
3 CoreFoundation 0x36fdaad3 0x36f4d000 + 580307
4 CoreFoundation 0x36fda29f 0x36f4d000 + 578207
5 CoreFoundation 0x36fd9045 0x36f4d000 + 573509
6 CoreFoundation 0x36f5c4a5 CFRunLoopRunSpecific + 300
7 CoreFoundation 0x36f5c36d CFRunLoopRunInMode + 104
8 GraphicsServices 0x35123439 GSEventRunModal + 136
9 UIKit 0x35205cd5 UIApplicationMain + 1080
10 English Club 0x00036a2b 0x34000 + 10795
It does not point to any of my classes (In the last line 'English Club' is the name of my app).
Does that mean that this is a bug in apple classes? how can I parse this report to get somthing helpful (like what are the +1234334 numbers in this case etc.
Thank you all
Shani
Does that mean that this is a bug in apple classes?
No.
how can I parse this report to get somthing helpful
Recompile with debug symbols enabled, and run the app in the debugger. Then, if everything was done right, you'll get a symbolicated stack trace.
what are the +1234334 numbers in this case
They're offsets from the beginning of the particular function address - and you're most likely not interested in them.
Your best bet here is to enable zombies and rerun in the debugger and try to reproduce the crash manually. The bug is likely somwhere in your code where you set a delegate that points to one of your objective C objects. For example, see this question which is much like yours: SIGSEGV SEGV_ACCERR Crash Reports - What to do?