Using C header and implementation files in Xcode iOS project - ios

I'm trying to use a separate C header and implementation file in Xcode iOS/Objective-C project.
I want to use the method I implemented in main.m but I get these errors:
Full size here
I've included user.h in main.m
Note that Target Membership is selected in user.c for HelloWorld. When I deselect this the errors are gone. But when I try to run the app, I get these errors at compile time:
Full size here
When I implement the struct and method in main.m it compiles and runs just fine. But I don't get it why I can't use this particular code in a separate file?
Source Code:
user.h
#ifndef HelloWorld_user_h
#define HelloWorld_user_h
typedef struct {
char *name;
int age;
char sex;
} User; //sizeof(User) = 16 bytes
void CreateAndDisplay(User *usr, char *name, int age, char sex);
#endif
user.c
#include <stdio.h>
#include <stdlib.h>
void CreateAndDisplay(User *usr, char *name, int age, char sex) {
usr->name = name;
usr->age = age;
usr->sex = sex;
printf("User address -> value:\n");
printf("Name:\t%u\t->\t%s\n", (uint)usr, *&usr->name);
printf("Age:\t%u\t->\t%i\n", (uint)&usr->age, *&usr->age);
printf("Sex:\t%u\t->\t%c\n\n", (uint)&usr->sex, *&usr->sex);
printf("User has a size of %li bytes in memory", sizeof(*usr));
}
main.m
#import <UIKit/UIKit.h>
#import "HelloWorldAppDelegate.h"
#include <stdio.h>
#include <stdlib.h>
#include "user.h"
int main(int argc, char *argv[])
{
User user1;
CreateAndDisplay(&user1, "John Doe", 24, 'm');
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([HelloWorldAppDelegate class]));
}
}

These errors are because there are two types referenced in user.c that haven't been declared in headers that it imports: User (defined in user.h) and uint (defined in <sys/types.h>). To resolve these errors, inside user.c you should add the following includes:
#include "user.h"
#include <sys/types.h>

Try to include user.h in user.c, like you include stdio.h.

Related

How to use LLVM's SanitizerCoverage code coverage instrumentation with a shared library?

I have a shared library linked to an executable for which I would like to have code coverage instrumentation using custom _sanitizer_cov_trace_pc* functions.
library.cc
#include <stdio.h>
void so_function() {
printf("SO function.");
}
callbacks.cc
#include <stdint.h>
#include <stdio.h>
#include <sanitizer/coverage_interface.h>
extern "C" void __sanitizer_cov_trace_pc_guard_init(uint32_t *start,
uint32_t *stop) {
static uint64_t N;
if (start == stop || *start) return;
printf("INIT: %p %p\n", start, stop);
for (uint32_t *x = start; x < stop; x++)
*x = ++N;
}
extern "C" void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {
if (!*guard) return;
void *PC = __builtin_return_address(0);
char PcDescr[1024];
__sanitizer_symbolize_pc(PC, "%p %F %L", PcDescr, sizeof(PcDescr));
printf("guard: %p %x PC %s\n", guard, *guard, PcDescr);
}
main.cc
#include <stdio.h>
void so_function();
int main(int argc, char **argv) {
so_function();
}
I compiled the library using clang's -fsanitize-coverage=trace-pc-guard into position-independent code (-fPIC) and then I created the shared library using both the resulted object file and callbacks.cc using -fsanitize=address.
I compiled main.cc and linked it with the shared library but it seems like these 2 custom __sanitizer_cov_trace_pc_guard* functions don't get called.
I would like have code coverage instrumentation using these 2 functions only for the shared library, and not for the main executable.

How can I have atos print mangled names?

