From 314fceff4f81bde042ffe78c9d2df83880338663 Mon Sep 17 00:00:00 2001 From: "codegen-sh[bot]" <131295404+codegen-sh[bot]@users.noreply.github.com> Date: Fri, 25 Apr 2025 03:13:40 +0000 Subject: [PATCH] Delete all Markdown files from repository --- JIT Backend/DEPLOYMENT.md | 165 ------------------------------------ JIT Backend/HOW_IT_WORKS.md | 157 ---------------------------------- JIT Backend/README.md | 149 -------------------------------- MIGRATION_GUIDE.md | 118 -------------------------- PR_DESCRIPTION.md | 41 --------- README.md | 1 - 6 files changed, 631 deletions(-) delete mode 100644 JIT Backend/DEPLOYMENT.md delete mode 100644 JIT Backend/HOW_IT_WORKS.md delete mode 100644 JIT Backend/README.md delete mode 100644 MIGRATION_GUIDE.md delete mode 100644 PR_DESCRIPTION.md delete mode 100644 README.md diff --git a/JIT Backend/DEPLOYMENT.md b/JIT Backend/DEPLOYMENT.md deleted file mode 100644 index 537d40f..0000000 --- a/JIT Backend/DEPLOYMENT.md +++ /dev/null @@ -1,165 +0,0 @@ -# JIT Backend Deployment Guide - -This guide provides instructions for deploying the JIT Backend to various environments, with a focus on Render.com deployment. - -## Prerequisites - -- Python 3.8+ -- pip -- A server or cloud platform to host the backend -- Dropbox account with API credentials -- (Optional) Docker for containerized deployment - -## Environment Variables - -The following environment variables should be set for proper operation: - -- `JWT_SECRET_KEY`: Secret key for JWT token generation and validation -- `FLASK_ENV`: Set to `development` for local testing or `production` for production deployment -- `DROPBOX_APP_KEY`: Your Dropbox application key -- `DROPBOX_APP_SECRET`: Your Dropbox application secret -- `DROPBOX_REFRESH_TOKEN`: Your Dropbox refresh token - -## Local Deployment for Testing - -1. Clone the repository -2. Install dependencies: - ```bash - cd "JIT Backend" - pip install -r requirements.txt - ``` -3. Run the development server: - ```bash - export FLASK_ENV=development - export FLASK_APP=app.py - export JWT_SECRET_KEY=your_secret_key - export DROPBOX_APP_KEY=your_dropbox_app_key - export DROPBOX_APP_SECRET=your_dropbox_app_secret - export DROPBOX_REFRESH_TOKEN=your_dropbox_refresh_token - flask run --host=0.0.0.0 --port=5000 - ``` - -## Docker Deployment - -1. Build the Docker image: - ```bash - cd "JIT Backend" - docker build -t jit-backend . - ``` - -2. Run the container: - ```bash - docker run -d -p 5000:5000 \ - -e JWT_SECRET_KEY=your_secret_key \ - -e FLASK_ENV=production \ - -e DROPBOX_APP_KEY=your_dropbox_app_key \ - -e DROPBOX_APP_SECRET=your_dropbox_app_secret \ - -e DROPBOX_REFRESH_TOKEN=your_dropbox_refresh_token \ - jit-backend - ``` - -## Render.com Deployment - -Render.com is the recommended deployment platform for this backend. - -### Using render.yml (Recommended) - -1. Fork this repository to your GitHub account -2. Connect your GitHub repository to Render.com -3. Render will automatically detect the `render.yml` file and create the service -4. Review and adjust the environment variables as needed - -### Manual Setup - -1. Create a new Web Service on Render.com -2. Connect your GitHub repository -3. Configure the service: - - Environment: Docker - - Dockerfile Path: `./JIT Backend/Dockerfile` - - Environment Variables: - - `JWT_SECRET_KEY`: (Generate a secure random string) - - `FLASK_ENV`: production - - `DROPBOX_APP_KEY`: Your Dropbox app key - - `DROPBOX_APP_SECRET`: Your Dropbox app secret - - `DROPBOX_REFRESH_TOKEN`: Your Dropbox refresh token -4. Deploy the service - -## Dropbox Setup - -To set up Dropbox for database storage: - -1. Create a Dropbox account if you don't have one -2. Go to the [Dropbox Developer Console](https://www.dropbox.com/developers/apps) -3. Create a new app with the following settings: - - API: Dropbox API - - Access type: Full Dropbox - - Name: JIT Backend (or any name you prefer) -4. Note your App Key and App Secret -5. Generate an access token and then convert it to a refresh token -6. Use these credentials in your environment variables - -## Security Considerations - -1. **JWT Secret Key**: Always use a strong, unique JWT secret key in production. -2. **HTTPS**: Ensure your deployment uses HTTPS to encrypt communication between iOS devices and the backend. -3. **Rate Limiting**: Consider implementing rate limiting to prevent abuse. -4. **Monitoring**: Set up monitoring and logging to track usage and detect issues. -5. **Dropbox Security**: Keep your Dropbox credentials secure and consider rotating them periodically. - -## Configuring iOS Apps - -After deploying the backend, you need to configure your iOS app to use it: - -1. Implement the device registration flow in your iOS app -2. Store the JWT token securely in the iOS keychain -3. When JIT is needed, call the `/enable-jit` endpoint with the appropriate parameters -4. Implement the JIT enablement logic in your iOS app based on the instructions returned by the backend - -## Scaling Considerations - -The backend is designed to be lightweight and scalable. For higher traffic: - -1. Increase the number of Gunicorn workers in the Dockerfile -2. Consider using a more robust database solution for very high traffic -3. Implement caching for frequently accessed data -4. Set up a CDN if serving static assets - -## Troubleshooting - -### Common Issues - -1. **Connection Errors**: Ensure your server is accessible from the internet and that any firewalls allow traffic on port 5000 (or your configured port). -2. **Authentication Errors**: Check that the JWT token is being properly generated and validated. -3. **Dropbox Errors**: Verify that your Dropbox credentials are correct and that the refresh token is valid. -4. **JIT Enablement Failures**: Check the logs for detailed error messages about JIT enablement failures. - -### Logs - -Check the server logs for detailed error information: - -```bash -# For Docker -docker logs - -# For Render.com -Access the logs through the Render.com dashboard -``` - -## Updating the Backend - -When updating the backend: - -1. Make your changes to the code -2. Test locally -3. Push changes to your GitHub repository -4. Render.com will automatically deploy the updated version (if auto-deploy is enabled) -5. Monitor logs to ensure the update was successful - -## Support and Maintenance - -Regular maintenance tasks: - -1. Monitor Dropbox token refresh to ensure database connectivity -2. Check for security updates to dependencies -3. Review logs for error patterns -4. Clean up old sessions and unused data periodically diff --git a/JIT Backend/HOW_IT_WORKS.md b/JIT Backend/HOW_IT_WORKS.md deleted file mode 100644 index 7f947a7..0000000 --- a/JIT Backend/HOW_IT_WORKS.md +++ /dev/null @@ -1,157 +0,0 @@ -# How JIT Enablement Works on iOS - -This document provides a comprehensive explanation of how the JIT Enabler solution works to enable Just-In-Time (JIT) compilation for iOS apps without requiring code modifications to the apps themselves. - -## Understanding iOS JIT Restrictions - -iOS enforces a security policy called W^X (Write XOR Execute), which means memory pages can either be writable OR executable, but not both simultaneously. This policy prevents code from being modified and then executed, which is a common attack vector. - -JIT compilation requires the ability to: -1. Write compiled code to memory -2. Execute that compiled code - -This creates a challenge under iOS's W^X policy, as JIT engines need to: -1. Write to memory pages (making them writable) -2. Then execute from those same pages (making them executable) - -## How Our Solution Enables JIT - -Our solution uses a combination of techniques to enable JIT compilation: - -### 1. Backend Server Approach - -Instead of modifying apps, we use a backend server that: -- Registers iOS devices -- Provides device-specific JIT enablement instructions -- Handles authentication and security - -### 2. iOS Shortcut as the Client - -The iOS Shortcut serves as a user-friendly client that: -- Communicates with the backend -- Applies the JIT enablement instructions -- Launches the target app - -### 3. Version-Specific JIT Enablement - -Different iOS versions require different approaches: - -#### iOS 15 Method -- Sets the CS_DEBUGGED flag on the process -- Uses legacy methods to toggle memory permissions - -#### iOS 16 Method -- Sets the CS_DEBUGGED flag -- Uses a more direct approach to memory permission management - -#### iOS 17+ Method -- Uses memory permission toggling to comply with the stricter W^X policy -- Leverages specific memory region marking - -## Technical Deep Dive - -### Memory Permission Toggling - -The key to enabling JIT is toggling memory permissions between writable and executable states: - -1. When the JIT compiler needs to generate code: - - Memory pages are marked as writable (but not executable) - - The JIT compiler writes the compiled code to these pages - -2. When the code needs to be executed: - - Memory pages are marked as executable (but not writable) - - The app can now execute the JIT-compiled code - -3. This toggling happens rapidly and is coordinated by the JIT engine - -### CS_DEBUGGED Flag - -On iOS, processes have code signing flags that control what they can do: - -1. The CS_DEBUGGED flag indicates a process is being debugged -2. When this flag is set, certain restrictions are relaxed -3. Our solution leverages this to enable the memory permission changes needed for JIT - -### Communication Flow - -Here's the complete flow of how JIT enablement works: - -1. **Device Registration**: - - The iOS Shortcut gets device information - - It sends this to the backend to register the device - - The backend generates and returns a JWT token - -2. **App Selection**: - - User selects which app needs JIT - - The shortcut identifies the app's bundle ID - -3. **JIT Enablement Request**: - - The shortcut sends the bundle ID to the backend - - The backend determines the iOS version - - The backend generates appropriate JIT enablement instructions - -4. **Applying JIT Instructions**: - - The shortcut receives the instructions - - It applies them to the target app - - This includes setting the CS_DEBUGGED flag and configuring memory permissions - -5. **App Launch**: - - The shortcut launches the target app - - The app now has JIT compilation enabled - -## Why This Works Without App Modifications - -This approach works without modifying apps because: - -1. **System-Level Changes**: The changes are made at the process/memory level, not in the app's code -2. **Runtime Modifications**: The modifications happen at runtime, after the app is launched -3. **Transparent Integration**: The app's JIT engine works normally once the memory permissions are properly set - -## Security Considerations - -Our solution maintains security by: - -1. **Authentication**: Using JWT tokens to ensure only authorized devices can request JIT enablement -2. **HTTPS**: Encrypting all communication between the shortcut and backend -3. **Minimal Permissions**: Only modifying the specific permissions needed for JIT -4. **Temporary Changes**: The changes don't persist beyond the app's current session - -## Limitations - -While effective, this approach has some limitations: - -1. **Session-Based**: JIT enablement may need to be reapplied when the app is restarted -2. **iOS Updates**: Apple may change how memory permissions work in future iOS versions -3. **App Compatibility**: Some apps may implement additional security measures that interfere with this approach - -## Comparison to Other Methods - -### vs. Custom App Development -- **Advantage**: No need to modify or rebuild apps -- **Disadvantage**: May be less persistent than built-in solutions - -### vs. Jailbreaking -- **Advantage**: Works on non-jailbroken devices -- **Disadvantage**: Less powerful than full jailbreak solutions - -### vs. Developer Mode -- **Advantage**: Works for sideloaded apps without developer accounts -- **Disadvantage**: Requires more user interaction - -## Technical FAQ - -### Q: Does this violate Apple's security model? -A: This solution works within the constraints of iOS's security model by using legitimate debugging flags and memory permission mechanisms. It doesn't exploit vulnerabilities or bypass security measures. - -### Q: Will this work with all apps? -A: It works with most apps that use standard JIT compilation techniques, including emulators, JavaScript engines, and virtual machines. Some apps with custom security measures may require additional steps. - -### Q: Is this persistent across app restarts? -A: No, the JIT enablement typically needs to be reapplied when the app is restarted. This is a limitation of working within iOS's security model. - -### Q: How does this differ from using a provisioning profile? -A: Provisioning profiles with the dynamic-codesigning entitlement can enable JIT, but they require a paid Apple Developer account and rebuilding the app. Our solution works with existing apps without modification. - -## Conclusion - -Our JIT Enabler solution provides a user-friendly way to enable JIT compilation for iOS apps without requiring code modifications. By leveraging a backend server and an iOS Shortcut, we can toggle memory permissions and set the necessary flags to enable JIT while maintaining security and compatibility with iOS's W^X policy. \ No newline at end of file diff --git a/JIT Backend/README.md b/JIT Backend/README.md deleted file mode 100644 index b3923e7..0000000 --- a/JIT Backend/README.md +++ /dev/null @@ -1,149 +0,0 @@ -# JIT Backend for iOS Apps - -A Flask-based backend for enabling Just-In-Time (JIT) compilation in sideloaded iOS applications. This backend is designed to be deployed on Render.com and provides a secure, scalable solution for enabling JIT without requiring device pairing or provisioning profiles. - -## Features - -- **Secure JIT Enablement**: Enables JIT compilation for iOS apps by toggling memory page permissions to comply with iOS's W^X security policy -- **Device Registration and Authentication**: Secure JWT-based authentication for iOS devices -- **Dropbox Database Integration**: Persistent storage using Dropbox API with automatic token refresh for reliable database access without requiring a traditional database server -- **iOS Version-Specific Strategies**: Different JIT enablement strategies optimized for iOS 15, 16, and 17+ -- **Secure Communication**: HTTPS and token-based authentication to secure all communications -- **Render.com Deployment Ready**: Configured for easy deployment on Render.com -- **Monitoring and Statistics**: Anonymous usage statistics and detailed logging - -## Setup - -1. Install the required dependencies: - ``` - pip install -r requirements.txt - ``` - -2. Run the server: - ``` - python app.py - ``` - -## API Endpoints - -### Authentication - -- `POST /register`: Register a device and get an authentication token - - Request: `{ "udid": "device-udid", "device_name": "iPhone", "ios_version": "17.0", "device_model": "iPhone15,2" }` - - Response: `{ "token": "jwt-token", "message": "Device registered successfully" }` - -### JIT Enablement - -- `POST /enable-jit`: Enable JIT for an application (requires authentication) - - Request: `{ "bundle_id": "com.example.app", "ios_version": "17.0" }` - - Response: `{ "status": "JIT enabled", "session_id": "uuid", "message": "Enabled JIT for 'com.example.app'!", "token": "jit-token", "method": "memory_permission_toggle", "instructions": {...} }` - -### Session Management - -- `GET /session/`: Get the status of a JIT session (requires authentication) - - Response: `{ "status": "completed", "started_at": 1650000000, "completed_at": 1650000010, "bundle_id": "com.example.app", "method": "memory_permission_toggle" }` - -- `GET /device/sessions`: Get all JIT sessions for the authenticated device (requires authentication) - - Response: `{ "sessions": [...] }` - -### Monitoring - -- `GET /health`: Health check endpoint - - Response: `{ "status": "healthy", "timestamp": "2023-04-22T12:00:00", "version": "1.0.0" }` - -- `GET /stats`: Get anonymous statistics about the JIT backend usage - - Response: `{ "total_devices": 10, "active_devices": 5, "total_sessions": 100, "completed_sessions": 90, "failed_sessions": 5, "processing_sessions": 5 }` - -## Deployment - -### Local Development - -1. Install dependencies: - ```bash - pip install -r requirements.txt - ``` - -2. Run the development server: - ```bash - export FLASK_ENV=development - export FLASK_APP=app.py - flask run --host=0.0.0.0 --port=5000 - ``` - -### Docker Deployment - -1. Build the Docker image: - ```bash - docker build -t jit-backend . - ``` - -2. Run the container: - ```bash - docker run -d -p 5000:5000 \ - -e JWT_SECRET_KEY=your_secret_key \ - -e DROPBOX_APP_KEY=your_dropbox_app_key \ - -e DROPBOX_APP_SECRET=your_dropbox_app_secret \ - -e DROPBOX_REFRESH_TOKEN=your_dropbox_refresh_token \ - jit-backend - ``` - -### Render.com Deployment - -1. Fork this repository to your GitHub account - -2. Connect your GitHub repository to Render.com - -3. Create a new Web Service with the following settings: - - Environment: Docker - - Dockerfile Path: `./JIT Backend/Dockerfile` - - Environment Variables: - - `JWT_SECRET_KEY`: (Generate a secure random string) - - `FLASK_ENV`: production - - `DROPBOX_APP_KEY`: Your Dropbox app key - - `DROPBOX_APP_SECRET`: Your Dropbox app secret - - `DROPBOX_REFRESH_TOKEN`: Your Dropbox refresh token - -4. Deploy the service - -## Security Considerations - -- Always use HTTPS in production -- Generate a strong JWT secret key -- Keep your Dropbox credentials secure -- Implement rate limiting in production environments -- Monitor logs for suspicious activity - -## iOS Client Integration - -To integrate with this backend from your iOS app: - -1. Register your device with the backend -2. Store the JWT token securely -3. When JIT is needed, call the `/enable-jit` endpoint -4. Follow the instructions returned by the backend to enable JIT in your app -5. Implement the memory permission toggling based on the instructions - -## Dropbox Database Implementation - -The backend uses Dropbox as a database to store device and session information: - -1. **Automatic Token Refresh**: The system automatically refreshes the Dropbox access token to maintain continuous database connectivity -2. **Thread-Safe Operations**: All database operations are thread-safe using a global lock -3. **Persistent Storage**: Device registrations, JIT sessions, and usage statistics are stored in JSON files on Dropbox -4. **Automatic Cleanup**: A background thread periodically cleans up old sessions to prevent database bloat -5. **Error Handling**: Comprehensive error handling ensures database operations are reliable - -### Database Files - -- `/jit_backend/devices.json`: Stores device registration information -- `/jit_backend/sessions.json`: Stores JIT session data - -## Troubleshooting - -If you encounter issues with JIT enablement: - -1. Check the logs for detailed error messages -2. Verify that your device is properly registered -3. Ensure your JWT token is valid and not expired -4. Confirm that the bundle ID is correct and the app is running on the device -5. Check the Dropbox connection status using the `/health` endpoint diff --git a/MIGRATION_GUIDE.md b/MIGRATION_GUIDE.md deleted file mode 100644 index 5bdaec2..0000000 --- a/MIGRATION_GUIDE.md +++ /dev/null @@ -1,118 +0,0 @@ -# Migration Guide: CodeMagic to GitHub Actions - -This guide explains how to migrate from CodeMagic to GitHub Actions for building the JIT Enabler iOS app. - -## Why Migrate? - -If you're experiencing issues with CodeMagic builds, such as the "Invalid encryption key" error, migrating to GitHub Actions can provide: -- Better integration with your GitHub repository -- More control over the build process -- Potentially lower costs -- Elimination of team-specific encryption key issues - -## Robust Build Approach - -This migration implements a robust build process: -- Multiple build methods (Makefile and script) for reliability -- Proper IPA file structure creation -- IPA verification steps -- No code signing required (builds for simulator) -- No GitHub secrets needed (values hardcoded) -- No TestFlight deployment (artifact only) - -## Migration Steps - -### 1. Add the Build Tools - -The migration includes several build tools: - -1. **Makefile** (`Makefile.ios`): Provides a structured build process with various targets -2. **Build Script** (`scripts/build_ipa.sh`): Offers an alternative build method -3. **GitHub Actions Workflow** (`.github/workflows/ios-app-build.yml`): Orchestrates the build process - -### 2. Remove CodeMagic Configuration - -You can now remove or disable the CodeMagic configuration: - -1. Either delete the `codemagic.yaml` file -2. Or keep it for reference but disable the workflow in the CodeMagic dashboard - -### 3. Trigger Your First Build - -1. Push your changes to GitHub -2. Go to the Actions tab in your repository -3. You should see the "Build iOS App" workflow running -4. Check the logs for any issues - -### 4. Download the Build - -After the workflow completes: -1. Go to the Actions tab in your GitHub repository -2. Click on the completed workflow run -3. Scroll down to the "Artifacts" section -4. Download the "ios-app-build" artifact which contains the IPA file - -## Build Process Details - -### Makefile Targets - -The `Makefile.ios` includes several useful targets: - -- `clean`: Removes build artifacts -- `setup`: Sets up environment variables -- `build-simulator`: Builds the app for iOS simulator -- `create-simulator-ipa`: Creates an IPA from the simulator build -- `build-ipa`: Main target that builds the IPA file -- `info`: Shows build information - -### Build Script - -The `scripts/build_ipa.sh` script: - -1. Builds the app for iOS simulator -2. Creates a proper IPA file structure with Payload directory -3. Adds required metadata -4. Packages everything into an IPA file -5. Verifies the build - -### GitHub Actions Workflow - -The workflow: - -1. Sets up the macOS build environment -2. Tries building with the Makefile -3. Falls back to the build script if needed -4. Verifies the IPA file structure -5. Uploads the build as a GitHub Actions artifact - -## Troubleshooting - -### Build Failures - -If the build fails: -- Check the GitHub Actions logs for specific error messages -- Try building locally using the Makefile or script -- Verify that your Xcode project builds locally without issues -- Ensure all dependencies are correctly specified - -### Simulator Build Limitations - -Note that building for the simulator has some limitations: -- The app will only run on iOS simulators, not real devices -- Some device-specific features may not work in the simulator - -## Future Enhancements - -If you need to deploy to real devices or TestFlight in the future: -1. Set up code signing with certificates and provisioning profiles -2. Configure App Store Connect API access -3. Update the workflow to build for real devices -4. Add TestFlight deployment steps - -## Need Help? - -If you encounter issues during migration: -1. Check the GitHub Actions logs for detailed error messages -2. Try building locally using the provided tools -3. Review Apple's documentation on Xcode builds -4. Consider consulting with an iOS CI/CD specialist if problems persist \ No newline at end of file diff --git a/PR_DESCRIPTION.md b/PR_DESCRIPTION.md deleted file mode 100644 index 8a0fdec..0000000 --- a/PR_DESCRIPTION.md +++ /dev/null @@ -1,41 +0,0 @@ -# Fix iOS App Launch Issues - -## Problems Addressed -1. The iOS app was failing to launch after being built and packaged into an IPA file -2. The app was using keychain storage which can cause permission issues on real devices -3. Device information was not being properly detected on real devices - -## Changes Made - -1. **Replaced Keychain Storage with UserDefaults** - - Removed Security framework dependencies - - Modified KeychainHelper to use UserDefaults for token storage - - This eliminates potential keychain access issues that could prevent app launch - -2. **Fixed Device Information Handling** - - Modified UIDevice extension to return raw device identifiers instead of simulator-friendly names - - Added a separate marketingName property for human-readable device names - - Updated DeviceInfo.current() to use raw device model identifier - -3. **Improved SceneDelegate Window Initialization** - - Added fallback logic to ensure window and root view controller are properly initialized - - This prevents potential nil window issues that could cause app launch failures - -4. **Verified Build Script** - - Confirmed build script preserves Info.plist - - Verified entitlements file is properly included in the IPA - - Ensured UIRequiredDeviceCapabilities is set to "arm64" to match modern iOS devices - -## Testing -These changes have been tested to ensure: -- The app launches properly on real iOS devices -- Device information is correctly reported -- User authentication works without keychain access issues -- App functionality remains intact - -## Technical Details -The root causes were: -1. Keychain access requires specific entitlements and user permissions that might not be granted -2. Device information was being detected using simulator-friendly methods that don't work on real devices -3. Window initialization in SceneDelegate needed additional fallback logic -4. The build script needed to preserve the original Info.plist structure \ No newline at end of file diff --git a/README.md b/README.md deleted file mode 100644 index baf72b1..0000000 --- a/README.md +++ /dev/null @@ -1 +0,0 @@ -l \ No newline at end of file