I'm running atos to symbolicate addresses using -arch arm64 -o MyApp -s <slide> -f <symbol file>. However, it prints lines like type metadata accessor for GradientView (in MyApp) (<compiler-generated>:0). I'd like it to print the mangled name instead, e.g. _$s22FeatureImpl12LanguageCellC19GradientViewSo012GradientI0CvpACTk. I need this for various reasons, including to pass to an order file for the linker. Is there any way to do this with atos?
I've found a workaround without atos. I can use the private CoreSymbolication framework directly:
#import <Foundation/Foundation.h>
#include <stdint.h>
#include <mach/machine.h>
#include <mach-o/arch.h>
#include <architecture/byte_order.h>
struct sCSTypeRef {
void* csCppData; // typically retrieved using CSCppSymbol...::data(csData & 0xFFFFFFF8)
void* csCppObj; // a pointer to the actual CSCppObject
};
typedef struct sCSTypeRef CSTypeRef;
typedef CSTypeRef CSSymbolicatorRef;
typedef CSTypeRef CSSourceInfoRef;
typedef CSTypeRef CSSymbolOwnerRef;
typedef CSTypeRef CSSectionRef;
typedef CSTypeRef CSSegmentRef;
typedef CSTypeRef CSSymbolRef;
typedef CSTypeRef CSRegionRef;
typedef CSTypeRef CSUUIDRef;
CSSymbolicatorRef CSSymbolicatorCreateWithURLAndArchitecture(CFURLRef url, cpu_type_t type);
CSSymbolRef CSSymbolicatorGetSymbolWithAddressAtTime(CSSymbolicatorRef cs, vm_address_t addr, uint64_t time);
const char* CSSymbolGetMangledName(CSSymbolRef sym);
int main(int argc, const char * argv[]) {
CFURLRef url = CFURLCreateWithFileSystemPath(NULL, CFSTR("/path/to/dSYM/binary"), kCFURLPOSIXPathStyle, false);
CSSymbolicatorRef cs = CSSymbolicatorCreateWithURLAndArchitecture(url, 16777228 /* arm64 cputype */);
int slide = ...;
ptrdiff_t addr = ...;
CSSymbolRef sym = CSSymbolicatorGetSymbolWithAddressAtTime(cs, addr - slide, 0);
const char *name = CSSymbolGetMangledName(sym);
printf("%s\n", name);
return 0;
}
https://github.com/mountainstorm/CoreSymbolication/blob/master/CoreSymbolication/CoreSymbolication.h provided the prototypes

How to implement PT_DENY_ATTACH (anti-debugging in iOS )

PT_DENY_ATTACH is an anti-debugging feature that helps prevent debuggers from attaching to the app. Following code can be implemented in main() to prevent GDB from attaching to the application. :
#import <dlfcn.h>
#import <sys/types.h>
typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);
#define PT_DENY_ATTACH 31
void disable_gdb() {
void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);
ptrace_ptr_t ptrace_ptr = dlsym(handle, "ptrace");
ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);
dlclose(handle);
}
int main(int argc, char *argv[]) {
#autoreleasepool {
#ifdef DEBUG
//do nothing
#else
disable_gdb();
#endif
}}
Guys it is true that this trick has been worked around and can be bypassed by overriding but have a look at that
Here the guys from iphonedevwiki.net are showing another way to implement the same thing in assembly, making it much harder to be patched. So to bypass this assembly implementation one has to have the Mach-O binary decrypted and override the implementation of the function, for example an attacker could swap all assembly instructions from the function with only nop instructions which do nothing. But if you obfuscate your assembly routine, it will be much harder for attacker to recognise what is happening, so only the most experienced folks will be able bypass that.
For those of you who don't know how to write assembly in Swift 5 project, here is what you will need to do:
Create a new C File + Header
lets name them disable_debuggers_advanced.c and disable_debuggers_advanced.h
In disable_debuggers_advanced.c add the following:
#include "disable_debug_advanced.h"
void mRiYXNnZnZmZGF2Ym() {
// No Need to encode these strings, because they will be directly compiled, they are not going to be present in the 'DATA' segment of the binary.
__asm (
"mov r0, #31\n" // set #define PT_DENY_ATTACH (31) to r0
"mov r1, #0\n" // clear r1
"mov r2, #0\n" // clear r2
"mov r3, #0\n" // clear r3
"mov ip, #26\n" // set the instruction pointer to syscal 26
"svc #0x80\n" // SVC (formerly SWI) generates a supervisor call. Supervisor calls are normally used to request privileged operations or access to system resources from an operating system
);
}
In disable_debuggers_advanced.h add the following:
#ifndef disable_debug_advanced_h
#define disable_debug_advanced_h
#include <stdio.h>
/**
Original name: `disable_gdb_advanced()`
This function makes the process deny the attaching request by debugers by
simulating what is already available on macOS:
ptrace(PT_DENY_ATTACH, 0, 0, 0);
by implementing it directly in assembly language.
This method of disabling debugers is well known to attackers but there is nothing they can do to easily bypass it
because it is a part of the kernel memory space.
Please note that this will make XCode not being able to attach its debuger to the process too,
so run it only in release builds.
source: https://iphonedevwiki.net/index.php/Crack_prevention#PT_DENY_ATTACH
*/
void mRiYXNnZnZmZGF2Ym(void) __attribute__((always_inline));
#endif /* disable_debug_advanced_h */
Add #include "disable_debug_advanced.h" to your bridging header and a bridging header if your project does not already have one.
Now you can call this function to disable debuggers.
Note that this will break even the XCode debugger, so use it only on release builds
If you are wondering about the __attribute__((always_inline)) part and the weird name it is because we want our function to be hidden as much as possible. If you are not familiar with function inlining, you can watch my video about function inlining here where i describe it in depth or you can read in wikipedia about it. Even thought it is a speed compiler optimisation, it could give us benefits here because if you call it from multiple locations it will be harder for attacker to patch all function body copies in the app.
And the name is written like this, because this inlining is just a hint to the compiler, it is not guaranteed that it will happen. And if it does not happen and our function for disabling the debugger is clearly defined in the TEXT segment of our binary, we want it to be at least with obfuscated name, so that no one could guess what it does just by reading its assembly label.
In my opinion one should call this as a top level function even before the UIApplication object is created.
In order to do that:
Add a new file to your Swift project and name it 'main.swift' (NAME IS IMPORTANT)
Remove the #UIApplicationMain tag from your AppDelegates class definition.
In your main.swift file write the following:
mRiYXNnZnZmZGF2Ym() // disable debuggers
// initialises the UIApplication and fires the event loop.
// This function never returns!
UIApplicationMain(CommandLine.argc, CommandLine.unsafeArgv, nil, NSStringFromClass(AppDelegate.self))
If you want to see a video of how to execute top level code in main.swift, you can see me doing it on this video
In attempt to make it even more obfuscated and harder to crack, one could use assembly obfuscators like this one Movfuscator so that only a few people would be able to recognise what these assembly instructions mean.
Note: according to the wiki page of this tool, it has been workearound and must not be used:
IMPORTANT NOTE: This trick has been worked around by pirates. Don't rely on it!
Assuming you are referring to a Hybrid application created in MobileFirst Studio 7.1 - this, well, is not different than any other iOS app.
The end result of a Hybrid app, is still an Xcode project that you open in Xcode in order to build the application. This means then that you need to place your code in the same place in the Xcode project as if this was a regular Xcode project (which, it is), per the wiki page for PT_DENY_ATTACH.
As noted by #Idan Adar - this trick is workedAround, but in case u want to try it in any education or some other purpose u can try do following:
add define for u'r app to allow u run and debug if needed
#define SOME
add following code in main.m
#define SOME
#import <UIKit/UIKit.h>
#import "AppDelegate.h"
#ifdef SOME
#import <dlfcn.h>
#import <sys/types.h>
typedef int (*ptrace_ptr_t)(int request, pid_t pid, caddr_t addr, int data);
#if !defined(PT_DENY_ATTACH)
#define PT_DENY_ATTACH 31
#endif // !defined(PT_DENY_ATTACH)
void disable_gdb();
int main(int argc, char *argv[])
{
// disable_gdb();
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
void disable_gdb()
{
void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);
ptrace_ptr_t ptrace_ptr = dlsym(handle, "ptrace");
ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);
dlclose(handle);
}
int main3(int argc, char *argv[])
{
return -1;
}
#else
int main(int argc, char *argv[])
{
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
#endif
Here - some good points to start about
I saw this question has not marked correct answered yet. I already use below code block to use anti-debugging. Please open your main.m file to added below code snipped.
#import "AppDelegate.h"
#import "Application.h"
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/sysctl.h>
#include <stdlib.h>
typedef int (*PYStdWriter)(void *, const char *, int);
static PYStdWriter _oldStdWrite;
#define PT_DENY_ATTACH 31
int __pyStderrWrite(void *inFD, const char *buffer, int size)
{
if ( strncmp(buffer, "AssertMacros:", 13) == 0 ) {
return 0;
}
return _oldStdWrite(inFD, buffer, size);
}
static int is_debugger_present(void)
{
int name[4];
struct kinfo_proc info;
size_t info_size = sizeof(info);
info.kp_proc.p_flag = 0;
name[0] = CTL_KERN;
name[1] = KERN_PROC;
name[2] = KERN_PROC_PID;
name[3] = getpid();
if (sysctl(name, 4, &info, &info_size, NULL, 0) == -1) {
perror("sysctl");
exit(-1);
}
return ((info.kp_proc.p_flag & P_TRACED) != 0);
}
int main(int argc, char *argv[]) {
#ifdef DEBUG
_oldStdWrite = stderr->_write;
stderr->_write = __pyStderrWrite;
#autoreleasepool {
return UIApplicationMain(argc, argv, NSStringFromClass([Application class]), NSStringFromClass([AppDelegate class]));
}
#else
//Anti Debugging Code
//https://coredump.gr/articles/ios-anti-debugging-protections-part-2/
//ptrace(PT_DENY_ATTACH, 0, 0, 0);
printf("Looping forever");
fflush(stdout);
while (1)
{
sleep(1);
if (is_debugger_present())
{
//[[NSUserDefaults standardUserDefaults] setBool:YES forKey:#"isAntiDebug"];
printf("Debugger detected! Terminating...\n");
return -1;
}
printf(".");
fflush(stdout);
_oldStdWrite = stderr->_write;
stderr->_write = __pyStderrWrite;
#autoreleasepool {
//[[NSUserDefaults standardUserDefaults] setBool:NO forKey:#"isAntiDebug"];
int retVal = UIApplicationMain(argc, argv, NSStringFromClass([Application class]), NSStringFromClass([AppDelegate class]));
return retVal;
}
}
#endif
}
As pointed out by Stoyan. Your implementation could be easily bypassed. You should add an assembly code. Just one missing thing from the above answer is that you have to add arm64 macro or you will not be able to build your project on simulators (OS X are using x86_64 arch)
So add this:
#if defined (__arm64__)
__asm(
"mov x0, #26\n" // ptrace
"mov x1, #31\n" // PT_DENY_ATTACH
"mov x2, #0\n"
"mov x3, #0\n"
"mov x16, #0\n"
"svc #128\n"
);
I wrote a simple guide for this. Check it out

How to pass a DynamicArray in c++ builder

I'm using C++Builder XE4 with the VCL Win32 platform. I am tring to setup a method that will take a DynamicArray of TPoint as an argument. Below is from my .hpp file for a standard VCL Win32 Form. My declaration for CalcPolygonDetail() is generating the error message: "Error in module NewForm: Incorrect method declaration in class TForm3_cpp" The problem is the argument DynamicArray MyPoints, Can someone show how to setup this declaration correctly. Thanks.
#ifndef NewFormH
#define NewFormH
//----
#include <System.Classes.hpp>
#include <Vcl.Controls.hpp>
#include <Vcl.StdCtrls.hpp>
#include <Vcl.Forms.hpp>
#include "AdvSpin.hpp"
#include <Vcl.ComCtrls.hpp>
#include <Vcl.ExtCtrls.hpp>
#include <Vcl.Mask.hpp>
DynamicArray<TPoint> MyPoints;
//------------
class TForm3_cpp : public TForm
{
__published: // IDE-managed Components
TImage *Image1;
TLabel *Label2;
----break----
int __fastcall CalcPolygonDetail(DynamicArray<TPoint> MyPoints, bool UseScreenCoordinates );
.
This simple file compiles fine as a Console VCL App on XE5.
#include <vcl.h>
#include <windows.h>
#pragma hdrstop
#pragma argsused
#include <tchar.h>
#include <stdio.h>
DynamicArray<System::Types::TPoint> MyPoints;
void __fastcall TestFunction(DynamicArray<System::Types::TPoint> MyPoints2, bool SomeOtherParam)
{
// Do something with this.
MyPoints = MyPoints2;
}
int _tmain(int argc, _TCHAR* argv[])
{
DynamicArray<System::Types::TPoint> MyPoints3;
TestFunction(MyPoints3, true);
return 0;
}
Does this compiles fine for you? Maybe the problem lies somewhere else, because the DynamicArray definition seems correct. I would create a type instead:
typedef DynamicArray<System::Types::TPoint> TMyPoints;
Specially if you are going to use that kind of arrays in your code more than once. But as the example shows, even without this it should work.

Lua does not load libs

I decided to add scripting with Lua. I've downloaded and compiled interpreter. It works fine, but when I want to use any functions from os.* or string.* libs, it says, that "attemt to index global 'os' (a nil value)"
Here is my code and should work, but it does not:
#include <iostream>
#include <Windows.h>
#include <string>
using namespace std;
extern "C" {
#include "..\liblua\lua.h"
#include "..\liblua\lualib.h"
#include "..\liblua\lauxlib.h"
}
int main(int argc, TCHAR* argv[])
{
lua_State *LuaVM = luaL_newstate();
lua_pushcfunction(LuaVM,luaopen_base);
lua_call(LuaVM,0,0);
lua_pushcfunction(LuaVM,luaopen_math);
lua_call(LuaVM,0,0);
lua_pushcfunction(LuaVM,luaopen_string);
lua_call(LuaVM,0,0);
lua_pushcfunction(LuaVM,luaopen_table);
lua_call(LuaVM,0,0);
int error;
lua_pushstring(LuaVM,"Ver 0.525.5");
lua_setglobal(LuaVM,"Version");
while (true)
{
string strCode;
getline(cin,strCode);
error = luaL_loadbuffer(LuaVM,strCode.c_str(),strCode.length(),"") ||
lua_pcall(LuaVM,0,0,0);
if (error)
{
cout<< lua_tostring(LuaVM,-1)<<endl;
lua_pop(LuaVM,1);
}
}
lua_close(LuaVM);
return 0;
}
What's wrong with it?
In Lua 5.2 the standard luaopen_* functions do not set the corresponding global variables.
Why not copy and adapt the code in linit.c or just call luaL_openlibs?
Otherwise, do what they do: call luaL_requiref for each luaopen_* function.
See http://www.lua.org/source/5.2/linit.c.html#luaL_openlibs.

Resources